I'm trying to find some good examples of open source games so that I can look at examples of things like controlling game flow and resource management. It's all good and well reading articles on the subjects or even looking at barebones examples, but I think I'll be able to get a much better understanding of these things if I can see how others have implemented them and incorporated them together into a larger project. Can anyone point me to some good examples of open source games? They don't have to be complete or inlude many features. I'm simply looking for source code that demonstrates the things mentioned above, preferably tying them together with other functionality. [Edited by - InsaneBoarder234 on May 3, 2007 9:35:51 AM]

Thanks, I'm browsing that website now.

Also I just came across Secret Maryo Chronicles. I just had a quick scan over the source code and it's actually really helpful.

I'm still looking for further examples if anyone can point me in the direction of any, thanks!

Quote:Original post by Ravuya
IMHO, you should figure this stuff out on your own; a lot of "shipping" code is virtually comment-free and impossible to understand.

The thing is, I've completed projects before but never anything polished or nice that I've really been happy with - for example no menu systems, intros, option screens etc. When I've attempted to incorporate such features the projects seem to quickly become overwhelming so I wanted to see how other people have incorporated such things into a larger project.

As for code documentation, as I said I've had a very brief look at the Secret Maryo Chronicles source code and I've worked out quite a bit from the variable names and such - things such as how the game is generally structured and the main game states used etc. In fact, the game states seem to highlight a possible mistake in my own projects which is overcomplication of the game state system, however I will examine the code further later in order to get a better idea of this.

Thanks, I'll have a look through that later after college.

In the mean time, after spending some time looking over source code structure in other games, I've decided to take a step back and work on smaller and more limited projects and basically do as Ravuya advised and learn this stuff myself. I think by working on smaller projects and setting clear goals in each project I'll be able to build up a better base of knowledge and source code from which I'll have an easier time tying these things together.

I am a developer for Crown and Cutlass. I'm not sure you can get a lot out of our code in its current state (we are in the middle of a total rewrite), but you mentioned resource management. That is one of the few things that both worked pretty well in our old code and that we have actually gotten a good chunk of the way through in the rewrite. You might want to take a look at it:

Pre-rewrite:
IResource (.h / doc) - Base resource type. This includes virtual functions for loading and unloading the given resource type. Also, all resources have a type and a name, which are combined to form a unique key. For example, the SoundResource class has a type of "sound" and a particular instance of SoundResource may be named "test.ogg", resulting in a key of "sound: test.ogg". That key is used to acquire that particular resource from the ResourceManager.

IResourceFactory (.h / doc) - Base factory class. The resource factories are only used to create instances of resources. They take an XML node that describes the particular resource and return a resource object based on that XML node.

You can find an example of the how those base clases are implemented if you look at the SoundResource (.h / .cpp / doc) and SoundFactory (.h / .cpp / doc). It's pretty basic, the shared resource is a OpenAL buffer that gets created from an ogg filename. The filename of the ogg file is an attribute of the XML node that is passed to the factory.

ResourceManager (.h / .cpp / doc) - The ResourceManager handles loading XML files that initialize resources as well as the interface for acquisition or releasing a resource. As I noted before, the actual creation of resources is done by the factories. The first time a resource is acquired, the resource manager calls that resource's Load() function. When the last reference is released, the resource manager calls the Unload() function.

Because I was doing the reference counting by hand and I didn't want the user to have to remember to release the resource manually, I created wrappers around all of the resources. For example, SoundEffect (.h / .cpp / doc) allows a user to just create a new sound effect and not worry about the resource management. As long as the object was cleaned up correctly, the resource would be released when it was no longer needed.

There are several things I was not happy about with this system, though. I learned about boost::smart_ptr right about the same time I was doing this, so I am unhappy with the manual reference counting. Also, due to the fact that you passed a XML filename and a factory to LoadXMLFile(), all resources in a single XML file had to be of the same type. It seems like it would be nice to have the option of putting all of a level's resources in a single file, rather than all of a single type of resource in a file. Also, you couldn't create new resources on the fly because they could only be loaded from an XML file. Finally, there was no way to totally remove a resource from the system. That worked ok for our project as it was, but I was interested in more flexibility.

When we started our rewrite, we spent some time playing with Ogre's resource system. It is pretty impressive. A lot of the ideas in our rewritten resource manager are based on how things work in Ogre. Here is a little bit of the new code (you can find docs for all these classes here, sorry I'm having internet issues at the moment):

IResource (.h / .cpp) - Same idea as before, but now we have a group and we use intrusive pointer instead of doing manual reference counting. Also, I think in the old code, almost every resource type had a "loaded" private boolean. I pushed that into the base class now. I also no longer do the type + name to form a unique key. The key is just the name now. It seems like that will work well enough.

IResourceFactory (.h) - Again, similar idea as before, but now you can create a new "empty" resource without going through an XML node.

You can see how these are used in SoundResource (.h / .cpp) and SoundResourceFactory (.h / .cpp). I'm not sure if those have been tested, but that's the idea...

ResourceManager (.h / .cpp) - This is much more complicated now, but much more flexible. You can now load/unload resources explicitly (individually or by groups). You can also create resource from a file or in code, and totally get rid of a resource by "destroying" it. A resource file can have multiple types now, because you register a factory for a given type and it stays loaded. When that resource type is encountered in the XML, the resource manager calls the correct factory to create the resource.

I think I will still wrap the SoundResource in a class like SoundEffect, but with the automatic reference counting, that is less important.

You can also find examples of how that is all used (in the actual game for the pre-rewrite stuff, and in our tests for the post-rewrite stuff), as well as our game state management code through those links if you are interested. If you look at this, remember that we decided to rewrite for a reason, so there are things that are not good examples in there. Also, while we have unit tests for quite a bit of the rewrite, it is still young and we have not gotten back to a workable state yet. Hopefully you can learn from both our good and bad code. If you have questions about why we did things the way we did, or if you have suggestions for the rewrite code, let me know.