Red Brick Games

Lately I’ve been hitting freesound.org like mad. That is such an awesome website.

This is a really good time to be an indie game developer. So many quality tools and resources are available for free, or for nearly-free.

Tools and resources such as:

• Audacity - free (a VERY nice tool!)
• Blender - free (amazing…though hard to learn)
• Blender Torque DTS exporter - free (the docs for this are FANTASTIC!!!)
• Freesound.org sound files - free (mostly)
• Ogg Vorbis tools and codecs - free
• OpenAL drivers - free (x-platform audio spec)
• OpenOffice - free (ok, so it’s not about game dev, but ya gotta do project management!)
• Paint.net - free
• Perforce source control - free (up to 2 users)
• RTS environment pack - $40 (for the indie license; bigger projects=more $)
• Torque 1.5.2 Game Engine - $150
• Torque Showtool pro - comes free w/ Torque 1.5.2
• Visual C++ 2008 Express - free
• WinMerge - free

- - - - -

The costs to break into the indie game industry are mainly just one’s own labor. (Although, that there is a considerable expense!)

A big thank-you to anyone who has contributed to the open source tools in that list! They’re much appreciated. And great quality! Thanks!

My development laptop no longer boots up. It loads a few dozen Windows drivers, then hangs.

What a nuisance. Moving a software development environment to a new machine is such a hassle. I’ll need to re-install at minimum

Visual Studio
Perforce
Winmerge
VirtuaDub
Audacity
Fraps
Ogg codecs
Ogg command line tools
Blender
Paint.NET
Gimp
UnxUtils
Open Office
Torque SDKs and tools

and I’m sure there are others I’m not remembering at the moment.

Oh well. I guess it’s a chance to get the latest versions of everything.

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.

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.

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

I’m happy to say, Orcs vs. Martians can probably be called an actual game now.  I’ve added the logic to detect when a game is won, and when it is, the game ends and shows the results screen.  That, coupled with improved AI, has made OvM start feeling like a real game.

…not a game that people would buy, not yet, but a game nonetheless :)

Some things that are working now:

Game results screen
I’ve got this screen grouping teams together and showing them in the order of team scores.  Individual player stats are visible too.  It’s got “progress” bars behind the scores/stats, in the same style as Starcraft.  I plan to colorize the bars to make it easy to see the individual players’ contributions to the total team stats.

In this game I teamed up with our old friend, Kork, and went after three AI teams.

Sadly, Kork and I got trounced.  @#$% Martians.

Unit-level AI
Military units now spread themselves out around their base to protect it better, and run to engage nearby enemies.  They also return if they wander off too far.  Ranged units are now smart enough to go only as close as necessary to bring their target into range, maximizing their advantage over melee units.

Melee units
There are melee units now!  Orcs have axemen, Martians have battle-bots, and humans have swordsmen.  (Each race now has three unit types: melee, ranged, and worker)

Networking
I fixed several bugs and crashes that crept in since I last tested networked games.  LAN games now work again, although with some visual artifacts.  I also made some progress on getting random maps to work in networked games, but that feature is still a work in progress.

Password-protected servers
Hooked up the GUI to the logic for this feature, and verified it works.  (this was a minor effort since Torque does most of the work)

Installer
I got the installer done!  It includes the ability to un-install via Windows’ Add/Remove Programs, and to create Start menu shortcuts.  The only thing it doesn’t do yet is put a shortcut on the desktop.  The installer is a single setup.exe, currently weighing in at 12MB.

I created the installer using NSIS.  Before chosing NSIS I read nothing but praise for it, but after using it I am slightly disappointed.  True, NSIS is pretty easy to use.  But -

For one thing, an NSIS installer’s GUI looks significantly different from the standard Windows installer GUI.  That’s a downside, especially for an indie application.  When you think about it, a user who installs an indie app is taking a certain amount of risk.  How does the user know the app doesn’t contain spyware, or other hidden malware?  After all, the indie company is some tiny entity the user has never heard of.  If the app has a windows-standard installer GUI, that lends a certain credibility to the app, and helps reassure the user.  It increases the chances the user will trust the app and eventually buy it.

Also, the syntax of NSIS’s internal installer script is the “clunkiest”, for lack of a better word, syntax I’ve ever seen for a scripting language.  And NSIS isn’t smart enough to simply un-install the files that it originally installed.  You have write an explicit uninstall script, like you wrote the install script, leading to redundant code.

—–

It’s been pretty fun test-playing the game, now that it’s playable.  Martians are by far the most powerful race, owing to their high-tech weapons.  But Martians also have the fewest hit points, so if the Orc horde ever manages to get close, it gets ugly fast for the Martians :)

Orcs are the second-best race, owing to immense hit points, pretty good speed, and powerful melee attacks.

Then there’s the human race…poor blighters :)  They’ve got neither good hit points, nor powerful weapons.  They tend to lose.

I think I will give humans the advantage of the best technology tree, which will eventually allow them to upgrade their weapons, if they can survive long enough.  To help them survive, I’ll probably give them the strongest buildings. (which kind of makes sense…Orcs aren’t known for good buildings, and the Martians have crash-landed, so they don’t have much in the way of construction tools.)

I’m not sure how far I’ll let humans upgrade their technology.  Hmm… it would be funny to see Middle-Earth humans attacking the Orc horde, with gatling guns :)  Or with a thermonuclear device.  Humorous possibilities abound, for this game.

I mentioned earlier that I’m writing Orcs vs. Martians in a home-brewed programming language, Meta-C. Meta-C gives me a chance to experiment with the design of a programming language, to try to make programming easier.

To me, “easier programming” means

1. less code is required to implement a particular feature
2. the code is easier to maintain and refactor as the app evolves

So I made Meta-C to have the same syntax as C++, but modified it to be less verbose, and to require fewer changes when the architecture of the code evolves. (Excuse me for going a bit off-subject about a programming language probably nobody will ever use but me, but I like this stuff : )

Here’s an example that illustrates some of the improvement possible over C++. Orcs vs. Martians has a function that looks for the nearest enemy base. It’s a small function, and it does three fairly common things; it:

1. iterates over a container (all the entities in the game map)
2. tests elements of a certain type (”Bases”)
3. returns the “best” element by some criteria (the nearest base)

Comparing the C++ and the Meta-C implementations of this function is pretty revealing. First, here’s the C++:

01   Base* Base::getBaseToAttack()
02   {
03      Base* ret = NULL;
04      for (set<Entity*>::iterator ent = gMap->getEnts().begin();
05           ent != gMap->getEnts().end();
06           ent++) {
07         Base* base = dynamic_cast<Base*>(*ent);
08         if (base)
09            if (isEnemy(base) && (!ret || distTo(base) < distTo(ret)))
10               ret = base;
11      }
12      return ret;
13   }

Now, here’s the Meta-C:

01   Base* getBaseToAttack()
02   {
03      for gMap.ents,Base*
04         if isEnemy(base) && (!$ || distTo(base) < distTo($))
05            $ = base;
06   }

With Meta-C, there’s much less code! Mostly, because

1. Meta-C’s “for” keyword natively understands STL containers. When its argument is an STL container, it automatically generates that ugly STL iteration code
2. “for” also takes an optional element type (”Base*”), when you only want to iterate over elements of that type
3. The “$” symbol means the return value of the function. If used, Meta-C automatically generates its declaration and a return statement for it in the function
4. other minor things you can probably pick out

Not only is there less code, Meta-C requires less re-work as the application evolves. For example, if the following changes happened, here’s what the impact would be on the two implementations of the function.

1. if the type of the container changed, e.g. from a std::set to a std::list, the C++ implementation would need a change to its “for” loop. The Meta-C wouldn’t need any change.
2. if the function’s return type changed from Base* to something else, the C++ function would need changes in four places. Meta-C would need changes in two places.
3. if a dedicated “gMap.bases” container was created that contained only bases, and you wanted to iterate over that instead of the “gMap.ents” container that contains all game entities, the C++ function would require several changes: changing the two instances of “gMap->getEnts()” in the for loop to “gMap->getBases()”; deleting the lines doing the dynamic_cast operation and testing its result; and un-indenting the 2nd if statement. Meta-C would only require one change: from “for gMap.ents,Base*” to “for gMap.bases”.

I like this language :)

We now return you to your regularly scheduled blog.