Hi all,

I'm attempting a game using a similar architecture found in the GCC book. I have a GameLogic class and View class. The logic contains the rules for updating the game universe whilst the view is a visual representation of the game world.

The logic notifies the view of any updates it may be interested in via an event manager.

One such event is the 'EventEntityCreate' which describes how the new entity should be displayed. Obviously sprites can either be a single, static frame or an animated sequence of frames. I'm not sure how best to embed this information in the event. I'm struggling to come up with an appropriate object that can represent this information. Maybe a static sprite and animated sprite are too different to be represented by a single object?

Dubiously named class attempts include "SpriteData", "SpriteFrames" etc. The data needed to describe an animation also includes fps, whether the animation loops or not etc, which don't make sense to be present for a static sprite.

Any advice on how you would tackle this would be much appreciated.

Couldn't a static sprite be represented as an animation with a single frame? With that in mind, create an object that can hold your list of sprites, and the duration each sprite should be shown before moving to the next sprite. For a static sprite the list would be 1 long, and the duration would be unimportant.

Although, I'm not sure that's what you really should send to an view, since you really should just give the view the sprites it needs to display NOW, which would be the proper sprite at it's current animation state, but I can't really say that since I'm not familiar with your framework.

Good luck!

Separate the concepts of sprites and animations.

The scene data structure used by the renderer need only know about sprites: the object's transform, a texture handle, and UVs into that texture.

The animation system then separately tracks the available animations, currently selected animation for a game object, and a timer for the game object. It would also contain a handle to the sprite instance for each game object. Whenever the animation system determines that it's time to flip to a new frame, it updates the sprite instance to use the new texture or UVs. The renderer then just "magically" renders with the new sprite frame, all without any knowledge that animations even exist.

If you have a 2D skeletal animation, it gets a little bit more complex... but if you follow the same approach, it doesn't get all that much more complex. The graphics system doesn't need to know about skeletons. All it needs to know about are transforms. The graphics system has no reason to care whether things are changing because of animations or because of physics or because of game logic or whatever. Graphics consumes changes fed to it by the other systems.

Loosely speaking, in the model-view-controller paradigm - which you seem to be leaning towards - the renderer is a view, the scene data structure is a model, and the animation system is a controller.

Thanks for the advice chaps.

Separate the concepts of sprites and animations.

I've coded up a prototype in this vein and it definitely looks like the way to go. My sprites are now completely dumb, whilst all animations are managed by a dedicated animation system. This will allow me to do more complex things like chain animations together, cancel running animations etc, so cheers for that!

Thanks for the advice chaps.

Separate the concepts of sprites and animations.

I've coded up a prototype in this vein and it definitely looks like the way to go. My sprites are now completely dumb, whilst all animations are managed by a dedicated animation system. This will allow me to do more complex things like chain animations together, cancel running animations etc, so cheers for that!

Probably one of the most effective things to learn for game development is to think of the different aspects of a game as being independant. In theory your game should be able to "play" without ever displaying anything, without ever playing sound, any of that. The moment you start making game logic rely on visuals is when things start getting taped together into a spider web. It also makes it much more difficult to change things.

In a way you can kind of think as visuals as a sort of peripheral, like you should be able to "unhook" them and even swap them out for some other pieces easily. You can technically think of it like model-view-controller but in reality it is more a design facet that the seperate systems of the game don't have much reason to be physically glued together, if anything they should just process relevant information.