Health v11

I added an extra shield hitpoint, so it takes three total hits to kill a player. I'm hoping this will encourage players to use abilities rather than only attacking each other directly.

Master server

I have the beginnings of a master server, which facilitates connections between players and servers. It's pretty basic at this point, but it works. I'll continue to expand this in the future with authentication and matchmaking.

AI

I threw out the behavior tree system, which badly needed refactoring anyway. Now I'm working on a system which will record player inputs into a database, then search through the database for specific scenarios and play back the correct actions. It's maybe halfway to a rough draft working prototype.

Clouds

Just another cool thing I wanted to pull in from my last game. They're animated and actually cast shadows on the environment.

GDC and PAX East

I'll be present for the first two days of GDC, plus out of nowhere I got an opportunity to show at a booth at PAX East! Beyond excited :)

Another rebrand

This is the last time, I promise. The game is called Deceiver.

Easier to remember, and a surprisingly uncontested name within video games at least.

Some people know the reasoning behind the name, but unfortunately it's extremely spoilery.

Rain

This system does raycasts to determine how far each raindrop should fall. Unfortunately, my particle system (and most particle systems I believe) requires that particles be removed in the same order they were added, meaning all particles must have the same lifetime. To get around this, I store each particle's individual lifetime in a vertex attribute and clip the particle out of existence in the pixel shader if the particle is too old.

The system keeps a cache of raycasts around each camera, updating the cache over time at a rate of about 1000 raycasts per second. As an improvement over my last rain system, it can also "fill in" missing particles when the camera moves or teleports too quickly for the normal spawn rate to keep up with.

Miscellaneous

• Added a network lag simulator and made more changes to further harden the netcode. One example: the server was using the client's running average RTT to rewind the world when doing collision detection for that client. Problem is, if the player sends a "jump" command that gets dropped by the network and resent later, the timing of that command is out of sync on the server and client, and it will only be resolved when the player lands. So now the server uses the sequence ID of the command to calculate and store an RTT value for rewinding purposes, which remains constant until the player lands.
• For the longest time I was bothered by the game's performance on my laptop, which has a GTX 950M capable of running Rocket League on decent settings at over 60 FPS. For a while this made me doubt a little bit my ability to write performant shaders. Turns out, my game was being relegated to the Intel integrated graphics chip. Tweaking the nVidia settings brought performance to over 150 FPS. Yay!
• Upgraded to VS 2017. I think it's an improvement from 2015 overall. Certainly the install experience was much better.
• The local/online multiplayer menu system is maybe half done. Multiplayer might be completely done soon. I am considering an Early Access release to stress test the netcode and collect gameplay feedback.

PAX East

I had an opportunity to show the game as part of the Playcrafting booth at PAX East. It was fun getting to meet a lot of cool people, but I realized that you get back what you put in when it comes to expos and shows. It's difficult to attract interest when you're part of a larger booth and have no signage.

Attract mode

To help attract attention at PAX, I wrote up a quick and dirty "attract mode". The game can now record matches and automatically play them back after 60 seconds of inactivity. As soon as someone touches a controller, the game goes back to the main menu. It was very straightforward to write; I just record the network packets and play them back in order. Unfortunately I couldn't get anyone to play a match with me before PAX, so the feature went unused. But it will come in handy in the future!

UTF-8 support

This was a lot easier than I expected. Essentially the only code that needs to think about multi-byte codepoints is the text rendering code.

This was necessary because I wanted...

Playstation button prompts

The game now displays different button prompts for each player, depending on what kind of controller they plugged in, if any. It also instantly switches to keyboard prompts if you touch the mouse. My last game always showed controller prompts as long as a controller was plugged in, and that proved to be confusing to some players. Besides, this is a feature that impressed me in The Witcher 3, so I decided to steal it.

Clipping v4 (?)

Still experimenting with new camera clipping techniques. If anyone knows any of the graphics programmers who worked on For Honor, I would love to know how they do their effect.

In this version, I'm rendering backfaces the same as camera-facing tris, but in pure black. I'm working on removing the white outlines inside the black areas. If I can also fix a few weird clipping situations that block the camera view, I think the effect will finally be complete.

Hacking improvements

The sudoku hacking game had one flaw, which is that sometimes it gave you a number that could belong in a currently unsolvable portion of the puzzle. To fix this, I made it calculate the number of possibilities for each cell and give you the one with the least number of possible values.

AI

I scrapped the old behavior tree system a while back, so the AI players have been sitting idle since then. I'm finally making significant progress on a new system which will be able to seamlessly playback recordings of player moves, mixed with ad-libbed AI actions. The recording system is done, and now I'm working on the AI actions. After that, I'll work on the playback system which will select which recordings to use in each situation.

Having AI players in the game again revealed to me a major issue with the gameplay...

Skill shots

I realized that the core shooting mechanic was a bit rock-paper-scissorsy, because it always takes the same number of hits to kill. Three hits is also too many; it feels tiresome, especially if the other player is trying to get away. The possibility of getting one-shotted as constant fear adds some thrill to the game. At the same time, I don't want a single dumb mistake to result in death, especially at the hands of a non-player character.

With that in mind, I'm bringing back an old concept I tried a while back: skill shots. Your shot can take away 1 hit point or all 3, depending on how good it is. I think it's especially satisfying to get a 1-hit kill because you don't bounce off at all.

HUD redesign

After posting last week's devlog, I realized the HUD was a bit of a trainwreck, so I redesigned it.

Before:

After:

Camera clipping effect

Last week I mentioned a few more changes I wanted to make to the camera clipping effect. These are now done, and after over a year of tweaking, I finally consider this effect good enough to ship.

The effect works by filling all the backfaces with a special G-buffer tag that causes later post-processing effects to block out any glowing edges and scan lines with a pure black color. The only downside is that the effect requires all environment geometry to be convex. I think it's a small price to pay for perfectly correct results with almost no performance penalty.

Active armor

I added an "active armor" ability that temporarily grants you invincibility and reflects any incoming damage onto the attacker.

Assault mode

Since October 2016, the main focus of the game has been Rush mode, where the attacking team must capture two control points by setting off a timed hacking process.

There were a few problems with this mode:

• The game is designed for 1v1, possibly 2v2 or 3v3 at the most. Rush games work best with large teams. In a 1v1 Rush game, the players often just take turns capturing one control point, then the other.
• Sitting still and holding X to hack a control point is not very exciting.
• The control points don't really interact with any other systems in the game. At best, they encourage you to camp in a single spot and wait.

The core consists of a number of modules which must be individually destroyed:

All turrets must be destroyed before the core becomes vulnerable. Turrets work like this:

I also realized that minions are important enough that they should be a part of every match, rather than being available as an optional ability. So now, they spawn automatically over time.

Where do they spawn from? Well, I wanted to give more reason for players to capture batteries other than just gaining more energy. So now, they also function as spawn points. You can choose to spawn from any battery you own.

This mode takes the game back toward the earlier MOBA experiments, but without some of the failed aspects (large bullet-sponge health bars, last-hitting).

Sniping tweaks

Your shield now goes down while sniping. High risk, high reward!

Active armor tweaks

You can now reflect incoming bolts, increasing their speed and damage. Useful for fighting turrets.

Misc

There are tons of other changes to talk about. One example is the "toggle zoom" option. Instead of holding RMB to zoom in, you can click it to toggle the zoom. I think unsexy accessibility options like this are super important. The new AI system is also still under construction. I'll be showing the game at Vector conference next weekend, so hopefully I'll get a lot of feedback to move forward with.

Vector conf

Had the opportunity to speak and show the game at Vector conference at Eastern Kentucky University. Got some playtesters and some great feedback.

