next »

[etodd]

Ludum Dare happened this past weekend. A few friends and I made a browser-based multiplayer version of 2048:



Play it here, and vote for our entry! Please?

Just a quick update for today. Implemented the Poor Man's Volumetric Lighting™ method used in Lemma:



The algorithm creates a lot of noise, but thankfully most of it gets masked by the film grain.

Source here

[etodd]

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

[JackMenhorn]

Dig it

[etodd]

New name [?]

To date, I have thrown out and rewritten the design doc and story seven times. This latest revision has lasted longer than the others, so I'm hopeful that it's the last.

"MK-ZEBRA" was originally a reference to MKUltra. The story started out in the vein of paranoia fiction, but now it's drifted toward something hopefully a little less cliche. The current working title is "The Yearning". Let me know if you hate it. I have not yet encountered any major concerns with the new title.



New humanoid model

I modeled, rigged, and animated a new placeholder humanoid model. It'll do for now.



Beneath a certain health threshold, the helmet opens to expose the head. It's not too visually distinctive. It'll probably get redesigned.



I'm using this to experiment with a "last-hitting" mechanic, as in a MOBA. You can't headshot an enemy until one of your ally units damages it.

Parkour

A while back I realized that I'm not quite done exploring the parkour mechanics in Lemma. There will be some parkour elements.

I'm taking the best bits from Lemma, refining them even more, and cutting out the garbage. With the new codebase, it's actually possible to build up momentum above the max speed, whereas Lemma killed your extra momentum whenever possible.

Here's the slide move filling in some transient yellow floor tiles:



Turrets, projectiles, particles

Things shoot each other. Lights flash. Sparks fly.



The red areas visualize the view range of enemy units. I hijacked the deferred point light renderer to overwrite the albedo color for those areas, rather than modifying the lighting buffer.

Also, film grain is gone.

Soren

This is a work-in-progress character. She's an AI who thinks she's a person, currently voiced by a text-to-speech program. The diamond frame grows and shrinks to match her voice.



Here's my amateur pixel art for her spritesheet:



Open source

The entire repo is now up on GitHub. I'm retaining copyright on the assets, but they're available for download, and all the code is MIT licensed.

[etodd]

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.

[etodd]

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.

[ashtonmorris]

Hey there! Its looking good still. Just wanted to chime in and say that for some reason the name The Yearning really doesn't sound pleasant to me. I can't put my finger on it but perhaps just the sound of the word yearning is a little off-putting.

If others agree, the perhaps it is something to think about. If its just me then feel free to ignore my isolated idiosyncrasies. 

[etodd]

I can't put my finger on it but perhaps just the sound of the word yearning is a little off-putting.

Hey, thanks for the honest feedback. I picked the name for reasons related to the story and overall meaning, but if the word rubs people the wrong way, there are plenty of others that can serve the purpose. Anyone else have an opinion?

Some other ideas dug up from my week of namestorming:

Qualia
Sense Gap
Strive / Striver

[etodd]

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.

[etodd]

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.

[etodd]

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!

[etodd]

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:

Code:

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

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

Code:

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:

Code:

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:

Code:

{
    "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:

[etodd]

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).

[etodd]

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'm headed to New York City this summer to teach people how to make games at MakeSchool. My hope is that when I return, the game will be in a playable state and I'll have some funding. At that point I'll probably start looking for some help on this project.

[etodd]

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.

[etodd]

Yesterday I set up itch.io refinery, which is basically itch's equivalent of Steam Pipe. It does binary diffs so you can upload new builds in seconds. I can now generate download keys for beta testers. I highly recommend this system for anyone who does any kind of beta testing. It's nearly as powerful as Steam Pipe, but only takes about 5 minutes to set up.

Still a lot of bug fixing, UI polish, parkour tweaking, etc. going on right now. But I built another level!



I think creating and exploring new spaces is a major part of why we make games, at least for me. This place didn't exist yesterday!

As usual, colors were difficult to get right. It doesn't help that there is absolutely ZERO correlation between the colors I choose in Blender and the ones I get in-game.

[Pixel Noise]

Wow, not sure how I'm just seeing this for the first time - but it's very cool to be able to skim through the last year's worth of progress. Really dig some of the concept art and level-design/architecture you've got going on. Super following!

[etodd]

...

I should clarify that nothing posted here is concept art. I have neither the talent nor time budget for that unfortunately. I have to slap together junk as I go. But I'm glad you enjoy it so far.

[Pixel Noise]

  My mistake - I thought those pictures in your first post were concepts. Far from junk - this stuff looks great!

[etodd]

Gamepad aim assist

This is something I didn't want to get creative with. It's a commonly solved problem, and I'd rather steal someone else's solution. I found a YouTube video explaining how aim assist works in Call of Duty. There are two factors.

First, when you are aiming at a target, your look sensitivity slows way down. So if you are swinging your crosshair over a target, it will linger on it ever so slightly. I actually put it down to 60% of the normal speed. It's hard to see in this gif, but it's there:



Second, when you are moving relative to your target, the game will adjust for that movement. It doesn't "lock on", it just offsets your input by the relative motion between you and the target.

This one can get really obvious, especially if you don't move the camera at all. It will just keep tracking forever, making it feel like a cheap aimbot. To avoid this, the tracking only kicks in if you are moving. It won't track a moving target when you're at rest.

I also put an inactivity timer in so that if you aren't actively aiming the camera, it won't track. In this gif, it doesn't track at first, but then I twitch the joystick and it tracks for another half second before going inactive again.



Footstep effect

This is just a nifty thing that shows where you've been.



Playtesting

I got some much-needed playtesting last week. (thank you COGG!) Splitscreen multiplayer is actually a lot of fun. I of course wrote down a ton of issues that I was able to correct this week. The hardest problem, as expected, is teaching people how to play. The tutorial was awful and I knew it, but after seeing people play I got some ideas to revamp it. That will probably happen 3-4 more times before it ships.

Overworld level transition

I'm planning on 16 levels. You have to beat two opponents to unlock the next level. Opponent 1 must be beaten on the level you're currently at. For opponent 2, the match-making system will choose a random level from those you've unlocked so far. I think it's important to replay maps in a multiplayer game.

Anyway, I want to show your progress through the game, so I made a simple overworld transition screen that shows how many levels you've unlocked, how many you have left, and which map you're about to play.



The loading time and black screens are all fake. It actually loads 15-20 MB scenes in under 100ms.

I'm not sure what to do for level names. Right now it's just "level1", "level2"... but something more creative would be nice. The guys who make Brigador just stole an album track list and used that for their level names. Brilliant idea if I could find the right album.