Barricaded Doors

Miscellany today:

In SpaceRL, I added barricaded doors that can only be opened from one side. With these, the level generator can control the order in which the player encounters rooms in the spaceship, while allowing the player to subsequently take shortcuts across the level.

I also added a slight refinement to the way the level generator places doors. It first creates the ship's original door layout, then replaces some of those doors with barricaded or broken doors to restrict the player's travel path. Previously it was only doing one pass to establish the connectivity of the ship's rooms. With this algorithm there is a slight bit of history implied in the level, as you can see the ship's original symmetric, non-maze door layout underneath the current restricted connectivity.

Separately from this I've been experimenting with learning Javascript. It's not that bad of a language, so far. I had a C program I wrote with a friend many years ago to generate random RPG names; it was designed to be run on a web server to generate a web page. Hardly anybody does things this way any more. As an exercise I rewrote it in Javascript; the server only has to serve up the page and the client's browser does the rest. It's around 10 KB, most of which goes into the word lists. Unfortunately none of the free Google things (Blogger, Sites) are good for serving up Javascript so I can't easily demonstrate. Maybe it's time to get my own domain and hosting again.

I logged into Facebook (as I do every other month or so) and discovered that Chad Jones, an artist with whom I worked on two games over the course of four years, has written an e-book about his last decade-plus of experience working in the games industry. It's a dollar and a good read, especially for anyone thinking about going into games. It's available for Kindle and Nook. The book's called “Laid Off” which in boxed games development is the usual disincentive for shipping a product.

Symmetric Starship Doors

This week I took a break from working on my lunar-lander game to go back and fix the level symmetry in a simple game I made a couple years ago.

SpaceRL (unimaginative working title) is a turn-based, grid-based, Roguelike-inspired attempt to represent zero-gravity motion; in particular, the ability to shoot a gun in one direction whilst floating in another direction. It's inspired by the cover of Tobias Buckell's book Ragamuffin:



The game is very simple at the moment: survey derelict, monster-infested starship wrecks and identify the crew remains. The basic combat maneuver is shown above: get some monsters following you, find a straight corridor, kick off, and blow them away as they pursue.

Coming up with level design that suggests a starship was an interesting challenge. I want something that appears to have been constructed along an axis of symmetry but that due to barricades and debris can no longer be navigated straightforwardly.

This week I finished making door placement be symmetric across the central axis. I also experimented with making the levels into simply-connected mazes. If there is only one way to get to each room from the entrance, the player will need to backtrack more in the process of visiting every room. Whether this is fun or not is debatable; it depends on whether revisiting rooms is interesting. I've thought about having the player eventually find the artificial gravity controls, for instance. Gravity would remove your ability to move and shoot simultaneously, which would change the experience.

The more-likely solution will be the typical thing of having shortcuts back toward the root of the tree that the player can open up. For instance, there might be a door that is barricaded from one side; once the player gets to that other side via a round-about route they can un-barricade it and take the shortcut.

Here are four versions of the same map:

Asymmetric

Symmetric

Asymmetric Maze

Symmetric Maze

The percent signs in the maps represent destroyed doors. They are there to imply that the original layout was symmetric even if the current connectivity is not. The “symmetric” level style means the generation algorithm attempts to connect matching pairs of rooms on opposite sides of the symmetry axis at the same time, rather than leaving it to chance. Without it there tend to be more destroyed doors.

Here is one more ship layout, this time with a horizontal axis of symmetry:

Caves and Orbiting Debris

This week I did a couple of small experiments with the terrain generation. One was to make the base density function (before applying noise) have a couple of concentric rings with space between. The noise function breaks through between the layers to create entrances to the caves. (Actually the base density function has a couple of built-in holes between the layers too.)

I also threw in some orbiting debris to see what it feels like to fly through it. At the moment it is just discs.

The terrain generation needs to have more smarts about area accessibility. I think I'm going to evaluate the density function onto a grid roughly the size of the rocket (maybe slightly larger). Then I can do evaluation at that level to figure out which areas are accessible, and add in terrain features. One of the things I want to do is generate a couple of background layers: one that gives caves a back wall, and then another layer or two that represent far-away mountains (and maybe move with some parallax).

