Latest update: Jan 16

Premise

Launch your spider drone at walls, ceilings, and enemy heads in this philosophical shooter set at the end of the world. PC/Mac/Linux/PS4.

Prototype

The game is very loosely based on a prototype called "grepr", which I made for 7DFPS 2014. Play it on itch.io.

New engine, open source

I built the prototype in Unity, which worked great. But now I'm so sick of Unity crashes and performance issues due to C#'s memory management that I decided to build this game from the ground up in C++, targeting PC, Mac, Linux, and hopefully PS4.

The latest source and assets are available here: https://github.com/etodd/deceiver

I retain copyright on the assets, but the code is MIT licensed.

Website

deceivergame.com

Grepr was already amazing. I look forward to this.

Stream: For those interested in coding, I've been streaming a bit on Twitch, although not at regular times. Whenever something comes up that I think would be interesting to watch, I stream it. Mostly C++ code. Here: twitch.tv/emt1337

Dishonored: I played this game for the first time last week. Accidentally beat the whole thing in a single 8-hour play session. I had completely forgotten about the game, and now I come to the obvious realization that my game is basically the Blink ability. Not a bad thing, certainly.

I learned some things about stealth. My AI bots now follow predictable patrol routes. And footsteps now emit sound which I visualize in-game like so:

But mostly, Dishonored just made me wish I was making a normal FPS with a human player character rather than a spiderbot. So, the big reveal is:

Humanoids: you can now switch back and forth between humanoid and spiderbot.

I always planned to do something like this, but it was going to be more of a "possess this character" thing. But I think it needs to play a more central role, so I think you'll be able to switch back and forth at will. We'll see. The controls will be exactly like Lemma. I've already got rough jumps, wall-jumps, mantles, wall-running, a decent acceleration curve, a non-horrible placeholder running animation, and wall sliding. All this was pretty straightforward since I've done it before.

Here's the tricky thing about humanoids: they can walk even on pink surfaces which are inaccessible to spiderbots. But spiderbots can climb on walls and ceilings. Several movement puzzles immediately come to mind.

Level design: still struggling with this. My goal is to bring a demo to GDC and find a world-class level designer willing to collaborate.

In the meantime, I decided to steal a design from Dishonored and use it to test the humanoid controls. See if you can place it. There are two Sentinels guarding the entrance...

I also removed edge detection on the out-of-range (pink) geometry. It cuts out some unnecessary noise, but also makes it harder to see stuff in the distance. We'll see if I keep it. Visuals are very much subject to change.

Engine stuff: The armature component now supports multiple blended animation layers. Silky smooth motion. I'm also nearly done with a major refactor which will enable saving/loading games. My goal is to basically fread a bunch of data into memory, hit "go" on the simulation, and have it work. Pretty much that boils down to: IDs everywhere rather than pointers.

Looking ahead: Been reading up on behavior trees. AI is a major shortcoming in my games, it's always been simple FSMs. I'd like to level up this area of my development expertise.

Happy new year! I'm busy experimenting with more appropriated architecture.

Train Jam

I was lucky enough to snag a Train Jam ticket this year! Got to meet a ton of lovely people, hang out and talk shop, and of course play some of the amazing games they made.

Here's my entry, Haunted Heist, a 3D browser game. Rob a haunted mansion!

Roscoe

I got hired to make a secret game embedded in a website footer. Check it out. :)

Right, on to the real stuff!

Design overhaul

The past couple months, I've been overhauling gameplay, going in some wild directions. The following is a synopsis of my "design" process (emphasis on the scare quotes).

Goals

The game has two main aspects. At any given time, you will be either a) parkour-exploring cool environments, or b) facing off against another player online.

Target emotions for parkour-land: freedom, delight, curiosity, relaxation. Basically the same goals Lemma had, or should have had. I'm not too worried about this mode; I've done it before.