I had the privilege of meeting Nathan Fouts from Mommy's Best Games. His was one of the blogs that convinced me of the viability of going indie back in 2009-2010. He played the game and enjoyed it but listed a lot of stuff he hated, which is exactly the kind of feedback I need. One problem he mentioned has plagued the game for years...

Dash combo

Up until now, I applied a shader that darkened everything behind the surface you're currently attached to, like this:

Notice the sharp line across the structure in the top left. This indicates that you can't shoot yourself anywhere in the darkened area, because you'd have to clip through the surface you're currently attached to. This always confuses everyone. I have to explain it to every new player.

Nathan suggested instead to automatically zip the player to the edge of the surface where the targeting line is clear, then launch them toward the intended target. So I got rid of the darkening shader and implemented his suggestion. Here's how it looks in slow motion:

That battery hangs below the floor level, but the game still lets me hit it by automatically dashing forward to the edge before launching at the target.

It seems asinine and nitpicky, but tweaks like this add up and affect players' subconscious impression of the game.

Rockets and decoys cut
Decoys were never really fun, and sensors accomplish basically the same thing (take aggro off the player). Rockets were really cool but not useful. Then I added grenades, which fill a similar role to rockets since they wait for enemies to approach before exploding.
New core design

Destroying six separate modules turned out to be tedious, so I lowered the number to three. People were also confused why they the core was invulnerable until the turrets were destroyed, so I put a force field around it which disappears once the core becomes vulnerable.
Force field changes
Previously, force fields had a short battery life. You could place one near a battery to increase its life, but it would still last less than a minute. The spherical shield itself was invulnerable, but there was a "generator" object inside the field that could be destroyed. If you happened to be inside the field when it was created, you could easily destroy the generator. Minions could also walk through the field to get inside and destroy the generator.
The problem is, now there are a lot more minions in a typical game, since they spawn automatically. I wanted force fields to be big, expensive, and important, but they don't last long with so many minions around. Plus, making them exclusively vulnerable to minions felt a little too rock-paper-scissory.
Force fields now sport an indefinite lifetime and a large amount of health, second only to the turrets. They can now be worn down from the inside or outside via minions, bolts, sniper bullets, grenades, or plain old drone attacks. And they're much more expensive.
Server optimization
The most CPU-intensive task in the game right now is actually ragdoll simulation. If more than 5 minions die at the same time, framerate drops from 300 to 60 or less. Ragdolls are strictly cosmetic, so I disabled them on the server to avoid CPU spikes. During normal gameplay, the server now puts one CPU core at 20-40% utilization, although AI might drive that number higher.
Project status and future
I decided not to teach this summer and instead subsist on money left over from last year. That means there will have to be a Kickstarter and/or Early Access release sometime around fall.
Audio
This is the biggest thing missing for any kind of release. Jack has been excited to work on this project for years now, but is currently crunching on LawBreakers. I started filling out Wwise audio events and spreadsheets in preparation for him to join the project this summer / fall.

Overworld redesign

Until now, I've been designing each level to function equally well for first-person running/jumping/climbing, and third-person spider bot PvP combat. I realized it would be much better to design separate levels for parkour and PvP, so now the plan is to have 9 parkour levels, each with a PvP map attached to it. While I was revamping the level structure I decided to redesign the overworld a bit as well. Still very WIP.

New tutorial

The PvP game has changed so much recently, and I kept shoehorning the new gameplay into a tutorial map originally designed for a different type of game. Finally I decided to start over from scratch.

Promo art



Someone asked me to design a retro cabinet for the game, so they could put it in their VR arcade. I jumped at the opportunity because I'll be showing the game at a few expos this summer and fall, and I need promotional artwork. The image above is all rendered in-engine, which I now realize is not going to work for a high-resolution physical sign. The new plan is to render something in Blender and trace over it with vector art.

Tweaks

Most of my work is on small details right now. Above is a development stream where I added animation to all the menus in the game, then added a footstep animation to the wallrun tutorial, then moved some blocking IO calls to the AI thread. All important changes that noticeably improve the game, but not exactly revolutionary.

Dot pattern

I had a bug in my AI, so I turned on my nav mesh debug renderer to see what was going on.



Sure enough, there was a bug where faces were not rasterized if they were almost horizontal but not quite. You can see a conspicuous gap in the screenshot above.

After fixing the bug, I thought the nav mesh looked cool enough to stay enabled in release mode. I cleaned it up by adding transparency and antialiasing:



Finally, I wrote a shader to make the dots fade out over distance:



Promo art

Last week I tried to use in-engine screenshots to create high-res promotional artwork. I realized that wasn't going to work, so I set about making Blender imitate my rendering style:



Of course Blender is so amazing that it was pretty easy. Freestyle edge rendering let me choose which edges to highlight, and a halo material worked for the stars.

I imported a few more models from the game, threw in a quick particle system, arranged them into a scene, and slapped the logo on it:



The colors seemed a little garish, so I tried another color scheme:



Everyone on Twitter liked the pink version better, but I really wanted to get rid of the black background behind the logo. I also enabled contour rendering to get a nice silhouette around the main character. Unfortunately, this also added a silhouette around each individual spark particle, which made them too distracting. I ended up putting the sparks on a separate render layer with no freestyle edge rendering, and then compositing the two layers together. Here's my final composite setup including an extremely simple bloom effect:



After a few more hours of posing and tweaking colors, I ended up with this:



Hopefully this will make for a nice banner at IndyPopCon.

Combat tweaks

As usual, I'm making tons of small but significant tweaks. Gameplay has changed a lot in response to a decent amount of playtesting recently. Weapons no longer take energy to fire; only building things incurs an energy cost. Energy also accrues more slowly, and upgrades cost more.

Here's 30 seconds of footage showing what the game is like now:

I ended up moving the main character into a separate render layer which allowed me to thicken the edges around her. I also added mist to give a sense of distance to the background, and a barrier in front of the character to give her some grounding. Also messed with the composition. Here's the new version:



New level

In the most recent redesign, I realized it would be prohibitively difficult to design maps that function equally well for both parkour/exploration and PvP drone combat. Now I'm designing different maps for different purposes. This is the first real map I've designed specifically for parkour:





Since I don't have to worry about things like balance and spawn points, I can focus on the spectacle and fun of just running around in the environment. Likewise, I can make smaller and tighter PvP maps without worrying about visuals too much.

New character

This guy has been planned for a long time, and now he finally has a model.



His name is Meursault, and he's a little nuts. I'm going to try animating and scripting the first encounter with him this upcoming week. Excited to see how it turns out.

WIP Cinematic

Been working on this cinematic where the player gets shot and drugged:



The player's model and Meursault's model are in separate blend files, so I created a "workspace" blend file with all the models linked in, so I can animate them together. Then I save the animations back out to their respective blend files, then line everything up in-game.

Settings menu



Finally fleshed out the settings menu. Almost every graphical effect can be turned off. All keys can be rebound, and the tutorial prompts and UI instantly update to reflect the change. In my last game, there was one menu for both keyboard and gamepad controls; if you plugged in a gamepad, you could only change the gamepad controls. One person was confused because they forgot they had a gamepad plugged in. Anyway, for this game I'm doing two separate menus. The gamepad menu is only visible if you plug in a gamepad. Also, other local players can change their own gamepad settings, but not the keyboard controls or any other settings.

Gameplay tweaks

I made a few changes in an attempt to move away from twitchy Call of Duty-esque gameplay. First, I halved the gamepad acceleration so that it takes 0.4 seconds to reach full speed. Then I slowed down the ADS zoom speed, and the speed at which drones and bolts fly. I also tweaked the energy rewards to encourage players to capture and hold batteries rather than aggressively attack all the time.