Gatling Gears

Rose accidentally bought Gatling Gears on the PS3, so I played it. It's a twin-stick shooter in the Robotron vein, set in a steampunk world.



Copious, slow-moving patterns of bullets (“bullet hell” I think I've heard it called) are a game mechanic that came out of games like Raiden. This mechanic seems to be getting mixed in to more things these days; Outland combined it with side-scrolling platforming (and Ikaruga's phase-changing) recently, for instance.

Unfortunately Gatling Gears looks unfinished in some respects. The gameplay apart from the bosses is very monotonous. I actually found myself looking forward to the bosses which is a reversal from the usual.

The story is nearly nonexistent. There are story cards inserted between the half-dozen chapters, and printed dialog exchanges at points during the gameplay, which you're apt to miss if you are busy. What story there is seems trite and predictable. You're best off reading Scott Westerfeld's Leviathan series (my review) and imagining that story overlaid on this game. It works pretty well.

The graphics are lovely, though. I am going to go back through the game and try to figure out how the environments were assembled.

Stealing the computer away from my daughter's Minecraft session to make a quick post.

I did some work on learning Blender and straight-away ran into something it can't do: individual edge/vertex beveling. It has an overall bevel modifier which can accept per-edge weights but it is not something you'd use as a poly modeling tool. Searching on the forums reveals that this has been a long-standing lack. Sigh. Well, Maya has a similarly baffling omission; you can't do proper insetting in a face in stock Maya. So they're all lacking something.

Salvage and rescue is the theme I'm working with at the moment. I'm trying to imagine how a spaceship would decompose into constituent parts in a 2D world. Here is some amateurish concept art:



I'm thinking there would be a couple of layers of spaceship: some skin pieces that could be removed, and then various modules underneath that could be salvaged for money. There might be an inaccessible background layer to the spaceship that has its skeleton, too. With 2D art it's not clear to me yet how this all goes together. Maybe the skin parts should just blast off and disappear; otherwise people will expect them to tumble like metal sheets, which they can't do.

Blender 2.5, Planning

I've spent this week doing some planning. One of the things I'm thinking about is how to streamline the process of putting new things into my game. Being able to author the physical parts of them in a modeling program is one way the process could be improved. Yes: the dreaded art pipeline approaches. (Some of my friends who have been involved in startups say that the art pipeline took a lot more engineering resources than they anticipated.)

I have worked extensively with 3D Studio Max in the distant past (I used it for versions 1-3 or so), but the last eight years I've worked with Maya. Of course they're both owned by the same company now. A legitimate copy of Maya runs about $3500, so I'm going to pass on that for now. Blender, the open-source equivalent, looks like it ought to fill my needs. I've been spending time learning how to get around in it.

Blender 2.5 switches to Python 3, with considerable API rework at the same time. This makes a lot of the example code on the net obsolete. Documentation is still a work in progress, so get comfortable with the dir, list, and help commands in Python.

There are a couple of possible ways to export geometry. I'm going to experiment with having the makefile detect when a source Blender file has changed and run Blender at the command line to export it to an intermediate file. The command looks something like this:

blender -b input_file.blend --python my_export_script.py

Restarting Lander Development

The past six months have been very busy at work. We also experimented with having my computer out in the family room, where the TV is.

Now it's back in the bedroom, and work's less hectic. I'm restarting work on my Thrust-alike with an eye toward getting something done and released, even if it is dirt simple.

There are so many things that need to be done it's been hard to decide where to start. At the moment I'm sorting out issues with having planets of different radii. Gravity ramps up linearly as you move from the center of the planet toward the surface, then falls off quadratically as you rise above the surface. The planet's radius was 1.0 which made that pretty simple.

After that, I will probably put a bit of effort into coming up with slightly more interesting planets to fly around. The camera continues to be a problem spot, so I'll keep trying things there.