Target emotions for multiplayer-land: tension, fear, triumph. This is new territory, and will constitute the focus of the rest of this post. I want to replicate and improve the experience of playing a one-on-one, sniper-only, one-shot-kill round of Call of Duty. Maybe the players only take 5 shots the whole game, but they're constantly trying to predict each other's moves and out-maneuver the opponent.

Detour into MOBA-land

In an attempt to improve on the CoD sniper idea, I tried to identify the things that make it interesting. I thought maybe the long-term player interaction differentiated it from your typical free-for-all CoD frenzy. The longer you're alive, the more interesting your interaction with the enemy becomes. As soon as you die, everything is reset and lost. I wanted to facilitate more methods of player interaction that didn't involve death.

I don't know much about MOBAs, but I think they have a lot of non-player-death interaction. Players are generally alive for a long time; dying is a big deal. And plenty of successful players go through a whole game without killing another player.

So I tried to identify compelling MOBA elements that could be transplanted into my game without too much fuss. I added auto-spawning minions, turrets, and big, granular health bars.

Only minions could attack turrets. Players could kill minions with a headshot, but only once the minion's health dropped beneath a threshold, which opened their helmet. This forced players to stay behind their minions and try to last-hit enemies.

Players could still kill each other with one or two hits, but it became a risky proposition to venture into enemy territory. I decided to visualize view ranges around enemy units to make it clear exactly where an enemy would start attacking. A bit like fog of war.

I hoped that all of this would give players more ways to interact with each other, albeit indirectly, killing minions rather than each other.

Progression

Again, I don't know much about MOBAs; I just can't get into them. But they clearly work for people. I wanted to extract the fun from them. I played a few (admittedly short) games of LoL, and more importantly, collected some feedback from MOBA players. I discovered there is no single feature that defines a MOBA, but one feature seemed at once pivotal and easy to transplant: player progression. In a MOBA, everyone starts each game on a (hopefully) level playing field, and becomes more powerful as the game progresses.

Mainly, they progress by leveling up their abilities. I decided to steal this, along with the idea of a team score.

Here I also experimented with colors, trying to brighten everything and make it more appealing, like a MOBA.

Killing enemy minions and players gave credits, which could be spent on abilities. Kill the enemy player five times to win. Easy. Ship it!

Problems

At this point, everything has at least 50-100 HP. I kept player attacks pretty powerful, but minions take around 30 seconds to wear each other's health down. In true MOBA fashion, they just stand still attacking until somebody dies. This works fine in a top-down RTS-like setting, but not in a "visceral" first-person game.

In general, my detour into MOBA-land was missing some of my target emotions, namely tension and fear. Giving players five lives, turning everything into bullet sponges, and brightening the graphics all worked to lower the tension. I could see that with some polish, the MOBA elements would accomplish the goal of long-term player interaction, but at the expense of everything else.

Backpedaling

I'm now back to the original prototype: you get one life. I think this is more impactful than an arbitrary score number at the top of screen.

I'm also back (way back) to darker colors. The vibrant, beautiful colors I love still have a place in parkour mode, but here the colors need to be dark and maybe even discomforting.

I also switched the reticle from a diamond to an inverted triangle, for several reasons. First, triangles are aggressive, especially inverted triangles. I noticed just that small change evokes a much more hostile feeling than the relatively peaceful diamond shape. Second, triangles and non-square angles are a theme I want to explore in this game, since my last game was all squares. I keep finding squares I've added instinctively and converting them to triangles.

Salvaged ideas

My goal now is to facilitate long-term player interaction without sacrificing tension. I'm keeping the "fog of war" idea, and even making it more central. Map control is one element I noticed was critical to MOBAs. I'm now experimenting with having players place proximity sensors around the map which "capture" areas. Maybe a bit like Splatoon.

Abilities and player progression are also staying, although I'm simplifying them so that only one ability can be equipped at a time.

Wrapping up

All this has not been very productive in terms of features making it into the final product, but I see it as a necessary step of my patent-pending "design by trial-and-error" process. The key is to have a set of design goals which you can use to judge potential ideas. Some of these crazy MOBA ideas work toward my goals, and so remain, while others get cut. Previously, my design goals have been, "make something I like".