Also, it's a minor detail, but I'm experimenting with analog zoom; the degree to which you pull the trigger affects how far the camera zooms in. We'll see if people like it or not. Probably doesn't make too much of a difference.

Indy Popcon

Almost ready for Indy Popcon. Tweaked the promo art a bit more and had it printed out:



Along with this one:



Also put up a quick website: http://deceivergame.com

Indy Popcon

Pictures!







This was a lot of fun, but unfortunately I won't be going back next year. There were maybe ten games total; most of the con focused on unlicensed pop culture stuff and YouTube personalities. Most people were not interested in my game at all, but those who did sit down and play almost always went away with a huge grin on their face, so that was encouraging!

Gameplay recording

I recorded almost 400 MB of gameplay. This works by blasting all network packets from the server directly into a file, then playing them back in order. I can record an 8 minute play session in under 10 MB.



The only downside is that the network protocol does not capture camera angles, so I can only watch replays in this weird top-down view.

Here's some highlights:


Right player stalks left player from the top of a pillar


Left player captures a battery but immediately gets smashed


Right player gets overwhelmed by left player's minion army


Left player does a good job of staying behind their minions


Right player holds their own against minions, left player not so much

I got a ton of player feedback from Indy Popcon, which means I have a huge list of cool stuff to work on. A few notable changes already implemented:

Camera culling

Yes I'm still improving this. Previously I used a cone shape to cull geometry between the camera and the player's drone. The issue was that, if you backed up close to a wall, it would intersect with the narrow part of the cone, leaving you a tiny circle to see through. I switched from a cone to a paraboloid, which slightly improved the situation:



There was another issue as well. When transitioning from one surface to another, the player's rotation lerps smoothly, which is nice. The problem was that, all the culling planes were based on this lerped rotation, which resulted in a lot of popping and graphical artifacts during the lerp. Now the culling transitions immediately from one surface to the next, while the player model still lerps smoothly.

Cooldown tweaks



Previously, after a cooldown, all three of your jumps recharged instantly. Now they recharge individually, similar to Overwatch's Tracer, which was the original inspiration for this system. The difference with this new system is, the first jump takes a long time to recharge, while the other two recharge much faster. I want to give players an interesting choice here: do you immediately use the first jump because it's an emergency, or do you wait a split second longer to gain more future mobility?

That's all for now. Big changes in progress. Next milestone is GDEX in September.

Title screen redesign

The title screen also doubles as the first level in story mode, so it's super important. Here's how it used to look:



I didn't like how the dark colors contrasted with the white outlines, and the nighttime setting didn't mesh very well with the start of a journey. Also, the level had you moving to the left to progress, which felt surprisingly jarring since our brains associate left-to-right movement with progress. Finally, there wasn't much room to explore and mess around, and the tutorial was very linear.

So I flipped everything around to progress toward the right, changed the colors, opened up the layout a bit, and integrated the tutorial more seamlessly with the environment. Here's how it looks now:



Cinematic

The cinematic I've been working on is done, for now at least. It's a little over a minute long.



Unfortunately I realized it needs to happen in the third level rather than the second, which means I still have another cinematic to do for level 2 before this vertical slice is done. I'm excited for it though, along with all the other story stuff. I recently found a way to cut the story down to 9 levels, 2 of which are already done.

Kill cam highlighting

This is a minor but important quality of life improvement. The kill cam now highlights your killer when they're not directly visible. I basically just change the depth test to pass when the depth is greater, and then render the mesh with transparency. Easy peasy.

Upgrades to the upgrade system

Upgrades in this game have always had a certain risk/reward mechanic. They take a few seconds to purchase, during which your drone remains immobile and vulnerable. Most of the time this was fine because you had to be at a friendly base in order to upgrade, but sometimes the base got captured while you were upgrading, which kicked you out of the upgrade menu.

Someone at Indy Pop Con suggested an idea that would both add some visual interest and make players invulnerable while upgrading:



At first, I was stressing out about the edge cases and physics of flipping a drone around - what happens if two drones are attached to the base when it flips? What if an enemy drone flies through the gap into the void while the base is flipping?

Then I realized I had to fake the whole thing. Nothing actually moves at all; I disable the drone's collision and animate the model, but otherwise, the drone just sits there. No physics objects move at all. About half of this feature was implemented live on stream.

itch.io integration

I spent a day getting cURL building on Mac, Windows, and Linux, which allowed me to make HTTP requests. Now I'm using itch.io's API for login and authentication. Launch the game from the itch app, and my game receives a JWT via an environment variable. The game talks to the master server, which talks to itch, et voilà, it magically knows your name. Scary. Steam authentication will work basically the same way.

Virtual servers

Now that we have actual user profiles, it's finally time to let people connect to each other. Until now, I had half-assed plans for a matchmaking system similar to the one I use in campaign mode, but then I decided to try an idea I've been wanting to do since at least 2011. It goes like this.

I really miss community-run servers in games. It's hard to build a community for, say, Overwatch, without a dedicated place for people to meet. Even if it's not a community per se, some of my favorite memories happened in dedicated servers with custom game rules. That's gone now. These days it's a lot easier to pay some cloud provider and not have to worry about community-run servers falling out of date or distributing malware.

So the idea is: virtual dedicated servers. Anyone can create a dedicated server for free. It's just a database row that holds a name, a set of game rules, and a list of admins. When someone wants to play on this "server", a real dedicated server is allocated from the pool and set up with the custom game rules. It's like giving gamers their own little version of Amazon Web Services. Here it is in action.



Still a lot of work to do, especially on the server browser queries. I'd like to use a Reddit-like algorithm to keep popular servers at the top while still surfacing new configurations.

I'm using the fantastic SQLite for the database. Their build process combines all their source files into a single 6.8 MB C file. Super easy to set up.

Samsa

I made a robot doggie. His name is Samsa. He plays a fairly critical role in the story. Don't worry, nothing bad ever happens to dogs in video games and movies and literature.

I didn't like how he turned out first. He has to unfold into a sort of command center, which dictates certain design limitations:



At this point, the vibe he gave was more Stegosaurus than Golden Retriever. I asked Twitter how to make him cuter, and they told me to shorten and speed up the footsteps, add some Z-axis roll, and add an antenna. A lot of them also suggested "googly eyes", but that was a bit much for this game. I implemented everything else:



The antenna idea was brilliant because it's so easy and fun to animate and adds a ton of visual interest:



Damage buffering

One of the abilities in Deceiver is called "active armor". You hit a button, and any incoming damage gets reflected back at the attacker. Like so:



If you watch that gif closely, you can see that I react well in advance of the actual bolt impact. But what if it was really close? If you look in the top left of the gif, you can see the ping is over 200ms. If I reacted just in time from my perspective, I would be 200ms too late from the server's perspective.

To solve this problem, I created a buffer for all player damage. That means the server acknowledges incoming damage, but waits for a split second before actually applying it. And by a split second, I mean whatever the player's ping is, plus one frame for good measure.

Here's what that looks like. The bolt disappears and spawns a particle effect instantly, but the damage doesn't actually register until 200ms later:



Now I can react to the bolt right up to the moment the bolt impacts. Note that damage buffering is unnecessary and in fact detrimental between two players playing splitscreen on the same client!

Yes, this skews the game against attackers, but I think it's much more frustrating to get killed cheaply due to lag, as opposed to the minor annoyance of having your hits not register. Especially in a game where a lot of damage comes from non-player characters.

While developing this feature, I used a tool Ryan Evans recommended to me called clumsy, which simulates bad network conditions. Brain-dead simple to operate.

Lastly, I added pings to the scoreboard, so you can rage at players who have Comcast.



P.S. - Sound is coming. This is me being completely hyped out of my mind.

