Resource Management

yeh, made me think.
this way you use the same function to destroy anything in the game, but as i see it, you still need to create them in different ways.
sounds really good. i usually separate my media, but yeh you are right all professional games do what you are proposing, i can recall.
you could actually make it a single call to destroy the whole game at once.
theres probably upteenth advantages to doing it that way, the full object oriented job.

That looks like a typical resource manager.

However, what is the reason for keeping music and textures in the same list? If you have a resource manager (or at least a list) for each type of resource, then that makes it so much simpler.

Also, consider using a map instead of a list. It would be a lot easier to implement than a cache, and it would probably be faster , too.

How would you implement a map? I haven’t used that data structure yet, sorry. I need a good solid framework that I can base many applications off of. Most people would say that different applications require different frameworks. I disagree because I think that one framework could suffice if you extended it or tailored it to your needs. Just take a look at Win32. Usually every one seems to incorporate that framework into their applications just fine.

Any ways, the engine is for tile based games. There will be many different types of entities in the game. There is no way of telling how much I will need because of the different types of maps. Some entities may use projectiles. So then a resource manager is needed to manage the entities. And if I’m going to use a resource manager for entities, why not use one for everything else (images, sound, music)?

One question I’ve been wondering; should I contain the resource manager in a separate module (DLL) or compiled with the actual executable? I also wanted to keep the logic for the entities in an external module. If I keep things external, then I could modify them and the entire game would be modified as well. So then I can just keep the core framework in the application and leave everything else in DLLs. I think this would be a good idea because I wouldn’t have to recompile the EXE every time I make a change to the AI. I would only have to recompile that DLL then reload the application to see the effects of my modifications. Good practice, yes?

I will probably have to make my own tools for this game; like map editors, texture and sound compilers. I want to use my own image and sound formats to better suite the application, not somebody else standard. I also need an archive format. This is pretty easy because there is a ton of formats already out there that could be modified.

So back on topic, I need a good sturdy resource manager. It has to be fast, very fast. When I ask for something, either to be created or retrieved from a list I need it now! So I need an algorithm that is capable of handling many different types of data and able to retrieve them at a decent speed. I’m going to research on this map data structure to see what it can offer me.

By "map", I meant "std::map", which assumes you are using C++. The generic term is "associative array".

Resource Manager: A resource manager is essentially a memory manager. This is true because of the simple fact that all resources require memory. A base resource class must be designed that provides the basic management necessities. The resource objects need to be tracked to prevent memory leaks. This can be done by an internal reference mechanism that will automatically delete its self if the object is not being used any more. This is my solution.

// Resource object interface
//
class IResourceObject
{
private:

std::list<IResourceObject>::iterator _this;
LONG m_lRefCount;

public:

IResourceObject( void );
virtual ~IResourceObject( void );

LONG __stdcall AddRef( void );

LONG __stdcall Delete( void );
};

// Resource object implementation
//
std::list<IResourceObject> g_rcsrcManager;

IResourceObject::IResourceObject( void )
{
m_lRefCount = 0;

g_rcsrcManager.push_back( *this );

_this = g_rcsrcManager.back( );
}

IResouceObject::~IResourceObject( void )
{
Delete( );
}

LONG __stdcall IResourceManager::AddRef( void )
{
return ( ++m_lRefCount );
}

LONG __stdcall IResourceManager::Delete( void )
{
--m_lRefCount;

if ( m_lRefCount == 0 )
{
g_rcsrcManager.remove( _this );

return ( 0 );
}

return ( m_lRefCount );
}

The reference count and iterator are made private so child classes may not access them directly. The AddRef() and Delete() methods have the only access to these variables because they are crucial to the memory management system. All call to g_rcsrcManager.clear() at the end of the application should ensure that the resources are freed. Every time a resource is created the base class (IResourceObject) constructor is called and the object is appended to the end of a list.

Now the resources of my application are managed. This best part of this is I can create an object just like I would normally any other object and the resource manager will handle the rest for me.

Any questions or comments?

Hmm... Well I think its a good idea.