6 Eylül 2016 Salı

Why do we move to Unity3D?

As I explained in my previous post, I am starting a series of Unity related posts. The idea is create every section of my talk on voxxed days belgrade as a separate blog post. So here it is the first one. Enjoy :)

Before diving into the reasons behind this decision. Let me give you a little background about Peak Games and mobile team.

Peak Games founded at 2010 to create social games on social platforms especially on Facebook. A bunch of very successful games has been developed and published on Turkish market. After one and half years, Peak Games was one of the companies realise that mobile will be the platform for social / casual free-to-play games. And we have established a mobile team. Back then it was very hard to find mobile game developers,  even it was very hard to find experienced mobile developers. Actually myself was a senior backend java developer who wants to be mobile developer. So we were aware that it would be a very tough learning process for us.

Our first mission as mobile team was to create ios and android platforms for our existing titles. With a lot of discussions we had decided to move native on these platforms. And we had tried different technologies like cocos-2d and uikit for ios platforms, and c++ (with custom engine) and libgdx for android platforms. I will not go deep on these technologies and decisions that we had. But I can easily say that after two years, we were very happy and comfortable with UIKit (for ios) and libGDX (for android). We had created 10+ games using these technologies, and created 20+ reusable libraries common on these games. With all these efforts and experience we had reduced the time of developing a similar game to one third according to first game that we had build. And I don't want to be humble about these games, they are not mediocre games, they are very very successful games not just in Turkish market, but also in US market. Today hundreds of thousands players are playing these games.

In short, we were happy with the technology, we had the experience, and common libraries for future games. And also we are happy with the end result (I mean the games as whole). We had no doubt that we could build even better games with these technologies. So I guess you wonder, what makes us to think to change the technology behind these games, libraries and experience.

The main reason was the nature of free-to-play games. You have to improve your free-to-play game continuously. Otherwise it would die very soon. We are still adding very big features, or making very big changes on our first titles that we had build more than two years ago. With this reason we have to code our games very clean and readable. We have to use common patterns to solve the problems. This is another topic that I can speak forever :) 

My point is having multiple codebases for the same game (ios or android) causes some issues. First of all it make things slow in overall. Since it has different codebases, both of them have different issues. And they have different solutions for same problems. It makes the release planning and enabling/disabling features very hard. Most importantly we want both platforms exactly same as much as possible. But with different platforms, technologies, codebases and different developers it is not possible to get the same results in ios and android. So we have three main reasons:
  • We want to be quicker on the initial development of the game. 
  • And also we want to be quicker and consistent  while improving the game continuously. 
  • We want to have one single codebase for two platforms.
That is why we have decided to go cross platform development for our new games. We were going to keep the existing games in their existing technologies, but we were going to build new games in selected cross platform solution. And also we would not touch our canvas platforms (which is written in AS3 action script technologies). Because even ios and android are different platforms, they are both mobile and we need to give same user experience on these platforms. But canvas is totally different and has to have different user experience.

So let's come to our options for cross platform development. I know that there more than these options to consider but I just list the ones that are in our short list :)

Haxe (with custom game engine)

Positive points :)
  • Run Time Performance is real good. Let me give you a real example from one of our games: We had a path finding algorithm written in AS3 and wanted to optimize the performance. By just converting the code to Haxe the performance was increased around 10 times, which is a shocking great result.
  • Dynamic typing languages are very efficient to hacking things or creating quick and dirty projects. But if you are creating a long living game to be able to maintain it for years. Than you should definitely have static typed language to be able add new features, make bug fixes without breaking other parts.
  • If you have experienced AS3 engineers, that means adaptation would be very quick and seamless. We all know that the de facto technology of games for canvas is AS3. Most of the social/online gaming companies has very experienced and valuable AS3 engineers. To adapt that experience especially to mobile platforms is very important.
  • Theoretically with Haxe, you can re-use the code not just in client technologies but also in server side. This is very important especially if you are building multiplayer real-time synchronous games like us. That means you need to have same game rules / game logic both in client and server.
  • With Haxe you can use different game engine underneath, you don’t need to stick with the same game engine technology for all kinds of your games. Think about that you are building different games in different genres. With Haxe you can have same language but different game engines for different game genres. (I agree that this is something that you need to avoid as much as possible, but having the ability is always good ☺).
