Friday, July 21, 2017

How We Survived Without A Programmer In Our First 3 Years

Did we have a programmer? Truth be told, we did , eventually. However, our first three years consisted of a few CG artists who just wanted to make a game. This was what happened.

GAME'S VISION
When we decided to go full-time into game development, we needed to know if we can pull off the type of game we wanted to make. There was only one category to consider: walking simulators. Thus, we decided to focus mainly on story and puzzles. We gathered inspirations from Shiver: The Vanishing Hitchhiker, Gone Home, and to a certain extend, the first Resident Evil. We wanted the game to be more than a passive ride, and decided to make the game lean towards an investigation. Knowing that we were limited in what we can pull off, we made the game focus mainly on readable content such as diaries and newspaper, keys and items for the puzzles, and a fitting soundtrack for an immersive experience. We also decided to go for a minimalist approach so there will be no in-game mini-map, quest markers, or overhead compass. Regarding characters, we decided that the only character in the game will be the player. As for the music, we will first use copyrighted soundtrack as references, then compose our own later. Even though things did not turn out to be this simple, our vision, at that time, seemed to work. So we went for it.

(One of the village's early design.)

PREPARATIONS & TESTS
Our next step was to list what we need to pull off technically. They are categorized into the following areas: (1) 3D environment and props, (2) terrain and foliage, (3) lighting and  effects, (4) sound and music, (5) programming. Out of all five areas, our biggest concern was programming. However, since we had some experience with Unreal Development Kit's kismet, we felt confident that we could pull it off with visual scripting, thinking that the game only required simple scripts, such as door scripts, item pick up scripts, etc.. As for the other areas, we relied heavily on Unity's asset store. The plugins we purchased and tested were as follows:

Area
Plugin used
Custom shaders
Shader Forge, AQUAS water.
First-person view
UFPS
Visual scripting
uScript
Image based lighting
Skyshop
Textures
Photoshop, Bitmap 2 Material.
Menu & UI
Daikon Forge GUI.
Audio
Master Audio AAA.
Save/Load
Easy Save.
Terrain & foliage
Advanced Foliage Shader, Relief Terrain Pack.

We also studied a lot of tutorials, especially in the area of scripting. We gave ourselves about two years to develop our game. What we didn't expect were, firstly, the unforeseen challenges that crept into our development and second, our estimated 2-year project took 5 years to complete.
THE UNFORESEEN CHALLENGES The original game design had 1 location. By the end of the game development cycle, we had 13 locations. This became a problem as Unity was unable to handle all the scenes, props and effects at once, and we didn't have experience optimizing the game yet. We decided to make every location an instance. This meant whenever the player enters a building, say the hospital, the game would unload the village scene, which the player was previously at, and load up the hospital scene. This allows the game to run better.

(The village as viewed from the Unity game engine.)

We also needed an inventory system, which we didn't know how to implement in the beginning. After watching some tutorials, we ended up looking through the asset store to find a suitable one. Unfortunately, there was none that would fit into with our game's look. If we decided to forgo inventory, we could just make it such that every key being picked up will allow the player to pass through the respective locked doors automatically. However, we decided to go our original idea, which is to provide an inventory for the players.

(Initial design of the inventory system, with mockup images taken from various sources online.)

Our game also had a lot of reading materials. At the start of development, we thought that not recording whatever the players read into a journal seemed like a realistic approach, and it makes it easier for us. After all, a real-life journalist would write notes that deemed important to the investigation, right? However, when the game consists of almost a hundred reading materials, all found in a non-chronological timeline, and some notes containing hints to proceed through the game, players would be confused and frustrated when they are unable to access what they read previously.

(A journal system was eventually added to aid the player when backtracking NPCs' storylines.)

In addition to the game design's challenges listed above, we also encountered technical challenges. One in particular was the conflicts between certain plugins. Since they were created by different authors, some were not tested extensively to work well with other plugins. When problems popped up, we didn't know how to fix them. Going through the forums to find out if anyone had the same problem was like finding a needle in a haystack. On top of that, for every new version that Unity released, a number of plugins showed errors, while others broke the game. We had to wait for the plugins to be updated before we could continue working.
Another technical challenge we faced was visual scripting. Visual scripting was advertised as scripting without writing a line of code, and was targeted at artists. However, it wasn't as easy as we originally thought. At that time, Unity's assets store had PlayMaker and uScipt. PlayMaker had great reviews, but uScipt resembled UDK's kismet and seemed to be the more powerful for us, so we went with it. However, the lack of uScipt tutorials and our limited understanding of visual scripting made it difficult for us.

The final challenge was game optimization, which was the process of making the game run as smoothly as possible on mid-spec computers. Since everything in the game was loaded at once when the game runs, the more assets you have in the game would mean that the game would run slower. Once it dips below 30 frames per second, the game was deemed unplayable. For us, the game would run as low as 10 fps in our heaviest scenes, and that was running on a high-end computer.
If we had chosen to ignore these problems, we would have to sacrifice some essential game mechanics, making the game worse than we originally envisioned. After numerous discussions, we settled on the fact that we cannot ignore the problems, but can compromise between our vision and what we can pull off.

2-YEAR PROJECT THAT TOOK 5 YEARS TO MAKE
When we first started developing the game, we were naive and thought it could be done within two years. The years went by quickly and we found ourselves still fixing the story, making changes to its acts, and at the same time trying to pull off certain game mechanics inside Unity. As we passed the two year mark, we told ourselves that we will make it in the third year. However, that didn't happen. As the story expanded, so did the number of game assets that had to be made. By the end of our third year, we had a partial game with partially finished mechanics. It was a no-brainer that the game was not done.

(Using Trello to categorize readable content for easy referencing when checking the story flow.)

(The furniture list is part of the few hundreds 3D assets made for the game.)

Then we had a breakthrough. A few people joined our team to help create the 3D assets, freeing one of our core member to learn how to code. She became our one and only programmer.
It wasn't a smooth ride. She had never programmed before. She bought and studied a book on C#, took the plugins that we had and dissected them. She also researched on how to create certain custom scripts for our game. Often times, the scripts would not work, and she did not know why. It took her one year to create the scripts needed to run our game. However, she still wasn't able to implement more challenging scripts, such as a journal system for the player. It wasn't until the fifth year that she was able to pull them off. By the time our game development ended, she had created most of the game's essential scripts. The only game mechanic script we ended using from the Unity asset store was Easy Save. We still used shaders and image effect plugins from the asset store as they made our development easier. Plus, the results looked great for our game.

(Painscreek village as seen in the final version.)

CONCLUSION
Can you make a game without a programmer? The answer is both yes and no. Yes, if you know exactly what game mechanics are required, that your game engine you use has the tools that you need, and there are plugins available from the company store or marketplace that you can acquire. No, if you need help beyond the all that is listed above. Could we have made our game within three years and call it done? Maybe. However, there would not be a journal system. The game would be simpler, the game mechanics limited, and the content of a lesser quality. We would also have to work around available plugins instead of asking using custom scripts that work around our needs. If there's one thing we learned from all these, it's that although having a programmer on board is great, you should not be limited by it. As long as you understand your strengths and limitations, have the desire to make it happen, and don't quit when things get tough, you can always find ways to solve the problems.

Thursday, July 13, 2017

Why We Use Unity

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 terrain and foliage in Unity 4.)

(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.