Hi there! Version 0.13 is done, so here’s what we did. A load of refactoring both in code and lobby design.
Problems with 0.12
The feedback after the Numerik Games revealed a few issues with the game. Thankfully nothing against the core mechanic (people liked it), but more about the way the game is handed to the players:
- The lobby/tutorial conveys too much info at once
- Players can’t join mid-game
- Players need to use specific controllers if they are 2, 3 or 4 to play
These issues made it hard for us to leave the exhibition area (or talk to people), because we had to constantly have an eye on new players trying the game. So the main goal of v0.13 was to have a game we could leave on stage without fearing that the players would not understand it.
As very often in software, if something feels not right, it’s probably not coded right. Because I’m new to Unreal, the way I handled Pawns, Player Controllers and Game Modes was a real mess. This causes issues 2) and 3). I’ll cover later how I fixed those. For now I’ll focus on how I tried to improve 1), the lobby.
1) The lobby/tutorial conveys too much info at once
Overwhelming the players with stuff is bad (hmmkay?). Our previous lobby system was like this:
The intent was to introduce the players to the game’s mechanics. Teach them what they need to know to play. Here’s the breakdown:
- “You move with the left stick” + “You are visible in light”
- “You reveal yourself with B”
- “You cannot change direction during movement”
- “You attack with A” + “You should attack while moving”
- “While attacking, you can pass through destructible walls”
- “You must grab the gold cube” + “You must be attacking to grab the gold cube”
That’s a lot of info. But at least we knew what we wanted the player to know. In a single-player game, we’d probably introduce these mechanics from level to level, and vary their relevancy in each level to create cool experiences. Everblind being a multi-player game, we figured the players would need to know most of this when starting to play. So we broke this down into different steps of a lobby/tutorial thing:
- Step 1 (Vision tutorial): “You reveal yourself with B”
- Step 2 (Attack tutorial): “You attack with A” + “You should attack while moving” + “You should grab the gold cube” + “You must be attacking to grab the gold cube”
- Step 3 (Movement tutorial): “You cannot change direction during movement”
And a final step acts as a map selection screen, in which players can also fully use the game’s mechanics, killing each other, jousting etc:
The destructible walls are left out for now, because these are introduced later during play, they are not as important. Step 2 is still a bit heavy on meaning, but hopefully those are simple enough principles that players grasp them real quick. Otherwise, we’ll do another iteration on it.
Vision tutorial
Step 1 looks like this:
Players are presented with the classic “PRESS START” prompt. Upon pressing start, they’ll join the game with their avatar, and the game prompts them to HOLD B. At that point they should understand the mechanic. Our lobby system moves to the next step when all players that joined (by pressing start) are holding B together. This (and we felt really clever doing so) ensures that all players understood the mechanic. This way, players who understood it can (and must) explain it to the others.
We are using the game’s logo in the center of the screen, to mirror the player’s states. In abstract terms, a checkbox indicates to each player whether the game thinks they are ready or not. This feedback should hopefully make it clear that the game expects all players to have executed the action before moving on.
Attack tutorial
Step 2 looks like this:
In this part players have control over their movement, but are limited to a 1-D move. They should understand that they need to grab the gold thing in the center of their lane, but when moving over it nothing happens. Upon reaching the other side of the lane, a “HOLD A” prompt shows up. This teaches them how to attack. Then (and fingers crossed that players will understand this), we hope that they move back over the cube while attacking.
As before, the logo activates depending on the players’ states of task completion.
Movement tutorial
Step 3 looks like this:
In this part we give the players free control over their movement (in their area). Because of the step before, they should understand that their goal is to get the gold pickup in the middle. They’ll try to reach it by moving towards it and changing direction mid-travel. But that won’t work. So they’ll have to figure out this tiny puzzle to understand how to get to it. This teaches the players that they’ll have to think this way. And that an object being close does not necessarily mean it’s reachable easily.
As before, a part of the logo activates for each player that has grabbed the gold cube.
Overall
Here’s how it looks altogether:
And more
There are a few mechanics left over that we could cover:
- “You are visible in light”
- “You can destroy some walls by attacking through them”
- “You can reveal other players by getting the purple pickup”
- “You can hide yourself by getting the purple pickup if you have the cube”
These could be introduced in dedicated maps or modes, that would rely on the players’ mastery of them to win, for instance.
I think this approach of a lobby also being a tutorial is interesting. We ensure that all players share a minimum understanding required to play the game before entering the main area. We’re obviously not the first to have come up with it, but when implementing it I could really understand what was going on.
Now let’s talk about refactoring messy code.
2) Players can’t join mid-game and 3) Players need to use specific controllers if they are 2, 3 or 4 to play
The original code that handled pawns and controllers was a mess. Player1 had to start by selecting the number of players, which would create the required number of pawns and controllers. The problem with that was that when creating a player in UE4, a specific gamepad is associated with it (they are taken in the order that they were plugged on the machine), so players would be forced to take the correct gamepad, otherwise they would not control anything.
In this new implementation, 4 players are created on start (actually only 3, unreal creates one by default). That means all 4 gamepads are listening for input when the game starts. They do not control a ball yet; they have a special PawnWaitingForStart that’s immobile and is a floating text saying “PRESS START”, which only waits for the player to press start, and then sends a message to the GameMode, saying “hey, this player would like to join the game”.
I’ve found many benefits to handling controllers this way: no need for an annoying UI asking for the numbers of players; players can join at any time; and players are free to use any controller available.
Also, this opens up e.g. the possibility to disconnect an inactive player (which happens all the time during festivals).
The “player wants to join” message is protected behind an interface, which is implemented by all the GameModes in which a player may join, so that game-specific actions can be taken to properly spawn the player. It’s as simple as it gets at the moment: when this message is received, the PawnWaitingForStart is destroyed and detached from the controller, and the correct avatar is spawned and attached to the controller (the gamepad).
A tiny issue I faced was to know which players had joined the game in the lobby, so that when the game map loads, they are not spawned as PawnWaitingForStart, but as their correct avatar. To fix this I’m creating a parameters list that could look like “PC0=true,PC1=false,PC2=true,PC3=true”. It’s my way of telling the map “players 0, 2 and 3 have joined the lobby, so they need an avatar; player 1 did not”. This fix seems a bit weak and I’m pretty sure it will break at some point. But as we say “if it ain’t broke, don’t fix it”, so I’ll refactor this when the time comes.
Game Mode refactoring
Extracted win conditions to change game mode
At the moment, the win conditions (keeping the cube for 30s to score, reach a certain score to win) were coupled to the whole codebase. I extracted all this into a simple script that can be spawned, which will listen to the proper game events (such as gold picked up, player killed etc.) and will notify the GameMode when a player wins.
The advantage of this will be to make playing around with win conditions possible. From there, we can imagine a ton of game modes. The classics: deathmatch, team deatchmatch, … But also new things, like a survival mode (a specified player scores points while alive), a super-hardcore mode where all the walls are hidden, …
Some items in the game are activated or deactivated when someone scores a gold (like pickups and destructible walls). Again, these were tightly coupled to the gold-scoring mechanic.
Spectator View
An inherent problem with the game, when showing it in festivals for instance, is that since the goal is for everyone to remain invisible, nothing usually happens on screen. Which does not make for a fun watch. We’re introducing a spectator view by leveraging UE4’s networking layer. Any client that connects to the server on which the game is played will be spawned as spectators, and they’ll all have the option to reveal the players for themselves.
For now the spectator view is a still camera on top of the game, but as we move on, I’ll probably introduce a few fixed viewpoints as well as a free-fly cam.
And more… !
Also, you might have noticed that the players placement has changed when the game runs in “flat mode” (with the monitor laid down). Initially, we had all the players play on each edge of the screen. We felt not very comfortable with this for a few reasons:
- With a 16:9 aspect ratio, players on the smaller edges had a weird viewing angle compared to players on the larger edges.
- Because of this “flat” mode, we need to maintain more things in the game whenever we make changes, to ensure that both regular and flat modes still work, especially in the UI. All texts need to be rotated appropriately. With players on the edges, the UI needs to be a lot different when in flat vs regular.
So we decided to reposition the players in a more natural way: two players on each of the larger edges of the screen. The resulting UIs feel more intuitive, need less work to maintain and we hope that this feels more natural to players.
What’s next
The next iteration will include a bit of work in the spectator view, potentially opening the doors to an online mode (who knows?), as well as some reflexion on the game design and how to expand a bit the game.
/Restaste
