Review: Gravitron 2

Gravitron 2 is a retro-style arcade shooter in the vein of Gravitar and Thrust. You fly a rocket to a series of tiny planet surfaces, where you must destroy one or more reactors and then make your escape before the entire planet blows up. In addition to flying and shooting, the ship is capable of landing on any flat surface, which is useful for rescuing engineers. Each rescued engineer repairs a bit of hull damage as well as adding a bonus to your score for the level.

The ship controls are a slight update to the Lunar Lander family. The mouse's X axis directly orients the ship, and there is a button each for thrusting, firing, and shields. Thrusting and shields expend fuel, which can be replenished by landing or hovering near fuel depots in the levels.

The game has a nice variety of enemies. Levels often contain moving parts. There are occasionally gates with switches, and destructible trees. Each level has a checkpoint; when you first touch the checkpoint, it snapshots the enemies alive at that time. When you die the game restarts you at the checkpoint with the snapshotted enemies. Thus there is an incentive to try and clear as big a swath of the level as possible before touching the checkpoint, which is risky.

I have not finished the game; I think I'm about twenty levels in. I don't think the difficulty curve is as smooth as it ought to be (I'm reviewing version 1.5). Gravitron 2 is brutally hard in places; I've played some levels dozens of times to get through. I have a dormant game project that uses almost this exact interface, so I was already quite good at flying the rocket, and it is still really hard for me. In general the game does a good job of encouraging “Just one more try” gameplay, though. My two-year-old daughter likes watching the game; when I die she tells me “We have to try again!”

I was just over at the Chipmunk physics library page and noticed the game author's handle in the forums, so I wouldn't be surprised if Gravitron 2 makes use of the Chipmunk library for its physics. In general the game's physics is impressive, but there does seem to be some inconsistency in how much damage collisions with the environment do. I also wish the rocket didn't bounce quite so much off of walls.

There's a free demo available with the first five levels. If you like it, the full game only costs $5 (at this writing) so it's not a difficult purchase to justify. In terms of hours of gameplay per dollar this is a great value.

Ron “X-Out” Bunce has since updated his game to version 1.7, fixing several minor interface quirks and an instant-death physics bug. Give it a try!

Villa Creation (first steps)

Andrea Palladio published his Four Books of Architecture in 1570. He designed villas for wealthy people who lived in and around Venice.



Palladio was one of the earliest Neoclassicists. You don't have to read him very far to find out that he was heavily influenced by Roman architecture, in particular by the only surviving book by a Roman architect, Vitruvius' Ten Books on Architecture.

Palladio's villas were an attempt to recreate Roman style in the 16th century. His books were eventually translated to English and because of them Neoclassicism swept 18th-century England. Thomas Jefferson was a fan, and used Palladio's blueprints as a starting point for designing his home Monticello.

I had gotten the impression that Palladio's books might have given some rules for laying out his villas, but that turns out not to be the case. He does give a whole bunch of floor-plans in Book Two, though, which are quite instructive.

In 1978 Stiny and Mitchell developed a shape grammar by looking at Palladio's blueprints (“The Palladian Grammar,” Environment and Planning B 5). I have not been able to get a copy of this paper so I don't know whether it's worth anything.

Vitruvius's books are interesting in their own right. For instance, the section about where to locate the temples for the various deities is interesting. Apparently the worship of Vulcan involves lots of fire, so you want his temple well outside the city. The worship of Venus involves rites that prove distracting to upright young men, so Vitruvius recommends putting Venus's temple outside the city as well. Near the harbor, if you've got one.

---

I have turned from whole-city layout to the layout of individual buildings. It seems wiser to work bottom-up from a single piece of gameplay (the burgling of a building) rather than top-down.

My initial steps for randomly constructing a building are not very impressive. I am using an adaptation of the algorithm I used for laying out alleys. The rooms of the house are laid out on a grid. The walls of the grid are then given random offsets. Finally, the random offsets are made to match in either the horizontal or vertical direction (randomly chosen) at each junction, to ensure that rooms don't overlap or leave gaps. Additionally I impose a line of symmetry on the house. Here's what I've got so far:



To ensure that all rooms are connected by doors, I use a breadth-first search to flood-fill connections from the front door. Then I go through and randomly add other door connections.



The problem with the grid-based approach is that it is hard to have rooms that vary significantly in size. For instance, a lot of urban Roman houses have a central courtyard (to admit light) surrounded by a whole bunch of little rooms.



Still, having something is better than having nothing. I'm going to throw in some loot and guard patrols and see how it plays, and then try to think about how to give the houses more realism and character.

Science!

I'm having trouble getting back up to speed on my programming project, as no doubt is clear. Today I'm going to stop by the library to pick up Andrea Palladio's 16th century book on architecture. I've heard that it lays out a shape grammar for villas which would be useful in my project. That may be a 20th century paper by Mitchell and somebody else, though; I won't know until I can get my hands on some of it.

In the meantime science marches on:

Epazote: My wife tried making identical batches of pinto beans, one with epazote and one without. I could not really tell a difference, so either we had weak epazote or it doesn't add significantly to the flavor of beans. At least not in an unmistakable way like, say, chorizo.

Head On: A product with one of the most memorable no-budget TV advertising campaigns in recent history. We picked up a small tube the other day when we were at the pharmacy. It turns out to be a homeopathic headache remedy! Who knew? Of course it's got menthol in it: that's how you know it's working. I have an idea for a product of my own: a special lamp with a row of switches for enabling various rays which will cure headaches, insomnia, constipation, etc. It would make use of advanced LED technology and the unseen portions of the electromagnetic spectrum.

Cheesy Chipotle Chicken Chorizo Chili: How does this sound for a Taco Bell special?

Avatar, the last Airbender: I stayed away from this Nickelodeon series for a long time because of the cheesy name and four-elements premise (don't get me started on the four elements!) but enough people sang its praises that I finally borrowed the first season from the DVD library at work. It's a great show!

Coming back gradually

I got a new hard drive and have been gradually getting everything reinstalled. I'm taking the opportunity to upgrade in a few places along the way.

The 2008 edition of Visual Studio Express fixes the bugs that annoyed me in the 2005 edition: the inability to double-click on solution files in Vista, the extra security dialog check, and the inability to drag and drop files onto the Visual Studio editor. All of these are the kinds of things you'd think would be impossible to break in a long-running product like this, but they probably re-implement everything periodically just to keep life interesting.

Beyond Compare has a new version 3.0 out; they finally implemented 3-way merge although they charge an extra $20 for it. This diff utility is an integral part of my day job and I can't imagine working without it. There are much more expensive solutions out there (Araxis Merge) but I think Beyond Compare delivers some of the best value.

I'm getting more and more pissed off at Perforce, mostly because I'm the de facto Perforce administrator at work. I am unimpressed (version 2 of my post) with the current programming lineup behind this product. The current GUI client (P4V) is quite noticeably slower than their old Win32 client (P4Win) despite years of development and suffers from incredibly bad user interface design and a never-ending stream of bugs. As an example of the bad user interface, the Sync and Checkout buttons are adjacent on the toolbar. Once or twice every month somebody will select the root of the art tree and accidentally check out everything. This action is very quick and locks everyone else out from checking any of the art files out. Unfortunately reverting the checkout takes hours, unless you use command-line trickery. The old P4Win client, by asking the user “Do you really want to check out 60,000 files?” avoids this sort of problem. I've requested that they put this warning into P4V since it is present in P4Win, and I've reiterated that it's a problem four or five times, and in as many releases of P4V they have not done it. I haven't even mentioned the inexplicable problems with the user interface, like not being able to get the Submit dialog to appear, and I haven't mentioned the Qt debacle, whereby they used a DLL with the same name as a DLL in Maya, and from the same vendor, but with different function sets, thereby rendering either P4V or Maya inoperable depending on which came first in the PATH.

The Perforce server, which was written by the Wise Ones at the Dawn of Time, continues to be a most excellent piece of software. It's a shame that all we can do is gaze back in wonder and mystification at these relics of a bygone era.

I'm considering switching to a different version control for personal use. My criteria are: free, easy to install and administer, fast, and no “turd files” littering my work directories. A good GUI client would be nice too. Wish me luck; I have a feeling such a combination of things does not exist.

I've tried out Google Chrome for a while. It is a decent browser but has a tendency to get very thoughtful (shall we say) when you require it to share those 4GB of RAM with other programs.

Finally, Jungle Disk was the real star of this computer breakdown. I was able to restore my backed-up projects with no trouble. They've continued to improve the interface of the client.

---

It's past time to return to work on my little game; I've been getting antsy while my computer's been out of commission. Fortunately there have been things like crunch time at work to fill the void. I'm looking forward to getting back to work this week, though.

Computer Problems Continued

I've isolated the problem to the hard drive. In the meantime I've been doing some thinking about the overall project I've been working on.

I've been contemplating two large changes to my thief-like/rogue-like. The first is random level generation. Before the computer crash I was working on a prototype for generating a full city. I envision the city as consisting of several large compounds which are the focus for thieving missions, surrounded by houses, shops, and so forth.

The main thing to consider with this is what gameplay purpose all the embedding city will serve. I run the risk of having large useless tracts of homes that just create unwanted travel time; or perhaps a level that will take too long to complete.

One idea I might try out is to have a kind of “inverse collectible”. I've been thinking about making gold into an actual currency rather than a strict collectible. In that case, I need places to spend gold. Taverns are an obvious thing. I was also thinking about having a “Robin Hood” style situation where you can distribute gold to the smaller homes. Perhaps homes would have little shrines into which you could deposit gold.

This opens up a lot of design issues. Can you retrieve the gold later? How does this change the main character's motivations? Do you get any sort of reward for doing this? I'm not convinced it's a good idea yet.

The other major feature I've been considering for the game is sidekicks. This could obviously be another gold sink. It might also help with the “heist” feel as you would need to plan out an operation ahead of time. This amounts to a whole new user interface element in the game, though; plus I would need to create the AI for the characters. So I'm trying to decide whether it would be an effective part of the game. One of my worries is that the AI characters would do interesting things that should properly be done by the player for maximum entertainment. Ideally they would either do things that the player can't do himself, or would allow tactics that aren't possible solo, or would make boring things less boring.

The Fire Emblem series of games (or perhaps Baldur's Gate) are a pretty good model of how I would envision sidekick characters interacting with each other. Basically there are little plot threads involving pairs (or in rare cases large configurations) of characters; if you have the proper character set assembled for a mission, another bit of that plot thread plays out. Sidekicks would also have plot threads that tied each of them to the central villain in some way, to help keep the player's focus on him.

Computer Problems

No post today. My notebook computer is dying. It's a ThinkPad T61 bought last year so I am annoyed. The symptoms so far are that it locks up after waking from sleep. The mouse cursor can be moved but it does not respond to keyboard or mouse buttons.

Fortunately things are backed up but it will take some time to sort through the problem.

You might think that programmers love computers more than the average person. Not true at all!

Flood-filled elevation

I sat down to eat in the Seattle airport last Thursday with a guy who unsurprisingly turned out to be a programmer. We talked a bit about Gaussian blurring; he was saying that for filter sizes much above 5x5 it was quicker to do the Fast Fourier Transform and do the blurring in frequency space. I spent some time trying to figure out how I might be able to do that. The pegging of the river to zero complicates things. Since I'm doing a bunch of steps it ought to be possible to replace them all with a single step with a really big kernel, but since I'm re-pegging the river in between each step I am not sure that would translate to the same thing at all. Maybe I could do half as many steps with a slightly larger kernel (in frequency space) instead.

On the plane back from Baltimore yesterday I tried a quick experiment. Because the Gaussian blurring is so slow I thought that if I could come up with a better first approximation I could get away with doing less of it. I tried flood-filling initial elevation data, working outward from the river. Each node is slightly higher than the highest of its neighbors that have been defined so far.

Unfortunately the quality of this is pretty bad:



Here are some resulting roads:



Overall I'm not sure that having roads primarily follow or cross the gradient is what I want. I may dive in and try to understand the L-system-based approach that Mueller's original paper describes. The writing is impenetrably bad, as is typical for academic papers.

I'm starting to feel like the terrain generation is eating up too much time. I'll probably just settle on something for now so I can move on to other aspects. I need to figure out if and how having a large city will be fun, and I need to work on plugging buildings into lots, generating patrol routes, street lights, and so forth.