Red Brick Games

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.

Just for fun, I tried using Windows’ tiny Terminal-6 font in Visual Studio on the L2335. With this font I get a whopping 202 lines of source code on a single screen. All your base! Here’s what it looks like. The picture was taken outside on my deck, where I sometimes like to work.

Success with networking and the game setup screen! I did some testing yesterday with two clients. The setup screens’ parameters correctly update on both clients as the players change their values. Launching the game also works, except when using the random map which still has some network-related issues.

I just upgraded from my six-year-old, 17-inch CRT, to a nice new 23-inch LCD monitor. I got an HP L2335, shown here. Like most 23-24″ LCDs, it is a widescreen display with 1920×1200 resolution.

I like to see as much source code on-screen as possible when I’m programming, so I’m excited to have a screen this big. Part of the reason I chose the L2335 over other monitors out there is that the L2335 has a portrait mode. I.e. where you rotate the monitor to be tall rather than wide. In that mode there’s 1920 vertical pixels for showing source. This is a big improvement over my laptop’s screen, where up til now I’ve been doing most of my software development. In Visual Studio 2005 with a 6×13 font, my laptop shows about 47 lines of code. The L2335’s normal mode shows about 76 lines of code, and its portrait mode shows 127 lines of code. It feels odd to be looking up and down that much vertical space (about 19.5 inches)!

I plan to use the L2335 mostly as an external monitor connected to my laptop (which in fact I’m doing as I write this). I’ve been very surprised, and pleased, to discover that my laptop’s VGA port seems able to display a clear image on this big thing. Conventional wisdom on the ‘net says that you need a DVI port to drive a 20″ or larger LCD, or else text looks too fuzzy. While I can detect a slight difference (my desktop system has a DVI port so I can compare), it still looks surprisingly good on the VGA port. Maybe HP ships really good quality VGA cables or something? At any rate, I had originally planned to buy an external DVI videocard for my laptop to drive this monitor, now that looks unnecessary. w00t

Off-center viewing on the L2335 seems excellent too. It’s hugely better than my laptop’s LCD, where you have to be sitting in exactly in the center for things to look right, and even then the top and bottom of the laptop’s LCD look slightly different from each other. The L2335 looks good even if you’re off-center by a freakin mile. “Ghosting” on the L2335 while playing games is nearly a non-issue as well; I can’t specifically see any ghosting, although with a first-person shooter I can just barely detect that the L2335 is not quite as smooth as a CRT. I think the only flaw in the L2335 I’ve seen so far is that its backlighting is pretty uneven. If you’re looking at a dark screen, there’s a big ol’ glow at the bottom of the monitor, and some lesser cloud-like glows in other various areas. It shouldn’t be a problem for looking at source code, but it might be a slight problem for some games, and might be a serious problem for using the monitor to watch movies.

Anyway, enough of that. Progress continues on writing Orcs vs. Martians. Albeit slow progress. I now have the setup screen mostly hooked up, and it now controls creation of computer players and the random map’s parameters. I’ve also improved the random maps a bit so that plateaus tend to be bigger, and I fixed a problem with jaggies tending to line the rims of plateaus, which prevented placement of buildings there. The random maps are looking better and better; the plateaus are becoming better spots for bases, and most plateaus are usually accessible via a slope or two even though I’ve written no code specifically to ensure that yet. However, the maps are starting to look  a little too smooth, to the point of being less interesting. I need to figure out a way to put in some rough terrain for variety, but without detracting from gameplay.

The setup screen, while now basically working for single-player mode, unfortunately still needs more work. Not all the networking considerations for multi-player are in place yet. I’m a little disappointed about how slow this feature has gone. It seems I’ve been on it for what, four-five weeks? Although, that’s partly due to a couple weeks there where I wasn’t working on the game much. Some other things came up (in non-professional life) that needed attention and I had to focus on them a while. I hope I can sit down and move things forward a bit more in the coming weeks. There’s lots still to do.