Team switcher

A ton of features have gone in recently to bring the game closer to a multiplayer demo. Previously, players chose teams before starting a match, but that didn't work for networked multiplayer. Also, there was no way to switch teams in the middle of a match. Until now!



Plus if you're a server admin, you can move other players to different teams as well.

Sniper ricochets

This is a little subtle and hard to see, but sniper bullets now work the same way as player movement: if the target survives the impact, the bullet ricochets. Sorry, I didn't have time to compile a trick-shot montage set to Breaking Benjamin.



IPv6

The master server and game server now listen on IPv6 as well as IPv4. If a client connects to the master server over IPv6, the master will return IPv6 addresses for all game servers. I suspect this may be a brittle solution that somehow breaks at some point, but it's good to have the plumbing done and know the code is future-proof. In related news, here's a great article I just read about what IPv6 could have been.

Minion pathing

Minions use a simple heuristic to determine which target to attack: whichever is closest. Now take a look at this map:



It has two floors stacked on top of each other. There's a turret on the upper floor. A minion who spawns on the floor directly beneath the turret will assume that the turret is the closest target, and kick off a pathfinding request to make its way there.

Unfortunately, the path to the turret turns out to be a roundabout excursion up a series of ramps, and will likely take the minion past other, closer targets. This is a problem. There's no way of knowing which target is actually closest without calculating a pathfinding solution for each and every one, which would be prohibitively expensive.

Instead, I decided to mark up the map with some extra pathfinding information. I added some special Blender objects which allow me to say "if you're inside area X, and you want to reach target Y, then you'll have to pass through point Z to get there". This metadata does not impact the actual pathfinding, it only improves the accuracy of the heuristic for choosing targets.

While I was messing around with minions, I also implemented a basic obstacle avoidance algorithm to keep them from running into each other and clumping together. The algorithm is this: if a minion is in front of you, turn to the right.

Another improvement I made is that if a minion attacks a player and then loses sight of them, they will advance to the last known position of the player and search for them before moving on to a new target.

In-game UI notifications

One piece of feedback I've received recently is that players have a hard time keeping track of the game state. How many batteries do I have? How many turrets do I have? Did the enemy just capture something of mine?

So now I'm highlighting batteries and turrets outside the player's range with colored icons. There are also icons for "under attack" and "lost", so you can easily see which things require your attention. If you happen to be looking away from the object that's under attack at the time, there's also a text notification.



Resolution switcher

I finally added settings for screen resolution, fullscreen/windowed, and v-sync. The settings menu is finally done.



Multiplayer demo

All of this is coming together to culminate in a multiplayer demo hopefully by the end of September. Prepare your bodies

Smooth camera

Thanks to Twitch viewer RayMarch for this one. They suggested adding some lag and springiness to the camera so you can better see when your drone hits something.



This makes things much less confusing when you bounce off an enemy:



The camera locks up again when you're done dashing or flying, so you can still do precision aiming.

UI cleanup

After seeing the first gif above, someone pointed out the "danger" sign blocking your view of the spider drone. The UI has a number of status indicators that turn on and off depending on the player state. These were scattered along the central vertical axis. I standardized their size and position and made the stack up nicely to the right of the reticle.

Turret tweak

Also visible in the second gif above is the newly tweaked turret design. Previously the base of the turret was dark, meaning spider drones could not shoot or climb on it. This caused some issues, as you're trying to aim at the turret and suddenly get a big confusing X on the screen indicating you can't shoot there. The new turret base allows you to crawl on it while avoiding other gameplay issues by having the actual turret body hover a foot above the base.

Build ID overlay

You can also see the new build ID overlay in the screenshot above. This will help me debug issues when people submit screenshots, and hopefully prevent people from taking pre-alpha screenshots as final quality.

Staggered grid experiment

I tried staggering the grid points to create a triangular pattern rather than rectangular:



I found the rectangular pattern emphasized the level geometry more clearly, while the triangular pattern distracted from it. I ended up undoing this change.

Kicking

Server admins can now kick people. You can even kick someone playing on the same screen as you.



Progressive upgrade pricing

Each upgrade you purchase now increases the price of all future upgrades. This makes the order of purchase more important, and also allows me to price things relatively cheaply at the beginning, which gives the player more options. Previously you really could only choose between the four cheapest upgrades at first.

Map work

Revamped Office:



Cleaned up and updated Refinery:



Cleaned up and updated Plaza:



Also, I tested out how Samsa looks in-engine. :)

This week has been INSANE. I don't even know why. When productivity strikes, you don't ask questions. You just go with it.

Shotgun
We coded up a shotgun live on stream:

The result:



Full auto bolter

The bolter is now full auto:



Speed changes, 20% map shrinkage

I increased the drone crawl speed a bit, and then decreased some other numbers to make it even faster in comparison. I slowed down the fly speed, decreased the drone's maximum range, and shrunk all the maps by 20%. This makes it more viable to tactically change your position by crawling, where before, everything was so spread out and the crawl speed was so slow that you felt essentially rooted in place. It feels like a whole different game now.

Camera rotation clamping

I clamp the camera's rotation so that the player is never stuck aiming straight into the wall they are attached to. At first, I clamped it against the wall's plane, but then I realized it was okay to let the player aim into the wall a little bit, so I switched to a cone. If the player tries to rotate the camera so that the look vector is inside the cone, the game pushes the camera back.

There were a few problems with this system. First, I didn't realize the algorithm needed multiple iterations to keep the camera out of the cone. So sometimes you would see the camera jitter a bit over the course of a few frames. I corrected this by running multiple iterations in one frame.

Second and more importantly, the cone sometimes pushed the camera out in a way that changed the player's aim unexpectedly. When landing on a new surface, I would start the cone perpendicular to the camera, then slerp its quaternion toward the final rotation of the surface. Unfortunately, slerp doesn't always rotate in the most direct path, and that caused it to move the cone in weird ways.

The new system immediately sets the cone orthogonal to the surface. Instead of tweening the cone's rotation over time, it tweens the cone's size. The cone starts out at 0 degrees and slowly expands to 45 degrees. This pushes the camera in a very smooth and predictable way.

I still have to smooth out the cone's rotation when crawling between surfaces, so I switched from a quaternion slerp to a linear vector lerp which takes a more direct path to the desired rotation. The end result is much more smooth and never disrupts the player's aim.

Here you can see the system nudging the camera away from the wall after landing:



Drone repulsion

I've had a pretty major problem until now, which is that you could shoot at a drone, barely miss, and anti-climactically land right next to them, with your character models uselessly clipping through each other. Worse, it's incredibly difficult to hit someone once you're that close; the physics just don't line up.

I corrected this by adding "repulsion". If two drones are just crawling around and their shields bump into each other, one drone will take a hit and the other will go flying. Drones that just landed take precedence. If both drones are just crawling around, the one that's moving faster takes precedence.

This change helps introduce more space and movement between players. Interestingly, this extra flight does not take one of your three cooldowns like it normally would.

Extra drone upgrade

I had a hard time keeping track of how many drones I had left while playing. It was always a surprise when I lost a match by using up my drone stock. So now I display your remaining drones at all times in the UI. I also added a new upgrade which allows you to purchase extra drones for a relatively high price. These changes are designed to make people play more carefully.

noclip in replays

I've had a replay system for a while, but the camera has always been a bit weird. I added support for noclip, which will hopefully allow me to film some neat scenes for a trailer.



Server regions

Servers now know which region they are in, and the client asks you which region you're in, and the master server matches the two together.



Text emotes and chat

The UI for this is still a bit rough, but chat messages and text emotes (a la Rocket League) are in.



Misc

