Sign in to follow this  

Where to put "stuff" in a game engine

This topic is 4305 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

In my game, I have quite a bit of "stuff" that is persistent throughout the scope of the game. For instance, I have character selection models for choosing what character you want to be (these are animated meshes and need to persist throughout player and bot states for instance), game logo for displaying the logo in whatever game state I want, mouse cursors, and various other graphics. Mostly this "stuff" is graphic related. Now where in the game engine is it best to store this stuff? More or less all of this stuff needs to be alive and accessible from the title screen to the end credits. Should I create a class to simply store all this "stuff" or is there a better and more elegant solution?

Share this post


Link to post
Share on other sites
I am not sure how "elegant" my current solution is to this, but right now this works for me..

My framework / engine is in a class and when i want to make a new application i just inherrit from the engine class... All my "global" data i just put in the newly created class...

something like this

class Game : public Engine
{
....
BITMAP *pLogo
CHARACTER *pPlayer;
std::list<CHARACTER*> enemyList;
....
}



I then have a load function that fills all the data...

A more "elegant" way to do this would to run a StateMachine
I bet there are better resources..


Share this post


Link to post
Share on other sites
Right, I have a state machine for all the different states the game can be in. Those states store their own needed data in their class. But I've got all this "persistent stuff" that I only need to load once and have it accessible to all states.

Eh, guess I will create a Persistent class or something and just put the stuff there :)

Any other suggestions are welcome. Thanks.

Share this post


Link to post
Share on other sites
Quote:
Original post by mcguile25
Right, I have a state machine for all the different states the game can be in. Those states store their own needed data in their class. But I've got all this "persistent stuff" that I only need to load once and have it accessible to all states.

Eh, guess I will create a Persistent class or something and just put the stuff there :)

Any other suggestions are welcome. Thanks.

Sounds like you need some kind of ResourcePool - a hash map with filenames as keys and loaded resources as the values usually works well. You can then have multiple pools for various bits (eg. a pool for all persistant resources, and a pool for all per-level resources which gets thrown away at the end of a level).

Share this post


Link to post
Share on other sites
Yeah, sounds like you need a "Resource Manager" or equivilent.

The way mine works, i have an XML config file that maps simple names ("Green Laser") to file names and may also contains some other info about the resource.

Client classes can "check out" these resources fairly easily:

graphic* g = ResourceManager->GetGraphic("Green Laser");

The manager will load and keep this graphic in memory until it is later "checked back in":

ResourceManager->DumpGraphic("Green Laser");

The manager also keeps track of how many "clients" have checked out an identical resource. So if "Titlescreen Background" and "Popup Window Background" turn out to be the exact same image, it's checked out twice with the manager. The memory for the image won't be released until both clients have checked the graphic back in.

This also helps is tracking memory leak problems since you can directly query the resource manager to see which clients have checked out which resources.

I hope that gives you some ideas!

Share this post


Link to post
Share on other sites
On the topic of a resouce manager, I was wounder where would one find more information on how resource managers work. I'm not looking for a direct code or anything, but more along the lines of theory and ideas.

Share this post


Link to post
Share on other sites
A resource manager needs three things:

1) A reference counted resource kind
2) A map from resource handle (typically file path) to loaded instance
3) A smart pointer/handle to the resource, which makes sure the reference count works right

Note that IDirect3DTexture9 can't be the resource class, because you'll need a notification when the last resource reference goes away, so it can be removed from the map.

Typically, in C++, you'll use a Resource base class, a template Resource subclass for the actual instances (texture vs mesh), and a std::map<std::string,Resource *> for the resource manager, if you have a single map. You can also have a map per resource kind, and forego the common base class, being entirely type safe.

Share this post


Link to post
Share on other sites
Well, the resource manager does all the loading and unloading for you.
Do be able to do that, it gives every "stuff" object it manages a unique ID,
the handle, which is usually actually a smart pointer or something similar.

So, when you create a new object in your game engine, it tells the resource manager that it needs a certain piece of resource.
If this piece of resource is already loaded and has a handle, the resource manager simply returns the existing handle, in other words tells your object where the requested resource can be found in memory.
When your object gets destroyed, it tells the resource manager too, as it's resources are no longer needed.

For that purpose, the resource manager implements reference counting - it just keeps track of how many objects depend on a piece of resource, and when no one seems to need that piece anymore, it's unloaded, so the otherwise wasted memory space can be used for new resource pieces requested by new objects.

Points 1 to 3 just tell you something about commom methods of realising a resource manager system in an object oriented language like C++.
If you don't understand what he's saying, try looking for basic object oerientation concepts and design patterns, which form a solid base for dealing with a vast field of problems related with a lot of game programming tasks (and of course non-game programming, too).

Share this post


Link to post
Share on other sites

This topic is 4305 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this