Throughout this project we have been using certain tools and processes to make the project easier for us. This includes the programs we used to make the game, manage source control and the frameworks created by our programmers to make designing the game less tedious.
Game Engine
First off I wanna talk about Unity. So Unity has been our go-to game engine throughout the course, so naturally we would use it since it’s what we all know. But there is so much about Unity that we still don’t know and that was really evident with this project. I personally had never worked with 2D or mobile development and that made this project a learning curve at the beginning. This lead to the project being mostly made through UI and menu navigation rather than 3D space which is what I am accustomed to.
A lot of the earlier Unity work was in the prototype made by just us designers in the team and I gotta say it was a lot of fun. Messing around with a build that would never see the light of day after it was finished is a massive relief and allowed us to get creative with our designer code. I was really proud of what we managed to pull off in the end, you can check out my other blog post about this prototype. The later Unity work was more so based around the alpha and beta builds the programmers made for us. Once the functionality was there, it was up to us designers to setup the mini game levels and polish the menu UI to fit with the visual style. The mini games themselves were really enjoyable to make, after learning the mini game framework the programmers made for us (more on that later) I felt at home with creating the quirky features of the mini game I was tasked with. The menu UI on the other hand was the biggest challenge for me but it served as an opportunity to learn about Unity’s UI features. Features such as UI panels, vertical layout groups and synchronized scene loading which I had only slight experience in, and other features such as buttons and sliders which I had used a lot but was able to get even more creative with.
Source Control
For source control we all use Source Tree (or GitKraken in some cases) which is what we have been using since the beginning of this course. Source control was kind of the elephant in the room in earlier trimesters, where people who didn’t fully understand it didn’t really speak up because of the difficulty involved in learning it. But because of its importance everyone naturally is required to learn it at some point. Because we are already in our third studio class, it’s nice to have a team that can successfully use source tree and also make full use of its features. Using source tree has become a habit for me in all of the projects I am involved in, especially solo projects! I think that the general workflow of allocating tasks and communicating our commits with source control in mind has minimized the risk of merge conflicts and issues with the repository. Because of this I am much more confident working with GitHub and Source Tree when working on group projects.
Custom Editor Tool
Given the structure of our project and how it utilizes mini games that have similar functionalities, we decided to get the programmers to make a mini game framework. This framework script would be applied to each interactable object in the mini game which allowed to it do various things. This allowed us to script each level ourselves but not have to worry about making separate interaction scripts for all of the interactable objects. Interactions such as tapping, dragging and holding which were present in some form in each of the mini games were made to be easy to implement with the given framework.
Caleb Middlebrook 