I Am a Cube! – Procedurally Generated Multiplayer Game

Initial Idea

This game was made in collaboration with Alexander Xu. Since we both come from a Computer Science background, we wanted to focus on some more technical topics such as procedural generation and networking.

Admittedly, the very first idea we decided upon was far too large in scope. We wanted to create a multiplayer game where the players took on the role of various quirky animals, and had to use their abilities collaboratively to escape a fortress they were being held in. Besides including multiplayer and procedural generation, we had also designed many different characters/ roles that the players could choose between, each having their own gameplay mechanics. We also planned to include enemies that would be chasing players around the map. Needless to say, this was too much work for a two month project. 

In the end, we had to remove many features and greatly simplify our initial idea. We were too ambitious and were trying to do too much at once. We needed more focus. Although at the beginning of the project, we were slowly implementing all the features we needed, we didn’t consider how long it would take to combine the features together and ensure that every feature was made multiplayer. With one player focussed on getting procedural generation to work nicely, and the remaining member on networking, there was simply not enough time to also implement a lot of advanced game mechanics by the deadline of the project. Ideas such as the narrative and having multiple character types were removed.

We still wanted to continue with the ideas of networking and procedural generation we had started working with, but we greatly simplified the game mechanics. The final game is a collection game where players try to gain as many points as possible by collecting pickups. The more pickups which are collected on one layer, the higher the score multiplier can become. Additionally, the players can move down to a new layer filled with new pickups, if all players vote to move down (although the score multiplier will reset). Collaboration comes from helping each other to open locks to access more pickups, deciding as a group when to move to the next layer, and ensuring that you don’t block paths for each other.

Initial Procedural Generation

To test some basic procedural generation, some testing tiles were used to produce a map which is randomly produced every time according to a simple algorithm – recursively generating tiles from a centre point (left image). There was a problem where tiles were produced on locations which already held tiles (it didn’t make any difference visually, but still increased the tile count). This was fixed by setting up a grid and keeping track of every tile’s location on the grid. Then any point in the grid could easily be checked to see if it already held a tile or not. The algorithm was then adapted to work for the isometric style we were aiming for (middle image). We then designed the tiles according to our colour palette and square aesthetic (last image).

Room and Corridor Generation

The basic generation was fine, but it was too random and offered no structure to build a game around. To move forward, we decided that we would randomly generate rooms (and connect them via corridors). That way, each room could hold different items, and corridors could easily be locked to block access to particular rooms. This provided us with a good base map to build our game mechanics on.

The first key focus was on the generation of rooms. First of all, we had to ensure that rooms did not clash with each other when they were generated and they had at least one tile of boundary around them (rooms were not stuck together). We also had to make sure that they did not clash with the boundary of the overall grid.

The left image below shows the initial version (each tile was marked as either a corridor tile or a room tile and coloured for easy identification). The most basic form of connection was simply ensuring that all rooms were connected (there was no room which was not connected to anything). This was implemented by having a list of rooms, and cyclicly connecting them from centre to centre.

But while the rooms are connected, there are some aesthetic (and functional) issues. When the corridors were being created, we needed to avoid corridors running alongside rooms and other corridors (which could make strange shaped rooms and paths in the game). This was fixed by making sure that the centre of each rooms was created only on x and y points in the grid which were even (the better version can be seen in the right image above).

Buttons and Locks

Buttons and locks were also designed to match with the game’s colour palette and aesthetic.

Locks And Buttons

Each room was assigned as a different type (one room to be locked by red locks, one room to hold the red button etc). There are some issues with certain rooms being unreachable with the current method of procedural generation. Dead lock situations were minimised by adding more rooms (and therefore more connections), and by making sure players did not spawn in locked rooms. However, there may still be some cases of rooms being generated which are not perfect.

Pickups and Layers

Pickups

The pickups were designed and randomly distributed across the map. There are 20 on each layer. The players can move down to the next layer if they all vote to move down. However, if they move to another layer, the score multiplier will reset. The score multiplier increases exponentially to provide greater incentive for players to stay on one map and to collect all/most of the pickups instead of jumping layers straight away and ignoring locked pickups.

Interfaces

TitleScreen
Interface

The user interface uses the same colours and fonts as used in the game for consistency (the title screen also includes a screenshot of the game). The title screen leads to pages with information on how to play/ credits. Pressing Begin! will take them to the multiplayer lobby. The interface in the game is simplistic and only shows critical information such as the score/ timer etc. It also has a button to take the players out of the game and back to the lobby if they would like.

Game Feel and Polish

ColourTrail
Pop
love

Near the end of the project, small changes were made to improve the feel of the game. One change was to add a fading trail to the character as it moved. This was a visually interesting way to show movement, and also allows players in game to spot other players easier (by catching the end of their trail perhaps). Particle and sound effects were added to make it more pleasurable to get the pickups. Additionally, a particle effect with a heart appears when a player tries to move down a path but there is another player in their way. It serves as a form of interaction that players can have with each other and hopefully turns the situation of players obstructing each other (which is negative), to a more positive situation where players can interact and send hearts to each other in the game.

Networking

Networking

The networking in the game was done by Alexander Xu.

The game uses a simple matchmaking system which allows players to create and name rooms, which can then be found and joined by other players. Through the use of Commands and ClientRPCs, multiple features are synced across all players in the network, including tiles, player movement, particle effects, sounds, time and score.

Rather than using Network Transform, player movement is synced across all players through a controller script. This is done by syncing the destination tile of a player and calling the movement function appropriately. A method such as this allows for a much smoother looking movement in multiplayer and easier checking of whether another player has moved onto a button or pick up.

The map is synced across all players by having the host of the server generate a random seed, which is then sent to all players in the network to generate the exact same map.

Conclusion

Although the design of the game was changed throughout the course of the project, I would consider the end result to be a success. Each member worked hard to make the game playable and polished in the limited time that we had. The game is in a complete enough state that it can be enjoyed, with no major issues. Although better planning at the start of the project may have allowed for implementation of more features, and there are still problems with the procedural generation algorithm that would need to be fixed.

It was a successful collaboration with good communication between team members, and with every member completing their tasks (as well as helping each other). I learnt a lot about how to set up Unity projects, collaborate with others, and how to organise my code appropriately. For my next project, I will place more focus on the design process at the beginning of the project to ensure that time isn’t wasted on features which will not make the final game.

Close Menu