I went to a great GDC talk about the narrative design of Dragon Age Inquisition's DLC. The writers picked movie references for their story; one was Captain America Winter Soldier; the other escapes me at the moment. But these two movies gave the whole team familiar references from which they could make decisions on every little detail of the game.

That's what I'm trying to do. I don't have any movie references for the story yet, but I'm looking. Unfortunately my movie literacy is pretty abysmal. :)

Design epiphany

Until recently, I thought of the game as a series of alternating levels: PvP level, parkour level, PvP level, parkour level...

That's a lot of content. It makes a lot more sense to design each level to work equally well in both contexts. First, you play the level facing off against another online player. The game overrides the level's color scheme and render settings to achieve the feeling of tension I want, and to communicate critical information about the game state.

Then you play the same level in parkour mode, where each level can look and feel wildly different.

It's not a new idea, plenty of games do this. The tricky part is tightening up the design so that each element in mode X serves a corresponding purpose in mode Y.

Custom nav meshes

For reasons not yet clear, I find myself in need of a bot-friendly method of navigating around a level.

Now, I already have a traditional nav mesh for bipedal bots, thanks to Recast. It's super nice and can even be modified at runtime.

But this bot needs to be able to shoot itself around the level, attaching to walls and ceilings like the player does. I need a different kind of navigation mesh for this.

Here's the plan:

Task 1. Sprinkle points across all the surfaces in the level.
Task 2. Do a bunch of raycasts to determine which points connect to each other.

Of course this is pretty compute intensive, so I do it at build time.

Surface parameterization

I try to code up task #1 live on Twitch, resulting in this:

Eh, it's a bit off. The problem is, I want the points to be regularly spaced in a nice grid on each surface. This is closer to what I want:

Here's the process I end up with:

1. Loop through each triangle in the scene.
2. For each triangle, calculate two "basis" vectors for the grid on the triangle.
3. Use a standard triangle rasterizer to generate all the points on the grid, projecting each one back into 3D space.

The end result works pretty well, although I'm still struggling with thin triangles slipping through the cracks of the grid, and with sampling around the edges of triangles. Here's a shot of a particularly bad configuration resulting in a lot of missed points:

Adjacency calculation

Next, I connect each point with up to 48 of its closest neighbors, like this:

Here you can see the sparse point sampling completely missed the walkway. Not good. I'll probably revisit this problem at some point.

It takes about 5 minutes to generate and connect ~4000 points. The raycasts are really slow. I end up splitting the level mesh into chunks, which speeds up the raycasts immensely. The whole process takes less than 30 seconds now.

Most of the points in the graph are maxed out at the 48-neighbor limit. The connectedness of the graph is insane.

Pathfinding

I code up a quick implementation of A* and run it.

Turns out, when each point in a graph has 48 neighbors, the computational complexity of A* explodes. Even a path of only 2 or 3 hops takes a good 30 ms to calculate. Granted, it's unoptimized, and I could also try another algorithm entirely, but I suspect any algorithm would struggle with this graph. The good news is, since the connectivity is so high, and since points can connect to each other across long distances, I probably won't see paths longer than 3 or 4 hops in practice.

I end up putting A* on a separate thread. Similar to the threaded renderer, I communicate with the AI thread via a simple bytecode protocol written to a pair of ring buffers. Results are returned via callbacks.

Double whammy update!

Lead indicators

From the very first prototype, it's been difficult to hit small moving targets (like heads). For a while I tried setting the player speed super high, which mostly worked, but you still had to lead your targets. Finally I buckled down and implemented lead indicators, which show you exactly where to shoot. You can see it proceeding ahead of the minion in this gif:

It's pretty satisfying to aim out into empty space and see everything line up as you fly toward the target.

That progress bar and "DETECTED" warning are part of the new sensor system. If you linger too long in an area claimed by the enemy, they'll get alerted of your exact location.

