Red Brick Games

I got my first spam comment on the blog. As Strong Bad would say: “DELETED!”

Lately I’ve been working on the setup screen I mentioned in my previous post. That screen poses some interesting implementation challenges, for an RTS game. In single-player games, it’s pretty simple. The user tweaks a bunch of game parameters, hits Start, and boom! off you go. But in multi-player mode, it is really a different beast. The setup dialog essentially becomes a networked, cooperative dialog. Each remote user is responsible for filling in his own race, team, etc. in his player slot. Then the local user, the guy who created the game, fills in all the general parameters. So you’ve got this one “virtual” dialog, where different users fill in different parts. Eventually everybody marks their player as “ready”, the local user hits Start and the game begins.

There are a bunch of interesting aspects to this. For one, everybody has to connect to the game server *before* the game actually starts. Otherwise they couldn’t cooperatively interact with the setup screen. For another, every user (client) has his own local copy of the setup screen, in-memory on his own machine. But the “master” setup data is kept only on the server. When a client connects to the server, the server has to dump all the master data out to the client, so his setup GUI can be up-to-date. Then, as the client tweaks his parameters, his local setup GUI has to sends those changes back to the server. The server then broadcasts the changes out to all the other clients, so they can see what the first client is doing. There are also security issues, such as validating that a particular client is authorized to change a particular parameter. The multi-player aspect of the setup screen even impacts how the game caches the setup parameters to disk (i.e., to be used as defaults the next time you play the game). Should single-player and multi-player modes share the same cache? Or should the multi-player mode parameters be cached at all? Or maybe multi-player mode should cache only the game’s general parameters, and not anything from the player slots?

I find it somewhat amusing that, in my impementation, it looks like there’ll end up being four(!!!) copies of the setup data sitting around in memory. Yes, four! And this for a single-player game. Why such redundancy? Well, single-player mode will have the same architecture as multi-player mode, so there’ll be both a client and server. And with that architecture, (1) all the GUI controls contain the setup data, so that’s one copy; (2) I need a client-side cache to detect when the user changes GUI controls, so that’s two copies; (3) the server needs its “authoritative” master copy of the data, so that’s three copies; (4) finally, Torque has a standard set of variables used for caching setup parameters out to disk (the “prefs.cs” file), and these variables’ values should really be human-readable whereas the master data is not, so these variables make yet another, fourth copy. LOL! Four copies, for some reason I find that funny.

In implementing this setup dialog, I also ran into some limitations with Torque’s GUI controls that I didn’t know about before. So Torque has this nice GUI system which is cross-platform and all, right? It has buttons, checkboxes, combo boxes (or pop-up menus depending on your terminology), etc. Unfortunately, Torque’s controls are missing some nice features. For one, I don’t see any way to get callbacks when the value of a control changes. I need this feature for the setup dialog, because like I said earlier, clients need to tell the server when a user changes a parameter. So I have to know *when* a user changes a parameter! (That’s the reason for the existence of the client-side data cache, to compare against current values of UI controls in order to detect changes.) Second, I don’t think Torque’s GUI controls can be disabled. But I need to be able to disable controls in the setup dialog, so that users can only mess with the controls that they’re supposed to mess with. A remote player should not be able to edit other players’ race, team, etc.! I think I’ll try to add this disabl-ing feature natively to the Torque engine, and if I do I’ll see about publishing it as a resource on Garage Games’ forums (the publishers of Torque). Seems like other people would find it useful too.

Phew!  Got the game setup screen finished.  This is the screen a user will see when starting a single-player game, or when joining a multi-player game.  I used (again) a screenshot from the game as the backdrop, but blurred it slightly so that text would be more readable against it.  I also added the sun using one of GIMP’s “lens flare” effects (it’s not the normal sun from the Torque engine), to add a little pizzaz.

This screen isn’t hooked up to any logic yet, but hey, at least I’ve got a screen now.  Let me know if you like or dislike it (or have suggestions).

You know it’s funny, as much as I like the RTS genre, I haven’t really played that many RTS games.  I’ve mainly played (in no particular order) Warcraft 2, Starcraft, Age of Empires 2, Earth 2150, and now Empire Earth 2 (recently purchased!).  I’ve also dabbled in Homeworld (only the demo version) and Trash (another indie RTS).  I actually don’t buy that many games in general, in fact I probably average one purchase a year.  I like to get “into” just a few games, and play those thoroughly.

Of the RTSs I have, I think my favorite would be the ever-popular StarCraft.  Earth 2150 though, IMO, is an overlooked gem among RTSs.  Earth 2150 has a really neat system for designing from basic parts the units that you build.  Mainly its just a matter of mating a chassis to some weapon systems.  But some of the weapon systems stack, so depending on your design you can pile onto a chassis a veritable tower of lasers, rockets and machine guns.  Then you get to field your creation in battle and see how it fares.

Also in Earth 2150 some weapons have limited ammuntion, so there’s a resupply ship which flies out to your units to reload them in battle.  It’s a neat concept because it makes it difficult for you (and your opponents) to send units too far from your bases, just as in real life.  If you do, you’ll need lots of resupply ships to ferry ammo across the distance.  Either that, or build new supply depots nearer to where the action is.

And Earth 2150’s in-game videos are hilarious!  Whenever you finish researching a significant new technology, the game pauses and plays this propagandistic / promotional video.  It’s like this is your government showing a propaganda film about how great this new technology is, and how it will bring victory to the homeland, etc. etc.  Really funny.  Earth 2150 was a nice game.

Lately I’ve been working on Orcs vs. Martians’s out-of-game screens and menus.  The screenshot above shows a new main menu screen for the game.  (The old main menu is the first screenshot in this post)

I made the bitmaps for the six buttons on the main screen with GIMP (GNU Image Manipulation Program).  Initially, I had a bad impression of GIMP and didn’t want to use it.  The way GIMP does certain basic paint operations is rediculously unintuitive.  So, I tried a couple of other free paint programs, Paint.NET and ImageForge.  Those programs are pretty good, but it turned out I couldn’t make the rounded-rectangle buttons (like the ones on the main menu screen) the way I wanted.  ImageForge came close to being able to make them, but couldn’t do full-color texture fills, which I needed for the wood borders on the buttons.  So, it was back to GIMP.  GIMP did the texture fills with no problems.  GIMP even came with a “pine wood” texture already built-in, so I didn’t even need to hunt for a wood texture on the internet.  Nice.  So, I now give a somewhat grudging “thumbs-up” to GIMP.

I’ve converted the website to use Wo rdPress blogging software and PHP scripts. Now it’s possible to get RSS feeds, leave comments, and search posts by category. :-)

Also, screenshots now appear in the post that they belong to. That makes more sense than the way it was before. Eventually, I’d like to stack screenshots vertically, along the leftside of the post they belong to. Maybe later, right now I’m tired of editing PHP scripts…

Preliminary random maps are now working, in-game. Yay! In the images at left, the landscape, textures, and water were all generated at run time. Placement of bases and trees was also random.

In other indie news, Venture Africa is going on sale at Wal-Mart! Venture Africa was also created using the Torque game engine and the RTS starter kit. The company that created it is PocketWatch Games. Our hearty congratulations to them.