Table of Contents Show
Archive notice: This article was originally published on March 15, 2019. Links and embedded videos are preserved as part of the historical record.
Four players find themselves in an arena and play each against each other in an ultimate showdown. The aim of the game is to defeat all other opponents in order to be the last survivor: also known as “Last Man Standing”. After being defeated as a player, you have the opportunity to influence the game from outside the arena with three so-called sabotage mechanics. If a player manages to defeat an opponent from outside the arena, they are spawned back into the arena and can compete for victory again. The rules are based on dodgeball. Before the game begins, each player has the opportunity to customise their character called Pillowhead. Each player can choose between two different vehicles and four different costumes, in which the head and body can be customised separately.
We had very ambitious goals with this project right from the start. We wanted to develop a polished vertical slice in the given time of eight weeks, which would then theoretically only lack content for release. The game needed to be accessible to both experienced players and non-players. We also wanted to engage all age groups and entertain the audience. During development, we placed particular emphasis on the following components:
Keep It Simple
As we wanted to develop a party game for the whole family and appeal to as large a target group as possible, it was very important to us that people could learn our game even if they had little or no other contact with video games. After all, you want to end up playing the game with your friends and family, and everyone should have the opportunity to win the game.
The simplicity of the gameplay was one of the biggest challenges during development, as you spend a lot of time playing the game yourself, so it was increasingly difficult to judge whether it was still simple and accessible for other players. Because we worked with an agile framework (Scrum), we were able to develop the game in short iteration cycles, and we were able to finalise a new prototype for testing every week. The prototype was used to collect and analyse data and information from volunteer testers through playtests. The accessibility and user-friendliness of the game was also tested. We also received useful suggestions for improving future features.
No Real Loser
The second component was the “No Real Loser” approach. We wanted to avoid the scenario where you’re sitting on the couch with your friends and one player has to put down the controller after a very short time because they’ve been eliminated. We wanted every player to be able to play and have a say in the game from start to finish. This is why players can use so-called sabotage mechanics after they have been eliminated. If they manage to defeat a player with one of these mechanics, they spawn back on the pitch and can compete for victory again. This makes the game exciting for everyone involved from start to finish, and even less experienced players have the opportunity to win.
Way Over the Top
As a final component, we placed a lot of emphasis on making the game as ridiculous and absurd as possible. Our characters were therefore dressed in funny costumes. Each character was also given a ragdoll to amuse them. The whole thing is supported by a cardboard audience that reacts to various events in the arena with laughter or cheers. There should never be a shortage of schadenfreude!
Level design
The first task in game design after the kick-off was to design an arena or playing field that fits the core mechanics of the game. To this end, three core mechanics were extensively tested in conjunction with an obligatory sabotage mechanic. With each test, the playing field changed and evolved. Initially, it was all about the shape and size. Then it was decided from which camera view the game should be displayed, how far away or how close the camera should be, and whether a static or dynamic camera should be used. We made the most important decisions in our meetings as a team. The feasibility and the results of the tests were used as a basis for debate. Through the many tests of the different mechanics, we realised early on that it was necessary to add obstacles to the playing field to give players the opportunity to use the environment and develop their own small tactics. At the same time, the obstacles should convey a feeling of safety from other opponents. Later tests also showed that players were falling off the pitch quite frequently instead of beating each other. The solution was to erect a fence with destructible planks around the playing field. The ability to seek cover and not fall off the pitch at the first mistake gives new players in particular the chance to get into the fast gameplay of the game.
There have been many plans and a few attempts to heat up the players with environment events. However, all attempts have resulted in shorter session lengths. The session length of Pillowheads is determined by the experience, skill and handling of a controller of each individual player. Experience shows that the best rounds are those of players with the same level of experience. It should be noted that this is the design of the first and so far only playing field. Accordingly, it was important that the players have an overview of the entire game at all times and that the players do not fight against the game, but against their fellow players.
In a party game, it is important to give all players the feeling that there is still a chance of victory at any point in the game. This feeling is guaranteed in Pillowheads by two rules. Firstly, eliminated players are revived by eliminating them with one of the three sabotage mechanics on the playing field. Secondly, all sabotage mechanics must be easy to use and have the ability to eliminate players. The basic playing field should therefore not overwhelm the players with mechanics, but allow them to get off to a good start.
Graphic style
Our game is designed for players aged six and up. The graphic style should therefore be colourful, cute, funny and based on simple shapes. In the end, we decided in favour of the children’s toy direction and the do-it-yourself style, as they gave us plenty of scope for ideas and creativity. We also drew a lot of inspiration from craft books and everyday objects. The first assets quickly found favour with the team and our fellow students. The style was then further developed and defined. It quickly became clear that a material language had to be created, as otherwise too many different materials could cause confusion. In addition, our Pillowhead character had to be able to stand out from the environment. It was therefore decided, for example, that the character should consist mainly of fabric, while the environment would appear rather hard and angular due to the paper and cardboard. The stylised or comic-like style of the VFX also reflects the vision that it should not be a serious game. To reinforce the intended style and party atmosphere, many assets can be destroyed by the player or react to the player’s actions in other amusing ways.
Art Pipeline
The concepts were first created in Photoshop or 3ds Max and then modelled and further elaborated after approval. After UV mapping, the objects were drawn in Substance Painter and textured with Smart Materials. In some cases, further details were added by hand. Maya was used exclusively for rigging and animation in this project. Smaller animations in the environment that did not require a rig were animated directly in the Unity Engine. The complete UI mockup was created in Illustrator, then finalised and exported as a spritesheet. The corresponding animations were then largely finalised in Unity using scripts.
Art challenges
We realised early on that the costumes and the facial rig would be a challenge for Pillowhead, as neither one of us nor our fellow students had any experience in these areas. As a result, we researched and experimented right from the start of the project in order to avoid problems or find solutions at an early stage.
The costumes had to work as a set, but also in combination with each other. They had to be unique, customisable and adapted to the shape of Pillowhead’s head. Unfortunately, clipping problems often arose due to the different sizes and shapes of the costumes. We often had to iterate, which was very time-consuming. The implementation of Pillowhead’s customisation feature was initially attempted by exchanging the geometry, which did not work as hoped. The solution was to switch the visibility of the geometries on and off in the customisation screen. As soon as the actual game starts, the non-visible elements are deleted.
To make Pillowhead immediately appealing and likeable, we wanted to give him facial expressions in addition to his animations. To do this, we created a facial rig based on joints, which proved to be very time-consuming as we had to skin every single joint on his face and test it several times.
Controller
A big factor in a local multiplayer game is the hardware. Especially the controller, as one is needed for each player. While the choice of controller is clear in a console title, there is a much wider choice on the PC. It is therefore possible to have any number of different controllers connected at the same time, all of which use different button assignments.
In order to be able to support as many controllers as possible, we decided to use a separate input manager, as Unity’s current input system had problems recognising different controllers, for example. In Unity, the names of the controllers are stored in an array of strings. However, this could not be used for anything other than querying the names. This meant that the current controller often had to be queried by string comparison. For this reason, separate key codes were introduced, which were serialised in a separate XML file. This file held the corresponding keys on the respective controllers for each key code. In addition, we wrote a small editor window to be able to edit this file more visually in Unity.
With this system, we were able to implement the Xbox One controller, the Xbox 360 controller, Sony’s Dualshock 4 controller and their wireless variants very quickly. With the idea in mind that party games are very popular on Nintendo consoles, we also tried to connect the JoyCons of the Nintendo Switch. Thanks to an external library, this was quite easy and even allowed us to access all the sensors, making motion control possible.
Once everything was done, we started testing, but a bug in Unity caused huge problems. When more than one Xbox controller was connected, you couldn’t control their triggers as separate axes, which was essential for our game.
As we focussed on supporting as many controllers as possible, we had never encountered this bug before, as we had always had four different controllers connected. Now we also had to resort to an external library for the Xbox controllers and therefore used our own Input Manager completely.
However, once this problem had also been solved, we were able to have some fun with this system and quickly implemented the controls for the GameCube controller and a dance mat. The latter caused a lot of amusement during the presentation.
Testing pipeline
Probably the biggest challenge within the project, apart from the little time we had to develop the game, was definitely the rapid prototyping.
Especially for a game like ours with somewhat unusual controls, it was important that they were quick and easy to learn. To this end, we developed a kind of rulesheet, a scriptable object in Unity that combined all game-relevant information in one file. It allowed the game designer to easily change values in runtime and to keep an overview of them at all times. Values in this rulesheet are, for example, acceleration, cooldowns, sabotage radii or similar. The additional advantage of this system is that instances of this scriptable object are created in runtime, which can then be freely adjusted by players. This would have allowed players to build their own presets. Unfortunately, this feature is not yet available in the game.
Future prospects
With the current status of “Pillowheads – It’s Party Time”, we have achieved our intended goals. The enormously positive feedback from the Games Academy lecturers and test players led us to the decision to develop an IP from the Pillowhead character. We expect to start work on this as early as next semester. For a possible release, we could consider adding an online mode.
At the moment, the game can only be played locally by three to four players. As Nintendo often represents party games, we are planning a possible implementation for the Nintendo Switch. As already mentioned, it is currently a polished vertical slice, which enables us to produce a lot of content for our game in a very short time and thus provide many hours of gaming fun. We are excited to see what the future holds!
