organizing everything visible on screen
-
in a video game you have a ton of different objects, they usually fall into categories: walls, characters/units, buildings, resource type objects (crystals, gold mines etc). the categories behave very differently. My question is how do you keep it all organized? I only have two types of objects and it`s a mess already, and I need to add another type or two. I have been keeping a separate list for each type of object, the exchange of information between types tends to be messy and that will just increase if I add new types.
Without knowing all the details of your problem, it seems like a case where object inheritance can help. Your objects can inherit from a base class, let’s say “entity” and reimplement various polymorphic functions. For instance, each can have a
collidefunction that does different things depending on the specific type of object. On the other hand, all objects have a location on the game map so you might have a functionEntity::location()that returns the position of an object without having to reimplement it. Also, your hierarchy might become more complicated as you find common traits between various classes of objects. You might haveFixedEntitythat describes walls and other things that stay put, andMobileEntityfor players, dragons and what not.Mircea
-
in a video game you have a ton of different objects, they usually fall into categories: walls, characters/units, buildings, resource type objects (crystals, gold mines etc). the categories behave very differently. My question is how do you keep it all organized? I only have two types of objects and it`s a mess already, and I need to add another type or two. I have been keeping a separate list for each type of object, the exchange of information between types tends to be messy and that will just increase if I add new types.
All my objects are the same "game block"; with a "type code". Each type loads a different "image" (with a transparent background) so they all look different. The "game block" can rotate, reverse, fire, etc.; except that certain interactions are disabled depending on the type of block currently selected / active (e.g. the "scout" doesn't have fire power which is handled by giving him "zero" range). I thought of deriving from one "base class", but in the end didn't find it necessary; just the occasional switch statement here and there.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
-
All my objects are the same "game block"; with a "type code". Each type loads a different "image" (with a transparent background) so they all look different. The "game block" can rotate, reverse, fire, etc.; except that certain interactions are disabled depending on the type of block currently selected / active (e.g. the "scout" doesn't have fire power which is handled by giving him "zero" range). I thought of deriving from one "base class", but in the end didn't find it necessary; just the occasional switch statement here and there.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
Quote:
All my objects are the same "game block"
I think I`ve seen that before somewhere. There`s two ways to code what you`re saying. You either have a single class or a struct for all types of objects, in which case you need a field/variable to hold your 'type code' or you can use inheritance in which case each type of object is a class derived from a common base class.
-
Quote:
All my objects are the same "game block"
I think I`ve seen that before somewhere. There`s two ways to code what you`re saying. You either have a single class or a struct for all types of objects, in which case you need a field/variable to hold your 'type code' or you can use inheritance in which case each type of object is a class derived from a common base class.
The problem with using
switchstatements to control behavior is this: when you want to add a new type of block, you have to hunt down everyswitchstatement that requires a newcaselabel. That's why using virtual methods is preferable. You just invoke the virtual method, and each different type of block provides the code that would otherwise have gone with acaselabel. It can sometimes be hard to define the interface for a virtual method. For those situations, you can invoke a virtualtypemethod that returns a block's type, which you can then use in aswitchstatement after all. But if you find yourself doing this often, it can mean that your methods are too big and should be broken into smaller pieces that would make it easier to delegate most of what they do to virtual methods instead. It's annoying to have to define a virtual method and override it in all the necessary places. The "code it now!" approach is to just write aswitchstatement. But in a large program, the time needed to add virtual methods will be more than recovered because the resulting code will be easier to maintain and evolve.Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing. -
The problem with using
switchstatements to control behavior is this: when you want to add a new type of block, you have to hunt down everyswitchstatement that requires a newcaselabel. That's why using virtual methods is preferable. You just invoke the virtual method, and each different type of block provides the code that would otherwise have gone with acaselabel. It can sometimes be hard to define the interface for a virtual method. For those situations, you can invoke a virtualtypemethod that returns a block's type, which you can then use in aswitchstatement after all. But if you find yourself doing this often, it can mean that your methods are too big and should be broken into smaller pieces that would make it easier to delegate most of what they do to virtual methods instead. It's annoying to have to define a virtual method and override it in all the necessary places. The "code it now!" approach is to just write aswitchstatement. But in a large program, the time needed to add virtual methods will be more than recovered because the resulting code will be easier to maintain and evolve.Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing.I almost never use switch - case approach to logical gates (good old if is always there to help)
-
The problem with using
switchstatements to control behavior is this: when you want to add a new type of block, you have to hunt down everyswitchstatement that requires a newcaselabel. That's why using virtual methods is preferable. You just invoke the virtual method, and each different type of block provides the code that would otherwise have gone with acaselabel. It can sometimes be hard to define the interface for a virtual method. For those situations, you can invoke a virtualtypemethod that returns a block's type, which you can then use in aswitchstatement after all. But if you find yourself doing this often, it can mean that your methods are too big and should be broken into smaller pieces that would make it easier to delegate most of what they do to virtual methods instead. It's annoying to have to define a virtual method and override it in all the necessary places. The "code it now!" approach is to just write aswitchstatement. But in a large program, the time needed to add virtual methods will be more than recovered because the resulting code will be easier to maintain and evolve.Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing.You're generalizing about switch without knowing the details. A switch could be implemented via a Dictionary ... Is that more "acceptable"? (In fact, the "game" is primarily driven via dictionary "tables")
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
-
Quote:
All my objects are the same "game block"
I think I`ve seen that before somewhere. There`s two ways to code what you`re saying. You either have a single class or a struct for all types of objects, in which case you need a field/variable to hold your 'type code' or you can use inheritance in which case each type of object is a class derived from a common base class.
That's already been said: inheritance. Choosing a single "game block" versus 20 or 30 (current) subclasses was an easy choice when you don't "personalize" the game pieces. Even an "asset" is simply a game block that doesn't move (even if the potential is there). Where subclassing is useful is when you have a team; and everyone is working on a "character" (versus a set of pieces).
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
-
You're generalizing about switch without knowing the details. A switch could be implemented via a Dictionary ... Is that more "acceptable"? (In fact, the "game" is primarily driven via dictionary "tables")
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
If it didn't mean a switch statement, I think you can see how it was misleading.
Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing. -
The problem with using
switchstatements to control behavior is this: when you want to add a new type of block, you have to hunt down everyswitchstatement that requires a newcaselabel. That's why using virtual methods is preferable. You just invoke the virtual method, and each different type of block provides the code that would otherwise have gone with acaselabel. It can sometimes be hard to define the interface for a virtual method. For those situations, you can invoke a virtualtypemethod that returns a block's type, which you can then use in aswitchstatement after all. But if you find yourself doing this often, it can mean that your methods are too big and should be broken into smaller pieces that would make it easier to delegate most of what they do to virtual methods instead. It's annoying to have to define a virtual method and override it in all the necessary places. The "code it now!" approach is to just write aswitchstatement. But in a large program, the time needed to add virtual methods will be more than recovered because the resulting code will be easier to maintain and evolve.Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing.On a second thought I think I know why this is important. It has to do with events. Making all the classes have a common base type is just half of the problem, all the derived classes end up with loose ends and you need to call(trigger) events in each of them. So that`s the second half of the problem. Thanks for bringing that into attention.
-
That's already been said: inheritance. Choosing a single "game block" versus 20 or 30 (current) subclasses was an easy choice when you don't "personalize" the game pieces. Even an "asset" is simply a game block that doesn't move (even if the potential is there). Where subclassing is useful is when you have a team; and everyone is working on a "character" (versus a set of pieces).
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
Quote:
when you don't "personalize" the game pieces
I think I`ve seen something similar somewhere.
Quote:
That's already been said: inheritance
I`m curious to know, c++ hasn`t been around since forever, how was this problem dealt with in the C days?
-
Quote:
when you don't "personalize" the game pieces
I think I`ve seen something similar somewhere.
Quote:
That's already been said: inheritance
I`m curious to know, c++ hasn`t been around since forever, how was this problem dealt with in the C days?
I used to work in a proprietary language (designed ~1976) that could perhaps be described as Modula (Pascal successor) meets a stripped down Ada. Before it was extended with object-oriented features (~1993), there were parts of our system that were OO-like, done manually. First, there was the concept of an
area: a data structure whose "base class" had to set its fixed size in bytes, but which could then be refined by "subclasses" that added their own data after the fields defined by the base class. Second, we made extensive use of function pointers, which were sometimes grouped into somestructwhose functions could then be "inherited" and "overridden" manually. These structs of function pointers were often registered in an array that was indexed by a type identifier, so you would see code likepolymorphs[type].function(...).Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing. -
Quote:
when you don't "personalize" the game pieces
I think I`ve seen something similar somewhere.
Quote:
That's already been said: inheritance
I`m curious to know, c++ hasn`t been around since forever, how was this problem dealt with in the C days?
I hacked Ultima XX way back when: it was all tables. I find that even with OOP, tables (dictionaries) have their place. VB 6 was component based; sort of like dependency injection; a pattern often overlooked. For my game blocks that have a "line of sight", I inject (attach) a line of sight control that can show in the UI. Tables, components and (yes) I have some "adapters" that are descended from a base class, including virtual methods (different historical versions of various tables); so, it all "depends" and reworking is part of the path as the "mental model" evolves. P.S. You also need to think about the best / easiest way to save the whole "game state" and restore it at some point. Then we get into "programming" scenarios / map points, etc.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
-
Quote:
when you don't "personalize" the game pieces
I think I`ve seen something similar somewhere.
Quote:
That's already been said: inheritance
I`m curious to know, c++ hasn`t been around since forever, how was this problem dealt with in the C days?
Calin Cali wrote:
I`m curious to know, c++ hasn`t been around since forever, how was this problem dealt with in the C days?
Even the original 1970 Pascal provided a simple polymorphism, through "variant records". In my first university level programming class, in 1977, the professor made some requirements not mandated by the language: All data shall be put into Pascal RECORD variables - or class instances, if you like - representing a set of related property values. All functions/procedures shall take a RECORD instance as its first parameter (although the formal parameter could be named anything descriptive, not just 'this'). Functions/procedures taking a RECORD type R as its first parameter shall be the only ones to modify an R record, and only the instance supplied as first parameter. The RECORD type declaration shall be followed by all the functions/procedures taking this record type as first parameter. If one object type is a special case of another one, embed the general RECORD type as the first field in the larger RECORD. For simpler subtype cases, we could use the variant record mechanism. When C++ arrived 8 years later, we changed 'RECORD' to 'class', moved the closing brace down to after the function declarations, changed 'operation(object, ...' to 'object.operation(...' and changed uses 'object.field' to 'this.field' (or only 'field'). Where subclassing and inheritance was used, the first field type name was moved to a parent class reference in the class definition and the name of the parent class field deleted (e.g. from MyBus.Vehicle.Numberplate to MyBus.Numberplate.) There really wasn't that much change in the programming style, mostly rather minor syntax adjustments. Obviously, our OO style of plain Pascal programming didn't provide all the mechanisms of today's C++ (nor did the first C++!). No abstract classes, no overloading, ... But we did have multiple inheritance! :-) (Another but not OO-related requirement this professor made: In any function / routine / method parameter list, the read only input parameters come first, out parameters and references that are modified comes last. To this day, when I see code breaking this rule, I find it terribly confusing and want to edit the order, regardless of who owns the code!) We never called it 'object oriented' in those days. Nor did those programming the first OS I had source code access to, programmed in a near-assembler-level language in
-
I hacked Ultima XX way back when: it was all tables. I find that even with OOP, tables (dictionaries) have their place. VB 6 was component based; sort of like dependency injection; a pattern often overlooked. For my game blocks that have a "line of sight", I inject (attach) a line of sight control that can show in the UI. Tables, components and (yes) I have some "adapters" that are descended from a base class, including virtual methods (different historical versions of various tables); so, it all "depends" and reworking is part of the path as the "mental model" evolves. P.S. You also need to think about the best / easiest way to save the whole "game state" and restore it at some point. Then we get into "programming" scenarios / map points, etc.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
Gerry Schmitz wrote:
I hacked Ultima XX way back when: it was all tables. I find that even with OOP, tables (dictionaries) have their place.
In my student days as a TA in the introductory programming course, half of the University departments insisted on sticking to Fortran ("we are doing engineering!!"), the other half had modernized to Pascal. Except for the language, the subjects taught was the same - except for one hand-in: In the Pascal group, the problem required the use of a linked list. There was this (very cute) female chemistry student - her department insisted on Fortran - who got a little crossed: Why can't we learn the same stuff as they do in those other departments? So I explained that Fortran had no pointer mechanism, where one variable would tell where another value was located. She got very curious, so I had to go into more details of the mechanism, with a heap that could be seen as a huge array, and a pointer serving as an index into it. (They had been working a lot with arrays at this time.) One week later this girl was back: She had gotten hold of the Pascal exercise, and solved it in Fortran in the way I had explained, with an array and using another variable as an index into the array. The solution gave the expected result, but she would be happy if I could take a look at it to see if she had done it the right way ...
-
in a video game you have a ton of different objects, they usually fall into categories: walls, characters/units, buildings, resource type objects (crystals, gold mines etc). the categories behave very differently. My question is how do you keep it all organized? I only have two types of objects and it`s a mess already, and I need to add another type or two. I have been keeping a separate list for each type of object, the exchange of information between types tends to be messy and that will just increase if I add new types.
Going by your question, "My question is how do you keep it all organized?": Organization should start with what is most important. Then to what is next important. And so on. That is it. All that answers your question about organization. For this to work: Make each of these work. Include error checking to each before moving to the next. Test them each before moving on to the next. Use switch or if then or whatever code is easiest for you (your personal self) to use and follow later. It is not so complicated. Just do as I said, one at a time. Take your time. Do not get into a hurry. Do not take short-cuts. Make *your* code readable to *you*. If you write most of it with simple if-then-else and if that is most comfortable to you, then that is how it should be coded. Thank you for asking. Here is an example. If you have a character moving in a scene with walls and background, then this all has to be rendered to some output. Remember this is just an example. First create or load or put together the background. Then effects to the background, like lightning or explosions. Then the walls. Then effects to the walls like splatter eminating from bullet hits etc. Then the stationary items in the space like blocks or resources etc. which are upstaging the character. Then effects to those stationary items. Then movable items or characters that are upstaging the character. Then effects to those particular movable items. Then the character. Then effects to that particular character. Then do similar to that which is down stage of the character. Upstage is further away from you than the character. Downstage is closer to you than the character. Now that I have answered your question as it was asked, I feel like I might now get into other things. The following might be tangental to the question, but I at least answered the question first. If you are doing this in Microsoft Windows and if you are blitting the images (still or virtually moving), then you might want to use 2 or three or many more buffers, blitting to each buffer as you go from the furtherest away from you to the buffer that is closest to you. Put all of these together and blit to the screen buffer. Then put the screen buffer to the screen. If you have 5 buffers and the background is buffer_5 then when you have buffer_4 complete, add buffer_4 to buffer_5 and save it as buffer_4. This can be done by starting buffer_4 as a solid color (example RGB
-
All my objects are the same "game block"; with a "type code". Each type loads a different "image" (with a transparent background) so they all look different. The "game block" can rotate, reverse, fire, etc.; except that certain interactions are disabled depending on the type of block currently selected / active (e.g. the "scout" doesn't have fire power which is handled by giving him "zero" range). I thought of deriving from one "base class", but in the end didn't find it necessary; just the occasional switch statement here and there.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
There are a few ways to organize everything on your screen. One way is to use the built-in organizational tools that your operating system provides. For example, on a Mac you can use Spaces to create different "areas" on your screen to keep things separate.
Another way to organize your screen is to use third-party apps. There are a number of these available, and they can be very helpful in keeping your screen organized and tidy.
-
Without knowing all the details of your problem, it seems like a case where object inheritance can help. Your objects can inherit from a base class, let’s say “entity” and reimplement various polymorphic functions. For instance, each can have a
collidefunction that does different things depending on the specific type of object. On the other hand, all objects have a location on the game map so you might have a functionEntity::location()that returns the position of an object without having to reimplement it. Also, your hierarchy might become more complicated as you find common traits between various classes of objects. You might haveFixedEntitythat describes walls and other things that stay put, andMobileEntityfor players, dragons and what not.Mircea
How should I Organise my homescreen? It's easy to create a folder by dropping one app on top of another. Put the first two apps you want to include on your homescreen. Long-press one and move it on top of another,Dubai website design Android may give your folder a name. ... Add more apps to a folder by long-pressing on the app and moving it into the folder.
