In the classes or objects they represent.
In a part of the program specialized in dealing with graphics.
It's not worth worrying about.
It is worth worrying about, but it all depends.
This is just a stylistic question, not a technical one. Should sprites be contained in the classes/objects they represent, or should they be off in a very different part of the program that focuses quite solely on graphics? In the latter case, the graphical part of the program would just look through the game state or whatever and keep transforming/translating the same sprites and drawing them wherever appropriate.
A poll is set up here, but explanations would also be appreciated. Thanks!
It depends on what design pattern you are using. What you are describing sounds an awful lot like a very popular pattern called Model-View-Controller. Essentially, the program is split into 3 parts:
The model handles all the logic (game-logic in this case), this is where you put your game-objects (entities, npcs, ammo, whatever).
The view handles the rendering of the game, this is where you have your sprites and your GL-code or whatever, the view does this by querying the model for the data (Where on the screen is the player, ie coordinates and size and stuff like that.)
The controller handles your player input, it changes the model whenever the player presses an arrow key or a mouse or whatnot.
MVC is an extremely popular way of structuring your code, and it's uses go well beyond game programming. There are many other design patterns that are just as potent, which one you pick is important, but what is more important is that you stick with it throughout the entire development phase. Some other popular patterns include the Observer Pattern and the Factory Pattern.
A few years ago when i started writing small games in C++, i just piled everything together into the model without giving it much thought. Whenever a project of mine reached a few thousand lines of code, it would be so hopelessly messy and ugly that i would just give up and start over, again, without thinking about the design before i started coding.
It would be prudent to spend a large amount of time thinking about the design and the pattern before writing a single line of code, it really makes things easier down the line. Another thing that has helped me get better at organizing my code is CRC cards, it's a mental excersize that helps you plan what classes you want and what functions each of these classes should have, before writing any code, there should be plenty of info on these @ google.
How I need a drink, alcoholic in nature, after the heavy lectures involving quantum mechanics.
Here is how I would do it:
Texture
TextureManager --> TextureID, Texture
Animation --> vector<TextureID> (in order)
AnimationMgr --> AnimID, Animation
Sprite --> vector<AnimID> called tracks
SpriteMgr --> SpriteID, Sprite
So animations are iterations over textureIDs. More than one animation can reference the same texture more than once and at the same time. The animation manager allows animations to be shared across multiple sprites. A sprite is a colelction of Animation IDs which map into the AnimationMgr so multiple sprites could share and use the same animation at the same time. The sprite manager allows sprites to be instanced so that the sprite is loaded once but used many times. Since timing information is in the sprites this means that 1 sprite could be instanced many many times and yet would not play at the same time as other sprites of its type. Each sprite can have one or more 'tracks' of animations which makes sprite usage efficient.
The systems that handle memory are the managers. No memory is allocated and thus cleaned up at the object level.
The idea behind this is to make iteration of frames as fast as possible while also limiting memory usage. Because the textures are shared and only accessed by ID's by other classes this allows a central place to track texture usage as well as memory usage be it video memory or system memory.
But again...this is how I would do it and you certainly do not have to follow it.
Whatever you do make sure you put the timing information at the Sprite level and not the animation itself. This may seem counterintuitive but it is not. If you put timing information in the animation then every Sprite that uses that animation will be identical to one another when they are rendered.
Last edited by VirtualAce; 02-10-2012 at 08:59 PM.
Both.
There is no reason not to put control over resources where they best belong. In the case of sprites, or textures, that is almost certainly a "GraphicResourceManager" of some kind.
There is no reason not to put control over resource components, such as what a thing looks like, with the thing those components represent. In the case of a sprite, this is probably a "Billboard", "PC", or "NPC" class of some kind.
If the thing acts as a client of the various resource controllers you can develop utilities to control both the thing and the resources without convoluted schemes or infecting one component with the facilities that the other component needs. For example, the "AnimationResourceManager" doesn't need to know what "North Facing Walk Animation" means and "PlayerCharacter" doesn't need to know how to load a "PNG" into video memory.
Soma
I have:
Graphics superclass (Draw, refresh, printtext, etc.)
GameObject superclass (Sprites, primitives, etc.)
Input superclass (Key/Mouse presses)
Event superclass (Contains flags, contains code to execute when flags are toggled on/off)
