Thread: Sprite animation system design

Should the engine maintain the collection of animation objects or should I leave this up to the client?

O_o

Do you have an engine that is content aware? (Does the engine "lease" objects from a factory based on named content? Or is the client responsible for giving the engine everything it needs?)

Do you have an engine that streams content? (Does the engine request new objects "automagically" from a factory based on what resources a "scene" needs as it is experienced? Or is the client responsible for telling the engine when to load more content?)

Do you have an engine that caches resources at the appropriate place based on the used resources? (Does the engine make decisions about where, as in hardware or software, to put content? Or is the client responsible for caching any content?)

Do you expose an interface such that `Animation' is unaware of these things? (Are the engine bits from above transparent? Or do they require client notification/interaction?)

I only ask because, odds are, you'll need something of the same nature as the "middleware" level `Sprite::AddTrack' to handle any of the above situations in a reasonable fashion, and more to the point of the question, if you plan on doing the above stuff well it doesn't matter which one you start with because you will ultimately provide a means of allowing a client to take control of some decisions from the engine.

Simply put, if you don't provide reasonable defaults, your engine is underpowered, and if your engine doesn't allow an interested client to take control of specific aspects your engine is restrictive.

If you aren't planning on doing any of the above, you have the option of pursuing a very "bare bones" style engine which almost by definition means the engine doesn't own anything so the only real choice is putting the client in control.

The less memory the engine manages the better in my book.

Okay.

So, the question is, why do you think that? Are you trying to provide only the essentials?

