Red Brick Games

Here’s a game design issue with which I’m currently wrestling.

• fact: terrain elevation is important in Orcs vs. Martians. High elevation gives bonuses to vision, attack range, and windmill productivity.
• fact: RTSs are usually played with the camera angled down.
• fact: it’s hard to see terrain elevation with the camera angled down!
• result: occasional frustration.

So I’m trying to think up some approach to help the player visualize terrain elevation better.

Should I draw equi-height contonur lines on the terrain, like you see on a surveyor’s map?

But that might be hard to implement. I’m using the Torque game engine, and I don’t think its terrain renderer could easily be modified to draw pencil-thin terrain countour lines…

In lieu of contour lines, should I draw contour “bands”? i.e., draw thick swaths of equi-height terrain, using an additional terrain texture?

Torque could do that pretty easily.

If I did that, should I draw terrain that way always? Or draw the bands only sometimes? i.e. like when planning a new building?

And if I used this additional texture to band the terrains, would it look confusing in regards to other textures? i.e., I already use different textures to denote

• walkable terrain,
• impassible terrain, and
• terrain flat enough to build on

If I threw yet another texture into the batch, would that just look confusing?

Hmm…

- - - - -

I’ve been experimenting with a new tile set for Orcs vs. Martians. Here’s “Mordor”:

I think it’s a nice, stark contrast to OVM’s other tile sets, which are all rather lush.

I’ve also been adding detail to the human character models. One of those details being: hair. Initially, I tried blond hair only…

…to which, my initial reaction was, “Gee, everybody looks Scandinavian now!”

Also, I’ve started looking at Torque’s particle engine. For the first time in any depth, really. I’ve heard lots of people praise Torque’s particle engine, and from what I’ve seen so far, I have to agree — it looks to be quite nifty.

Lately I’ve been optimizing Orcs vs. Martians‘ run-time performance.

My stress-test test case is:

• largest possible map (90×90 tiles)
• maximum number of players (9)
• maximum number of trees
• maximum number of ore deposits
• no fog-of-war, so that
  • everything’s rendered, stressing the rendering code
  • everything’s in-scope, stressing the networking code

In addition, all players start with a big pile of resources, enabling them to immediately build big armies.

I start profiling 45 seconds after the game starts. The 45-second delay allows the players’ armies time to reach each other. That way, there are multiple battles raging while profiling is in progress.

Current results:

• roughly 6 frames per second on my 3-year-old laptop (2.4 GHz cpu, ATI X300 gfx (ack))
• about 60% of time spent rendering, 40% doing everything else

I’d say that’s pretty good. I consider my laptop’s graphics to be weak by today’s standards (I mean, ATI X300? come on, the ancient Egyptians used that chipset). And the test case intentionally stresses the game as much as possible.

A “typical” game on this laptop tends to run more like 30 frames per second.

Results were obtained using Torque’s excellent built-in profiler.

Recent progress on Orcs vs. Martians:

A.I. players now explore more

This fixes the blindness issue with maintaining a personal-view-of-the-world. Big “yay” there.

I actually had to do two different exploration algorithms: one to explore near the unit’s home base, in order to find new expansion base spots; the other to explore the entire map, in order to find enemies. Two different algorithms, for two different needs. The combination of the two seem to work pretty well; the A.I. is no longer dumb as dirt.

…In fact, they almost work too well. Despite the fact that the A.I. no longer cheats, the A.I. is once again finding my home base mighty quickly. Those meddlin’ explorers. Maybe I need to dumb down the exploration algorithms?

But it’s still kind of fun. If you can quickly build towers out a distance away from your base, and fend off the A.I.’s explorers, the A.I. takes considerably longer to figure out where you are. Muwahahaha!

Heavily armed, and no place to go

Stack-based unit modes now work

Finally.

One benefit of this feature is that all movement code is now factored out into its own stack element, making movement “smarter” for all modes. Whether a unit is harvesting, building, or just marching somewhere, the unit now intelligently re-paths around unexpected obstacles, no matter what its mode is.

End User License Agreement

Got that written.

To write it, I read the EULAs from about 10 other games, to familiarize myself with their contents and how much they varied from game to game. The verdict? They differ a lot in format and wording, but all contain pretty much the same stuff, or different subsets thereof.

Here’s an interesting question. Are EULAs themselves copyrighted? Instead of writing my own, could I have just copied a EULA from another game? or would that have been some kind of infringement in itself? No idea. Just to play it safe, I rolled my own.

Flattened never-explored terrain in the 3-D view (a fog-of-war feature)

This feature was another Big Thing to me, having been on my to-do list for nearly 2 years.

If you played one of the beta releases or are a long-time blog reader, you may remember this issue. The way I used to “hide” unexplored terrain in the 3-D view, was to color it black. But, you could still see the silhouettes of hills, and water showed up plainly. Those were big problems, because terrain elevation and water locations are key elements to the gameplay (elevation provides all kinds of bonus, and water makes trees grow faster). Being able to see those two things gave the player way more info than they should have had.

My solution? Dynamic terrain height alteration. Initially, all terrain that’s not explored is set to be one meter above sea level. That flattens all hills; and since it’s above sea level, the “false” terrain hides water that lies beneath it. (All terrain still starts out black, so you just see black.) As units explore and new terrain is revealed, the game “pops” the elevation of tiles to their true height. For hills, the terrain gets popped up, and for water, the terrain gets popped down. And of course the black is removed, painting the tiles with their correct textures.

