Behind The Scenes: Development Pipelines and Technical Challenges! blog - InsertImagination

Hi, Steven again! This week I’m here to discuss the change in development pipeline from Kuria to To-Tum, the challenges we faced in recreating the experience of Kuria for a Mobile platform, and several technical design decisions we made to help us stay true to the core of our original game.

During Dare To Be Digital I wrote about the early development stages of Kuria (Daretobedigital.com) and how we iterated upon this throughout the summer (Daretobedigital.com). Working with such a hardworking a dedicated team allowed us to Plan, Develop, and Iterate on Kuria throughout the summer, without being precious of our work, and maintaining this attitude allowed us to make the tough decision to start development from scratch with To-Tum. This was not necessarily an easy decision for us, a lot of work and time had went into Kuria, but we felt starting again gave us a chance to come up with new ideas, including pushing development for mobile and designing the game around a new control scheme!

Part of development was to ensure that we were able to load levels quickly, much like Kuria, to allow players to seamlessly play though several levels in quick succession. The solution to this was to create levels as prefabs, and instantiate them at run time. This was fine until we started attaching new components to objects in scenes, and we found that unfortunately Unity doesn't currently support nested prefabs. The solution we found for this was creating levels using “Building Pieces” that created the actual game object assets when a level had fully loaded. This means that we are able to make large scale changes to art assets, prefabs, and materials without breaking prefab connections between levels!

This system has allowed us several times to change art assets, implement a system for enabling and disabling mesh colliders on pipes when the player object was not near them, and to create levels quickly using our modular assets created by the wonderful Jess Magnus!

Following this modular principle has allowed us to create a strong pipeline in which to develop To-Tum, allowing artists and designers to create content without the need for features to be scripted, and allowing us to prototype features using basic prefabs before assets had been created and implemented! This freed up a huge bottleneck that features in game development, so that all disciplines would be able to focus on their task at hand without relying on the others, which considering the remote nature of our team has worked out very nicely!

This next point might sound like beating a dead horse, but something I’ve personally found important during working on projects is ensuring that development is organised. For me this was met by setting up a specific workflow for the project with the team, specifically following the Git work flow (Atlassian.com) ,this allows the team and myself to monitor features and test them individually from the main build, something which is crucial to making sure game breaking bugs don’t make it into the game. I know this may not necessarily work for every team on every project, but for us it allows clarity to see what progress is being made on features in development, and allows us to not step on each other’s toes :D

Thank you for reading my post today! Just a quick shout out to the awesome guys at Teaboy Games (Twitter.com) who we forgot to mention in our Develop Post! The are awesome and you should totally check them out! Please check out our Twitter and Facebook pages. If you have any questions feel free to leave a comment or hit me up on Twitter (Twitter.com)