Devlog for version 0.20 news

Hello my dudes ! It’s time to unwrap what we’ve done during this sprint 0.20 !

Content !

To kick things off, as promised we’ve had time to focus on a bit of content for this iteration. We’ve added traps in the levels. The idea behind these was to take a bit of control away of the players. Our reasoning is that a game without luck elements will be strongly focused on skill, and even though we'd love to have a skill-based game, it does not make for a very satisfying experience when new players go against experienced ones.

Enter the traps. Their purpose is to hopefully reduce the skill gap between newcomers and experienced players.

We’ll see if this works as intended. There is also a chance that they'll have the opposite effect, so I guess playtest will tell ! If you've had experience with this kind of situation and would like to share it with us, we'd happily chat over this !

Slow-mo 2.0

I couldn’t resist the urge to have a slow-motion system that could also slow down the physics. So I did what any reasonable human being would do: slow down the whole game and speed up what needs to remain at “real world” speed.

This led to a fun bug, in which a player was able to obtain super speed.

This should be fixed now. It was a question of things happening during the same frame.

Destruction impulse in the wrong direction

This bug was tricky. It caused two different errors in the game, and was caused by my general lazyness.

You know, these “//HACK: … “ or “//TODO: Do this properly” comments you have in your code? Well one of them came back, biting me in the arse.

Just as the “invincible bug” in mentioned in the last devlog, a delay node was put when a player was killed, just before destroying it and playing the destruction FX.

The delay caused the killer to pass through the victim, and the destruction impulse was computed with this new position, resulting in the debris flying off in the wrong direction.

On top of that, this Delay node caused players to feel like the game had incorrect collision boxes or was laggy, because explosions were triggered 0.2s later.

This damn node was put here to avoid a simple error when pushing a PlayerKilledEvent in the EventStore.

So, just as for the invincible bug, simply reversing the order of two nodes, and removing the Delay node fixed all issues.

Damn I'm stupid sometimes…

Anyways, now the game feels much snappier and reactive, and with a final fix, the debris fly off in the correct direction, respecting the speeds of both players involved.

Lighting

Until now, all the maps shared the same lights, which was of course not definitive but allowed us to keep working on the game while testing new environments. Moving forward, and the game being more and more exposed to new players, time had come to do a proper lighting pass on these maps.

Some of them were even barely playable. Here is a before/after look at all the maps we currently have in the game. Look at how areas on the side of some maps were completely dark.

In order to keep specular highlights on the edges of the walls, we actually have an unusual setup for the game's lighting:

The maps are all placed in space very far from each other. A bunch of lights are baked on them, and when the game starts, the maps are moved back inside the game's frame. This was made possible thanks to a neat option in Unreal that allows static baking lights on movable objects (a nifty checkbox "Light as static" on the mesh).

Then, on top of the game's frame we have a few dynamic point lights that generate our reflections and specular highlights that add some life in the game.

GDC !

I am super hyped that my day job (MindMaze) is sending me to the GDC. I don’t know yet if I’ll have time to really take part in the conference, but I’ll try to at least say hello to the #SwissGames delegation that will be there (Qui? Elias?). I’ll have my laptop with me and a few controllers, and will gladly show the game to anyone interested. I’ll be in SF till the 7th.

Empty attack visuals

You may remember that we struggled with players not understanding that their attack was losing strength when used, and that they should stop attacking to let it reload. We tweaked the FX in hope that a drastic reduction in the visuals would clearly indicate to the players that their attack was empty.

Although we believe this did the job, some players kept on holding their attack active all the time! These were usually the players who had the hardest time grasping the fact that their avatar was invisible. Our interpretation is that they kept their attack active because their brain refused to accept the fact that they won’t see their avatar. So they subconsciously used any trick available to remain visible somehow. In this case the game offered them just that: a small visual clue of their avatar when their attack is empty.

With this visual clue we enabled a way to play the game incorrectly. So we iterated once again on this. When your attack is empty, you’ll now leave a tiny trail behind you for one second, and then you’ll be completely invisible. This should effectively prevent players from using the attack to see where they are. We'll see !

What’s next

Now that we’ve got a bit more content in the game, and that the main bugs are solved, I’ll start implementing a second game mode (probably a variant of King of the Hill). We also need, based on the last playtests, to iterate a bit more on the level design of some maps. A heatmap of the positions of the players could be interesting to see areas of levels that are unused.

But that’s all for this time, folks ! As always, hit that follow button on indiedb to get the latest updates, follow us on twitter because why not, and love each other ! We have a small surprise waiting for you soon... Cheers !

/Restaste