It seems to work fairly well. At first, I was concerned about performance. Could Torque alter terrain heights fast enough for changing fog-of-war? In OVM, fog-of-war gets updated twice a second, so Torque is now modifying terrain heights at (up to) twice a second, for potentially dozens of tiles at a time. The verdict? I haven’t profiled it yet, but Torque seems to do it plenty fast. No noticeable slowdown. Wahoo!

Visually, I generally like the way it looks, though with… reservations. When exploring high areas, you’re constantly seeing artificial “canyons”, that aren’t really there. It’s definitely…different. See for yourself.

Here’s a unit exploring a hilltop, where fog of war covers the interior of the hill, creating an artificial “canyon”.

As the unit explores, the canyon fills in.

Also, when you spot enemy buildings, if you haven’t seen all terrain they sit on, the effect is…interesting.

Hmm.

My thoughts are, it all looks kind of neat, and visually it’s very striking. But it’s also distracting. Those artificial canyons really draw the eye to them, but since there’s nothing really there, I feel like it distracts the player too much.

I think this feature is going to need further fine-tuning.

Rally points are now visible

I used a little 3-D model of a banner, from the good folks at Frogames, to mark rally ponits. The banner is dynamically recolored in the player’s color:

The banner appears & disappears as you select & de-select the base building; pretty standard RTS fare. It also runs a nice animation of being blown in the wind.

…and

…and besides the above, there’s been lots more internal bug fixing, refactoring, renaming, optimization, pulling out of one’s hair, and what-not. All the usual trials and tribulations of software development.

In contrast to the aforementioned progress, A.I. has not gone so well. I made a serious effort to smarten-up the “unit-level” A.I., i.e. what units do on their own (mostly in regards to fighting) when the player isn’t actively directing them. But I haven’t been able to come up with algorithms to do it. It’s been pretty hard to do, despite the fact that I can pretty well visualize the behavior I want them to have. Bummer.

I also haven’t yet made much of an effort to smarten-up the high-level, strategic A.I., either.

And now for something completely different: a photo of NASA research aircraft. Just thought I’d include this since the aircraft look so cool :)

For a while now, Orcs vs. Martians has had a weird problem where a unit’s (RTSUnit) position can become out-of-sync between the client & server. The position becomes wrong on the client, and can be off by as much as several game tiles. People who tested the beta may have noticed this, e.g. when a worker goes to pave a road. The worker sometimes does his shoveling animation while standing several tiles away from the tile he’s supposed to be actually paving. On the server, the worker is (correctly) standing adjacent to the tile, but on the client he’s in the wrong place. Since the client does the rendering, you see the worker paving via “remote control”.

I’ve also seen this bug when workers construct buildings.

What the heck is going on??

Technicals

Maybe OVM is overflowing some network bandwidth limit in Torque for sending notifications to the client? So the server tells the client, “hey, this unit has just changed direction, and is now walking in a different direction.” But an overflow occurs and that notification gets dropped. So, on the client the unit keeps walking in the (now incorrect) original direction, causing him to appear in the wrong place…?

An overflow would explain why the problem is sporadic, and relatively infrequent. But, it’s just a guess at this point…

(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.

Implementing Orcs vs. Martians’ replay feature is turning out to be a big project.

Replays already “mostly” work; currently, the biggest feature hole is that they don’t work for online games. The clients don’t have the replay data. So that’s mainly what I’m working on: sending replay data from server to clients, and sending it efficiently.

Technicals

I tell you what, working on this feature highlights a truism I’ve learned about game development - getting a game to be playable over the internet, adds a lot of development work.

At least, that’s been the case with OVM. I estimate, unscientificly, that implementing network support in OVM has increased its development effort by somewhere between 50% to 100%. That’s a lot.

IMO, it’s not too hard to make a game that sends bits over a network, especially not with Torque. But, it’s much harder to make a game that sends real-time data:

• bandwidth-efficiently - so the game is playable over a 56k modem
• with low latency - so the game doesn’t “lurch” due to bursty network traffic
• securely - so clients get minimal data that would allow them cheat

Those are hard to achieve.

When I first bought Torque, I imagined it would “automate” most of the networking stuff for me. That’s not the case, though. Torque doesn’t really automate anything network-wise, so much as it gives you a nice design pattern to follow, and the low-level tools to follow it. As your write your own networked object classes (for example, like OVM’s Unit and Building classes) you have to write your own data serialization code yourself.

That means those issues - bandwidth, latency, and security - still fall on the shoulders of the Torque developer, and not on the engine.

(I don’t fault Torque for this; in retrospect my expectation was unrealistic)

Anyway, back on the subject of replays: the main trouble with them stems from the fact that they involve a lot of data. For OVM, the worst case scenario will probably involve about 1-2 MB of replay data.

So, for one thing, that data needs to get compressed down before being transmitted anywhere.

And besides compression, another issue is that as far as I can tell, Torque lacks a mechanism for sending a large chunk of data over the network. Really, I’m not kidding! Ppppthth!! I guess Tribes/Tribes 2 never had the need for such a thing.

Torque is good at sending small, incremental, updates for objects, as the objects move around in a game. But I can’t find an API for a big chunk of data. That’s a problem for me, since I’d like to send the replay data at the end of the game, in one big chunk.

The closest thing Torque has to that is an API for sending files from server to clients. Unfortunately, I can’t use the file API, since (1) it only works for files, and (2) the files have to exist at game start-up, i.e. they can’t be created in-game. Plus, it has a few other limitations.

Fortunately though, the file-sending API is close to what I need, and it has a pretty small implementation. So I’m going to try copying the implementation, and modifying it to work for in-memory data. Then, I should be able to use it to send compressed replays.