I was writing the memory management code for my game today and realized that I had most of the work already done in the GTL. I wrote up the memory management kernel in a few minutes, no problem. Then I went to write the smart pointers. I simply inherrited from my gtl::simplepointer class, overrode the function that deals with releasing objects to make it interrect with the kernel, one or two small additions and I was finished. Then I went to write my Singleton class. Again inherrit from the gtl's singleton class. Since the gtl version uses the gtl's smart pointer and I wanted the singleton to use my smartpointer I simply change the template perameter for the storage object and I was finished, short of a few tweaks. (You can't do this with the current release version of the GTL. This is the developement version of 2.0).
I love templates.
Anyway, coding is underway. I have a nice big design doc for the engine, so its just a case of sitting down and coding. I have around 16/17 seperate systems which I have to code up. They ar eall designed so each of them should only take me a day or two to code up, and then a few days debugging when I get to the testing stage.
Here's a breakdown of the systems I'm including in the engine:
- Mem Manager (done)
- Config Parser (probably going to be a wrapper around some XML lib)
- Logger
- Profiler
- Timer
- Kernel
- State Stack
- Scripting (Not actually required for this game so I'm not sure if its going to be included)
- Graphics
- Sound
- Input
- Entity Manager
- Renderer
- Resource Manager
- Client / Server
- Networking
- other stuff I've forgotten
This is the third iteration of Riot2D, so I'm calling it 0.3. 0.1 got to a functional stage before it died due to being more design flaw than design. 0.2 was the engine I used for Jailbreak. It was heavilly influenced by Enginuity. I learned a lot about engine design with it. 0.3 is a large step above its predecessors - I have high hopes for it.
Proceedural Content
This is somethting I've been harping on about to anyone who'll listen for quite some time. I've been spurred to write this now after watching the Will Wright's Spore vid, where he mentions many of the same things I've been saying for a while. If you haven't seen it yet I recommend doing so, its very impressive.
Ever since the rise of the CD games have been including more and more content. A game will have a lots of hand crafted models, lots of textures, lots of animation, some FMVs, and more and more intricate levels. But as Wright says, it gets to the stage that you are after giving them so much content that the extra content you are piling on top has less effect on the players experience, which in fact makes the artist's work becomes less and less valuable as quantity of content increases. And yet gamers yearn variety. Variety increases the replayability and the sticking power of a game significantly, variety means there is simply more to see. Variety sells, even if its actual impact per playing session isn't that pronounced.
So the question is not whether to give them that content, but how to make that content as efficiently as possible. Where efficiency is not only measured by time it takes to create but also how much space it takes to store (vital for games being distributed over the net). Take planets (which is what I'm currently working on). To make create by hand the image of a planet is both time consuming and difficult. To make 1000 such planets is a LOT of man hours. Lets say planets can be procedurally generated. We have now made planets faster to create, and much cheaper to store. I have now made it possible to increase the number of planets I can ship with my game from say 100, to 2000 and gain in both man hours and storage space. From both the developers and the gamers point of view procedurally generating planets has a positive effect.
Procedurallity (what a word) of content also opens up another avenue, which Wright seems to have latched onto and run with. When you create content proceedurally what you make will always end up at least somewhat suitable for your game (asumming the range of acceptable input values is calibrated correctly). This means that allowing players access to the planet generator ingame is entirely feasable, and possibly benificial. Allowing players to create content is always welcomed. It also encourages communities to develope around your game since players can take a sense of pride and ownership over a piece of homebrewed content.
Well, thats the gist of my proceedural content speach - its usually more oriented around the fact that current games are being lazy in their content stoage methods, but its fairly similar.
Anyway, feel free to ignore/violently disagree with the above rant. This has been one long post, so if you've made it here, well, you're a better man than me.
