It's been one month since we started developing Good Slots, - our first major mobile game in Unity3D. It's a casino slots game, and more or less follows along the lines of the prototype we built in one week in Corona last fall. But prototype is one thing, and a commercial game is a whole another story.
It took just three days to replicate the Corona prototype in Unity, but then the pace ground to a turtle's crawl. If I was an experienced C# and Unity developer, this whole month's effort would've taken just a few days. As things stand now there are many many technologies I need to master to make this game happen. Here is a look at them:
 |
| A tile for one of the slots. Guess what's the theme? :) |
It took just three days to replicate the Corona prototype in Unity, but then the pace ground to a turtle's crawl. If I was an experienced C# and Unity developer, this whole month's effort would've taken just a few days. As things stand now there are many many technologies I need to master to make this game happen. Here is a look at them:
C#: a nice language. Last time I touched a C type language was a dozen years ago that left me with a bitter taste from mallocs and pointers. Since then I've only coded in dynamic languages like the yacky PHP and the awesome Ruby so going back to compile time is a ... change that takes getting used to. Each language (computer or human) has its own flow to it, and it takes time to grok it. I am certainly not there yet with C#.
Unity3D: I love this game framework. A while back I took a Graphics and Game Programming class at Stanford University. The final project was to develop a 3D game with OpenGL, without any game engine. Man that was a low level coding mess! Never again! Even compared to Corona (which is great btw), Unity is noticeably more powerful.
Toolkit2D: Good Slots is a 2D game. Unity3D has 3D in it's title not for nothing. The good folks at Unity did release a 2D workflow recently, but it's lacking some features for working with multi-resolution sprite atlases. Unity also doesn't have a good GUI framework. Toolkit2D offers both, and is a breeze to use. (I did look at the other major GUI packages for Unity, eg NGUI, but at the end none really stood out, and Toolkit2D covered all of my needs.)
StrangeIoC: One of my major gripes with Corona was the lack of a coherent game architecture. Throwing everything into a home baked game loop is asking for a disaster. Unity itself is only slightly better. Placing code in random scripts or in monolith GameObjects will lead to a maintenance nightmare. I searched everywhere for ideas on making a coherent game architecture, and I found one! StrangeIoC with MVCS . Yeah, that's a strange title :) It's based on dependency injection, and I had no idea what that was until last month. Took me about a week to learn and convert our game to StrangeIoC, and now it's finally well organized and coherent.
Parse.com: Our game, although single player, has major server components to prevent hacking: all the data and game logic are stored on the server. There are many other benefits to a server based game: I can tweak any game parameters in real time, analytics is easy, adding social features is easy. But developing server side is a pain in the ass, and wastes time better spend refining game mechanics. I certainly wasn't going to set up servers, build in scalability, replication, and the rest of the infrastructure. So Parse.com comes in to save the day. Except it's still a pain in the ass, albeit a smaller one. For the last two weeks I've been learning and building the data layer. There are just so many parts to it: a data admin module, storing data, retrieving data, batching server calls, local caching. Add on top user authentication and authorization, Facebook connect, the myriad edge cases. Argh... This is just stupid! Why isn't there a plug and play module for this? Every other game dev is writing code like this. I would easily pay a couple hundred dollars for this module.
That's my one month of effort. The data layer will take another two weeks to finish. And then there is more:
Error Logging: A must have, there are bound to be client errors that I would miss otherwise. Might use Loggly or Airbrake.
Analytics: A must have, these games are perpetual works in progress, and I need visibility into player behavior. Might use Mixpanel or Swrve.
Facebook posts: Distribution will be the #1 challenge for us, so anything to help along is a top priority.
So the first two months of the project will be spend building the ecosystem for the game, and only then I will implement the actual game mechanics. I've chosen such development path on purpose. I am focusing on the riskiest parts of the project first. All of theses technologies are new to me, and I have no idea how much effort it takes to implement them. Also, the whole ecosystem is fully re-usable for future games. Contrast that to the casino slots game mechanics that is well known and tested by hundreds of existing apps (except our innovations :)