Players are now rewarded for damaging other players, even if they didn't get a kill. Servers will now kick you after a certain period of inactivity to prevent AFK players from clogging up matches. I've also made a ton of improvements to the netcode, making it more robust and improving the client-side prediction.

Objective labels

After adding text emotes last week, I realized how useful it is to be able to reference points on the map by name. To facilitate this, I added labels for batteries and turrets. Batteries are numbered, turrets have letters. These labels also appear in the event feed in the top right, so there are multiple ways to find out which objective requires your attention.



Shell casings

This was a no-brainer. The bolter, shotgun, and sniper now eject spent cartridges. They're purely aesthetic. The cartridges are sized differently for the different weapons.



eeeeeeeeeeeee i love it

Audio

Jack has been summoning incredible sounds out of the ether despite being one of the busier human beings I know. I spent most of this week hooking them up and experimenting with spatial audio. I was kindly given a trial copy of Wwise Reflect, which I immediately integrated. Unfortunately, the plugin didn't quite work for our use case. We're switching to a more standard reverb setup where the game scales different reverb presets from 0-1 depending on the results of a few raycasts.

Reverb is nice, but obstruction and occlusion is essential for gameplay. Obstruction is easy enough - one raycast is enough to determine whether a sound is blocked or not.

Occlusion is trickier. Let's say a sound is just barely obstructed by the edge of a wall. The sound would not be affected much, because the occlusion wouldn't be very high. In some sense, the sound just takes a slight detour around the obstruction, arriving at the listener barely distorted.

I'm approximating occlusion by estimating how far the sound would have to travel to reach the listener without penetrating any walls. If the sound is nearby but behind a large wall that we can't get around easily, the occlusion should be 100%.

To calculate this, I'm leveraging the AI nav mesh. When a sound source is obstructed, the audio system does a pathfind to determine how occluded it is. Here's a visualization:



Sound doesn't actually work this way, but the total path distance minus the straight-line distance is a good rough estimate of how far "out of its way" a sound will have to travel to reach the listener.

Map switcher



Server admins can now select which map will load next, even if the map is outside the server's normal rotation. They can also force the server to instantly switch maps.

The Last of the Jaggies

It took me two and a half years, but I freakin' FINALLY murdered the last surviving jaggies.

I started out using a typical edge detection post-process effect for the glowing edges. Then for a while I was supersampling the edges. Then I switched to a new system based on GL_LINES, which finally gave me some nice anti-aliasing. As a refresher, here's the comparison:



This has worked pretty well for the most part, except for a few cases where I got Z-fighting between the solid geometry and the lines. It looked like this:



I tried to mitigate this by restoring the depth buffer with a shader that sampled multiple pixels, taking the farthest one, but it wasn't enough.

A lot of times it was more subtle than the above example. The anti-aliasing would get cut off by the depth buffer:



Long story short, turns out drawing lines on top of solid objects is a common problem in 3D modelling software, and thus OpenGL has a built-in solution called glPolygonOffset. You render the solid geometry with a specially calculated depth offset that takes the depth derivative into account. So polygons that have a larger depth differential get offset more.

Rendering the whole scene with this offset messed things up for my culling system, so I settled on drawing the scene once normally, then instead of restoring the depth buffer later for edge rendering, I render the whole scene again in a depth-only pass with the polygon offset enabled.

It works beautifully:





Shotgun kick

I'll leave you with this gif of a feature I threw in yesterday. The shotgun has a teensy bit of kick now.



It's a minor thing in the grand scheme, but it makes me happy.

Cooldowns, again

Cooldowns have gone through the most iteration to date. Aside from the health system, movement system, reticle code, and story. :P

People were having a hard time equating the three pips below the reticle with the amount of "charges" they had left. The bolter made things more confusing both for the player and for the code, because it let your fire three bolts per charge. Then the shotgun came along, which required two whole charges to fire. Things were getting crazy.

I did away with all that and replaced it with an actual heat-based cooldown system. Looks like this:



You can also see the new muzzle flash effect in that gif.

Linux

I finally re-installed linux on my desktop, and wonder of wonders, the graphics drivers worked out of the box. That never happens. I was shocked. Here's the built-in open source AMD drivers running the game faster than Windows 10:



Spawn effects

Jack made a pretty awesome spawn sound which had basically zero accompanying visuals, so I added some:



Adding controllers on the fly

I never realized what a huge win this feature is. Especially at expos, it's great to be able to add and remove players on the fly as people come and go. Took maybe 50 lines of code. Totally worth it.

Friends, admins

I finally added some rudimentary friend functionality. You can create a server and mark it as "private", which means only friends are allowed to join. I also added the ability to mark others as server admins, which means they can change the server settings, switch maps on the fly, mess with teams, and kick people.

Tons of other stuff is going on in the background, including work on the first official trailer (woah)

Trailer
I spent a few weeks animating, capturing, and editing a trailer. I started out working on some story scenes:

Animation can be really tricky. Here's a problem I encountered with Blender's "Child Of" constraint:



I export the animation at 24 fps, but play it back at 60 fps. That causes the cigarette to shake around a little. Fortunately you don't really see the cigarette too closely in the shot I had planned.

At any rate, I talked to the wonderful M. Joshua who advised me to hold off on the story elements. The trailer isn't for the full release, only for a multiplayer alpha.

I did finish the trailer, and even managed to cram a teensy bit of story into it. OBS Studio wasn't able to record even 720p video at 60 fps without hitching, so I picked up an HDMI pass-through recording box and hooked it up to my laptop. Worked beautifully at 1080p 60 fps. This is the first time I've been able to make a 1080p trailer.

Generators

The Assault mode is a bit like League of Legends. Team A tries to destroy Team B's turrets. When people try this mode, they immediately want to know if they can repair their turrets. A repair tool has been on my to-do list for some time, but I wasn't excited about adding a whole new ability that accomplishes only one purpose.

Then I started thinking about Sensors. These have been in the game almost from day one, but they've never felt overpowered like everything else does. They detect and track enemy drones, and they create a stealth zone where you become invisible. That's it.

I decided to combine the repair tool idea with Sensors and ended up with Generators. In addition to the old sensor functionality, these also passively generate energy at a fairly good clip. They pay for themselves within 30 seconds or so. They also slowly heal any minions and turrets in range. I also buffed them up and gave them more health and a shield. You can spawn a ton of these near a turret to get a whole bunch of healing power.

Prepare for alpha

The multiplayer alpha is really close to release. Just need to polish a few things and deploy the servers. I tested my ability to run multiple instances on the same server. It looks like I could run about 6 games with 4 players each on a single t1.micro.

I added support for GameJolt login. Also added a crash reporter on Windows:



It also opens the GitHub issues page after uploading the crash dump.

I'm showing the game at GDEX this weekend, then at LexPlay next month.

GDEX

My friend Charles Dickens loaned me some massive TVs that made this booth a sight to behold:





Deceiver got two honorable mentions for something something art-related, and best of show. The weekend was a lot of fun, and there were a ton of great games. BOMBFEST absolutely stole the show!



One interesting insight was that the game played really really fast, much faster than previous builds. One one hand, that's great, people love the action, but on the other hand, I could tell people were getting tired playing the game. It's very demanding. Players would become completely absorbed for 10 minutes, then snap out of it and say "okay that's enough of that".

That was one thing I noticed about the best of show winner MageQuit. Despite offering a lot of PvP action, it actually plays pretty slowly and gives players a ton of downtime. I realized this design works great for local multiplayer games where you're mainly trying to hang out with friends anyway.

This ties in with something I read a while back about the success of PUBG. That game also has a ton of downtime, which is great for streamers because they need time to interact with their chat.