Glitches

I keep encountering glitches which make the game look way cooler. I would like to find a way to incorporate a glitchy aesthetic into the game somehow.

AI player

This still needs a ton of work, but I'm making progress. The navigation graph is pretty much done, and I'm now able to display what the bot is seeing:

I'm currently using two behavior trees running in parallel, one high-level and one low-level, plus a super-low-level system responsible for aiming and shooting.

Level design envy

I imported a cool map somebody made for Quake 3, just to see what it would look like. Now I kind of want to hire the guy:

New test map

For now though, I have a new, non-copyright-infringing test map in the works.

Blender SSAO

Speaking of level design, someone on the stream the other day told me that Blender now supports SSAO in the editor view. Hit "N" in the 3D view to open the property pane, then turn on ambient occlusion:

Control points

I wanted to imbue the sensor mechanic with more utility and depth, so I added "control points". Every 60 seconds, you receive a credit bonus based on the number of control points within range of your sensors. They look like this:

They're very unassuming, and there are no attendant UI elements, so right now they're pretty confusing. I'll eventually think of a good way to make them more obvious.

This shot also shows the new compass, which is less cool but more functional. The red and blue triangles point toward the respective spawn points of each team. I kind of miss the old compass rose though. We'll see if this one sticks around.

Friend/foe colors

This has bugged me for awhile. I use red in the UI to convey "bad"/"enemy". I also had two team colors: red vs blue. It was pretty confusing when you were on the red team.

Now there are no red or blue teams. It's just "friend" (blue) or "foe" (red). Here you can see both players are blue on their own screens:

Crawling is back

I uncommented it again. This time I turned the speed down pretty slow; it's not meant to be a major part of gameplay. It just alleviates some of the frustration of being rooted in one spot, and it gives you something to do while waiting for the movement cooldown. The AI player also has some rudimentary crawling code. It also exhibits inaccuracy when trying to hit targets.

Sensor system

Currently, placing sensors is an ability that comes equipped by default. It's on a 20-second cooldown timer, which is frustrating. You have to keep track of it in the back of your mind, and it just feels arbitrary. Today I realized it makes much more sense to just charge a certain number of credits to spawn a sensor. If you place it near an uncontested control point, it will eventually pay for itself.

I'm considering another idea with the sensor system, which is to make players invincible when they are within range of their own sensors. To damage an enemy in their safe zone, you would first have to destroy their sensors, which is a risky proposition.

Maybe there's an expensive ability later on that cancels the invincibility. This could be something that both players save up for in the late game.

Parkour

The parkour code is 75% done. I started to re-implement animations from Lemma. My test level is also starting to look half-decent.

Third-person

When I've shown the game to new players, it usually takes a good five minutes before they even vaguely understand what's going on. I think the biggest point of confusion is: "what exactly am I?"

The game is so strange that they have no point of reference. If you're making an FPS or a platformer, people are familiar. But in this game, the combination of vector graphics and strange movement is a lot to take in at first.

Another problem is the fact that at any given time, you can't aim at half the screen because it's blocked by the wall you are attached to. It makes sense, but it's confusing to a new player in first-person because they don't even realize they're attached to a wall.

A third-person camera alleviates some of these issues. I realized that as far as gameplay, nothing is really lost in the switch to third-person, except for the perennial problem of what to do when the camera is inside a wall. Right now, I'm just culling everything in the way.

Ideally, I would still render blocking geometry, but with low opacity. In fact I'll probably do that eventually. This works for now though.

I've always had a janky third-person option (as seen in the previous devlog), so this was just a matter of cleaning it up and making it work for real.

Ability overhaul

Here are my gameplay goals:

• Create tension by making it possible to be killed at any point in the game.
• Encourage a lifecycle of progression through the early/mid/late game without destroying the tension.
• Minimize the number of mechanics and wring everything possible out of them by making them interact with each other.

