top of page

Painscreek Devlog #8: Why We Use Unity

(Testing terrain and foliage in Unity 4.)

To understand why Unity was chosen for our game project, The Painscreek Killings, we have to first share a bit about our background.

BACKGROUND In 2011, we were doing freelance CG work and teaching high school students about CG. Some students wanted to learn how to make games, so we studied the UDK tutorials. Once we got comfortable with the basic tools, we initiated a UDK group project consisting of several students trying to make a first-person platform puzzle game. That went quite well. We then initiated a second group project. This time, we wanted to try out multi-player. Unfortunately, the programming part proved too difficult for the students and the project eventually halted. However, those responsible for building the assets were able to create a roamable world. That foundation turned out to be the starting point of The Painscreek Killings.

(One of the students working on their project using Unreal Development kit.)

VISION FOR OUR GAME We had limited manpower and talent, no experience in game development, and had doubts whether we could even pull off puzzle based scripts, let alone anything beyond it. The only genres we could attempt were probably platform/puzzle games or walking simulators. So we decided to focus on what we love and possible our only strength: telling a good story. Since we also understood the importance of appealing visual and immersive atmosphere, we wanted our game to lean towards a film look rather than games.

(Using RealTimeBoard to plan out the story and puzzle flow.)

UDK Or Unity? Unreal Development Kit (UDK) was our first introduction to the game development world. At that time, there was another game engine called Unity 4. We made a comparison between those two game engines. UDK had a 25% royalty fee while Unity was free. UDK came with pre-installed packages, making the game accessible right from the start, which seemed a good thing for newcomers. On the other hand, Unity started from a blank slate. Yet, that was actually more to our advantage because we had to understand how the engine works underneath. UDK had no marketplace for 3rd party plugins so you will need a dedicated programmer to pull things off, while Unity had an asset store which was a huge boost for beginning developers. Despite the advantages that Unity have, we were still unsure if it was the right game engine unless it could achieve the film look that we envisioned. The only thing left to do is to test it. UNITY 4 DEMO TEST We knew that Unity 4 was used in many 2D mobile games and not well known for 3D games. However, our game did not require many things that AAA games have. All we needed was a first-person view, a 3D world, and a decent lighting setup that can simulate a mysterious atmosphere. It turned out that Unity 4 was good enough for all that we needed. We also purchased some plugins from the asset store, such as Advanced Foliage Shader and Relief Terrain Pack, to name a few. The result was a huge boost in the visual department. We felt confident that Unity was the game engine to go for. The success of the demo test, in addition to the advantages described above, sealed the choice for us.

(Testing Advanced Foliage Shader and Relief Terrain Pack in Unity 4.)

TRANSITIONING INTO UNITY 5 One of the limitation of Unity 4 was not having bounced light. When Unity 5 was launched, it gave us hope for a more realistic lighting effect by introducing global illumination. In addition, they also revamped the way menu UI are made. On top of that, they made notable improvements to the audio department. The lighting and UI were game changing for us. However, the initial versions of Unity 5 proved to be a learning curve as we moved our project from Unity 4 to 5. Light leaks can be seen everywhere. Many light parameters were not working. Plugins that worked in Unity 4 were showing up as errors. At some point, we wondered if it was a mistake to move to Unity 5. As time went on, the problems were solved, plugins were updated (or depreciated in some cases), and we embraced the advantages that Unity 5 brought. By the time Unity 5.3.4 was released, it was stable enough for our game to run without game-breaking problems. Unity continued releasing further version, but due to the plugins that we used, some altered the way our game looked while a few of them stopped our game from running. In the end, we decided to settle on Unity 5.3.4 and used certain workarounds for the bugs that Unity could not fix in that release version. Overall, we were quite satisfied with using Unity.

PROS AND CONS OF USING UNITY  Early versions of Unity 5 had a lot of problems, especially in the area of lighting. We struggled a lot with light leaks, unwanted bounced light, broken shadows, and lightmap problems. In addition, we relied on certain image effect plugins to achieve the film look that we need, but when newer versions of Unity 5 were released, some plugins would either be buggy or ceased to work. Troubleshooting the problems were time consuming and frustrating. However, using the Unity engine for our first game project has a few key advantages. First, the Unity Asset Store helped us tremendously, especially in the beginning stages of our game production. We were able to find at least one or more plugins in almost every area of our production. Never once did we feel stuck and hopeless to the point where we could not continue. Second, Unity uses components as its base, which meant that components can be linked or added upon. With that, we were able to create the desired results based on a few modular scripts that our programmer made. It's an extremely flexible pipeline to achieve whatever we want. Third, many changes were implemented in Unity 5 to make it a better 3D game engine. One area, in particular, was lighting. The results we could achieve in Unity 5 surpassed those in Unity 4 by a huge margin. Last but not least, using Unity 5 also meant that we can benefit from further improvements that will be implemented down the road. All in all, we were glad that we switched to Unity 5.

(Depth of field effect achieved using the SCION plug-in in Unity 5.)

(Using the Time Of Day plug-in to achieve the volumetric light effect in Unity 5.)

CONCLUSION There is a saying that the grass is always greener on the other side. Did we think of switching to a different game engine over the course of developing our game? We did. While working on our game, Epic released Unreal Engine 4, which was really powerful and by the time of this writing, only required 5% royalty fees. Cry Engine showcased what the power of the engine and is completely free. Unity, on the other hand, decided to implement a subscription model which, quite frankly, surprised us. On top of that, many of the amazing plugins that need to be purchased to make Unity great came free with vanilla UE4. At some point, we were even considering going back to Unity 4 so we didn't have to deal with the light leak problems. But one thing is for sure. If for whatever reason we did switch to a seemingly better engine, we still have to face with the difficulties and problems that came with it. Even if Unity isn't all bells and whistles, and not be the most powerful 3D game engine on the market, we were glad to have chosen it because it gave us the opportunity to achieve our dream - making our first commercial game come true.

(Note: This article was originally printed on July 13, 2017. Due to the nature of the content, we decided to add it to the Painscreek Devlog series.)


Recent Posts

See All


bottom of page