For now, I tempered the pacing a bit by increasing cooldown times. It's a stop-gap measure. I would like to find another way to facilitate those all-important peaks and valleys in pacing. I think larger maps and larger teams would be a great way to do that.

Website, Steam

I made some major improvements to the website on the advice of the illustrious Jessie Kooner.



I also submitted a Steam store page for approval from Valve so people can wishlist the game.

This leaves two items on the alpha release to-do list. First, I'm waiting on itch.io to enable OAuth support. Second, I need to buy and deploy some dedicated servers.

I wanted to release tomorrow, but it's looking like I'll have to push it to next week. At any rate, it's getting close!

Dedicated servers

I shopped around for a while but ended up back where I started: Digital Ocean. So, the reason you're not supposed to use VMs is because performance is unpredictable; you never know when someone else on the host is going to saturate the CPU with a massive cron job or something. Theoretically you should be shielded from that, but in reality, it's not great for realtime applications.

I personally can't yet say whether it's an issue or not. But I did purchase special "high CPU" instances, which guarantee that you get two dedicated physical cores. One instance each for US East, US West, and Europe. I'm running four server processes per core for now.



Also set up an extremely simple alerting system that sends me an email when a server process crashes, and when a client uploads a crash dump.



Dashboard

I added a simple dashboard to the master server that allows me to execute SQL commands and keep an eye on connected servers and clients.



The bulk of this feature was done on stream:

Spotting

Someone on stream suggested adding a "spot" feature which would allow players to call out targets for their team. I thought it was a pretty good idea. This feature was also done on stream:

Gifs

Needed some new gifs for the website, so I recorded a few.





The alpha is basically ready. I might have to launch without itch's OAuth support. We'll see.

The multiplayer alpha is live! Limited number of keys, check it out now: https://etodd.itch.io/deceiver

Here's the trailer:

Nice looking game, I really like this style.

Playtest feedback

I've had a ton of incredibly useful playtest feedback the past two weeks. Here are some of the gameplay changes and additions I've made in response to feedback:

Team bases are now surrounded with indestructible force fields to prevent spawn camping.



My friend Zac Fierce gave some great feedback about abilities. Previously, you could carry three abilities, which were permanent. Abilities got mapped to X, Y, and B in the order they were purchased. You could "toggle" them on and off by pressing X/Y/B to select the ability, and then right trigger "fired" the ability. The ability automatically toggled itself off after firing.

One of the problems with this system was that it changed the behavior of the right trigger without telling you. If you switched to the shotgun and attemped to fire, you'd expect it to fire and then toggle back to the normal movement/jump ability. But if the shotgun wasn't ready to fire, you none of that would happen, which might leave you confused as to which mode you're in.

Zac suggested putting the movement ability on a separate button, but I didn't want to add complexity to the controls. There was also the problem that the reticle gives tons of feedback about where you can and can't jump, and of course if you have a weapon equipped, you can fire it anywhere you want. So I would need two reticle indicators, one to show whether you can jump, and one to show whether you can fire. I might still do this, but it will take some thought to pull it off without complicating things too much.

Here's what I ended up doing. Rather than toggling abilities on and off, I made it so that when you press Y, it switches to the Y ability and stays there until you select a different ability. I also cut the number of abilities down to two, so that I could map the movement/jump ability to X. I also now allow abilities to be replaced, so while you can only carry two at a time, you can buy as many of them as you can afford.

The upgrade menu also now lets you choose which slot you want the ability to go in, which solves another issue. When someone always buys the shotgun first, they build up muscle memory that says "Y is shotgun". If they change the order of buying, the old system would change their control bindings so that Y is something else. The new system lets the player choose their control bindings regardless of purchase order.

Here it is in action:



Another feature request I heard a lot was for a "capture the flag" game mode. So that's in now:



Another common complaint dealt with the camera. I've explained previously how I use a cone to nudge the camera away from whatever surface the player lands on, so that they're more likely to be aiming in a direction they can shoot toward next.

Unfortunately I've always kept this cone active, even after the player has landed on the surface. This prevented the player from looking directly back at the surface they were attached to. They would have to swing the camera around the cone. This was an easy fix. After landing on a surface, there's a half second where the cone does its thing, and then I disable it. Now you can swing the camera around any way you like without regard for level geometry.

Spotting was another requested feature. I already have text emotes in the game that allow players to shout out specific turrets or batteries, but it's much more intuitive to just aim at something, hit a button, and have everyone see it.



Assault needed a bit of balancing. It was weighted pretty heavily in favor of the defenders. I'm balancing this by giving the attackers a pretty hefty chunk of energy to start with, and also by adding time to the clock and giving the attackers extra lives for every turret they destroy.

Also, players on the attacker team used to have an individual pool of lives, which meant one player could run out of lives and get stuck spectating. I switched to a ticket system so that lives are shared across all players.

That takes care of gameplay changes for the most part. Of course I've been tweaking cooldowns, damage values, and other numbers like crazy. But that's not very interesting.

One thing everyone agrees is very interesting is authentication! I asked itch.io to add third-party OAuth support, and they did it! Now you can log in to the game using your web browser even if you don't have the itch app installed.



I also integrated the Steam SDK, which will also log you in automatically.



Some players were having issues initiating and maintaining a connection, so I made another pass at the netcode and added some redundancy and improved latency handling. Now I'm sending every message at least twice as a pre-emptive measure. Also, when packets arrive delayed or out of order, the game does a better job of fast-forwarding to catch up with the server.

Another common feature request was mouse support in the menus. This is mostly done now.



Tons of other minor improvements have also been made. Players can edit server settings in-game. The game now gives more feedback when you kill another player. There's now an FOV slider. The input system now respects your operating system's keyboard layout. The crash reporter system has allowed me to fix a number of crash bugs.

I'm also putting together some assets for the upcoming Kickstarter. Progress continues!

CTF tweaking

CTF turned out to be a bit too easy to score in. There was no incentive to capture the batteries, which takes a lot away from the game. So I added force fields around the flags. Now you have to beat down the force field before capturing the flag, which encourages you to earn more energy to improve your damage output and capture flags quicker.

Story mode

Started working on story mode again, beginning with the most important features, like shopping cart physics:



The story mode is basically Dishonored, except there are no people and all you do is climb.

For a long time, the first level has had a problem of not feeling like a real place with a purpose. It feels like everything was put there just for you, the player. I spent some time fleshing out the level and making it feel more like a city with a life of its own:





This is like, version 10 of this level. There's still a lot of work to do on it. I would like to add more NPCs.

Hello! It's been a while since the last update. I was out of the loop for a few days recovering from wisdom teeth removal. Also, while the past few weeks have been very productive, it's more like a thousand small improvements rather than two or three big ones. I'm writing a lot of commit messages like this:

Story mode changes

I was able to watch some brand new players get a little lost and confused in the Docks level I posted last time, and have since refined the level design to the point where my sister had no problem finding her way around. Some super dedicated playtesters in our Discord server also found a ton of bugs and exploits which I was happy to patch.

I also decided to include audio logs in the game, to give more time to explore the characters without having to build expensive cutscenes. Other small touches to add life to the Docks include this fire effect which didn't turn out quite right on the first try:

Drone combat tweaks

The active armor effect has been a problem for a while. It was too subtle. Just some sparkles around your drone. I finally did what I should have done months ago:

Back in August I posted about "drone repulsion". Basically, if two drones are crawling around and they bump into each other, the slower one takes damage and goes flying. The intent was to avoid the problem of shooting at a player, just barely missing, and landing anti-climatically right next to them, so close that your shields overlap. Drone repulsion ensures no two drones ever overlap.

The problem is when you're crawling along, suddenly bump into an enemy drone, and your drone goes flying 20 meters without any input on your part. It's jarring, disorienting, and not fun.