I'm using an ability system with upgrades to accomplish goal #2 (progression). I immediately thought of a bunch of crappy abilities like stealth, skip cooldown, invincibility, etc. You would buy these upgrades at your spawn, then switch between them in the heat of battle.

The problem is, these abilities obliterate goal #3 (interaction between mechanics). So you press a button to become invincible for a few seconds; that can become an interesting idea (see TF2) but on its own there's nothing else for it to interact with.

These abilities do nothing but augment your ability to kill the other player, which isn't very interesting. There's much more potential for interaction if instead you augment the environment.

I already had a bit of this, since you could spawn a minion by capturing a certain point. But that doesn't really allow player expression; it's just a checklist for the player to fill out. Capture points A, B, and C.

All this to say: I turned the minion spawn mechanic into an ability. I actually cut it down to three abilities: spawn sensor, spawn teleporter, spawn minion. And there are no cooldowns, it's just a flat fee for each item spawned.

Here's the new menu that pops up automatically at your spawn point. Hold one of three buttons to upgrade that ability.

Sensors and minions are mostly done, but I haven't even started teleporters.

Lots of work to do!

Hey the game looks pretty cool. Will you be needing any music for it? If so you can check out my portfolio here www.sbeastmusic.com/portfolio

Allow me to regale you with an exciting tale: the birth of a janky dialogue and voice system.

I have a JSON file with all the localized strings in my game, like this:

{
    "danger": "Danger",
    "level": "Level %d",
    ...
}

A preprocessor takes this and generates a header file with integer constants for each string, like this:

namespace strings
{
    const int danger = 0;
    const int level = 1;
    // ...
}

At runtime, it loads the JSON file and hooks up the integer IDs to localized strings. A function called "_" takes an integer ID and returns the corresponding localized string. I use it like this:

draw_string(_(strings::danger), position);

This all worked (and still works) pretty well for UI strings. Not so much for dialogue.

To write dialogue, I had to come up with a unique ID for each line, then add it to the strings file, like this:

{
    "hello_penelope": "Hello! I am Penelope.",
    "nice_meet_you": "Nice to meet you.",
    ...
}

Yes, the preprocessor generated a new integer ID in the header file every time I added a line of dialogue. Gross.

I construct dialogue trees in Dialogger. With this setup, I had to use IDs like "hello_penelope" rather than actual English strings. Also gross.

A better way

I keep the string system, but extend it to support "dynamic" strings loaded at runtime that do not have integer IDs in the header file.

Now I can write plain English in the dialogue trees. The preprocessor goes through all of them and extracts the strings into a separate JSON file, using the SHA-1 hash of each string for its ID. Once everything is loaded, I discard all string IDs in favor of integer IDs.

I couldn't find a simple straightforward SHA-1 implementation that worked on plain C strings, so here's one for you.

The point of all this is: I now have a single JSON file containing all the dialogue in the game. Ripe for automation...

Speak and spell

Penelope is an AI character. I'm using text-to-speech for her voice, at least for now. I don't want to integrate a text-to-speech engine in the game; that's way too much work. And I don't want to manually export WAVs from a text-to-speech program. Also too much work.

I create a free IBM Bluemix account. They have a dead simple text-to-speech API: make an HTTP request with basic HTTP authentication, get a WAV file back.

I write an 82-line Python script that goes through all the dialogue strings and makes an HTTP request for each one. It keeps track of which strings have previously been voiced, to facilitate incremental updates.

Now I have a folder of WAV files, each one named after a SHA-1 hash. I'm using Wwise for audio, so the next step requires a bit of manual involvement. I drag all the WAVs into the project and batch create events for them.

Now when I display a dialogue string, I just have to look up the SHA-1 hash and play the audio event. Easy.

Disaster strikes

I don't hear anything. All signs indicate the audio is playing correctly, but nothing comes out of my speakers.

I look at one of the audio files in Wwise.

Looks like the file is corrupted. I play the WAV in a number of different programs. Some play it fine, others don't play it at all.

