Red Brick Games

Players can now choose their race! (screenshot on left.) Race currently determines team affiliation, so this feature now allows human players to compete head-to-head. This was a simple feature to implement, once I figured out how. Race selection is done client-side, but must be passed server-side to take effect. As it turns out, Torque makes this easy by letting a client pass an arbitrary number of parameters to a server at connection time. So adding your own game-specific connection parameters is simple. However, figuring that out was not so simple. I spent a good bit of time browsing the source code before getting it.

The next screenshot shows the base status again, this time showing the correct resources and workers for the base. Something else new is that the base building is now casting a shadow on the terrain, though it’s a little hard to see. The status is currently positioned a little too low over the base; that needs some work.

The next three screenshots show base building. There’s now a green “base planning” marker, that follows the mouse pointer around to show when a player is planning a new base. Bases currently occupy four world tiles (2×2), and the marker aligns itself to the tiles to show exactly where the base will be constructed. Green means the current site is ok for building, red means it’s not. The 2nd screenshot shows a base as a worker is building it, and the 3rd shows the finished base next to the original base.

Also, that 3rd (two bases) screenshot shows the building multi-selection feature working. Yay! I’ve tested this feature a little, and it does seem to improve gameplay and reduce micromanagement nicely. You can issue production orders and change rally points, for multiple bases, with just a few clicks.

The next two screenshots show a red building marker over sites where you can’t build; over an existing building, and on a slope.

The last screenshot shows a couple of new game elements, walls and towers! I was originally thinking that bases would be the only type of building in the game, but walls and towers are just too much fun to leave out. What can I say? :-) I think defensive structures add a lot to a game. And since they’re basically optional to build, they shouldn’t put off casual players (who don’t like too many choices) too much. At least that’s the theory. I’m planning for these walls and towers to behave much as they do in the Age of Empires games. Although, I might also allow units to walk along the tops of walls, that wouldn’t be hard to do with my pathfinding algorithm. Each wall block and each tower occupies a single (1×1) world tile.

Day 9! I’m considering using this RTS art pack (and this one) for Orcs vs. Martians. At first look these packs seemed too cartoon-ish for me, but the more I look at them, the more I like them. The art style is bright and colorful and matches the light-hearted spirit of Orcs vs. Martians. It’s also the kind of style that should appeal to the casual gamer crowd. Plus, polygon counts are low, and RTS units should show up very clearly against that terrain.Previously, I was thinking of using this art pack. Some of the artwork there is just stunningly beautiful (click and see). However, it is more realistic-looking, and seems better suited for my 2nd game, which’ll come after Orcs vs. Martians.

Been doing a bunch of misc. programming work recently, organizing code, filling in corner cases, hooking up the base status display, finishing the selection logic, fixing bugs, checking out Visual Studio 2005, etc. I think I’m going to move the code for the game’s units & buildings from TorqueScript to C++. TorqueScript’s facilities for polymorphism and class hierarchies is just too awkward for my taste (although it does have such facilities, which is fairly impressive in itself).

Next up, I need to hook up the pathfinding algorithm to work with soldiers in addition to workers. The squad/formation movement also needs improvement to be usable.

Making good progress on the unit selection behavior. I plan for selection to behave in a “Starcraft plus” way, meaning it’ll have the same behavior as Starcraft plus a few enhancements. One enhancement will be that multiple buildings may be selected, which is not allowed in Starcraft. Another will be that ctrl-clicking (or double-clicking) a unit will give priority to multi-selecting the nearest units to the unit clicked. This’ll make squad grouping easier. In Starcraft, ctrl-clicking selects units randomly all over the screen with no regard to proximity.

I also started work on selection ring colors. Your own units will have green rings, allies will have yellow, and enemies red (screenshot on left). I think I’m going to need two different resolutions for the selection rings, one for buildings and one for units. Currently the ring looks too thick around buildings and too thin around units because it’s the same bitmap, scaled.

The Torque + STL issue may be resolved, hooray! It required inlining one function, and building Torque with TORQUE_DISABLE_MEMORY_MANAGER set. My only reservation is that this solution turns off Torque’s real-time memory manager. I’m sure there’s a reason the Torque developers wrote their a custom memory manager, so I’m wary about turning it off. The normal C run-time’s memory manager may be more prone to “hiccups” and less smooth gameplay. We’ll see, I’ll leave it set this way for a while and watch for problems.