(Making wise decisions about where to stick resource, when to cache them, when to expire them, and when to move them from one area to another depends on enough information that you'll need to provide a callback for streaming this information to the client.)

You've implied that the engine is already aware of textures, sprites, and animations.

You also implied that textures at least are owned by the engine.

Are sprites any less of an engine resource? If sprites are an engine resource, how are animations any less of a resource?

Really though, this may be, and probably is, a simple case of "You don't have enough separation between resource management and the game engine.". The engine has no business knowing how to fetch a sprite, an animation, or even a texture. The resource manager has no business knowing when these things should be created, cached, expired, or even where to put them when they are cached.

If you do that properly, you can get far along both options with relative ease by altering the flow of resources.

With this flow in mind, the client, of the library, shouldn't invoke a `Sprite::AddTrack' interface with an `Animation'. Ever. The `Animation' object should have already been added to a pool of resources. (This can be done via a "lease" such that the client owns the object. Who owns the object and so is responsible for its deletion is thus irrelevant.) The sprite, and every other type or resource that combines other resources, can behave with respect to the pool in the exact same way. The client is also then allowed to treat every resource with respect to the pool in the exact same way. All clients, the library client and other engine code, of the pool registers a given resource to the pool and requests them by identifier.

At that point, both "middleware" level functions are trivially simple to code as they do the exact same job with almost the exact same consequences. It is, in fact, such a trivial matter that it isn't worth having them at all because the "sameness" breeds familiarity with the core functionality.

So, my advice, based on what you've asked, is to provide neither functionality in one function. Make registering a client owned object with the resource manager (or engine proper) simple. Make associating an animation resource with a sprite simple by always requiring the resource identifier so no "fetch" type operations is necessary.

If you are feeling forgiving, you can make registering a factory instance with the resource manager (or engine proper) easy so that resources can be created "on the fly" without explicit client instructions. In this way, even if the `Animation' resource doesn't already live in the pool the resource manager will attempt to create one that it will own because the client didn't care to own that particular object.

Soma

Do you have an engine that is content aware? (Does the engine "lease" objects from a factory based on named content? Or is the client responsible for giving the engine everything it needs?)

Neither. An editor outputs a level data file that contains all content to be loaded. Neither the game nor the engine ask for content to be loaded or know about the content at startup. It is all data driven.

Do you have an engine that streams content? (Does the engine request new objects "automagically" from a factory based on what resources a "scene" needs as it is experienced? Or is the client responsible for telling the engine when to load more content?)

The engine does not stream content. It does not create new objects internally. The loader reads the data file and creates new assets and adds them to the engine. This memory is managed by the engine and is cleaned up at shutdown. The loader can be overloaded via a callback that the client can use to load custom content.

Do you expose an interface such that `Animation' is unaware of these things? (Are the engine bits from above transparent? Or do they require client notification/interaction?)

The animations are not engine aware. The animations are not graphics aware. The animations are sequences of frames which are composed of a texture ID and rectangle information. No other information is present in animation frames. The sprite class does offer a SpriteListener class that supports client notifications of important Sprite-based events such as starting, stopping, looping, completed, etc.

I only ask because, odds are, you'll need something of the same nature as the "middleware" level `Sprite::AddTrack' to handle any of the above situations in a reasonable fashion, and more to the point of the question, if you plan on doing the above stuff well it doesn't matter which one you start with because you will ultimately provide a means of allowing a client to take control of some decisions from the engine.

The engine 'sprites' are only accessible via a plugin DLL that plugs into a renderable object. This plugin accesses the underlying sprite objects but never exposes it beyond itself. The game is not engine sprite aware but rather plugin sprite aware. The client cannot ask the sprite to do anything that the plugin interface does not expose or allow.

If you aren't planning on doing any of the above, you have the option of pursuing a very "bare bones" style engine which almost by definition means the engine doesn't own anything so the only real choice is putting the client in control.

This is the direction I am leaning for the entire system.

O_o

It seems to be that you have a confused design without a belief of your ultimate goals.

Neither.

"Neither" is not an option. "It is all data driven." is meaningless in this context.

You've simply not answered the question.

To put it in your terms, who is responsible for "loading" the "level data" for new scenes as one scene transitions into another?

The engine does not stream content.

I believe this to be a mistake. The engine usually has a more elaborate and sophisticated understanding of the host environment and resources, virtual and real, consumed.

You must, at the very least, export an API yielding enough information that a client can do an intelligent job of it.

The loader reads the data file and creates new assets and adds them to the engine.

Yes. Okay. Now, who is responsible for telling the loader to read the data file and create new assets in response to live events?

When level one is completed, when Mario drops the flag, who is responsible invoking the loader with the "level2.zip"? Alternatively, if you don't support levels and everything is a unified layout, who is responsible for unloading "Upper_Crust" textures and loading "Hell_Pit" textures? Does the engine manage these transitions? Are there, perhaps, triggers in the level data created by your editor? Or is the client responsible for saying "You don't need those textures in video ram anymore; use these other textures instead!"?

This memory is managed by the engine and is cleaned up at shutdown.

If your engine already manages resources, from a loader and level pack or from anything else, there is no reason to distinguish between resources. It will only be confusing to a client. Why design an engine so that `SpriteAnimation' is a resource the engine doesn't own when `Texture' and `Sprite' are owned by the engine? That's just gagging for technical support entry and your not even done.

The animations are not engine aware.

I always find it useful to make abstraction agnostic, but you are saying that engine is aware of animations as both a resource and a facility so again, why would they be a resource the engine doesn't own?

The sprite class does offer a SpriteListener class that supports client notifications of important Sprite-based events such as starting, stopping, looping, completed, etc.

This leads me to think that you are fibbing about your goal, but it could go either way so I'll just ask.

Is `SpriteListener' an object managed by the client and queried, or notified by callback, by the engine? Does the engine simply report input so that the client can say "This sprite should be displayed with a walking animation!" to the engine?

Or is `SpriteListener' an object managed by the engine and queried, or notified by callback, by the client? Does the engine understand actor movement, possibly via scripts loaded into a VM by your level loader, such that the client doesn't have to tell the engine what to do with events?

The game is not engine sprite aware but rather plugin sprite aware. The client cannot ask the sprite to do anything that the plugin interface does not expose or allow.

Yes. You have an abstraction over resources. I assumed.

My question isn't "Can the client ask a sprite to do something?". My question is "Does the engine know how to ask a sprite to do something?". It doesn't matter, as again, if the engine has a cooperative relationship with a VM or anything else that may be "data driven" as tied to a level pack of some kind. I'm not asking if the engine knows about animations either as you've already said that. Does the engine "know" when to play an animation by context? Or must it be explicitly told by the client code?

This is the direction I am leaning for the entire system.

Fine. There is nothing wrong with "bare bones" systems.

Based on what you've said though, you don't have that or even really want it.

*shrug*

But then, based on what you've said you want a sophisticated an engine as is possible without the engine to growing unmanageable.

Soma

To put it in your terms, who is responsible for "loading" the "level data" for new scenes as one scene transitions into another?

Clearly answered this already. Data comes from file resources which load other file resources. Who do you think is responsible for loading the data if the engine does not know about the files???
The only system I know of that I have worked with that is data file aware is Unity where it auto loads all data within specified folders which allows you to alter the data files for new games. Other systems appear to provide loading capability but do not auto-assume where or when to load the data. The client alone is responsible for utilizing the loading functionality when and where they want. I prefer this type of system.

I believe this to be a mistake. The engine usually has a more elaborate and sophisticated understanding of the host environment and resources, virtual and real, consumed.
You must, at the very least, export an API yielding enough information that a client can do an intelligent job of it.

Explain what you mean when you say 'stream content' since that is quite vague in itself. Perhaps this is a simple issue of semantics.

Yes. Okay. Now, who is responsible for telling the loader to read the data file and create new assets in response to live events?

Clearly answered. The client.

If your engine already manages resources, from a loader and level pack or from anything else, there is no reason to distinguish between resources. It will only be confusing to a client. Why design an engine so that `SpriteAnimation' is a resource the engine doesn't own when `Texture' and `Sprite' are owned by the engine?

Clearly answered. There are only a few resources that any engine must absolutely own in any given environment. It can choose to take control of more but I prefer not to take this approach. You can either take the approach that the system provides functionality that clients can create on their side and use...and be responsible for or you can take the approach that the engine handles it all. The second approach leads to numerous factories inside of the engine as the engine factories out various resources. The approach I am taking is there are a set number and type of resources the engine will handle and the rest is up to the client. As long as this is clearly documented I see no issue with a partial management of resources. I have seen it done both ways in various systems and I prefer less in the engine and more in the client. In my experience this appears to give the client more flexibility in working with the engine as a whole. There are several systems out there that provide structures and classes to be used by clients with the caveat that the management of said objects is left to the client. There are other systems that take an all or nothing approach in which all resources are managed by the engine and there are others that managed certain specific resources and leave the rest to the client.

Keep in mind my engine is NOT platform agnostic. I do not have a layer below the graphics portion that handles I/O, memory, etc. via interfaces and impls for various platforms. I did not design the system down to this level and do not plan on it any time soon.

I always find it useful to make abstraction agnostic, but you are saying that engine is aware of animations as both a resource and a facility so again, why would they be a resource the engine doesn't own?

The engine is not animation aware. The engine never calls into any animation interfaces and is not aware of them. By the 'engine' I mean the core rendering. By aware I mean when Render() and Update() are called the engine doesn't know if its object A or object X and does not care if object A is of type T or type T2. I am saying should the engine be aware of animations as a resource....b/c currently it is not.

Is `SpriteListener' an object managed by the client and queried, or notified by callback, by the engine? Does the engine simply report input so that the client can say "This sprite should be displayed with a walking animation!" to the engine?

Or is `SpriteListener' an object managed by the engine and queried, or notified by callback, by the client? Does the engine understand actor movement, possibly via scripts loaded into a VM by your level loader, such that the client doesn't have to tell the engine what to do with events?

SpriteListener is created and managed by the client and is purely optional to the Sprite. SpriteListener is called from the Sprite class when certain events occur within the sprite. Scripts are not yet implemented in the current version but will be handled via Lua scripts. However the engine will still not be aware of actor movement other than it will see more AABBs to test for collisions. But the engine will never know that object A moved from point P1 to P2. It doesn't care. The client can create whatever abstractions they want to manage this. Sprites do not move unless told to do so by the client or by scripts (not yet implemented).

Or must it be explicitly told by the client code?

In its current state it must be told. I plan on creating an event system to handle this to ease the burden on the client and later it will all be handled through Lua scripts. The new system is not mature and I'm still pondering some of the design for this. I have done this multiple ways both for hobby and professional code and I'm mulling around in my mind which approach I think is the best. Ultimately I believe it will be a hybrid approach. I am being intentionally vague here.

Based on what you've said though, you don't have that or even really want it.

*shrug*

But then, based on what you've said you want a sophisticated an engine as is possible without the engine to growing unmanageable.

I think you summed up my post great there. Truth is I am in the design phase for this so I'm looking at all options. Based on what I have written and what we have talked about it is clear that my system is bare bones at this time. Part of the reason for that is I am the only developer on my engine so I can really only tackle issues that are achievable with 1 developer....which forces me to take a hands off approach. If I had a team of 4 or 5 people I could delegate out various systems all the while working on the overall integration and collaboration between the systems and would come out with a much easier to use and more robust engine. I simply do not have that luxury at this time.