I edit my text-to-speech script to use Python's wave library to load the WAV file after downloading it from IBM. Sure enough, the library doesn't know what to make of it.

Too lazy to care, I edit the wave library in-place in my Python distribution. YOLO.

After a bit of printf debugging, I pinpoint the issue. The WAV format is based on RIFF, a binary format which breaks the file into "chunks". According to Wikipedia, the format of each chunk is as follows:

• 4 bytes: an ASCII identifier for this chunk (examples are "fmt " and "data"; note the space in "fmt ").
• 4 bytes: an unsigned, little-endian 32-bit integer with the length of this chunk (except this field itself and the chunk identifier).
• variable-sized field: the chunk data itself, of the size given in the previous field.
• a pad byte, if the chunk's length is not even.

Turns out, IBM's text-to-speech API generates streaming WAV files, which means it sets the "length" field to 0. Some WAV players can handle it, while others choke. Wwise falls in the latter category.

Fortunately, I can easily figure out the chunk length based on the file size, modify it using the wave library, and write it back out to the WAV file. Like so.

Problem solved. Wwise is happy. Next I set up some Wwise callbacks to detect the current volume of Penelope's voice, and when she's done speaking.

Here's the result, along with some rope physics in the background being destroyed by the wonky framerate caused by my GIF recorder:

New terminal system

Here's the new workflow for each level:

• Spawn into the level as a humanoid.
• (Explore and find stuff, not done yet)
• Activate a terminal, which looks like this:
  
• Have a conversation with Penelope (main AI character previously called Soren), who starts the matchmaking process.
• While chatting and waiting, you can still parkour around the level.
• Once Penelope finds a match, she connects you with the other player and reloads the level in PvP mode.

New health system

Previously, health worked as follows: you started with 1 HP, and you could "capture" health powerups to get to 3 HP total. If someone hit you just right, it was still an instant kill. But most shots bounced off and subtracted 1 HP from you.

Now, you can only damage a player if you have the same or higher HP. If there's no chance to damage a player, you'll see a flashing "danger" sign. I also got rid of the instant kills; they felt more like random chance than skill.

Previously, when a player captured a health powerup, it remained theirs until you damaged them, resetting the powerup to neutral. At that point, they could recapture it to get their HP back, or you could capture it and get an edge.

Now, you can capture a health powerup even if it belongs to an enemy. You steal their HP. This encourages you to set up protections around your health powerups. Also, once you get to full health, you can't capture any more health powerups. This encourages you to run on low health so you can steal enemy HP.

This system makes things crazy if you happen to get into a fight near a health powerup. You'll start out at the same HP until player A damages player B, at which point player B is forced to capture the powerup before they can do any more damage. It gets pretty hectic.

In the early game, this sort of back-and-forth is exactly what I want, but I can see it dragging on in the late game. So I will probably design an expensive mechanic (available only in the late game) that allows you to "freeze" powerups in some way, to force the game to end in a reasonable amount of time.

Control point UI

Control points now have icons that change color depending on their owner. Here you can see one point inside my sensor zone, and one outside:

Each captured point earns 2 credits every 15 seconds. The UI shows this "credit delta" beneath your total credits (+2 in the above screenshot).

Teleporters

I started out giving two possible actions for each ability. Hold the ability key (e.g. 1, 2, or 3) to spawn the item (e.g. a teleporter). Tap the key to execute an action with those items (e.g. teleport).

I ended up combining the two. Hold the key to simultaneously spawn a new teleporter and teleport to an existing one.

The particle shader needs some work. From some angles it looks like flying macaroni noodles.

Roll animation

Look, I did an animation!

There is no fall damage, but if you fall too far, you'll instantly lose all momentum and completely stop for a second. You can roll at just the right time to maintain and even increase your momentum.

New menus

I worked on some menu animations.

Notes / matchmaking

I planned out three systems for parkour mode. Notes are done:

Matchmaking is also done. One more system to go.

