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.