Last week marks a milestone for me, as I left my old job (and a steady paycheck) to become a full-time “indie” developer. Today is my 2nd day at it. So far, no worries! I’m loving it. I relish the freedom and responsibilities that this new venture entails. I have 23 years of programming experience and a couple of years of Ph.D. work in geometric modeling, and I plan to put them all to good use. The risk of this venture is, of course, that I’ll have no income until I release my first product. But that just makes this career move more exciting.

I posted a bunch of new screenshots of Orcs vs. Martians on the left. The first one shows a new status bar on bases. The bar displays the number resources and workers that a base has. It’s necessary because I plan for each base to have its own, dedicated collection of resources, unlike the single, global pool of resources that other RTS games have. I think this will add an interesting territorial aspect to the game. Once an area runs out of resources, it will become difficult to defend. To counteract that, a player can build infrastructure, like roads or railroads, to ferry resources from resource-rich areas to the areas with factories and such. This should allow some interesting strategies for attacking and defending lines of supply.

The next three pairs of screenshots show improvments to the game’s pathfinding algorithm. The 1st screenshot in each pair shows the path found by my previous, tile-based pathfinding (the path is shown as a green line). Notice the kinks and “jaggies” in the original path. The 2nd screenshot shows the same path, but after a smoothing algorithm has been applied. The jaggies are almost completely gone, resulting in nearly-natural path for units to follow. The smoothing algorithm still needs some work, but overall I think this puppy is nearly ready to roll. Performance is good too! I’m using Micropather in the most inefficent way possible, yet the pathfinding still seems almost instantaneous.

The next four screenshots just show the pathfinding algorith in action: figuring out to cross a river in the shallow part; finding a roundabout way up a hill because the direct route is too steep; and finding a couple of very long paths across nearly the entire map.

Next tasks up will be to fix up the selection logic for units and buildings, which really needs improvement. It’s currently both hard to use, and buggy. Then, there’s still an STL issue with using Torque and Micropather together that needs addressing. I got release builds to compile ok (though I’m not sure I did it “right”), but I haven’t gotten debug builds to compile. Or more specifically, they won’t link. The linker sees multiple definitions for operator new and fails. I’m not yet sure exactly why this is, but I do know that not having debug builds is Bad Thing. So I’ll also be trying to get Torque and STL to peacefully coexist.

Pathfinding is coming along nicely! More tomorrow.

Development is still coming along splendidly. The game’s UI is now working. The player can now

• build workers
• build soldiers
• build new bases
• set rally points from bases
• select units
• send units to attack other players

Also, networked multiplayer games now work! I can’t believe how easy that was to get working. Thanks, Torque.Unfortunately though, I have run across one major “risk item” with Torque. You can’t use STL in the Torque engine! The STL header files won’t compile, the result of Torque doing some funky stuff in overloading operator new. The bottom line is that no compiler translation unit can see header files from both Torque and STL, or things blow up. You can use one or the other, but not both (and actually the problem is slightly worse than that). I’ve got a bad feeling this is going to be a very big headache for me. I’ve been planning to rely heavily on 3rd-party C++ libraries to write this game, but nearly every modern C++ library uses STL.

Speaking of 3rd-party libraries, I’ve started using a path-finding library called micropather. A pretty neat library. I now have very rudimentary path-finding working. Units now walk around bodies of water in the map, staying on land (except for shallow water, which they can wade through). It’s pretty crude at the moment, as the movement is jerky, and units only walk along 90-degree or 45-degree angle paths now. There’s a good bit more work to do to get it polished.

The exciting thing, though, is that I think I see how to do pathfinding and still support all the game features I want to implement. I want units to be able to dig trenches, which will cause existing paths to become invalid while the game is running. I also want to allow players to build buildings adjacent to each other, which has the same blocking effect. In addition, if a building gets destroyed, a previously closed path becomes open again, so my pathfinding model has to handle that too. I think I see how to support all these features with micropather and the A-star pathfinding model. This had been an open question for me up til now, so this is a good thing.

Starting Feb. 11th, I’ll be working full-time on this project (whose working title is now “Orcs vs. Martians”).