I am programming a 2D game in C++, but my question seems more like a fundamental programming one
So I have created classes for monsters / projectiles / players / etc with children like greenmonster / bullet / rocket / etc for the respective classes and I'm wondering how to go about organizing my data.
For each instance of a class (rocket / bullet) there is unique data for that instance (x, y, directional travel data, etc) , and data always the same for every rocket or bullet (animation data, state info, clipping info from spritesheet, etc).
This constant data I was thinking of storing in files to be read during loadup as it seems the case with most games nowadays. But my concern lies more in storing that data.
Now I could store this constant data in the parent or child class but that would mean for every instance of the child theres another copy of the same data repeated in memory (unless the compiler does cool stuff there). Now thats not a big waste but I considered making a seperate structure for all the const info(such as bulletInfo, rocketInfo, etc) to hold generic animation info, state data, etc. which could be stored globally or in a monstermanager / projectilemanager class to conserve some space.
Still though that method seems strange to me and I feel I might be missing some basic C++ way of linking generic information about a class to an instance without wasting memory on repeated data, and keeping the class self contained (not needing some seperate info structure to reference all the time).
Thoughts and experiences?
storing constant data for a class
You might start by looking into the "static" keyword.
However, let me say up front that you might indeed be better served by going with your gut, and just separating the non-changing/shared data out into a separate class or struct.
However, let me say up front that you might indeed be better served by going with your gut, and just separating the non-changing/shared data out into a separate class or struct.
It's been a while since I've used C++ (so I've forgotten many of it's idioms), and you don't give a lot of details of your program structure. That said, I often have 'helper" objects that contain the data (either loaded in from a file or static & laid out in-code) that is used to build other objects from, or assists during program operation. In your example, I may have a SpriteInfo object that contains a collection of coordinates for each sprite in a sprite sheet. The renderer or sprite manager object can own the SpriteInfo object, and indexes into it during runtime as needed.
This way I have a centralized, or at least predictable, place for this type of data.
Also, if I remember correctly, static initialization of objects can be tricky in C++.
This way I have a centralized, or at least predictable, place for this type of data.
Also, if I remember correctly, static initialization of objects can be tricky in C++.
You're muddling concerns in a couple of ways -- firstly, an entity in the game is just its own personal state, not its image or animation or sound effects. That kind of data should be in a different class and referenced as needed. Secondly, be wary of using subclasses for each entity -- you can certainly subclass in this way, but its also very possible to to create different entity types in a largely data-driven way. Since subclassing tends to be inflexible once its been done, the data driven approach is generally more flexible, requires less code, and could be said to be superior.
An extreme simplification is that you don't need to subclass both a green slime and a red slime, because they probably only differ in color and a few stats.
An extreme simplification is that you don't need to subclass both a green slime and a red slime, because they probably only differ in color and a few stats.
Author
Thanks guys, you've each given me valuable information!
Ravyne, while I understand the point about subclassing, I'm curious why its bad to have the entity own anim/sound/image data vs reference. My guess is easier management of resources with them all consolidated, but I was considering non-referenced as an exercise in trying to make each entity own its personal information (seemingly the whole point to object orientation and why I was resisting the "helper" class idea), although I understand sometimes this is sacrificed in the name of time or space. I can see this being bad for the subclassing issue aswell. Hmm... perhaps I answered my own question on that one, is there more to it than that?
The more I think on that the more terrible it actually sounds. References don't really bother me anyway, vs the helper class idea however which is a seperate structure entirely. I still may go the "helper" route or static after I look into it alittle more though.
Ravyne, while I understand the point about subclassing, I'm curious why its bad to have the entity own anim/sound/image data vs reference. My guess is easier management of resources with them all consolidated, but I was considering non-referenced as an exercise in trying to make each entity own its personal information (seemingly the whole point to object orientation and why I was resisting the "helper" class idea), although I understand sometimes this is sacrificed in the name of time or space. I can see this being bad for the subclassing issue aswell. Hmm... perhaps I answered my own question on that one, is there more to it than that?
The more I think on that the more terrible it actually sounds. References don't really bother me anyway, vs the helper class idea however which is a seperate structure entirely. I still may go the "helper" route or static after I look into it alittle more though.
Media resources like models, textures and audio are comparably *huge* in size, relative to what an entity in the game should be -- An entity should basically be its position in the world and its unique state. a single texture dwarfs the few dozen bytes that ought to comprise your entity -- Of course, the entity references all kinds of "outboard" data, but it doesn't need to be inside the class itself, nor should it. You're talking about generally well under 1K of data for a core entity, but there could be literally megabytes of media resources that form its representation. You certainly don't want to repeat that for every single entity, particularly where those media resources are shared -- such as when there are multiple enemies which have the same appearance. Its just wasteful, by several orders of magnitude.
Author
Yea I realize i was smokin crack there, thanks for the in depth reply! I confuse myself going in circles sometimes.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
