Implementation work has finally been completed on the new data format system. Testing remains, though. What’s next is to make the concept of Data Modules work in code. Modules will enable modders and addon makers to create their own, freestanding packages of game content without modifying the original game’s stuff, and without disrupting data of other mods and addons.

On the file system, a module simply looks like a folder in the game’s directory, named “MyMod.rte” or something. It contains at least one .ini (index.ini) and whatever other resources like bitmaps and binary data files used by that module. For organizational purposes, the index ini can ‘include’ (IncludeFile = MyMod.rte/Weapons.ini) other ini files within the same module, like a ‘Scenes.ini’ or ‘Actors.ini’. All these ini files use the new data formatting system throughout (see earlier post).

In its ini files, a module can define instances of almost every object in the game engine. So, one could for example make a module with only weapons, or only effects, or only new scenes (maps/levels), or a combination of these. Gameplay logic is currently totally hard-coded, but eventually we’ll see how data driven we can make that too. This would mean modders could define their own gameplay styles as well, much like Unreal’s ‘mutators’.

There will always be at least a single module present called Base.rte, which will contain all the data of the basic game. Other modules can safely refer to data in the base module since it can be assumed to be there, but add-on modules should never refer to bitmaps and such in other (non-base) modules. This will ensure that each add-on module can be passed around to fellow CC players without a hitch.

After work is done on a module’s data, there will be a tool to compress its containing folder into a single file with the same name as the folder (e.g. MyMod.rte). Hopefully this will make it even easier for people to share their new weapons, actors, levels, etc. with the community.

I was going to draw a diagram to make this post a little more visually interesting, but I’ll spend that time on actually getting the code done instead. (Update: but then I drew one anyway!)

I just thought this was funny:

http://www.joystiq.com/2006/07/20/colin-mcrae-less-popular-than-dirt/

(D.I.R.T. used to be the name of the Cortex Command project, more info here)

Ok folks, here’s the rough plan for what we’ll be spending the last precious weeks on before it’s time to submit CC for next year’s Independent Games Festival:

• Week 1 (next week): Finish data structure overhaul, including data module support (see next post).
• Week 2: Rework and tune the locomotion logic and physics to make it more intuitive and fun.
• Week 3: Continue work on the locomotion. The goal is to, by any means necessary, virtually eliminate sticking and snagging of characters to the terrain.
• Week 4: Get the in-game GUI up and running, the main goal being to implement a working buy menu so the brain can order new guys and supplies.
• Week 5: Continue work on the menus and GUI. Start work on reimplementing audio.
• Week 6: Get a new spacecraft in the game.. going to be a supply ship. Tune and also work on gameplay logic. Finish up audio.
• Week 7: Polish anything that needs it and package for the submission!

Well, as you can see, we have our work cut out for us. Please leave comments on whether you think we’re missing or not allocating enough time for something critical you’d really like improved.

Back to work!

This is a real treat if you’re into old games – check out Arne’s (Prometheus’) recent update to his site with tons of remake concept art and other amazing stuff:

M.U.L.E.:
http://itchstudios.com/psg/main.php?id=mule

Utopia:
http://itchstudios.com/psg/main.php?id=utopia

DragonQuest:
http://itchstudios.com/psg/main.php?id=dragon

Alternative Metroid game:
http://itchstudios.com/psg/m05/designdoc.htm

Frontier Elite paper models – print and make ’em at home!:
http://itchstudios.com/psg/ecp/frontier.htm

And I hear there’s even more to come soon, so keep an eye out on his site!

Came up with a way to make things even easier on anyone who needs to edit the data files… This is the new format

Which can be written as:

to get the same effect, relying on default MOSParticle class’ default initialization values.

Basically, the difference from the last post is that I got rid of the special Parent properties required before to define the values of parent properties. Keeping track of the class hierarchy while reading is just a chore the program and not the human should be doing.

Ok, after a few days of thinking hard and long about what to do with the data file reading/saving system, I’ve finally come to a decision and plan for what to implement.

The CC engine originally used a very simple way of exposing every single object’s variables to the data files by serializing out their values in a certain order. The order of these values determined which variable they belonged to. It looks something like this:

Note the use of indentation to keep track of the class hierarchy, and # to mark line comments.

