Red Brick Games

After traveling all the way to Middle Earth, even Martians need to take a break and cool their heels…at the beach!

Given humans’ inferior technology, it’ll take lots of work to repel them pesky Martians. And much work means means many…workers.

In other news…units and trees now cast shadows!

And here’s a new tile set (i.e. new terrain textures) for the game. Gorgeous!

Another new tile set.

Picturesque screenshot of Orcs vs. Martians (click to enlarge):

I’m going to try something new that will hopefully make this blog a more enjoyable read. I’m going to separate out, probably at the end of each blog entry, programming details that would be of interest only to software developers. That way, people who aren’t into such things can skip them more easily. We’ll see if that works out.

redbrickgames.com saw 60% more web traffic in June than it saw in any previous month. Wow - that’s kind of exciting. I’m actually surprised how many visitors this site gets, considering that it’s mostly a blog about an unfinished game! Don’t get me wrong, I like visits, and *I* think watching a game go through development, with the occasional wrong technical direction and humorous bug, is pretty interesting. I’m just surprised (and glad) some others think so too.

For anyone who wants to link to this site, go right ahead (and thanks). Eventually, redbrickgames.com will become a storefront to sell the software I write, so for me, any traffic is good traffic. Here’s a link-bitmap:

For June, here’s what’s been done on Orcs vs. Martians:

• allowed workers to queue multiple build orders!
• allowed multiple workers to work on the same building.
• added many more unit animations & sound effects.
• implemented a system to make animations/sound effects more network-efficient.
• fixed some problems with animations not stopping.
• got hand-made maps working!
• implemented a “tabbed property sheet” gui control for Torque.
• came to a decision on what content I want in the end-of-game screen.
• …and in that vein, added many new stats & graphs to the end-of-game screen.
• fixed lots of small bugs.
• fixed several areas of “questionable” code, code that hadn’t exhibited any problems yet but theoretically could.

Building multiple buildings now requires considerably less micromanagement. Just select a worker (or several), hold down SHIFT, and click once each place you want a building. It’s a fire-and-forget sort of thing, so when the workers finish one building, they’ll automatically start the next. (if you don’t want multiple buildings, don’t hold down SHIFT) It works great for building a tower defense around a base or multiple windmills.

You can also see planned buildings in the 3-D view now!

I also implemented a new animation/sound system, and I’m pretty happy with it. It allows a sequence of animations and sound effects to be associated with each little “act” that a unit can do. For example, when a worker chops a tree,

1. a chop animation plays;
2. a swoosh sound plays, as the axe swings through the air;
3. a chop sound plays, when the tree is hit.

The new system allows the sequence to play multiple anims/sounds as a result of a single act, which wasn’t possible before. So now chopping, mining, building, paving, etc. are more interesting to watch. The system could also be extended to support particle effects too, like bits of bark flying as a worker chops a tree, or puffs of dust as a worker paves a road.

Hand-made maps now work! Orcs vs. Martians is designed to rely heavily on random-generated maps for replay value, but I figure it also needs to support a few hand-made maps too. For one thing, hand-made maps are currently the only way to get some different color schemes into the map. Here’s a hand-made map that has a nice alternative to the conventional water color:

(In the future, I hope to add more color/texture variety to random maps, too)

I’ve also implemented a generic “tabbed” control in Torque. This is like those tabbed property sheets you often see in Windows. I previously cheated with some hacks to make the Options dialog look like it had tabs, but this is the real thing now. The Options dialog now looks like:

Plus, I’m using my tabbed control two places in the end-of-game gui, and might use it once in-game too.

I’m pretty excited about the end-of-game gui; I’ve come to a decision about what content (statistics and graphs) I want in there. I want to provide a satisfying experience when the player reviews the game he just finished, and I think what I’ve got planned will do that.

Another nice thing about the anim/sound system is it uses very low network bandwidth. Each time a unit does an act, I just send the act number (encoded in only 4 or 5 bits) over the network. The client-side then plays the sounds, animation, and in the future, particle effects - with no more network activity. w00t!

The Torque Game Engine doesn’t have a native implementation of a tabbed control, can you believe that? so I may submit mine as a code resource to GarageGames. Everybody needs a tab control! at least, you do if you have an options dialog.

I’ve found that TorqueScript makes the programming model for a tabbed control wonderfully easy, too. I just defined a single control class, GuiTabbedCtrl. GuiTabbedCtrl looks for any child controls beneath it, and automatically renders them as tabs. It’s that easy to use! To get the name that appears on each tab, GuiTabbedCtrl looks on each child for a dynamic field named “tabName”. I may do something similiar to let children specify bitmaps to appear on their tabs, too.