Some Thoughts

I came across a great talk today by Matt Gilgenbach of 24 Carat Games, which gave me a lot to think about. As a lone developer with a limited budget (I'm also self-funding) and limited time, it's important to prioritize.

My current habit is to look at what I've accomplished so far and think, OK, in what way is it most obvious that this isn't a finished game? Whatever the answer to that question, that's what I work on next.

I still think this method is going to work if I stick to it. In fact, I have renewed confidence that it's the right way to work. But what I now think might not work is the current art style of the project.

I've been designing with a view to a semi-realistic 3D art style, but I'm going to look into dropping that for a simpler, more abstract look. Most of the graphics are still placeholders, so this won't mean much wasted work.

As Matt says, as an indie, you aren't going to compete with AAA studios in terms of graphics. I'd be better off spending that time on level design, game features, gameplay polish and the level pit.

Realtime AO

Before

After

If a friend is trying to convince me to try a new game, the first thing I always say is, "I dunno... how dirty are the floors? The corners, especially?" I'm sure you're the same. As we all know, the best games have dirty floors and filthy corners, which is why ambient occulsion was invented.

Ambient occlusion (AO) is a technique used to make CG scenes appear more realistic by darkening surfaces near corners. Used subtly, this can add realism as corners and crevices are less accessible to light, making them darker. Used less subtly, it gives a distinctive dirty appearance.

Modelling AO the physically correct way is still too computationally intensive for general use, so if you want it in your game, you have to fake it. I'm doing it with a precarious conglomeration of textures, render passes and stencil tests. I think it's looking pretty good. And it works on moving objects, too! You'll have to take my word for it for now, but you'll see in the next video.

Mechanics

I've just finished rewriting the mechanics code, which I had been putting off because it's so bloody complicated. But it's done now, which is great news because now the game engine itself is feature-complete.

Fun

Blackshift's mechanics system is what I call the code that handles pushing blocks, deciding what is pushed by what, what gets to move, what doesn't, and what is crushed. It's not a full physics simulation, it's much simpler and more abstract, which ironically makes it more difficult to code. Why? Because fake, abstract physics is specific to your game, whereas more realistic physics can be achieved using off-the-shelf libraries with little or no modification. Neither is better, but each suits a different type of game. Of course, you're free to use the wrong sort of physics for your game on purpose...

Not Tetris 2, Stabyourself.net

Blackshift's mechanics are, in a nutshell:

1. The player, enemies, arrow blocks, and anything on a force floor generates a force.
2. Forces propagate through blocks.
3. Clusters of sticky blocks always move together.
4. Once all the forces are propagated, anything that can move does.
5. Anything that can move in more than one direction moves in the direction of the strongest force.

There are some other rules as well, to deal with annoying questions like "What happens if a cluster of sticky blocks has two different force floors under it?" and "Can arrow blocks push each other?"

In the end, I'm happy with how the mechanics work and I think we'll be able to get a lot of puzzle mileage out of them, especially when combined with the four sorts of blocks:

1. Normal block; can be pushed and can push other blocks along in long columns.
2. Heavy block; can only be pushed by the player, not by other blocks.
3. Arrow block; pushes itself in one of four directions.
4. Sticky block; always moves together with adjoining sticky blocks.

That should be enough for now, but if I think of any awesome new blocks (that won't mess the code up) I won't hesitate to add them. Any ideas?

(I'll post a video of the new mechanics in action once I'm free of all these embarrassing placeholder graphics.)

Editors and Economies

It's easy to throw together a quick and dirty editor where the user has to memorize 300 keyboard shortcuts and there's no undo, and for some games that's the right thing to do because it means you get to spend more time making a fun game.

But for Blackshift I want the editor to be a core part of the game, and to encourage users to make and share their own levels, so I'm taking the time to do a nice GUI (and boy does that take time!)

I've got a few ideas for ways to take what at its heart is a single-player game and give it an online bit. One thing I'm definitely doing is integrating a usable editor, and letting users browse and play others' custom levels from within the game.

If I've got the time, though, I'd love to experiment with some of these ideas:

The level pit — Watch other people beat your level or fall into your traps. Rate, comment & follow level creators.

An economy — Players spend coins to put unique and interesting things in their levels. Put a bounty on your level, giving other players money when they complete it, to attract punters. Or, require an entrance fee for them to try.

Deathmatch — Two, three or four players playing the same level at once, trying to kill each other instead of finding the exit.

Still working on those graphics

I can't go for too long without doing some graphical work because, for me at least, it's just no fun to play a game with placeholder graphics. Still not all the way there yet, of course, but normal maps and some tasteful light halos go a long way.

(Once again, the extra fidelity of 3D raises new questions — now I've done the random enemy as a walking lava cube, I'm going to have to make it the one enemy that can't go over pits, lest it look weird.)

Enemies

The game's developing a bit of a lonely feel. Just you, in space, wandering around uninhabited space mazes. Let's make things more interesting by adding enemies.

I've gone into a bit more detail than usual on this post. Also, if you're using a recent Chrome, Firefox or Safari, there are animated diagrams!

So. The first thing to think about is how the enemies should move. There are a few obvious patterns:

• Move up and down
• Move from side to side
• Go straight and turn when hitting a wall.
• Follow the left wall or the right wall.
• Follow the player.
• Move randomly.

For the patterns that involve turning left or right, we can define two versions of that enemy, a "left-handed" one which turns left and a "right-handed" one which turns right.

So, let's think about how to implement these enemies. What do they all have in common? Well, they all need to decide where to go next as soon as they enter a new square. The difference is in how each enemy makes that decision. Let's start with the simplest, the up-and-down enemy.

Here is a first-draft "decision function" for this enemy:

• If you can go forward, go forward.
• If not, turn around.

Looking at this, you can see that it would work not only for the up-and-down enemy but also the side-to-side one; the only difference is the initial direction. So, we can consider both these enemies to have the same movement pattern; let's call it the Oscillator.

The Oscillator

If we use ↑ to mean "go forward" and ↓ to mean "turn around", we can summarize this enemy's movement pattern as ↑↓.

To see how the Oscillator uses its movement pattern to move back and forth, here's an animation:

The Flyer

The next enemy type is also pretty straightforward:

• If you can go forward, go forward.
• If not, turn left or right.

We can define a left-handed and right-handed version of this enemy by changing which direction it turns in the second step. In fact, we can define a third version that choses randomly. Collectively, let's call these enemies Flyers, and summarize their movement patterns thus:

↑↱↓ — Right-handed

↑↰↓ — Left-handed

↑? — Random

The Wall-Follower

Now for the wall-followers. This isn't as obvious:

↱↑↰↓ — Right-handed

↰↑↱↓ — Left-handed

The Player-Follower

The obvious way to define a player-follower in this system would be to introduce a new command called "follow player" and have the player-follower's list consist only of that command.

We can do better, though. After all, it might be nice to be able to retreat from the player as well as follow them; or follow or avoid a different object, something other than the player.

With one small change, we can create enemies that behave like this using only the forward, backward and turn commands we've already defined.

First, we define a "relative axis" for each enemy type. All the enemies introduced so far have their relative axis pointing forwards, from their point of view. For the player-follower and the player-avoider, the relative axis points from it to the player.

Next, we interpret the results of the decision function differently: forward now means move in the direction of the relative axis; backward means go in the opposite direction, and left and right mean turn relative to the relative axis.

This way, the existing enemies' behaviour is unchanged, but we can define a player-follower with a decision function of ↑ and a player-avoider with ↓. We can also define enemies that follow or avoid any item we like. How about a moth-like enemy that's drawn to a light, or an enemy that's scared of other enemies?

It might be interesting to see how ↱ and ↰ behave in combination with the relative axis; perhaps it will yield some sort of orbiting behaviour?

Also, there may be other ways to play with the relative axis besides pointing it to some sort of target object.

Experimenting with Projections

I reckon this looks more interesting than a flat top-down view, but I find it harder to control. Perhaps I'll make it an option.

I've done a lot of work on the game lately — meatier updates coming soon.