next »

[relay01]

So I've been pondering the line where code meets game resources and have been wondering what is a better idea.

Say we have several high to lower level game resources like sprites, sounds, levels, player(s), menus, etc. implemented in code and now we just have to all have them work together to form what we would consider a game.

Idea 1:
It can only be assumed that things like sprites and sounds may be tied to a higher level classes like level and player.

Each high level may have its own lower level data types.

This would make the programmer have to implement resource management for every higher level class.

So basically in this scheme, each higher level class would manage their own resources. For instance Level handles their sprites, sounds, and music - Player handles it's own sprites, sounds, and music.

Idea 2:
Rather then having some of the higher level classes like level and player manage their own resources, we implement an even higher level class that manages all resources like say "GameHandler" that each lower level class only contains routines used to make modifications to the game data.

In this scheme, Level just worries about doing it's own level stuff, and it's up to a higher GameHandler to worry about the resourses associated with it.

I'm not sure if this makes sense, its kindof hard to describe I guess.

Basically I'm asking, what do you think the best way of managing game resources is?

What are the pros and cons as they pertain to game speed and code maintainability, or readability.

[TheLastBanana]

I've been using a bit of a mix of the two - I've got low-level objects like Sprites, Entities, Sounds, etc.  Each of these types has an upper "controller" class that calls the update functions of each of the objects that fall under its category each frame.  Within there, though, each object deals with its own resources.  For instance, an Entity has to tell its Sprite to animate before rendering.
I can say it's definitely not the fastest method, but if you do it right it can be a little easier to organize in some ways.  On the other hand, if you don't keep track of where everything is grabbing its information, you can get some serious spaghetti code.  I'm fairly new to C++ so this is probably totally the wrong way to do it, so I'm a bit interested to see what other methods people use.

[Snakey]

I use a component architecture for this sort of thing. Usually everything in my game is considered to be an Actor. Actors can have any number of components that they want.

When it comes to rendering, I iterate through all the relevant actors (relevancy is up to you to decide) then I iterate through all of the actor's components and render renderable components.

Now, to bridge the gaps between this idea and things like controlling the player, regard the player as simply a bridge between a user and an actor in the game. When the user inputs anything, he tells the bridge (controller) about it, then the controller tells it's actor about it. [This is similar to Unreal Engine].

Now, to make it relevant to you, levels can be composed of actors. Actors can also represent the enemies, projectiles and many other things you want in the game.

In terms of handling resources like textures, sounds, etc, I tend to use a manager object for that.