So I got rid of it and instead solved the problem of near-misses in a much more obvious way: use a sphere-cast rather than a raycast. Now if you're flying toward an enemy and any part of your shield touches their shield, that counts as a hit for you. Once you land and start crawling, no more drone repulsion.

Can't believe it took me this long to figure this out.

New map

This is Treatment Plant. Actually it's an old map by Ian Cuslidge, but it's been revamped, cleaned up and welded together to accommodate the new rendering system and game types.

Other news

Special thanks to Ryan Evans for pointing me in the right direction to get my game recognized by graphics drivers so that it runs on discrete GPUs rather than integrated Intel HD garbage. Here's the code in question:

#if _WIN32
extern "C"
{
    _declspec(dllexport) DWORD NvOptimusEnablement = 0x00000001;
    __declspec(dllexport) int AmdPowerXpressRequestHighPerformance = 1;
}
#endif

Also, look for a new entry in the "Poor Man's" series of game programming articles this coming Tuesday.

In the course of poring over old screenshots and gifs for said article, I dug up a couple neat images from the past 2.5 years of development:

Seven

Seven is the character with the most screen-time in the game. And she's a no-nonsense badass. I knew I needed to dedicate
some time to her.

I started out last week by playing hair stylist. I wanted to take Overwatch's wavy hair and bring it into Deceiver's neon aesthetic.

Next I modeled some cyberpunk combat boots.

Then the rest of her outfit.

The last piece was a military ALICE pack, but I'll get to that later!

Rain audio

Logan whipped up a looping rain sound for me. Previously I've just ramped the volume up and down based on a system that calculates how much rain is falling near you. But this time I wanted to control not only the volume, but also the positioning. So if you're standing under an overhang, the
rain will sound like it's coming from outside.

I already had a grid of raycast results surrounding the camera to drive the particle system, so I just ran some weighted averages on that to figure out where to place the rain sound. I used a Wwise RTPC to set the spread to 100% when the sound is close to the camera, so if there's rain all around you, you'll hear it in both ears.

Reverb voxel

I spent a day and a half on this crazy voxel-based reverb system. When my level importer builds a level, it first chops the level up into chunks.
Then at the center of each chunk, it queries the AI navigation mesh and collects all the points that are "visible" from that chunk.

Then it rasterizes those points into three "shells", for close range, middle range, and far range geometry. Each shell is sort of like a spherical
black and white bitmap image. If the close range bitmap is 100% black, then that means we're in a pretty tight space.

The importer spits out three coefficients for each voxel chunk, representing the amount of close range, middle range, and far range reverb. After this it runs the whole voxel through a smoothing kernel and writes the result out to a file.

At runtime, whenever a sound plays or a sound emitter moves, it's just a quick lookup to figure out what reverb values to use.

I'd like to write more about this soon. Hopefully there will be another Poor Man's article on it. :)

Adaptive client-side interpolation delay

I watched a talk on Overwatch netcode:

Pretty much the only thing they mentioned that I wasn't doing already was the adaptive interpolation delay. Basically, if you have a reliable
connection (regardless of ping), the game will buffer incoming packets for a shorter amount of time, because it trusts that new packets will
come in on time. This reduces latency.

If your connection is dropping packets left and right, the game will start to jitter. Eventually it will decide to increase the interpolation buffer to smooth over those missing packets. I use a simple scoring algorithm with some basic hysteresis to prevent the client from switching back and forth all the time.

Of course, algorithms often do the wrong thing, so it's important to give people control whenever possible. Hence this menu option:

Store art

The character in the store art I've been using dates back to 2014... and it shows.

With Seven's model finally done, I decided to redesign the store art and focus it around her, since she's the most important character.

First I tried just adding her to the existing scene:

This worked okay, but I was never quite satisfied with this color scheme. I tried messing with the lighting.

At this point I started soliciting feedback from some fellow developers, and they all thought it looked confusing and muddy. The foreground and
background bled into each other too much.

I kept messing with the lighting.

Everyone wanted me to switch to cold background, warm foreground, so I tried that:

Eventually I realized the old 2014 model had to go. It wasn't up to par. I also had to spend some time in the Blender compositor to get ambient
occlusion to behave the way I wanted to. By the end I had seven render layers, some of which spit out multiple passes.

At this point I slapped the logo on top and realized it would never work. The logo is surrounded by a dark border, and it didn't stand out against
the dark background at all. So I switched back to a pink background, and also threw in some geometry from a level I've already completed.

You can see I also removed the scan lines from the logo. On their own, they were okay-ish, but I realized they were just too complex and I couldn't make them work with anything else.

I'm still not 100% happy with the colors on Seven; I think she might not stand out enough. But after two whole days of tweaking I think my time is better spent elsewhere. I've never had this much trouble with store art before.

The capsule art stands out pretty well, but I'm still worried about it.

The problem I've had with this game from the beginning is that it's essentially two different games in one, complete with two different art
styles. There's the exploration game with vibrant, feminine colors, and then there's the drone combat game with deep, masculine colors. Which
style do I use for marketing materials?

A fellow dev suggested doing a simple A/B test with Facebook ads, which I actually tried once a few years ago. The sample size for a $50 ad spend (on the order of 50 clicks) seemed to small for me to take action on. I dunno. It might be a good idea.

Improved map view

The map view before was too zoomed in to show the whole map at once, and it kept panning the camera around all over the place. Also, the UI was
unclear. I switched to a static camera that overlooks the whole map, and cleaned up the UI:

Cooldown netcode

The cooldown netcode has been a problem for a while. Previously it worked like this. The first time the player performed an action, the server
would add the necessary heat to the cooldown meter, but then instantly subtract the amount of heat that would be dissipated during the network
round-trip time (RTT) between the server and client, to ensure they stayed in sync.

When the client needs to add heat to the cooldown meter, it does so instantly and ignores the cooldown value coming from the server, simulating it locally until enough time has passed for the server to receive a packet and send one back. Then the client overwrites its local heat value with the one from the server. Most of the time, they're perfectly in sync and the handoff isn't noticeable.

However, the server only needs to compensate for lag one time. If you have multiple cooldowns stacking on top of each other, and you subtract the
RTT from each one, you'll get incorrect results. So the server only performed this lag compensation if the heat value was at zero.

The tricky part is, the bolter adds a very small amount of heat to the cooldown meter for each shot fired. It takes less than a third of a
second to dissipate the heat. Turned out, if your ping was high enough (i.e. the RTT was more than 150ms), the server would subtract enough
from the cooldown meter that by the time you fired the bolter again, the heat would be down to zero already, and the cycle would continue. You
could fire the bolter indefinitely.

Long story short, I made the client do lag compensation instead of the server. It takes the current heat value coming in from the server and subtracts the RTT no matter what. Much more simple and robust.

Grapple

As I've said before, the singleplayer portion of the game is basically Dishonored with no enemies and all you do is climb. Well, I wasn't
joking. The game now has Dishonored's Blink ability as a movement upgrade:

It uses the same cooldown system as the rest of the game, which I like because the cooldown is pretty quick the first two times, and slows down
after that.

Triangular minion head