Negative points :(
  • Since it is not a popular language/technology, it will be very difficult to find someone experienced on Haxe. And also it will not be easy to convince good talents to learn and give commitment on Haxe.
  • There are couple of initiatives for pure Haxe IDE (like HIDE) and also some plugins for existing popular IDEs (like IntelliJ Idea). But it seems to be a pain to establish a fully functional development environment with unit testing support, quick and robust simulator/emulator support, automated UI testing support and CI support.
  • The documentation is quite weak. Actually Haxe is not that young, it is almost 10 years old. So I would expect better and much more rich documentation. And when it is compared to alternatives, the community is not that big. So with Haxe you will by your own hand, it might be very difficult to get support in emergent cases.
  • We couldn’t find any very successful top grossing game projects written with Haxe (except the ones in the site). So I guess, it is a very important indicator that it has not enough support or belief on technology.
  • As far as  understand it is not that easy to use Haxe for prototyping a new game idea. That means you need to have another technology/solution for prototyping.

Unity3D (with C# Language)

Positive points :)
  • Prototyping is very fast and it gives the nearly real feeling of the game play before the production.
  • With all integrated components (editor, animator, debugger...) you can base your entire game production pipeline over Unity. What I mean is your product managers, level editors, visual designers, sound and animation experts can work on Unity. So that integration of all these parts can easily be done.
  • With very powerful editor, simulator and debugger, as a developer creating game scenes and tweaking tiny details is very handy.
  • With the power of language C#, you can leverage most of the C# libraries and community. And also it enables you to create best practice game architecture in means of engineering. And entity/component driven architecture helps to build robust and flexible games.
  • It has arguably good support and community options. There are a lot of engineers (from indie world to very big game companies), who works on Unity, creates games and develops the community.
  • It has very great asset store, it is not always the case to use those assets as it is, but it gives really good starting point.
  • Back then it was one third of all top grossing mobile games were build with Unity3D, nowadays it is almost half of it.
Negative points :(
  • Right now there is very limited canvas support (with Unity plugin or WebGL) but I believe it will change soon.
  • Optimizing the performance is very difficult, and out of the box it is not performant. You will always need to make some optimization for performance issues.
  • Prototyping very fast but finalizing as a complete product and polishing it, is not that easy. You have to be ready to spend a lot of time for just polishing the game.
  • It is not easy to work Unity as a team. No problem with C# source code but for the other components (like prefabs, scenes) cannot be worked collaboratively by its nature.
  • As I mentioned C# is great and powerful language. But you should always keep in mind that running the C# code on Mono Runtime has some limitations. And also Mono Develop itself is one of the downside of Unity.


Positive points :)
  • Open source and highly contributed game development framework and game engine.
  • It is a library based platform on top of powerful language C++
  • Since it is based on a very low level language of our days,  performance would be very satisfying.
  • Creating a game with it is very satisfying from engineering point of view.
  • Optimised for 2D games.
Negative points :(
  • For me the main negative point is again the language C++. It is very difficult to find someone who knows C++ or who wants to learn C++ :( at least it is the case in Turkiye.
  • It doesn't have a good game scene or animation editor etc... You have to use different 3rd party tools for this purposes and find ways to integrate with cocos-2dx. It is possible but not easy.
  • In long term it might be a good decision, but in short or mid term, it requires a lot of effort to create a game. Even create a prototype.

LibGDX with RoboVM

Before pros and cons I want to mention that, we had produced and published a successful game with this option. And you will see that all the good points come from libGDX, and all bad points from RoboVM. 

Positive points :)
  • Half of the mobile team (Android team) is already using libGDX as the primary technology for our native Android games.
  • There are quite amount of reusable components and libraries based on libGDX. We are already using them in production, so they are mature enough.
  • Both RoboVM and libGDX is open source. And there are many contributors especially for libGDX, it is always getting better.
  • libGDX has very robust and quick simulator support, especially when you compare to emulator on Android Studio.
  • Optimized for 2D games which is important for us.

Negative points :(
  • RoboVM was an ongoing project and it was changing a lot and frequently.
  • There were very limited support from community to RoboVM
  • Since it was kind of beta versions, it has very limited documentation.
  • We were spending a lot of effort and time to understand and integrate RoboVM.
  • Bindings from Java to Objetive-C was very painful and very very limited.
  • One last point project is stopped. It is acquired by Xamarin. And Xamarin aquired by Microsoft. And they decided to stop the project. It is open source but there are no real contribution any more.


After all these positive / negative points it was very difficult to foresee the future of these technologies. So what we have decided is to give a try on Unity3D at least for a few games. And then we could discuss further with real game development experience. And we had developed multiple games with Unity3D, we are happy with the result so far. I think we will stick with this decision especially after we see that it is becoming de facto technology both for indie developers and bigger game studios like EA Games, Blizzard etc...

So first section is done, I hope you enjoyed it. Now I will move to next sections that I am going to tell you about the experience on game development with Unity3D.

Hiç yorum yok: