Collagionary

Have fun with your friends putting together collages for each other to guess!

Solo Project

Roles On Project: Designer, Programmer & Artist

My Process

This project was originally developed as part of the IGB400: Game Studio 3 unit at QUT. In this unit, we were tasked with conceptualising a project that would fill a gap in our skillset and portfolio, and somehow help us in our aspirations in the games industry post-graduation. From there we were to develop our project.

Collagionary is a social multiplayer game where players put together collages for other players to guess and earn points.  I created Collagionary as my final IGB400 project in order to:

1) Fill a gap in my skill set which I have an interest in which is experience with multiplayer game development and networking

2) Create and publish a project that could be put on my portfolio that showcases gained experienced in multiplayer game development and networking

3) Position myself better when applying to local game studios such as Gameloft and Playside who have shown a need for people with experience in multiplayer game development and networking

Alignment To Unit & Industry Outcomes

I made Collagionary to fill a gap in my skillset and portfolio that would allow me to better position myself for job opportunities within the game development industry. To summarise my skills as a developer, I primarily have been a designer, programmer and producer on several industry and university projects that I have worked on.

When looking at jobs being offered within those areas, I found that the majority being offered were programmer or software engineer roles. Quite a few of these roles in particular wanted experience with multiplayer and online game systems. None of my past projects had involved any sort of multiplayer or networked game systems. Considering that two of the largest game studios in the state were both looking for people with these skillsets, I resolved to not only fill this gap, but also improve my chances of getting hired into the game industry by creating a multiplayer game.

Scope & Technical Considerations

Considering the scope of the unit and having zero experience with multiplayer systems, I had to ensure a suitable scope and design for the provided timeline.

Roadmap For Further Development

My first consideration for this project was what I was going to use as the foundation for the multiplayer systems and networking. I ended up selecting Unity Netcode for GameObjects and its Relay service. Given I would use Unity to develop the project, I chose these two due to them being first-party packages of Unity, which would guarantee that they would be compatible and supported by the engine. The only caveat was that Relay makes use of a peer-to-peer relay server model to connect players across the internet; which can result in easier data desynchronisation compared to a dedicated server model. This made something like a fast paced real-time multiplayer game that was polished less feasible, and therefore I needed to come up with an idea that could accommodate this system.

I therefore came up with the concept of Collagionary. As shown in the early concept art above, the base concept for the game has remained relatively the same.

I felt the more slow paced and turn-based nature of Collagionary’s gameplay would work well with the Unity Relay setup that I was planning to go with. Only one player would be making a collage at any given time, and the data needing to be shared across the network would be quite simple, as it would only involve sharing the properties of the collage pieces that make them up such as their sprite and their transform. For the other players, the information being shared from their end would just be the guesses they submit which would also be quite simple considering it would just be a string. Therefore, I felt Collagionary’s simple mechanics would be quite compatible with the Unity Relay system.

What I Learned & Core Outcomes

As was the goal of the project, I learned a lot when it came to multiplayer game design and development.

One of the biggest challenges I had in the early stages of the project’s development was wrapping my head around the peer-to-peer relay server model. To be more specific it took some time for me to fully grasp how I would manage the host’s state and the state of the clients. Since the host acts as both a player and the server that manages the game state, I had to consider what functionality would be exclusive to the host, and what functionalities would need to be shared across all players. This was something I had not been familiar with in previous projects I had worked on, so this took some adjustment.

The first example of me tackling this challenge was creating the game lobby system. While Unity has its own Lobby matchmaking service, this more so handles allowing players to find game sessions without needing to get a code from another player like when you use Unity Relay; which was a system I wanted to keep. I therefore needed to manage how to assign players a number and their corresponding colours and ensure this information was synchronised across the clients. The solution was to set the player numbers and colours on the host, and then propagate this information to the clients. This design philosophy would extend to just about any type of information that would need to be shared between the host and the clients.

Network Variables

Information sharing and game synchronisation across the network would manifest in one of two ways in Collagionary: network variables and remote procedure calls (RPCs).

The first method of information sharing on the network came in the form of Unity Netcode’s network variables. For script components attached to game objects that exist across clients/the network, network variables can be contained within them which when changed on the host, will have the change automatically reflected on the clients. In this way, information that constantly needs to be accessed by both the host and client can be guaranteed to be synced.

The above diagram shows how I made use of network variables. Clients connected to the game session will be able to send remote procedure calls to the host. The host then receives the RPCS, and depending on their context, can set and manage the state of network variables in response. These network variables include information such as who is currently collaging, what the current collage word is, and the current time before the end of a round. When these network variables are changed, this change is sent to the clients. Through this system, the host and clients alike are guaranteed to have this information to be synchronised, and helps ensure a consistent gameplay loop between them.

Remote Procedure Calls

The name of the game, however, is efficiency. The more data being sent across the network, the more network traffic is experienced, and makes the likelihood of lag and desynchronisation higher. Collagionary was designed to be light on how much data would be sent across the network at any given point. Regardless, I felt it was good practice to ensure I was being efficient in the sharing of data packets and the synchronisation of the game state, especially considering that not all information needed to be constantly synced through network variables.

The solution to this issue was remote procedure calls. Remote procedure calls allow the host and clients to request functions to be called on the host or other clients, allowing for game logic to be executed on one instance of the game based on what occurred in another instance. 

An example of where I found this useful was in the placing of collage pieces and ensuring this propagated to other game clients. The game client placing a collage piece would do so locally before sending the required information to place the collage piece across the network in an RPC. This RPC would be received by the host, which would then use the information sent to place it locally on their game client before forwarding that information to the rest of the clients through another RPC. The remaining clients would then receive the RPC and accompanying placement information and then place the collage piece locally on their game client as well.

Using this system, I could ensure that the placement of collage pieces, the starting/ending of rounds and the displaying of points were synchronised in real time across clients without needing to increase the amount of persistent network variables that the game clients would need to keep track of at any given time.

Through these learnings and developments,  I believe that I was able to deliver a fully resolved and highly polished game that not only filled a gap in my current skillset, but will also be a fun game that can be played by people and their friends.