Team Size: 13
Game Engine: Unity
Role(s): UI Programmer, Network Programmer
Worm Punk is an online multiplayer VR PvP game that challenged me to adapt to a new type of game development environment. As the UI and network programmer, I conducted extensive planning and research into VR games to ensure that my work integrated seamlessly with that of my team. Through my research, I was able to create a user interface that felt good to interact with in the VR environment and communicated information across a server-client network through RPCs. I am responsible for getting the game flow working, from booting up the game to getting into a round. I created interactable screens for joining public / private lobbies, interactable objects to show / edit settings for the host to change across the network, and getting players readied up for each round of combat.
Created a lobby spawning and readying up system, a wrist menu displaying tutorial & game info, and an achievement storage & notification system.
Engineered a real-time online leaderboard, flexible matchmaking, customizable room settings, and integrated voice chat.
Designed an interface including physical levers, dials, and buttons; player HUD for speed, elevation, and kills; personalized nickname/color setup; and networked Jumbotron displaying round time, kills and ranking.
Whenever a player kills another player, a popup briefly appears in their vision before disappearing. Only the person that got a kill sees this popup. For all players, the most recent kill is broadcast on a Jumbotron, including the method of how the other person was killed.
With a game that centers around killing other players, communicating when a kill happens is crucial feedback to give. In order to do that, whenever a player is hit by another player, a call is made to everyone in the server. That function is sent information such as the player data getting damaged, the player that dealt the damage, and the type of damage in the form of an ID number. For the player that was dealt damage, the function checks to see if they were killed. If they were, a call is then sent back to the killer alone. This call creates a translucent popup that is added to the killer’s view, showcasing that they have successfully killed someone. In the VR headset view, the popup appears near the top of the screen as to not be too intrusive on the actual combat itself.
In the same function called to everyone when a player is hit, if any player is killed, a call is made to update the scripts for each Jumbotron, which displays it for everyone to see. The call relays the name of the killer, the name of the victim, and the cause of death. This call also sends the same data to a kill log in the scene, adding the kill to the top of a list of kills made during the round. With all of this information present, it becomes very clear when someone is killed, and anyone around the arena is able to figure out what exactly happened.
A list of all players and their nicknames are stored on the network, alongside their kills, deaths, and kill streaks for the round. Multiple leaderboards are placed around the arena and update whenever a player dies. All players see the leaderboard and animations that go with it. Only the local player sees their name highlighted on the arena.
When the combat scene is connected to the server, the leaderboard grabs the name and color for all of the players in the network. They are all displayed in a vertical list, adding a background specifically to the local player’s name. The players move a lot in the scene, so having a very obvious background for the local player allows for them to simply look for the position of their name to see how well they are doing in the round.
Whenever a player is killed, a call is made to the server to everyone. The call sends the killer’s name, the victim’s name, and the current kill streak of the killer. The script adds 1 kill to the killer’s name on the list, 1 death to the victim’s name, and adds to the killer’s streak while resetting the victim’s streak.
After the values are set, the data is sorted based on their kills, then their deaths. Then, each player is given a ranking from top to bottom. For any tied players, the rank is shared. After the ranks are set, the position of each player on the leaderboard is checked to see if they are in the right position, based on their ranking. If they are not, the transform of the position is eased into the right place to add a nice transition animation to the event.
The real-time leaderboard is something that we decided to add based on playtesting feedback. Since the rounds are competitive in nature, players were interested to see how they ranked up in real-time to fuel their desire to win further. This addition was positively received, and overall helped test the networking skills I had been learning through the development of the game.
Before entering the network, the player can customize themselves. To their left, they can change their color. In front of them, they can choose from a list of pre-set adjectives and nouns using dials. There are other small features as well, such as viewing the player’s lifetime stats, generating a random nickname, and turning on / off mature nicknames.
One key feature of the game that played into the VR environment was the use of in-world objects to navigate through menus and make decisions. In order to make the physical UI system, I developed a kit of buttons, sliders, dials, and levers that could be used for any purpose.
The physical buttons were the simplest objects to make, as they only require a box trigger that registers when the player’s hand has entered the trigger. If the button is interactable and currently not being pressed, it will play an animation of the button pressing itself. At the peak of the animation (when the button is fully pressed), the script invokes a Unity Event tied to the individual button. This event is able to subscribe to whatever function is needed, being able to be set in the Unity inspector. These buttons emulate the same functions as Unity’s UI buttons do, being able to change colors or be disabled. However, in addition to the basic functions of a button, they are able to be locked in place after being initially pressed, only allowing the player to press the button once.
The other physical interactables follow a very similar nature as the button, with the additional functionality that they have to be grabbed in order to properly use them. This was done by ensuring the player is holding down a specific button as their hand remains within the trigger.
The slider and the lever objects track the position of the player’s hand relative to where they have grabbed. The slider moves alongside the hand and returns a decimal value based on where it is in between the left and right bounds. They are used primarily when the host needs to change any settings. The lever rotates on one axis based on the location of the hand, invoking events when the lever reaches the minimum or maximum angle it can rotate. The lever is primarily used for indicating whether a player is ready to start a round.
The dial works a bit differently than the other interactables in that once grabbed, it keeps track of the rotation of the player’s hands. Once the player’s hand rotates a defined amount, the dial itself snaps relative to that angle. While also used for host settings, players often use them to customize their player name at the start of the game.
Having this set of reusable objects made the game feel a lot more tactile, playing into the VR experience and immersing the player’s further into the game’s world.
I initially faced the challenge of being unfamiliar with VR Development while working on this project. To bridge this gap, I immersed myself in basic VR Development tutorials and played VR games on my own time to understand what makes a unique VR experience.
My strengths come from 2D UI programming, but the project required a tactile 3D UI system. I meticulously kitbashed and designed components such as buttons, dials, and levers for player interaction, with each element triggering events upon activation. After thorough testing and creating them as modular assets for any purpose, I seamlessly integrated them into the game.
As I began working on the game’s menu structures, I came to an important realization; these components would be key for server communication, like joining lobbies or entering room codes. This prompted me to delve into this project’s networking system (Photon Unity Network 2). To create a user-friendly multiplayer experience, we chose a server-authoritative system so that players wouldn’t need to worry about the hassle of making their own server. The ideal user experience is something that someone can simply hop into, play, and then leave just as quickly.
As I connected network code to my UI components, I grasped concepts like Remote Procedure Calls (RPCs) and learned what should be communicated on the server, such as player hits and menus that I wanted all players to have the same information for. I also learned how to efficiently store and share information within the server room with details such as player names and player colors. Through these challenges, I acquired the necessary skills to bring our VR game to life, delivering an engaging multiplayer experience.
This project was worked on in a physical game studio environment full time, something I had not done prior. I feel like developing this project in an environment with everyone else present was highly beneficial to this project. It felt like the ideal situation that I would be working in after college and let me figure out how to manage my time and work flow.
This project was a test of my skills to teach myself how to learn, as a lot of the systems that I worked on were things that I had no prior experience with, primarily working in a VR environment and on an online multiplayer game. It was a very ambitious project, but with the team that I had, I felt like we were able to get something that worked well and made for a lot of fun playtests. I consider this project to be a pivotal milestone in my journey as a game developer, since it gave me an environment that pushed me to learn self-discipline while still being relatively low stakes.
In terms of the technical aspect of the project, Worm Punk taught me the essentials to having a functional online multiplayer game, something that I feel like is a medium that is becoming higher in demand in the professional game industry. One lesson that our team learned the hard way was to have a means of testing the game without being connected to the server. One of our playtests was done in an environment with spotty internet, which led to us not being able to run the game. In order to get it working, I used a hotspot on my phone to get reliable Wi-Fi through data, but afterwards it led us to ensuring that the core functionality of our game worked without being connected to the internet. While the ideal environment for the game is online, it felt like making sure the player was functional in an offline setting helped make our foundations even stronger as a result of it. It also helped us figure out behaviors for when a player is disconnected from the server and gave us something to show in the event that the servers were offline for any reason.
