Red Brick Games

I just witnessed an Orcs vs. Martians game consume 1,100 MB of memory. That’s 1.1 gigabytes. lol. Now that’s bad. I’ve got to get that number down.

(All scenes are generated - nothing handmade)

A rather pleasant setting for an Orc base. (click for full size)

A wooded brook.

An attack on a snowy plateau.

A snowy base high up.

- - - - -

I’ve now got a rudimentary chase camera working! Just hit ‘c’, and the camera will zoom down for a near-first-person view of the currently-selected units.

The chase cam is nice to watch in-motion as your units walk over hills and see new vistas, and as the fog rolls back in the distance. Without the motion these screenshots don’t quite do it justice.

One nice thing about using Torque for an RTS is, Torque makes close-up views look better than they look in many other RTSs IMO. After all Torque was originally designed for first-person shooters.

Of course, that’s the positive side of using Torque for an RTS. The negative side is, the coding doesn’t always seem like a natural fit.

Based on feedback, I’ve set out to modify Orcs vs. Martians’s camera behavior.

Technicals

You’d think a camera would be pretty simple to program and modify - it’s just a 3-D point in space, right? So I took a look at RTSCamera, the C++ class for the camera in the RTS-Starter Kit.

Ack. Not simple.

For example, RTSCamera has *four* member variables, just to represent the camera’s *height* alone. What the heck? And of course none of those variables are documented - what exactly does each one do? And, RTSCamera and its two auxilliary classes comprise nearly 1k lines of code. My goodness.

I think the software development profession needs to have a few bearded old men who sit around with their legs crossed, uttering wise and profound sayings for the rest of us. Like:

“a software implementation will always be 100 times more complex than you expect it to be.”

so that we have our expectations set accordingly.

I’m pretty old myself… maybe in another 10-20 years I can be one of those guys?

Anyway, another thing I found is that the RTSCamera class appears to send network updates from every client to the server, 32 times a second. I didn’t realize that.

After pondering the issue a bit, I can see that some games might need those 32Hz network updates. But OVM doesn’t. OVM would be happy with just a simple point-in-space camera, doing its own thing, with no updates between client & server.

So I’ve set out to re-write the camera class. It’ll have the behavior I want, and not consume any network bandwidth. Plus, I want to add an additional camera mode, where the cam follows a squad around to give you a ground-eye view of the action. (I think that’ll be really fun to watch.) So even though normally I’m a believer in trying to re-use existing code, with all the specializations I want, it seems to make more sense to (re-)write my own camera class.

I played a game of Orcs vs. Martians recently that produced some good screenshots. The style of game was what I call a “team free-for-all”. Everybody is teamed up with a single allied player, but there are multiple teams competing.

My ally (Kork) and I had the good fortune of starting in the lower left corner of the map by ourselves. Our area of control was bottlenecked by a single passage to the north, so I built defensive towers there early on. In the screenshot below I’m the cyan human, and Kork is the pink Orc.

(an Orc player colored pink just seems kind of wrong…maybe I should disallow that race-color combination? : )

(click for full-size)

The other A.I. teams played really well. It was difficult for Kork & me to break out of our little bottlenecked stronghold. But the center of the map held a ton of resources (ore deposits - see screenie), which enticed me to come out and set up shop. The other teams, consequently, sent attack wave after attack wave against my new base, and nearly knocked it down several times.

-

Kork also played fairly well. Here he is executing an ill-fated attack against yellow, which, by the time I took the screenshot, was about to get overrun by yellow’s defenders. But, at least he tried : ) The units Kork is attacking with weren’t upgraded well, but in the screenshot you can see he has some excellent upgrades, waiting in the wings.

The alert at the bottom of the screen is telling me that my center base is being attacked…again. I saw that alert a *lot* this game.

-

This is a later attack, in the same spot. I was launching my own attack against yellow and, by chance, Kork arrived at the same time with his own attack. It was a happy coincidence.

It’d be an interesting game feature, if you could tell your A.I. allies when you’re about to attack. Your allies could then decide if they could join in and help you. Your A.I. allies could also tell *you* before they launched their own attacks, in case you wanted to help the them.

-

Me laying down a missle barrage on yellow’s towers, while Kork engages his units.

-

w00t! success! (and also getting attacked by brown, for the umpteenth time)

-

Finally laying the smack down on brown. By this time, I’d upgraded my archers to the point where they completely out-ranged brown. It was a one-sided battle.

-

Attacking red’s base. Earlier, I sent a full squad of my supposedly-elite archers against this base, but red had himself upgraded so well, that he wiped them out! That was quite a surprise.

That’s one reason I like having unlimited upgrades in this game; the opponents can present an unexpected challenge if they’ve upgraded more than you know about. It keeps the human player on his toes and makes the game less predictable.

-

Boom. Red is no match for the combined might of Kork & me.

-

Kork had upgraded his axemen hugely by this time. Check out the comparitve size of the Orc holding the axe, to the red robot. Orcs get physically larger as they get upgrades, and you can see these guys are huge.

-

Here’s a screenie of Kork’s original base, late in the game. Replete with a multitude of defensive towers and windmills.

-

And here’s my original base. Notice that all the nearby trees have been clear-cut! Kork made too many workers, clear-cutting the surrounding land, and undercutting my resource supply. What a rotten neighbor. After all I did for him…

The alert in the upper-right corner is showing me engaging green, our last remaining opponent. Green sat on the sidelines the latter part of the game and didn’t present much challenge at the end.

-

Great game!

I only hope once the game is released, other people will have similarly good experiences, enough to make them want purcha$$$es :)

Thankfully, project management is fairly simple when you’re a one-man development house. Case in point - up til now, I’ve been maintaining Orcs vs. Martians’s task list as a WordPad document. Pretty low-tech, eh? But now I’m trying to make a roadmap of tasks to final release, and I need something a little more powerful.

So I downloaded OpenOffice. I’m putting OVM’s tasks into a spreadsheet, courtesty of “Calc”, OO’s equivalent of Microsoft Excel. The main reason I’m doing this is I want to be able to sort/view my tasks by multiple criteria. Those criteria being:

• by task category
• by task priority, i.e. how crucial is it for release
• by the order I plan to tackle the task
• by task completion

Voila’:

I figure a spreadsheet is adequate for my modest needs. I know there’s more powerful project management software out there, but it’d be overkill for me.

This is the first time I’ve used OpenOffice. My first impression of it: nice. Calc feels very much like Excel. And it supports about a bazillion file formats. I opened the “Open File” dialog, clicked on the “File type” drop down, and the list of supported types is quite huge.

I’ve contributed OVM’s tab control to the Torque development community as a code resource. Here’s a short video of the tab control in action:

Testing an embeded video in the blog.

This is an old video of some of Orcs vs. Martians’s character animations. The animations (and many of the 3-D models) were created by the folks at frogames.net.