Red Brick Games

One of the challenges of writing a game like this is random map generation. Generating random maps isn’t quite as easy as it might sound. For a map to be any good, the map needs to

• be smooth enough for units to get around
• have flat spaces to build buildings
• look reasonably realistic
• have natural barriers (ledges, etc.) that add a strategic element

In this particular game, maps also need plenty of water since water will play a key role in the game. Lastly, maps definitely need elevated areas. Not only do they make the map look more interesting, they give a strategic advantage: they increase the attack range of ranged units. So elevated areas (mesas and such) should be coveted real estate during gameplay.And from a subjective angle, I want the maps to look nice. As millions of artists will testify, landscapes are one of the most beautiful subjects around. This is an opportunity to do a little artwork alongside writing a good game.

The last couple of days I’ve been experimenting with various fractals and filters to generate maps, and (finally) hit upon a pretty good combination. I’m pretty excited about it, the maps are starting to look really good! The screenshots on the left show an example generated map.

Got unit animations working (walking, etc.). Also made an initial pass at unit formations. The formations are fun to watch. If there are obstacles in the formation’s path, the formation breaks up, but at the end the units fall back in line.

Added a few screenshots on the left. The 2nd screenshot shows a soldier attacking a tower. Towers can’t shoot back yet, but the plan is for them to fill the same role that they do in the Age of Empires games.

It’s been a busy week. According to Perforce, I’ve

• finished converting server code from TorqueScript to C++
• finished converting building marker (client) code to C++
• got C++ RPC commands working
• allowed for a variable # of AI players
• made buildings solid (units can no longer walk thru them)
• made units pathfind around buildings
• made buildings destroyable
• made workers handle when their base gets destroyed
• made workers move out of the way when told to build on their current tile
• fixed a number of issues involving building in crowded areas
• allowed a player to order soldiers to attack specific targets (including the player’s own units and buildings - handy for testing)
• did some LAN client/server testing
• made the join-game screen scan for LAN servers on startup
• fixed a crash on player/client disconnect
• made the disconnected player’s team convert to an AI team on the fly
• started experimenting with putting fire on damaged buildings

I feel like I’ve made a lot of progress. As far as I know, there is now only one crash left in the game. That is when a unit or building dies while it is still in a player’s selection set (i.e., the selection rings). In that case the selection set can contain a stale pointer and cause a crash. It is a little work to fix this because the selection set is contained on both the client and the server, so there is some networking involved. But other than that, I think all other object references get cleaned up properly when objects die.Which is good, because stale pointers were one of my concerns about converting to C++. As it turned out, in most cases a “dying” object knows who is keeping a pointer to itself. So cleaning up stale pointers is just a matter of making the object’s destructor notify the interested parties about its death. In the other cases, a SimObject ID can be used instead of an object pointer. When you have a SimObject ID, you can ask Torque whether or not an object is alive, before using the object. SimObject IDs do not go stale in the same way pointers do.

I feel like things are shaping up reasonably well for this game. My project strategy is to first

• implement the basic mechanics of an RTS, and get a feel for those
• get a feel for the Torque game engine

Then, once I have a reasonable idea about what’s easy to implement and what’s not, I’ll take a step back and decide the creative direction of this game. I have a lot of ideas for what could go into this game, but they all have to be filtered against development effort.The creative design stage is where the real fun begins. That’s when the game will take on its unique personality, as something that other human beings will hopefully enjoy. I think all game designers like that stage, because we all like creativity. At that point, you can probably expect all the artwork in the game to get swapped out for new artwork, and it will look and feel quite different.

I think am getting fairly near that milestone. I would still like better understanding of Torque’s animations, finer control over unit movement, finer control over Torque’s collision model, knowledge of what’s involved in programmatically generating Torque’s terrains, and a better understanding of RTS network optimizations.

A funny side-effect of my becoming a full-time indie software developer has been manifesting itself lately. It’s not exactly that I’m feeling more relaxed now, although that is certainly true. It’s that my favorite exercise — walking — just isn’t cutting it anymore, as an exercise.It used to be that walking felt like exercise. It got my blood moving, got my metabolism up, got me a little tired, etc. — all the things you would normally expect from exercise. But since becoming an indie a month ago, walking has been doing less and less for me. No rise in metabolism, no tiredness, and worse no endorphins. It’s just not exercise anymore!

For this, I blame indie software development. Clearly, the problem is that I’m too relaxed now. LOL. Really, the only theory I can come up with is that I am less stressed, so therefore it takes more exercise to get my system going. And walking is no longer enough. Well, as far as problems go, that’s a good problem to have.

However, this problem now takes a dark and sinister turn. I keep taking longer and longer walks, trying to get that “exercised” feeling back again. These longer and longer walks take more and more time. And that means less and less time for software development. And that, my friends, simply won’t do. Therefore, I am forced to turn to the unthinkable…the sadistic…the most painful form of exercise I know of…jogging. God help us all.

Code metrics, before and after the TorqueScript-to-C++ conversion:

TorqueScript:  773 lines / 2661 words
C++:          1219 lines / 3750 words

Wow, very impressive. TorqueScript needs only about 2/3rds the code as C++ to implement the same functionality. Very nice. These stats exclude code lines that are blank, comments, or only contain a single curly bracket.

As a side note, strictly speaking, I am actually not writing this game in C++. I’m writing it in my own home-brewed computer language, Meta-C. Meta-C is very C++-like, but is meant to be more concise and easier to write. Meta-C generates C++ code, which can then be compiled in the normal fashion. Here are Meta-C’s code metrics:

Meta-C:        882 lines / 2858 words

Huh, TorqueScript even beats my Meta-C language. My pride is injured

Very cool! Orcs vs. Martians is now creating workers, soldiers, and buildings from C++ code. It was exciting to see this work the first time. And both workers and soldiers are now pathfinding (moved that code to a common base class). I still need to move tree creation into C++, and re-hook up the workers’ harvesting behavior.Unfortunately, converting to C++ has made deletion of SimObjects a bit of a challenge. Back when the game logic was in TorqueScript and my objects were all held in SimSets, deletion was easy. Torque magically removes a deleted object from any SimSets that contain it, thus the game logic rarely needs to worry about stale object references. Not so now: my objects are now contained in STL lists, as C++ pointers. And accessing a deleted pointer will bring down the house in a hurry.

Hmm…there are a number of possible approaches here. It’s still possible to use Torque’s SimSets and/or object IDs in C++ code. Presumably the magical deletion can be made to work in C++ too. Also, one can use the SimObjects’ constructors and destructors to automatically add or remove the SimObjects from STL lists. I’ll probably try a combination of both those approaches, and see how it goes.