Our experience as an inexperienced Game Studio
CHAPTER 6: SAVING THE MECHANICS
One of those things you regularly hear from developers is to take what you already have and use it for your coming projects. It makes your life a lot simpler, and is the reason why, when you play a game from any studio, their following title is pretty much the same one as before but with a few tweaks. No need to dig too deep to find this, just look at the titles built by SuperCell and King, and you will see what I mean.
Don´t get me wrong, this is a great idea, you save time and money (time=money, anyway), and once you find success on a category, you’ll most likely stay there and notice that half of the ride is almost done when on a new project.
As you know, we needed to save anything we could from the previous title. That title was developed using Corona SDK, which is an engine built over Lua and allows to release versions in several platforms (iOS, Android, etc). Corona is OK, but it was not OK enough for us. We found many limitations with it which I will not talk about, but in the end, we made the decision to switch to Unity 3D.
Switching from Corona to Unity meant that none of the code libraries we already had would be useful at all, so whatever we did would need to be re-written from scratch. It also meant that we would have to learn to use Unity, and go through the learning curve you´d normally find whenever switching to a new technology. Nevertheless, we already had experience building a game, so we kinda knew where to start.
To learn Unity and other aspects of the business of Mobile Games our team joined two courses. The first one with the SENA (Colombia’s national learning service), and another one, called the Videogame Jump Camp, which was also set up by the Colombian Government (and yup, both for free, thanks Colombia!). The timing was amazingly appropriate; both courses began right after we decided to start working with Unity, so we saw this as fate.
Checking on the stuff we previously made, we had some artwork, we had some libraries, we had the algorithms, and we had the accumulated experience. From all of these the things, we could use all the experience, part of the artwork, and some of the logic; but none of the libraries.
We already had a story to tell, and the guys were working on the concept video. It was time to create a gameplay design, ie: the logic scheme. We needed to take the previous game mechanics (the logic), and fit it into the new story:
- We had a bouncing Soap you needed to tap, what will you bounce now?
- How is it related to the new story and why is it a key element?
- How can we include the new enemies in the gameplay considering there were none involved in the gameplay of the previous title?
After a day working on it, we came up with an idea which would adapt to the storyline we created, that it would allow us to develop many levels around it, and thus, save the logic scheme of the gameplay mechanics. This meant that the players would interact with the product in a similar way as before, and all we needed to do is to find the proper codes to make it work that way, and insert the new artwork and other minor details.
It felt just about right, and now that the scenario was clear, the team was a little more relaxed.
But I wasn’t, not just yet…
You can also follow us at: https://www.facebook.com/mobaqgames
Visit us at: www.mobaq.co