A viewer on Twitch said I should try making the minion's head more triangular. I had no argument against it, since everything else in the game is
triangular. Now all my brand new promotional art is outdated :(

Force field sound obstruction

This was an easy win. I already have audio obstruction/occlusion code, it just wasn't taking force fields into account. It's pretty cool when
someone fires a weapon inside a force field and it sounds muffled and muted.

UI colors

I switched the UI from teal and pink to yellow and pink. Here's how the main menu looks now.

Working on some scenes for the trailer. Here's Seven and Samsa in "holographic cyberpunk space command center" mode:

He folds up into cyberdoggo form:

And Seven packs up to leave:

The backpack animation was incredibly tricky. It's not perfect, but I'm okay with it. I did it by duplicating the bones that affect the
backpack, then creating constraints that glue the new bones to the original ones. To put the backpack on, I just animate the influence of
these constraints from zero to one.

Still working on the trailer. Here's a new shot from it:

It's coming together quicker than anticipated. Most of the footage is pretty close to final, and now it's just a matter of getting the audio together.

In the mean time, I realized while watching gameplay footage that the weapons were in desperate need of camera recoil. So I added some.

It's just velocity and acceleration. I overwrite the velocity when the gun fires, then the acceleration (or "gravity") brings it back down. Once the angle gets close to zero, I limit the velocity by a multiple of the current angle, so it slows down instead of slamming back to zero. Relevant code here.

Unfortunately this new feature means I now have to re-shoot several scenes in the trailer.

I got an opportunity to talk to Michael Cox, marketing guy from Crows Crows Crows. He's @DevMicco on Twitter, he has DMs open. Great guy with super helpful advice.

He told me to release the trailer, release the demo, push PR, everything, but don't launch Kickstarter. Instead funnel people into Discord and mailing lists. then launch Kickstarter when there's enough people to make it succeed on the first day.

That makes a lot of sense to me, so that's tentatively the plan I'm going with now.

In the meantime, we had another playtest session on Thursday and I came away with a bunch of balance tweaks and bug fixes, which I was able to knock out yesterday.

The most interesting news is, the game now has a Discord bot.

This thing allows you to indicate when you are available to play, and if anyone else is online or marked available during that time, you'll get a
notification. It also periodically blasts out statistics about who's playing.

I've been using vyte.in to organize playtest sessions, and it hasn't been great, so hopefully this will work better.

Initial Discord integration is done. You can now see what people are doing in-game.

And if you're in a game, you can invite a person or a whole channel to play with you, even if you're in a private server.

The invite updates the number of players in the server in real-time.

I also upgraded the bot to place LFG players in a special role and mention them specifically when people are playing.

I'm really impressed by the quality of Discord's software. Their APIs are well-designed. Everything they do is a pleasure to work with.

New map WIP

I decided the maximum number of players I want to support is 12, so the game can support 4 teams of 3 or 3 teams of 4. In light of that, I started working on a new map with enough room for so many players. This will be the largest map yet.

It's still a work in progress, but sometimes I'm tempted to leave parts purposely unfinished.

Presets
Some friends were kind enough to play a few local matches of Deceiver with me, and even though most of them were familiar with shooters, they were still confused. It didn't help that the game was in the middle of some of the design overhaul changes described below.

What I should have done was set the game to unlock all the abilities and disable the advanced stuff so we could all just shoot each other. The game does offer those settings, but I didn't want to sit around tweaking settings while they waited.

This is related to another problem I have with the servers online. Playtesters have created 77 different servers with different settings. It's impossible to see at a glance what the rules are for each server. Also, when creating a server, it's overwhelming to see all these options, and it encourages you to tweak all of them, which is usually not a great idea.

Presets are the solution I came up with. When you create a server, you can choose "Standard", "Arcade", or "Custom". Now you can see at a glance what to expect from a server. Arcade unlocks all abilities, and Custom lets you go crazy with any setting you want. The nice part is, these presets work with all three game modes. I can easily envision more presets like "Snipers Only", "No Shields", "Fast Cooldowns", etc.

Hardware cursor

Ever played a game where the cursor felt laggy and unresponsive? That was my game until just recently. Turns out, computers use a separate low-latency hardware path to render the cursor. I switched from my custom OpenGL cursor to a hardware cursor. Unfortunately, that meant my vector-based anti-aliased cursor mesh wouldn't work anymore.

I spent WAY too much time trying to pixel art a cool looking cursor, and ended up settling for a plain ol' crosshair. I may switch to the default system cursor, but I think this helps everything fit together better.

Design overhaul

I made a number of sweeping design changes. Below is a list, with the accompanying reasoning behind each change.

• Remove ticket system from Assault. Assault is an attack/defend mode, and previously the defenders won by either running the clock out or exhausting the attackers' tickets (respawns). Now the ticket limit is gone. Reasoning: Originally, both teams actually had limited tickets, which made the game type devolve into just regular ol' team deathmatch. With only the attackers limited by tickets, it still meant the defenders were basically playing deathmatch. Receiving energy and deterring the enemy is enough of a reward for killing an enemy player, there's no need to attach a win condition to it. Also, the ticket system had to scale based on the number of players, so if a player joined or left mid-match, the number of tickets would change. Confusing UX.
• Remove spawn selection. Previously you could spawn from any battery you captured, and by default you spawned at the battery nearest to where you last died. This is all gone now. You only have one spawn point. Reasoning: it's important to have downtime with lower intensity gameplay. Also, the decision of where to spawn was never interesting, and mostly just served to confuse newer players.
• Make turrets auto-heal and decrease player damage against them. Reasoning: Once again, over the past year or so I forgot that the Assault game mode is basically a MOBA. Players are not supposed to fight turrets themselves. It's not interesting or fun. So now, it's mostly worthless to fight turrets.
• Make ability re-purchases cost nothing. Once you've purchased an ability, you can now replace it with another one and later switch back to it free of charge. Previously you had to purchase it all over again. Reasoning: I want to encourage more diverse usage of different abilities. Also it feels more friendly to the player.
• Make all abilities free to use. Previously, you would pay energy to buy an ability, and then some abilities also required energy to use. Now, energy is only used to buy abilities. Reasoning: it was always impossible to balance prices for moment-to-moment combat purchases against prices for longer time-frame purchases. If a high level ability costs 1000 energy to unlock, and a low-level ability costs 20 energy to use, that means you can spam the low-level ability 50 times. Also, you never got a sense of progression because you're always spending your progression currency on combat. The number never really goes up. Now the abilities are easy to balance: I just put separate cooldowns on them. And your progression is much easier to see, since your energy always goes up until you spend it on an ability.
• Change the minion ability to a passive spawn rate boost. Previously you could use it to spawn minions at will. Now it just takes up an ability slot and increases the rate at which minions spawn from your captured batteries. Reasoning: the minion ability previously required no strategy. You could just show up at an enemy base and plop down 10 minions in as many seconds. Now you are more encouraged to capture and protect batteries, since they spawn minions.
• Change DM and CTF modes to no longer spawn minions by default. Reasoning: the DM and CTF modes, which should be straightforward for anyone familiar with shooters, confused my friends who are familiar with shooters. These are the modes I use to introduce the game to new players, since there's much less to explain. But people are still confused, and one of the major confusion points is "who are all these people walking around?" It just makes the game feel unfocused and chaotic. I still think minions are a blast, and people love shooting them, so I'm keeping the minion boost ability in for these game modes. Instead of boosting the minion spawn rate, it enables them spawning at all.

Stealthed rectifiers
Rectifiers do two things: they heal stuff, and they create a field which provides stealth for your drone and alerts you to the presence of enemy drones.

Previously, rectifiers were pretty ineffective because they were easily destroyed. Now they're tougher because they're stealthed by default, so enemies can't see them unless they plop down a rectifier of their own.

Unfortunately, the healing particle effect I was using completely gave away the rectifier's position. It showed a trail of particles going from the rectifier to the object being healed. I changed the effect to use a sphere mesh instead. Had to modify the instancing system to allow per-instance colors.

Suicide minions

You can now launch a grenade at a friendly minion and it will attach to the minion's back, waiting for a hapless victim to wander near. While implementing this feature, I accidentally turned the minions into giant walking grenades: