Red Brick Games

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’ve started working on the game results screen, which shows player scores and other statistics.

One idea I had for this screen was to include a chat window.  That way players can discuss game results after the game is over.  I’m surprised so few RTSs have a chat feature here.  After all, nearly every first-person shooter game allows chat when a game/round ends.  Torque, included.  And since Torque already has this feature, including it into my results screen is easy.

One thing I’m finding not-so-easy though is programmatically creating the results screen from C++ code.  Torque’s GUI controls are really designed to be instantiated from TorqueScript - and from TorqueScript only.  I haven’t seen a single GUI control class that has a convenient C++ constructor.  I.e., a constructor that takes traditional arguments like position, text, parent window, etc.  In fact, most control classes don’t even have C++ accessor and mutator methods!  You have to set all control attributes TorqueScript-style.  What a nuisance.

That’s one of the problems in general I’ve found with Torque; some functionality is accessible from TorqueScript only, while other functionality is accessible from C++ only.

In other news: do you recognize these two fugitives?

Catch them in action in a re-release of this gaming classic.

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.

Code metrics, before and after the TorqueScript-to-C++ conversion:

TorqueScript:  773 lines / 2661 words
C++:          1219 lines / 3750 words

Wow, very impressive. TorqueScript needs only about 2/3rds the code as C++ to implement the same functionality. Very nice. These stats exclude code lines that are blank, comments, or only contain a single curly bracket.

As a side note, strictly speaking, I am actually not writing this game in C++. I’m writing it in my own home-brewed computer language, Meta-C. Meta-C is very C++-like, but is meant to be more concise and easier to write. Meta-C generates C++ code, which can then be compiled in the normal fashion. Here are Meta-C’s code metrics:

Meta-C:        882 lines / 2858 words

Huh, TorqueScript even beats my Meta-C language. My pride is injured

Very cool! Orcs vs. Martians is now creating workers, soldiers, and buildings from C++ code. It was exciting to see this work the first time. And both workers and soldiers are now pathfinding (moved that code to a common base class). I still need to move tree creation into C++, and re-hook up the workers’ harvesting behavior.Unfortunately, converting to C++ has made deletion of SimObjects a bit of a challenge. Back when the game logic was in TorqueScript and my objects were all held in SimSets, deletion was easy. Torque magically removes a deleted object from any SimSets that contain it, thus the game logic rarely needs to worry about stale object references. Not so now: my objects are now contained in STL lists, as C++ pointers. And accessing a deleted pointer will bring down the house in a hurry.

Hmm…there are a number of possible approaches here. It’s still possible to use Torque’s SimSets and/or object IDs in C++ code. Presumably the magical deletion can be made to work in C++ too. Also, one can use the SimObjects’ constructors and destructors to automatically add or remove the SimObjects from STL lists. I’ll probably try a combination of both those approaches, and see how it goes.

I’ve taken the plunge and started converting Orcs vs. Martians from TorqueScript, to C++. So far, I have C++ classes for Workers, Soldiers, Bases, Walls, Towers, Trees, Players, Races, the game Map, and some base classes for shared functionality. I should be done converting the server-side code today. It’ll be interesting to compare code size before and after the conversion. I’ll post metrics.I like TorqueScript ok, but when writing it I really miss C++’s class declarations. In fact I found myself writing commented C++ class declarations in TorqueScript, so I could remember my data members. I am very data-centric in the way I think and need a programming language that caters to that. Before I write much code for a new app, I usually draw an entity-relationship diagram which is one of those bubble-and-lines diagrams. An ER diagram shows the main objects and their “has-a” relationships to one another, and whether each relationship is 1:1, or 1:N (one-to-many). I love those, they help me see the big picture and remember it later. Based on the ER diagram, I then write the class declarations with one data member for every “has-a” relation.

I also really like to document my classes’ data members. If I know exactly what a data member represents, then later it’s easier to write new code that works on that data member, without introducing bugs. For example, if a data member is a file path, is it absolute or relative? or can it be both? can it be the empty string? if so, what does the empty string mean? If it’s a pointer, can the pointer be NULL? what does NULL mean? I usually document that kind of stuff next to each data member. I find it considerably more helpful to do that, than to document function bodies. In fact, if you ever look at my code, you’ll see heavily-documented data members and lightly-documented function bodies. Most programmers do the opposite, i.e document their functions, but not their data model.

Anyway, to do all that stuff, I need a language that supports explicit class declarations. Hence my decision to switch from TorqueScript to C++. Not to mention that C++ has easier class inheritance, static type checking, and other things.

The conversion itself hasn’t gone as quicky as I thought it would, despite the similar syntax between TorqueScript and C++. I’ve been working about four days to convert ~800 lines of TorqueScript (when I’m done it’ll probably be five days). I think the biggest problem has been that the syntax for accessing data types is very different between the two languages, despite similarities elsewhere. For examples, TorqueScript uses strings for Points and other “structures”, and ints for object handles. C++ uses explicit structs and classes, and pointers. So most of the code that access that data has to be changed. Also, it wasn’t obvious to me how to use TorqueScript’s schedule() function in C++, so I’ve converted its usage to processTick() everywhere. No complaints though, five days isn’t too bad. Be forewarned though, if you ever contemplate converting a large TorqueScript app to C++, it could take longer than you think.