Heist Night is an asymmetric multiplayer stealth released on IndieDB.
Two players compete; each having different objectives, resources and camera perspectives.
Two players compete; each having different objectives, resources and camera perspectives.
FIRST PERSON THIEF
One player assumes the role of a thief. Under the cover of darkness, the thief infiltrates the museum in an attempt to steal its valuable exhibits. |
TOP DOWN GUARDS
The other player assumes the role of the security guards. In order to secure the museum, the guards must find and catch the thief - before they escape with the treasure. |
DETAILS
|
My Roles: Lead Designer, Level Designer, Technical Game Designer & Gameplay Programmer
Development Team: "Team Fifteen" Team Size: 10 Platforms: Windows, Mac and Linux Engine: Unity 4 / 5 Development Cycle: January 2015 - July 2016 Release Date: July 10, 2015 Website: www.indiedb.com/games/heist-night Reception: Heist Night was met with significant praise; both internally and externally. Many players complimented the gameplay structure, and the scenarios it affords. More than 1.000 people have downloaded the game, and some people have even recorded their experience. Videos of people experiencing the game can be found here. Awards:
Nominations:
|
|
MY WORK
On Heist Night I was responsible for the design, whiteboxing, implementation and testing of the levels the players compete in. In this role, I had to work with the constrains and requirements introduced by the asymmetrical gameplay structure. I had to ensure that both players have a fun and fair gameplay experience.
Additionally, I designed, prototyped, and programmed a large variety of features related to gameplay, networking, UI and UX.
For more detailed descriptions of some of my tasks expand the tabs below:
Additionally, I designed, prototyped, and programmed a large variety of features related to gameplay, networking, UI and UX.
For more detailed descriptions of some of my tasks expand the tabs below:
(Level) Design
The most important elements of making Heist Night (an asymmetrical game) work was gameplay balance and level design. We had to somehow ensure that both players had a fun and fair experience. For us, this meant continues testing and iteration during the 14 week period the project originally ran.
We had to try out as many things as possible, and gradually define what works and what doesn't, both in terms of balancing and level design.
We had to try out as many things as possible, and gradually define what works and what doesn't, both in terms of balancing and level design.
Level Design
For level design this meant continuously creating and testing new levels and ideas. As the project ran, the design team created and iterated upon as many as 10 different levels. Each level had it's own focus or concept: "what if we had long corridors?", "what if levels were very small?", "what if levels were very large?", etc. This lead to us discovering the core rules that make a level work, as well as specific gameplay scenarios.
|
|
|
As the design lead, I was very involved in this process. Not only did I design, whitebox, and test levels of my own. I made sure that each level that was created answered specific questions.
Doing this brought us to a point where we had a pretty good idea of the gameplay implications of the walls we placed and the routes we created. By then, we had a large library of levels. I selected the best parts of some of the previously created levels and assembled them in a way where they would flow into each other. After that we did extensive testing and tweaking on the level, and eventually created a highly functional level that afforded the gameplay we wanted Heist Night to afford. This became the level Heist Night was released with on IndieDB.
Doing this brought us to a point where we had a pretty good idea of the gameplay implications of the walls we placed and the routes we created. By then, we had a large library of levels. I selected the best parts of some of the previously created levels and assembled them in a way where they would flow into each other. After that we did extensive testing and tweaking on the level, and eventually created a highly functional level that afforded the gameplay we wanted Heist Night to afford. This became the level Heist Night was released with on IndieDB.
|
|
Many moths later we decided to create new levels based on player feedback. At this point we were very familiar with the affordances of the game. We decided to each create a level of our own and help each other with testing. After reminding myself of all the rules, I could quickly come up with a new level design and start implementing, and iterating on it.
Heatmap & KPI data collection
During early development we were doing continues play-testing to help guide us in our design decisions. These play-tests gave us a lot of valuable insights, but we constantly noticed inconsistencies in the data. All the data we were gathering was qualitative, and very much dependent on the individual. One day the balance might seem completely out of whack! But this might have only been due to a large skill discrepancy between the players that were playing that specific day.
Because of this, when we set out to create more levels, I decided I wanted a system that would give us more quantitative data, something we can truly analyse. Mainly, I wanted hard stats: "Who won?", "How long did the match take?", "How many matches have these players played before?" and more importantly, "What did the players do during the match?".
There are then two primary questions:
Because of this, when we set out to create more levels, I decided I wanted a system that would give us more quantitative data, something we can truly analyse. Mainly, I wanted hard stats: "Who won?", "How long did the match take?", "How many matches have these players played before?" and more importantly, "What did the players do during the match?".
There are then two primary questions:
- How do we gather the data from the player?
- How do we visualise and analyse the data?
Gathering data
As university students, we have limited resources, and at the time no free access to a server that could handle the data. As such, the question of gathering the data immediately becomes quite complex. Luckily there is one big server that (nearly) everybody with an internet connection has access to: Google! To be more specific Google Sheets. To get the data from the player, when a match ends, I construct a HTTP request to a public Google Script which splits up the inputs, and neatly organises them into a Google Sheet on a per level basis. This creates a long list of data that looks like the image bellow.
|
This lets us do basic analysis on for example the win rates, or session duration. But how are we going to get heat mapping data? Luckily we can use the same system! I created a simple colour coded system that tracks all the different characters by periodically placing pixels on a texture based on the character's position. This generates separate texture maps for each entity it tracks: bmpThief, bmpGuard0, bmpGuard1.
Then, once a match has ended we convert the images to a BASE64 string (replacing the underscore), and send it with the HTTP request! This might sound ridiculous but a 128x128 texture maps is actually less than 600 characters long as a BASE64 string, so the full HTTP request comes in at roughly 2KB. |
|
Visualising data
With the data in Google Sheets we can already do some nice analysis, but we can't see the heatmaps, and with more sophisticated tools we could make this information more useful. For this purpose I created the "HeatMap Viewer" in Unity. This tool lets us download the heatmaps of the currently opened level, and overlay them above the level.
We can then customise which maps we want render, and by searching for maps that match certain criteria analyse more interesting questions, both on a overall levels: "Where do players generally walk when the thief wins?", or more match specific: "Why did this match take so long?".
We can then customise which maps we want render, and by searching for maps that match certain criteria analyse more interesting questions, both on a overall levels: "Where do players generally walk when the thief wins?", or more match specific: "Why did this match take so long?".
|
|
As an example I added two selections of heatmaps: one shows all the recent heatmaps where the thief player wins, and the other shows all the recent heatmaps where the guard player wins. And there is very clearly a difference in behaviour. On the map where the thief wins, the thief (indicated in yellow) seems to generally be more careful, stick close to the wall, and run from cover to cover. While on the map where the guard player wins, the thief is generally more direct, and perhaps stays in their starting locations for too long. From this we can research the behaviour further: "is it a specific player that behaves like this? or is it general behaviour?" and decide if we should make changes based on our findings.
Creating this system helped us find the flaws with our levels, and as such more methodologically iterate on them. The system was my first significant experience of working with and integrating external APIs as well as creating a workflow around a system.
Creating this system helped us find the flaws with our levels, and as such more methodologically iterate on them. The system was my first significant experience of working with and integrating external APIs as well as creating a workflow around a system.
Programming & Steam API integration
After the initial 14 week project ended, I took over all major programming work for Heist Night. There were still a lot of things that needed significant improvements. For example: The players could not yet switch sides. When the players wanted to switch sides they would have to disconnect, go to the main menu and connect again.
|
Some of the things I implemented are:
|
|
Probably the most interesting challenge was the SteamAPI integration. Specifically related to the networking. At first I really wanted to purely use the Steam networking system so that I would not have to host a master server and facilitator. This would have required a full rewrite of the networking system. Because of this I decided to use a combination of the two systems, essentially: The players establish a connection through the Steam networking system, exchange information, and then connect through P2P using the NAT punch-through provided by the facilitator.
As I am still using the masterserver system, I was also able to create a random connection system. This system first tries to connect to any existing server in the random server list. If it can't find a server to connect to, it will start it's own server and wait for someone to connect to them. While waiting for someone to connect, the it will periodically poll the list of existing servers to see if there is any older server it could also connect to. I created the system in this way to ensure that players can successfully connect to each other as much as possible.
As I am still using the masterserver system, I was also able to create a random connection system. This system first tries to connect to any existing server in the random server list. If it can't find a server to connect to, it will start it's own server and wait for someone to connect to them. While waiting for someone to connect, the it will periodically poll the list of existing servers to see if there is any older server it could also connect to. I created the system in this way to ensure that players can successfully connect to each other as much as possible.
