Game media and TMaps

How do people manage their game resources?
I was thinking of using a TMap loaded from an external file (maybe .xml).
Anybody doing something similar?
What problems might there be doing that?
It might be considered overkill but I could soon be using hundreds of sounds, songs and images so a 'Resource Controller' seems like a good idea.
What do you think?

I'm using TMaps for my media handling as well.
This is needed as I am using several XMLs (with per level stuff, general setups for enemy, projectiles and the like etc) and "by name" handling seems to be the most appropriate and error free approach ...

and just to mention that: it works great as well :)

Sounds interesting Dreamora.
Care to post a simple example? (the xml file and "by name" handling)

Thats for example the XML.

<root>
	<enemy name="Drone" image="ufo" imgexplosion="explosion_32" size="16">
		<stats health="3" speed="0.5" armor="0" points="2" credits="1" />
		<sounds die="explosion" hit="playerhit" step="alienfire" />
		</enemy>
	
	<enemy name="Scout" image="ufo" imgexplosion="explosion_64" size="64">
		<stats health="7" speed="1" armor="0" points="10" credits="2" />
		<sounds die="explosion" hit="playerhit" step="alienfire" />
		</enemy>

	</root>

the images and sounds directly refer to the names of the media they use. the names are without extensions as they are stored without it in the tmap. (I only use 1 type of media, not a mix of several. This means OGG, PNG)

the parsing of that xml actually is quite simple if you use maxml.
Even the enemies are stored in a tmap by their names and when I need one of them, I use valueforkey, cast it to TEnemy and call its clone method and place it in the world.


I should be more specific: The class that handles the media does this itself, its extended from TMap and automatically clones the output when I ask it for a specific enemy etc.

The basics of this idea came from Grey Aliens framework which already offers such media storing capability out of the box. Extended that idea for my own storages.

I create my own world type and use streams to create my own media packages (LOVE STREAMS!) since I didn't have flexible access to it in my previous language.

I created a method of format on files to write their name, id, length in bytes, and position in the file, so streaming a file from a package containing hundreds of files is surprisingly easy.
Easy to create your own encryption methods, extract single resources, update game files (if the game is online), and hard for people to extract your media.

It probobly isn't the best way, but it's the method I use.

I have an abstract file system somewhere in this forum that does just that.

You can go:
LoadTexture("brickwall")

And the texture is either loaded or returned (if it already exists).

All my data is stored in a map. When the engine is loaded, the game is then loaded and all files from the game directory (there is a difference between application directory and game directory) are indexed and these become the only files accessible to the game. You cannot read files above the game directory (e.g., application directory, C:\WINDOWS, C:\TMP, etc.). All files can be searched for glob-style, extensions aren't necessary to load media (e.g., models and textures- the best format is chosen when there are multiple choices). If the game writes data, the file must be in a directory that is considered writable (for example, saves/).

I was originally using a hash table but decided to go for a TMap instead just because 1) it's already there and 2) collisions won't occur in most situations. It took me a long time to come up with something that could get a collision, but that I could do it means anyone could have, and that just wasn't good enough. Plus I didn't feel like writing a new hash function.

All data is kept in a package that is more or less a modified .PAK format. Each file is individually compressed (I'm thinking about changing this such that each file is made up of small, compressed chunks to make reading/decompression easier for larger files that would be processed over time.

Shaders, materials, etc. are done using my SParse format, which is more or less a complete ripoff of Quake 3's shader format in terms of syntax. I'd considered using XML, but honestly, that's just bloated and ugly. Neat toy back when I was playing with it, but it slowly becomes more and more obvious that it's really, really stupid to use most of the time.

Doubt any of that made sense.

RE:Dreamora

I have a similar technique with lua..

--the data
ball={
  ["image"]="images/ball.png"
  ["static"]=0,
  ["solid"]=1,
  ["mass"]=600,
  ["inertia"]=1000
}

--link the data to string "ball"
class("ball",ball)

put("ball",200,200)

my images are stored in a collection type which extends map. This collection will first look in a buffer to see if it has loaded the image or will otherwise get it from the file system.

Nice :-)

I would be happy if my skills with using LUA were better but I am looking at TinyCC which was wrapped by Noel as a "scripting extension" as it seems to be far simpler to get it in than LUA (and I definitely have more experience with it)

lua's not so bad once you get used to working with the stack. That can be a deal breaker for some people although I kind of enjoyed looking at the gory underbelly of a script language. I love writing with it though. It's a fantastic loosey runtime language.