Red Brick Games

Just a quick update to show some recent progress.

Here’s an experiment where I replaced the tree model with a new model, from Todd Picken’s RTS environment pack.

I also added some ore deposits, represented by stand-in boulders on the map.

Here are some shots showing a mix of the two tree models (and some closeups of the boulders, er, I mean the ore).

Also, the bases now have working production queues, and that is visible there in the 1st screenshot.

I think this next week I’ll take a break from working on Orcs vs. Martians.  I need a break, and this seems like a good time for one.  I feel the game’s development is far enough along that I need to stop and re-evaluate where I am.  It’s about time to firm up what features will be in the game, and time to make a roadmap for getting to a released product!

Also, I need to get the game out of my mind for long enough that I can come back and take a fresh look at it.  I think from here on out the game’s development will be less about solving technical hurdles (though there are still a few), and more about making the game fun.  It’ll help to forget about the details for a while, so I can better see the forest for the trees so to speak.

It has been fun - but I’m tired at the moment.

Here’s a really good science fiction short - And He Built A Crooked House. As the story starts out, you wonder how on earth Heinlein is going to turn this into a sci-fi story. Then, when the story takes a rather fantastic turn, he makes it seem almost plausible.

Why is it that old sci-fi seems so much better than new stuff?

I think the best I’ve read was Azimov’s Foundation series. It was written back in the 50’s and 60’s, I think. In a way the series has a certain simplicity and innocence. Yet, it has greatly entertaining concepts and situations.

Back on the subject of game development, I’ve spent a few days improving the unit-level AI. Melee units now fight much more effectively. Ranged units now fire at the sides of buildings, instead of their centers, which obviously looks more realistic.

Note here how the crossbow bolts are exploding on the building’s exterior, where they should.

Also implemented are escorting, repairing buildings, and tooltips on the buttons in lower right corner of the screen.

At this point I’m just about done with everything I’d consider “basic mechanics” of a real-time strategy game. Pretty much the only thing left in that category is production queues on buildings — as it is now, units are produced instantaneously when you buy them.

So after production queues are in, I should be able to focus on making the game unique and giving it some personality.

Actually, before I do that, I may upgrade the sound effects and graphics a bit. Especially the sound effects; I’ve been using the stock sounds from the Torque SDK, and they don’t work well for an RTS. And, this stuff about Martians using crossbows for a weapon…that has got to go :) I need a low-polygon model of a laser pistol for them.

I take back some of the things I wrote about NSIS. It can in fact make installers that conform to Microsoft’s Wizard ‘97 specification (or whatever it’s called).

Wow, October has started off with a bang, in terms of web site traffic. That’s definitely nice to see.

I’ve started working on the scalability of Orcs vs. Martians. That is, making OvM accomodate larger numbers of units in the game. After a couple of days of optimizing, OvM can now deliver smooth gameplay with up to about 300 moving units. It even plays fairly well with up to 500 units.

500 units is a quite a few; to get an idea here’s a screenshot of 500 Orc workers.

Here’s the 500 workers harvesting. Notice the long congo line of workers on the horizon. In addition to the workers, there are also about 350 trees in the game.

A better view of the congo line.

Another screenshot, with human workers.

Getting 300-500 workers in the game is a huge improvement over where the game was before. It used to lag / play choppy at about 30 moving units. That limitation really made it a pain to test (for the last seven months!), so this is one improvement that I am glad to see!

Interestingly, even with 500 units moving around the map, the pathfinding code only takes about 0.2% CPU time. That’s quite a bit less than I expected. The bottleneck now seems to be network bandwidth (again; even after I already made some optimizations). Also, depending on the view, my laptop’s mediocre ATI X300 graphics chip struggles to render all those units/trees.

The CPU for all tests was a Athlon 64 4000 (2.4GHZ).