Transcendence 1.0

Transcendence reached version 1.0 this past week, so I have been playing some of that. George Moromisato has been developing it in his spare time for the past fifteen years. Transcendence takes the basic flying and shooting action gameplay of the Escape Velocity series and enfolds it in a game that is otherwise heavily indebted to Nethack.

After picking a trader/fighter/balanced ship, you are off on a quest to reach the galactic core or some such. You get there by warping through a series of semi-random solar systems.

Each system has jump gates connecting it to the next and previous systems; exactly like the up/down stairs in Nethack. Instead of rooms forming a dungeon you've got planets which orbit around the central star(s). At the planets you'll find friendly bases with shops and quests, or hostile bases which will deploy a bevy of fighters against you. Looting wreckage supplies you with things to use or sell. There are space analogues for magic potions and scrolls of enchantment. You have a deity to whom you can make sacrifices and from whom you can request aid. You've got tinker bases that will transmute junk into items according to their own recipes. There is a gladiatorial arena for earning money by fighting other spaceships. You can even acquire robotic sidekick ships. And behind it all is the ticking clock of your fuel consumption: run out and it's game over.

Unlike Nethack the universe is not wholly hostile. Trading ships ply the major routes within each solar system, and the friendly bases may have fighters that will launch to defend their allies.

The game's interface has some holes that I wish would be patched up. It's cumbersome to examine your ship's current configuration for comparison while shopping, for instance. When you are submitting items to the tinkers for transmutation it would be nice if the list would only show things they accept; nicer still to see recipes for things so you know what to be on the lookout for when you're collecting loot. Quest management could be improved as well; there isn't currently any way (that I've found) to remind yourself of the details about what you're supposed to be doing.

I wish there were more ability to communicate with other ships in the area. Being able to respond to distress calls or request help would do a lot to make you feel more connected to the world. Also there seem to be quite a few space bases that don't really do anything which just makes the universe seem more boring. I haven't figured out what the pubs and nightclubs are for yet, and since I've never been able to figure it out I've stopped looking into them. If they ever do become useful I won't know, and that's just bad design.

On balance, though, the game does do a fairly good job of encouraging you to play just a little bit more to see what new things you will discover. It's free so give it a try if you are at all a fan of space games or roguelikes.

Grrrr...

Grrrr... not much to report.

I've wondered in the past if Haskell might make a good language for writing data compilers: something to take source art and turn it into something ready to be linked into the game. My thinking was that it would allow for concise construction of parsers, good error messages when input is ill-formed, and make it easy to morph the data through multiple representations in the compile process.

I needed some vector art for my lunar lander program and thought I'd just take SVG output from Inkscape and convert it to a triangle mesh for inclusion in my game. Seems simple enough. I don't know yet what the best way to represent graph structures like triangle meshes will be in Haskell, but I can probably dodge that for now.

Step 1: Install Haskell. There is an installer called the Haskell Platform which is supposed to be a one-step install for everything you need. On Windows it really hasn't been well thought out though. It installs to the Program Files (x86) directory by default, but Microsoft really wants this directory to be read-only apart from installation, which seems to break the Haskell package-manager's assumptions about what it can do. If you try to install to a different directory it doesn't respect that. Some things go to the directory you've specified but most things land back in Program Files (x86). Very unprofessional!

Step 2: Parse SVG. SVG is an XML format. There are five or six different XML parsers in Haskell with no clear indication of which one's “the one you should be using”. I have a book that uses HaXml so I look it up. It doesn't appear to be installed, even though it's part of the standard Haskell libraries. I run the cabal package manager to install it. Can't do it unless I elevate privileges to Administrator first. OK, that works. But on the web I see there's another one called the Haskell XML Toolkit; it claims to be better than HaXml. So I try installing it. It fails trying to install the curl library. After searching around on the web I find a thread from November 2008 describing what's wrong: the curl library installer depends on running a shell script of some sort, and on having the curl C library installed! So you need Cygwin installed. Once Cygwin is required you've lost me; sorry!

I'll try this out in Python next. I have a feeling it will be ridiculously easy.

GDC 2010

The Game Developer Conference came and went in a hurry. I was severely disappointed to find that Emily Short's talk was on Tuesday, before I arrived. Likewise there was a physics panel on Tuesday or Wednesday featuring folks like Erin Catto and Erwin Coumans who I would have liked to meet.

The one talk I attended that really enthused me was a half-hour introduction to R-Trees, an adaptation of B-Trees to spatial indexing. Sebastian Sylvan's main point was that our current situation, with processor speeds greatly outstripping memory access speeds (particularly random access due to cache misses) is exactly analogous to the old days of database programming where disk access was very slow. Many algorithms (like B-Trees) that were developed to mitigate disk-access problems are useful in avoiding cache misses.

There wasn't time to do much networking at the conference but I did manage to meet Andy Korth and Scott Lembcke, the duo forming Howling Moon Software and the creators of the Chipmunk 2D dynamics library that I use in my lunar-lander program. They just announced a space game under development titled “Solaro”. I'm looking forward to seeing that one.

Landing gear continued

I'll be at the Game Developers Conference this year; if anyone's interested in meeting up drop me a line: mcneja at gmail.

Is there anything so lovely or useful as a critically damped spring?

The basic differential equation:



This is saying that the acceleration (the second derivative) is a weighted sum of the velocity (first derivative) and position (x), measured relative to the desired velocity and position. The weights are expressed in terms of a constant omega which indicates the spring's response speed: higher omega means faster movement. The proportions of the weights are chosen to achieve critical damping: the spring returns to its rest position as rapidly as possible without overshooting.

To solve this differential equation we form and solve a characteristic equation:



Being critically damped makes the characteristic equation work out very simply. This then allows us to construct the general solution for position as a function of time:



The constants A and B are unknowns which we determine via supplying additional constraints on the problem, which will yield a particular solution for our problem. The first constraint I'll impose is that the spring is at rest position at time zero; the idea is that the landing gear is not stretched or compressed at the instant it touches the ground:



To solve for the constant B I'll supply a second constraint, which is that the spring is being compressed with speed v0 at time zero. This is the impact velocity. To use this we'll need to differentiate our general solution:



Plugging v0 into this yields the answer for B:



Now we have an equation for the particular solution of position as a function of time:



I have to get off to work now but suffice it to say there's a lot more tedious math where this came from. The next step is to replace omega as an input constant with something more useful: the maximum acceleration we want for the given impact velocity. To find this we have to check the extrema of the acceleration function, as well as the acceleration at time zero. Turns out time zero's acceleration is bigger than any other acceleration by a factor of about 40.

After that I've been working on adding gravity's constant acceleration into the equation which messes things up a fair amount, although the math's not hard.