Red Brick Games

At least, they do in my case.

Particle effects have worked out well. Here’s a particle-heavy animation of a worker building a road:

I’ve been wanting to implement those effects for a long time. The intial shovel-scrape kicks up dust, dirt flies off to the side, and when the dirt lands, it kicks up more dust. All done with particles.

All that is courtesy of a powerful “action” system that Orcs vs. Martians has. Every action, such as shoveling, can trigger a sequence of so-called micro actions. Each micro action can play an animation, play a sound, change the mounted tool, and now, trigger particle effects. Put together, actions can now consist of an elaborate sequence of audio-visual effects, as the shoveling action does in the video. The sequences are declared in Torque script for easy editing. It’s a nice, flexible system for unit animations and effects.

It all plays client-side, so all that mounting, animation, and sound happens without consuming any network bandwidth.

I’m now working on re-laying out the game setup gui, portions of the in-game gui, and portions of the results gui. It’s going well so far - things are fitting where I want them, and the in-game gui should emerge from this re-layout somewhat simpler. Some of this work is about applying some really good feedback I got from the last beta test.

Also, much of this layout work will probably be final! That’s not to say I have all the final 2-D artwork in place; I don’t. But as far as the arrangement of gui controls, their resizing behavior, etc., this will probably be a final pass for a lot of gui work. w00t.

More good thing are a-happenin’ with Orcs vs. Martians:

Further optimization

I’ve spent the last few days doing numerous, small optimizations. Their effects have added up. New results for my stress-test case:

• roughly 8 framers per second (was 6)
• about 71% of time spent rendering (was 60%)

w00t. I was already pretty happy with 6 FPS, on my laptop’s weak graphics system. And now 8? that’s practically playable.

And another good thing: most of my current 3-D models are not optimized for an RTS. So when I get final art, I expect that number to go up further.

Considering that this is the stress-test, I believe Orcs vs. Martians‘ code is now sufficiently optimized to put this puppy up for sale!! (but I’ll still shoe-horn in a few more optimizations before release.)

Networked games are working again

I’m now testing networked games between two PCs. It’s been a long time since I’ve done such testing, and so far, I’ve only found two crashes. And I just fixed those crashes.

I’ve successfully played one networked game, from start to finish, with no serious network problems.

Improved arrows

Up to now, I’ve just been using “particles” to render arrows. So the arrows have looked like white streaks:

Now, however, I’m using a true 3-D arrow model:

I like the the new 3-D arrow model much better. On top of that, I think the 3-D model renders slightly faster than the particles did. ??? Now that was a surprise.

…And a funny bug

Apparently, I did an OpenGL no-no somewhere: on my second computer, the building and tree shadows are rendering as grey squares:

Oops. Also, you can notice that the unit portraits have a black background. That’s wrong, they’re supposed to be transparent.

)-: I must’ve done something non-portable. My development laptop is ATI-based, whereas my 2nd computer is Nvidia-based. Up ’til now, I must have been lucking out with ATI’s OpenGL driver.

But that bug should be easy to fix.

I did a small favor for a fellow indie, and he in turn made some new 3-D models for OVM! OVM now sports a UFO model to serve as the Martians’ base, and a laser rifle for Martian crewmen to hold.

I felt the placeholder art I originally had for those two items really detracted from the game’s look, even as placeholders. What a nice improvement. Thanks Thak!

If you’re interested in more of Thak’s work, check out 3dmatter.com or spellcraft.biz. He works fast - he turned out those two models in no time flat.

Progress

These last few weeks I:

• finished the A.I. personal-view-of-the-world feature
• started to separate OVM’s pathfinding code into a stand-alone library
• added new features to meta-C (my homegrown programming language, which OVM is written in)
• optimized meta-C for speed

I kind of spread myself too thin these last weeks, trying to do all those things simultaneously, and several of them didn’t go as planned. Still, I got some progress done.

A.I. personal view of the world

This is done! The A.I. now makes all important decisions based on a limited, imperfect view of the world. No cheating anymore!

This is a huge milestone, and it’s been a long time coming. I remember putting this feature on my to-do list well over a year ago. At the time I thought to myself, that’s pretty ambitious, I don’t know if I’ll get that feature in. So, I’m definitely happy that it’s actually in!

I still need to do the follow-up work of increasing the A.I.’s exploration ability; without that, as predicted, the A.I. is behaving dumb as dirt.

Pathfinding library

I started pulling out OVM’s pathfinding code for packaging as a sellable product.

Here’s what the main API currently looks like:

   F32 findPath(
      Point2F          bgnPoint,
      RectF            endRect,
      IMap*            map,
      Vector<Point2F>* path,
      ICoster*         coster = NULL,
      F32              range = 0,
      F32              maxCost = FLT_MAX
      );

It’s simply a global function that outputs a vector of way points. Maybe I’ll describe the parameters in a later post. I’m still figuring out how to make the API as user-friendly and flexible as possible, by using C++ templates, etc. Naturally, it’ll also need a friendly TorqueScript interface, too.

There will also be some utility functions and data structures, for things like iterating over the tiles crossed by a ray (useful for smoothing out the final path).

One good thing is, I’ve taken a look at some other free pathfinding packages, and it looks like OVM’s pathfinding does indeed provide features beyond what’s already out there. Got to provide value, to sell a product.

Next up: Squads

I’ve started working on giving OVM a notion of sqauds, i.e. groupings of units.

The more I think about squads, the more issues I see them impacting in the game. For example:

• making units march in formation
• reducing the number of calls to pathfinding (and hence reducing CPU demand), via squad flocking
• reducing network traffic, via squad flocking
• allowing the A.I. to temporarily subdivide a force to deal with attacks from multiple directions, via a hierarchy of squads (i.e., squads of squads), and then bring those forces back together to resume the squad’s original mission
• helping the AI manage multiple units sent to do a single job, e.g. when multiple workers go to build a new base
• allowing units to auto-explore in two’s or three’s, in addition to individually

I thought that was kind of interesting. Originally, I thought of squads as mainly relating to marching in formation. But they seem to touch quite a few other areas, at least from a programming perspective.

Mystery solved - the problem wasn’t network overflow or dropped notifications, it was my own code not handling variable network latency! A few details are below. The bug should be fixed now - “remote control” harvesting / paving should no longer happen.

And with this fix came two bonuses -

• it fixed another problem where workers occasionally skipped action animations, like missing an axe swing while chopping a tree! That problem was in the Beta, too. Turns out, the fixed bug was directly responsible for that problem as well.
• it revealed some code that was wasting network bandwidth, sending unnecessary notifications

I’m still ironing out the solution, but two long-standing mysteries have been cleared up, and OVM’s network utilization has been lowered, to boot! To quote Wallace and Gromit,

That went as well as could be expected, didn’t it?

Technicals

There are always slight variations in network latency, and I had some code that presumed that worker actions were uniformly spaced apart in time. That’s an ok assumption on the server side, but after action notifications traveled across the network, it was no longer true on the client side (pretty close, but not quite!). Consequently, my code ignored the notifications, making it look as though they were dropped. Without the notifications, the units moved differently on the client.

The fix was simply not to require time uniformity on the client side — it’s only really necessary on the server anyway, where it’s done to enforce game rules.

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…

I’ve started testing multiplayer using two side-by-side comps, and things are starting to work. Most significantly, replay downloads work. I can’t believe all those 0’s and 1’s are coming out correctly, considering the pounding and mangling they get. I’ve now got about 11 general bug fixes and cosmetic changes I want to make to the game, then it’ll be on to the 1st beta.

A few gratuitous screenshots to celebrate:

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.