Heya Guys,
It’s time for the first real dev blog post. I’d like to start out by giving an overview of the technology choices we have made so far making Buster Ranger. I won’t be going into details about the tools and process on the art side since that isn’t something I know as much about. This will focus on the development environment, engines, and tools we’ve chosen from a programming and development perspective.
The first thing to introduce is the core tool and engine choice we’ve made: Unity. Before now this may have only been controversial because it did not have a lot of built-in focus on 2D games and Buster Ranger is a sprite-based 2D game. You may know exactly what I mean by “sprite” but in case you do not what I mean is that every object you see in the game is actually completely flat. Any depth is an illusion created by either effects or the excellent art itself. Given that we are very comfortable with Unity from past work – in both 3D and 2D – it was an obvious choice for us. The benefits of building our own engine are far outweighed by the costs. We probably would still be knee-deep in engine programming now, but instead we’ve been able to leap forward with game development and the project is already in a stable playable state. That’s the power of out-of-the-box engines with mature editing environments like Unity. There are other similar options out there – like Unreal – but our past experience with Unity allows us to move so quickly.
This brings up one of the issues we had with the connection between the art team and the development team: how do we get Majid’s sprites and sprite animations into the game? He had already done a lot of work in Spine to create these characters and backgrounds and many of them with complex animations. Would he need to redo all of that work again with the Smooth Moves editor? We decided this was not a good idea. This is an important lesson we learned prior to this project and an attitude we brought with us when we started working with Majid: accommodate your artists. Majid is very comfortable in Spine. That comfort means that he can produce high quality very quickly. If he needed to learn a new system – in this case Smooth Moves – it would have been wasted time because it does not actually provide any benefits for the art process over Spine. Instead we took some time to create a 2-sided tool for bringing his artwork and animation into Unity directly.
One of the areas that I have historically been disappointed with has been how we handle audio. In the past we simply used the Unity built-in audio systems directly and the lack of a higher-level framework felt very limiting. This time around I decided to do some research before putting any audio into the game and ended up picking another system from the Asset Store: Master Audio. One of the cool things about this is that audio clips can be assigned to groups which allows you to control many sounds at once. It provides a lot more options for controlling volumes. It is a tiny convenience since grabbing a random number and choosing a clip based on that is not very difficult but it is these small conveniences which allows us to focus on more core game development instead of engine development. I very quickly realized how good this system was when I was able to fashion together a “voice-over” system for playing our narrator over the game audio in just one day. The sound effects and the music both lower their volume automatically and then come back up to full volume after the voice over is done playing. All this with one function call that our level designer can access without needing to look at code.
I hope this was an interesting introduction to Buster Ranger’s development. What I’d love to hear is any feedback. Leave a comment with any suggestions for future blog posts or if there is anything specific you’d like me to cover in more detail. I’d also be interested in hearing if anyone solved some of these problems in a different way.
Nimble Point
