Ludicious

The main thing of the past weeks is that we went to Ludicious, a large festival in Zurich dedicated to video games development. For a few days, people could come and try out many of the games created in Switzerland, amongst which was Everblind. Shoutout to all the festival staff and game developers, this was a huge success !

This meant for us a lot of stability work, to ensure the game could remain playable for days straight.

Slow-mo !

In an effort to increase comprehension when a player gets killed, we’ve tweaked the destruction effects. There is now a tiny delay right after a player dies where we don’t destroy it, but make it visible, with a strong light of its color. Time is also slowed down for the two concerned players, to give a better chance to the killed player to understand his mistake, and to contemplate his defeat.

Unreal has two options for slow-mo (a.k.a. “Time dilation”): Changing it globally, which affects all players, animations and physics, or changing it per actor. We tried changing it globally at first, to have the destruction physics also slowed down, but unfortunately this is extremely annoying for the other players. Especially in small maps where many kills happen per minute.

Look at that effect. Seriously, it’s glorious. Such bullet time. Wow. The feeling of passing through another player and tearing it apart is exhilarating. Too bad I couldn’t keep it that way.

Having the game slowed down for the other players was too annoying however, so we switched back to a per-actor time dilation. The downside is that we lose the slowed physics, as there is no way to have them affected individually. If I really want to have the slowed physics back, I could also globally slow down time, and speed up the other players, on a per-actor basis. Maybe I’ll do that one day. I guess we’ll see…

Not blowing up player that scored

A complaint we had was that when someone scores, everyone is blown up and respawned after a while. This was alright for the players that didn’t score, but it felt weird for the one that scored.

I didn’t want however to let the scoring player have control of its ball. So what I did instead was to keep killing all players when one scores, but the one that scores is not actually blown up. That way, he loses control of its ball like the other players, but doesn’t feel bad because his ball exploded.

Idle detection

A hot fix I did while at Ludicious was to implement an idle detection mechanism. Especially in the tutorial, where we require that all players perform a series of actions to get to the next tutorial step, the game can be “locked” for groups of players. Let me explain:

Suppose a group of 4 players arrive and play halfway through the tutorial, then leave. The game is in a state where it requires 4 players to e.g. hold A simultaneously. So when 2 players sit down to try the game, they have very little chance of understanding what to do.

To counter that, I’ve added a piece of code that reloads the main scene if no controller has had input in a given amount of time. The end result is a game that we can confidently leave alone in festivals, without fearing that no one can play it because it’s in a locked state.

Build on IndieDB ?

I’m evaluating whether we should place a build of the game on indiedb at this point. I feel like it’s atin a state where it’s stable enough for that, but some bugs still sometimes pop up. Also, we don’t have half the content we’d like to have in the end.

On the other hand, it will make it easier to ask friends to give it a try and gather feedback…

Invincible bug

When playing, we stumbled upon an annoying bug. At one point one of the players became invincible, and also unable to kill. Just a ball moving around, not interacting with the other players.

Fortunately for us, this time we were recording the play session, so I was able to precisely determine the conditions that triggered this bug: a player got destroyed, and respawned on top of a player that was attacking, destroying him again, but making it “invincible”.

This tricky situation was caused by a race condition in my blueprints. There is a small amount of time between the moment a pawn is respawned, and the moment it is possessed by a controller. Due to my buggy implementation, if the player got killed within this gap, it was considered dead by the game, but did not explode or respawn, and was possessed by a controller, which meant a player could use it. The incriminating part is this return node if “Cast to PlayerController” fails.

The fix was fairly easy, I just moved the early exit, before telling the game that the player died:

There is a small side-effect to this, however. Now, if a player spawns on an attacking player, it will not get killed. For the time being, I’ll consider this a feature. If people start complaining that this feels unfair or incorrect, I’ll fix it.

What’s next

Our artist is working on the gameplay elements we want to add in the levels. We’ve settled for an initial list of three items that we will introduce and see how they affect gameplay:

• Doors: Closes when a player passes on it. Opens back after some time
• Rotating walls: Rotates over itself when it feels like it. This will open up and close pathways over time.
• Jaws: Placed in corridors, the jaws sometimes show their metal teeths and will destroy any player that passes between them.

Also, he’s starting to tweak the visuals of the maps, to give them a more unique atmosphere.

Finally, we’re planning on going to A MAZE in Berlin, so if you know anyone there or have any advice, or just want to meet up there, don’t hesitate to hit me up on twitter @restaste!

That was all for this 0.19 sprint folks! Next sprint is 0.20 which will focus on content and bugfixes.

/Restaste