Over the course of my past few game development projects, I’ve had to write a lot of code multiple times and every time I’ve been slightly more inconvenienced by it. This ends up wasting valuable time that could be spent doing fun stuff. So I decided enough was enough and I’d create a reusable framework for use with all of my future projects. The premise was simple, I’d outline a set of basic requirements that every project I work on will have and then create a unity package I can import at the start of development to avoid having to try bodge implementations from other projects into a new one.
The initial requirements were simple; a menu system, basic AdMob integration, generic object pooling and simple game management systems to track state/play sounds/etc. These were picked as the requirements because they were the things that I had found the most tedious to set up fresh in every project. However, as I began implementing these features it dawned on me that this limited scope would definitely need to be expanded, what if I wanted Analytics in my games? I would need to first update the framework and then update the package in all subsequent projects it was used in. With the thought of a tedious upgrade process in mind, I went back to the drawing board for my requirements. The final scope was far bigger but added far more value to my future projects, these components and why I chose them are explained in detail below.
Google Analytics
Having Google Analytics in all my projects hit me while I was checking the ad data for my project Super Blasty Blasty. It dawned on me that the data provided by AdMob wasn’t nearly detailed enough, I wanted the ability to break down how a player was interacting with the games in great detail. I’ve always been a fan of Google Analytics for websites so it was a natural fit to use it in my games as well. The data I can obtain from each project will be a potential goldmine and will help all future projects I work on, which more than justified the time it took to implement it into the framework.
Google Play Games
Having the full suite of Google Play Games services in my projects was something I had initially wanted to avoid as I felt it was an excess of bloat that wouldn’t add much value. But while I was playing other mobile games, I noticed they all had chosen to implement the full suite of Google Play Games features including achievements and high scores, which were both things I had planned to implement without using a third party plugin. Having seen these games use the common services utilizing the uniform interface and familiarity that provides made a lot of sense to me and changed my mind on including this. The bloat issue is still something that concerns me and it definitely has a large impact on filesize which isn’t ideal.
AdMob
The inclusion of AdMob was a simple one for me, I wanted to stay in the Google ecosystem of adverts rather than commit to a competitor such as Unity Ads. The plugin offers the facility to play banner ads, rewarded videos and interstitial ads which are all I foresee ever needing in my game development projects. These methods were also linked to other parts of the framework, menus trigger banner ads as an example.
Unity UI Extensions
This plugin was something that stood out as providing a lot of value in several ways the key of which being timesaving. Having the ability to create complicated UI systems by simply clicking a button in a drop down and treating them as you would a new GameObject saves an enormous amount of time. These menus again could be tied to other parts of the framework such as the tweening system. Having this connection allows transitions between UI components that add a base level of polish for all projects using the framework.
DOTween
Deciding on a tween package to use within the framework was one of my more difficult decisions as there are several which come highly recommended. In the end, I settled on DOTween because it has a professional level of documentation and is very lightweight. With size becoming an issue due to the sheer number of components in the framework packages being lightweight was a big focus. Integrating the tweener with UI Extensions and even Ads was very simple and the effect provided was very good.
TwitterKit
TwitterKit integration was another package I had initially been reluctant to add, I felt that social sharing in Super Blasty Blasty was acceptable and didn’t really warrant a place in the framework. However, after seeing Twitter integration in a few other projects done far more professionally than just opening a browser window, this plugin became an essential inclusion for the framework. Now sharing is done all within the app meaning a user is more likely to stay and play, it also allows callbacks to be performed so sharing score can be rewarded and screenshots can be shared with ease.
Game Managers
Having had to write several game managers for various systems in my past I decided it would be best to make them generic and applicable to all situations, this meant following proper design patterns and employing some coding standards that I hadn’t before in past projects. There are 3 main managers; the Game Manager which handles object pooling, tracking score and saving/loading saved player data. The Sound Manager this can be used by all GameObjects to trigger sounds, play the background music, etc. And finally a third party services manager, this was an integration the third party plugins would interface with in order to provide seamless integration with the framework.
Conclusion
Aside from filesize concerns I couldn’t be more happy with how the framework turned out. Working on the Microcosm Framework (named after the new moniker my games will be released under), has rekindled a passion for developing games that had dissipated during the course of 2017. Having a high-quality framework to use in my future and existing projects to take them to the next level technically is exciting and I’m looking forward to seeing the first game that utilizes it in 2018.