This is a very rickety and fragile way of storing game data. Leaving out or mixing up any values would make the order, and therefore the reading procedure get messed up in sometimes hard-to-catch ways. As soon a member variable is added to a class, the data files had to be updated with values for this added variable – Bad. But this old crappy way worked on the small proof-of-concept scale of the current CC Test build!

So what I’ve been thinking about is wheteher to completely replace the current system with something new and probably XML-based, or to just improve upon the existing code, or do something in between. I started going down the path of replacement with an article and sample code of Frederic My’s article in Game Programming Gems 4. It’s a very robust and complete system for custom RTTI (real time type identification, or reflection) and properties-based data persistence. Its files look like this:

Note how he definies how the classes and properties are structured before describing the values. He also uses the current pointer addresses as the unique identifiers for the object instances saved out.

It took some pondering to conclude that I’d probably spend more time gutting my existing code and replacing it with an adjusted and adapted version of My’s sample code to make it worth it. I also don’t have much use for some of the benefits of his techniques, since I’ve already engineered my code to work around the shortcomings of my original techniques.

After reading this excellent thread by the Moonpod guys on XML, I had to reconsider once more whether I should go with my own format or some XML flavor:
http://www.moonpod.com/board/viewtopic.php?p=15369#15369

Although the DTD’s are a compelling and really interesting feature, I’ve decided that readability and ease-of-editing are my highest priorities. XML just isn’t very readable or convenient to edit with all those closing tags and different ways of formatting things. I prefer to keep things simple and with little room for my formatting obsessive-compulsiveness to freak out when I change my mind about pointless conventions.

Another big priority is to keep things very self-documenting, and that was why I actually didn’t like My’s way of keeping the property definintions in a separate place in the file. When I’m editing something, I’d like for the documentation to be right there in some way so i don’t have to look it up in the code or somewhere elese. This’ll be even more important for any modders who want to change things around in these files and don’t have the code to refer to.

Finally, the last important benefit I’m seeking is to be able to omit as much redundant data as possible in these files. I found that even in the CC test, I ended up with really long files to scroll through, and much of it was just default value filler to keep the order intact. If I can just keep the defaults of an intialized and read object by omitting those values in the data files, I’ll be much better off. This’ll also help keep old data files working with new versions of the code since they’ll just define their old values and leave loaded objects’ undefined properties with safe default values.

Anyway, if you’re still reading this, here’s the way the new format I’ve come up with will look like:

# are still comments. Everything before an equal sign is the property’s name, and everything after is the corresponding value. % means to set the entire object’s data to that of one which is already defined. Properties can be in any order, or omitted. The big constraint is that the tab indentation now matters, so that’s a source for errors, but I think it’s a good tradeoff to having some kind of nested opening and closing brackets (e.g. { and }) all over the place. 

That’s all for now… my tired brain going to bed. Tomorrow is all about retrofitting the old code with this crazy new system.

Just put up a slightly updated version of the previously available test build. The only real change is the addition of a proper Readme, and a quick control keys instruction to the loading splash screen:

Download the new version here:

All right!

This is a quick status update on what we’re working on at the moment. We are done renovating the data realms websites, including this dev log, so now we can turn our focus back to the game (CC) 100%.

As far as Cortex Command goes, we’ve been working on rethinking and revamping the data file loading system. A fundamental feature of CC is to have everything be completely data driven, meaning next to no data is hard coded into the executable, but instead stored in easily editable text files which can be modded by the player.

Up till now, this has been the case with the CC (formerly D.I.R.T.) engine, but with a kindof non-robust and unfriendly system and data format. If we added a new variable to any of the classes, we had to go back and update all data files as well – major obstacle and pain for both development and modding. We want to be able to put out new versions of the game very frequently, and we don’t want to break all the mods that players will have made for previous versions.

The solution is a property-based system, where varaibles in the code are indirectly mapped onto ‘properties’ which can then be matched when loading a file. If a property exists in the code but not in the data file, it is just handled gracefully instead of crashing things. Also, the order in which objects are defined in the data files won’t matter anymore, so references within one object can go to something that is only read later on. This, along with a bunch of other beneifits is going to make prototyping and tweaking a lot easier.

I have to warn the folks anticipating a new version of CC that it’ll take a while to get such a big change done, which includes having to rebuild and reformat all the data files that already exist. The good news is that after it’s done, it’ll be so much easier and faster to develop the game, so there will likely be far more frequent updates then.

That’s all for now; stay tuned as we intend to update with more details on developments at least three times a week, and possibly much more frequently!