Todo

• Balance and adjust PvP gameplay
• AI programming
• Level design
• Writing

I'll skip all the boring stuff I did this week... writing dialogue, fixing build errors on Mac, incrementally improving the parkour code, refactoring a bunch of templates out of existence, fixing rare AI crashes...

Just a few things of note:

Level design revisited

I resurrected this level and re-worked it in light of new design decisions. It now works pretty well in both PvP mode and parkour mode.

Stealth upgrade

In order to encourage you to plan for the long game, I must make it more difficult to kill your enemy at the beginning of the game. However, in order to make you feel vulnerable, you still need to die in a few hits.

This led me to the stealth mechanic: you're invisible while planted on surfaces that you "own".

Now you're safer, but you're cowering in your safe zones.

In the late game, I want things to get more hectic, more lethal, and less safe. Easy solution: pay X credits to upgrade your sensor ability and disable the enemy's stealth. This was easy to implement, so I did.

There are two problems with this design. First, when someone disables your stealth, you have no idea what happened. Your stealth just stops working, and now you're frustrated and confused. A UI element could solve this, but that's extra work, extra visual noise, and you still might miss it.

Second, it's not a "fun" upgrade. When I look at the upgrade menu, removing an element of the game looks unappealing, even if it's a good tactical choice. I want an upgrade for me, not a downgrade for my enemy. Maybe it's just semantics, but it makes a big difference emotionally.

Then I realized that you the player already have power to disable your enemy's stealth: you can spawn a minion to destroy their sensors. It's way more fun to spawn a dude that shoots lasers than it is to just buy an upgrade.

TL;DR: I trashed the stealth upgrade.

More health revisions

Previously I described how much fun it was to battle an enemy near a health powerup. You have to constantly switch between attacking your opponent and re-capturing the health powerup, depending on how much health you both have.

This is made possible by two important details: first, when you are damaged, the game resets your nearest owned health powerup to a neutral state, giving you a chance to quickly regain your health by recapturing it. And second, players can steal health powerups owned by an enemy.

This design has a problem too, though: once you are damaged, you immediately retreat to the nearest health pickup, since you can't do damage anymore. Your enemy follows close behind. Once you're both at the powerup, neither of you has an incentive to leave. You can always gain an upper hand by re-capturing the powerup. The game will end there, after an indeterminate period of back-and-forth.

The game should not end with the first encounter.

Here's where I'm at now: first, when you are damaged, your most distant health powerup resets. This forces you to make a significant retreat, probably back within your safe zone where you have an advantage. Second: in the early game, you can't steal enemy health. You have to buy an expensive upgrade.

This upgrade is much more appealing because it allows you to gain a huge advantage very quickly. It also splits the game into four different modes, depending on which of the two players have the upgrade. And it makes the game end more quickly as time expires.

Containment fields

Now there's another problem. In the early game, it's pretty easy to escape danger. You might be frustrated if an enemy slips through your fingers, but no worries, it's early.

However, in the late game, it's still just as easy to escape, making the game drag on endlessly.

The first thing I thought of was a "stun" ability. Pay X credits and now you can hit a button to temporarily freeze the enemy in place.

More design problems. First, it's frustratingly difficult to hit a button at the right time while frantically bouncing around chasing someone. Second, there's no way for the enemy to counter. Maybe they buy a counter-upgrade that makes them un-stunnable?

That is soooooo boring.

Here's what I'm experimenting with: you buy an upgrade that adds "containment fields" to your minions.

It's hard to see, but there's a transparent field around that minion. You can pass through it freely, while the enemy cannot. This accomplishes the goal of corralling your enemy, but is more interesting than a stun ability for two reasons: first, the field is mobile because minions walk around. Second, the enemy can counter it by killing the minion (which happens to be a lot of fun).

I've only playtested these mechanics against my not-very-smart-yet AI, but I'm hoping to do some real playtesting this weekend. In the meantime, there's plenty of level design, animation, and writing to do.