RuinVerse - A Postmortem

RuinVerse Postmortem:

RuinVerse was developed in 2021 by myself and 2 others. The goal was to create a small 3^rd person adventure game for mobile devices in about a 3-month period. While we were able to complete the project on time, it wasn’t without many challenges that ultimately led to the decision of not officially releasing it. However, this was an amazing learning opportunity that we all stepped away from.

The team was very talented, but also very green to game development, myself included. Most of us came from different industries and all happened to be a producer on some level, so while we could all manage the project, it would take us longer to implement our design. The game was originally designed to have a mashing of art styles with the story focusing on someone who was whisked away to a world of colliding universes. In one area we would have simple geometry as the environment, another exaggerated details, another more photorealistic, etc. The core mechanic was going to be collecting note pages to “fix” the universe while using motion gestures to use magic, solving puzzles to collect pages that explained the game’s story and lore. In the end we only managed to have one art style and implement the collection of pages, where the story was revealed.

The first major issue we ran into was the technology behind our version control. I made the choice to use GitHub, which in the past has been completely fine. I used GitHub on the Project Bizarre Plunger Crusade (BPC) just a few months prior without issue so I thought we could do the same with RuinVerse. This was a mistake on my part. During BPC, my team made 100% of all of our assets, we never used any asset packs. This helped keep our Repository relatively small as we could control the file sizes, poly counts, and amount of assets in our Repo, and GitHub never gave us any issues. With RuinVerse, we wanted to focus more on features and mechanics so we made the choice to purchase asset packs. This made our project size grow exponentially and required our Repository to hold MANY assets and not just code. Oh yeah, we made this during the Covid Pandemic lock down so we were all remote.

GitHub was not built to handle such large projects and that many assets. While we were prototyping we ran into daily issues with just making sure we were all on the same version. We later discovered that if we installed LFS to our Repo, we. could upload larger files to our Repo, however one of our team members consistently had issues getting it to accept their commits, and just work for them in general. Many of our team meetings were spent just trying to get all of us on the same version of our project. This cut into our development time significantly. Looking back, I should have made the call early on to switch our Repo manager to something easier that I knew also worked, or even spent the time to learn something like Perforce, from what I’m told is more of an industry standard. While the team was still making progress it was slow because of all the issues. By the time everything was finally solved 3 weeks was spent just on getting our Repo properly set up, leaving us with barely over 2 months to actually move into full production.

We had to make many, many cuts to the design to make sure we were going to produce a functional game of some kind. The first thing we cut was about 2 weeks, amid our tech issues, in and that was the idea of meshing art styles. Given all the issues with the repo, we didn’t want to run into more issues with the Repo, and more biomes, meant more asset packs uploaded to the Repo. While our team’s strength was all in producing, we still had competencies outside of this role, but again, since these weren’t our focuses it took us longer to get things working.

Out of our whole team, I think I had the most experience working on games (and it wasn’t a whole lot more experience), however, my experience was working with Unreal Engine 4, and our project was required to be made with Unity. We all had experience Unity, however it was very limited. Had we been given the chance to pick our game engine, we probably would have gone with UE4, for its easier to use out-of-the-box tools. I am always going to say, “A game engine is just a tool and you can almost always get the exact same results no matter what engine you use.” And I still firmly believe that. In this case, the learning curve needed to make our project in the timeframe we had proved Unity, at least for us at the time, was probably not the best tool, but we were given no choice.

At about the 6-week mark we made the choice to cut the puzzle solving aspect using gestures. This was a big blow to our design because we really wanted to give the game a unique mechanic that made use of the fact it was on mobile devices. What’s worse is the technology was working flawlessly, the issues, was we didn’t have the time to make any puzzles. This was because we had to move to a more open space design with our level, and unless we spent a lot of time, time we didn’t have, making large environmental puzzles, we would need to take the time to build more intricate environments to force players into more simple puzzles. Both would take too much time, and we didn’t want to have something in the game that felt haphazardly put together. This meant that the game went from a magical, universal trekking, puzzle game, to a “collect all the pages” game.

We finished the project on time but felt that it was not where we wanted it to be. In this case, delaying was simply not an option as our stakeholder had an unmovable deadline with very ridged requirements, such as using Unity instead of Unreal. If I could go back, I would have made several changes to our design, and the technology used, mainly using Perforce for source control and using UE4 as our game engine. However, despite RuinVerse feeling like a failure, it provided my team and me a great learning opportunity. This experience gave us all insight on being able to recognize when something is snowballing into a much larger issue and make changes before they become too big and impede the progress of our projects.