Stellar Dust
This is a VR RTS game built with the team at Robot Sea Monster Games, and the culmination of everything I've worked towards in computer science. To build an RTS after being born in the age of games like Command and Conquer, Dawn of War 1/2, Starcraft 1/2, Warcraft 3, ... this is a dream come true. My role in this project was to be the tech lead, working as effectively the architect owner and project manager (with the final say of what is prioritized by the CEO) for the majority of the year. I helped with every single facet of this project.
The general premise of the game is that it is a 1v1 competitive game between two players on Quest 2/3/Pros, micromanaging a set of bases and drones on a hologram-like map to conquer territory and eliminate the opponent. There are additional win conditions such as king of the hill or capturing resources in a similar way to games like Company of Heroes 2, holding the point for resources. The gameplay is very similar to games like Mushroom Wars, but on VR.
For my role, I monitored up to 6 developers at a time on this project, working on architecture, project managing, and general development. The project managing side included task estimations and priorities set to move the project further and monitor progress made by everyone in every build (building weekly in Sprints and Agile methodology). One major part of being the team lead involves delegating tasks in a way that allows each developer to grow and own specific parts of the game- for example, one developer owned the AI and drone feature as domain knowledge experts of these topics, and another developer was a feature owner of the entire PHP laravel hosted server that talks to Playfab to create separate rooms. I also made sure to do task scoping and technical documentation, especially for newer developers to make sure that they could handle the tasks given to them. If the developer was struggling, I would go in to clarify and simplify parts of the task until the task became manageable, and I would write deeper documentation for devs that were newer to the team. Lastly, I did code reviews in a git flow that involved each developer having separate branches for major features and creating pull requests when the branch is ready, merging them in when they look good from a code perspective and functional test, or fixing the branch and commenting on the dev's code to next time fix parts of the code.
I had parts in all of gameplay programming, tools programming, network architecture and backend, game design, QA and bug fixing, and building and dev ops. The network architecture primarily relied on Photon Fusion and Playfab. Previous work I had done in Photon were using PUN2, so Fusion was a new adventure to me, though it was fairly similar to PUN2 and more feature complete. Playfab was entirely new as well. The network architecture connected Photon and Playfab together using a PHP Laravel server that called Playfab APIs from Unity side with nodejs. Photon Fusion 2 is the real time game multiplayer backend, dealing with game objects, real time game data, general room persistent objects, and dead reckoning, while Playfab is the room hosting service, matchmaker, and account data backend.
Oculus and Playfab were also combined to be used for authentication, profile account data, leaderboards and competitive play, and queue based matchmaking through rules from the leaderboard's score. Oculus authentication and Playfab's leaderboards are combined through the Oculus ID creating an account on Playfab's side to host data for the leaderboard. This is done so we have finite control over player data, especially when we want to create fake AI players on the leaderboard to be able to match the player with a number of different AI types.
There were multiple major refactors, including Tilia's removal to use OVR Input (controller and hand tracking), migrating from Photon Fusion 1 to Fusion 2, and moving to Dedicated Server mode from Host mode. The game had to be entirely rewritten when we decided to change to Dedicated Server, as we had all game logic in a system where one player is the host and the other is a client. Features like disconnect host migration were endlessly complex due to host and client logic being different. All game logic was ran on the host, enabling cheating from the host as well, ruining competitive integrity. The dedicated server became the host and all clients became clients, holding information from only that client and having all information come from Playfab's dedicated server build. Fusion 1 did not have as many features as Fusion 2, requiring a massive rewriting of much of the code base. Lastly, Tilia required a full rewrite of all input code, creating a major change in how we ran our input detection from Tilia's collider system to a physics collider sphere based on a specific point set by us.
I worked on many gameplay mechanics and programming pieces, including unit tracking and behavior, node GUI and types, in-game objective changes, random and predefined map generation, player controller input variations, hand tracking input, map manipulation, game settings, preference menus and UI tooltips on controller, art passes in meshes, menu and in-game UI, and more. The amount of work put into this project would be too much, and the fact that I also monitor, review, and know what each of my developers do increases this amount of work significantly. I am not only a feature owner of some pieces entirely such as hand tracking and UX variations, but also know enough of each of the specific parts of changed gameplay very well.
Lastly, since the dedicated server migration, I've been the main person to build, and the amount of steps to make a linux Docker dedicated server build to Playfab, into making a client android apk VR build for Oculus Quest Store App Lab is an insane amount of work, along with monitoring security, keystores, and making sure the two environments and release channels are separate between dev and prod.
It has been a wonderful adventure... I hope to revisit this card when the game finally releases!
Robot Sea Monster Games