ROLE: Producer, Designer
TEAM: Solo
PLATFORM: Unity
The project started with a simple proposition: how can I get hired in a highly competitive industry? My only experience derives from my degree, my work with web design, and all the time spent playing the games I love. After researching the stories of other professionals, it became clear to me that studios are looking for verifiable demonstrations of skill and willingness to learn, i.e. I need to make games to get hired. However, anyone can make video games given enough time; I want to expose my potential. By setting an extremely tight schedule for my project, I not only make it clear I am a voracious learner, but that I can also perform under the rigid constraints of major game development. With a tight schedule and clear expectations, the project is designed as a structure to encourage rapid growth and maximum exposition of my talents.
TARGET
To build a game in ten work days using Unity that includes creative gameplay elements, a complete storyline, and an acceptable level of reliability.
SCHEDULE
With a ten day limitation on main development, I tried to keep my expectations for the game realistic. I broke the project into several categories: Terrain, Quests, Enemies, Audio, Debugging, UI, and Polish. These categories were allotted several days each, generally in this order. One of the main differences was Debugging, which I opted to perform throughout the development. I found that if I did not debug as I went, then unexpected problems would inhibit my ability to develop other game details. UI and Polish were pushed off into post production. These two were necessary elements to release the game publicly, but they were not necessary to demonstrate the core concepts of game development.
CHALLENGE #1
The biggest hurdle for this first game was my complete lack of experience with Unity. Certainly, I faced problems with code and design elements, but the most difficult was diving into an engine which I knew so little about. Simple things, such as the pivot or center options for an object selection, eluded me. Another good example was the static option on all objects. Such issues did not cause any long term problems, but an hour here and there figuring out what I was missing certainly added up under such a tight schedule.
RESOLUTION
Without prior knowledge, it was impossible to avoid running into unknowns within the framework. I found the best approach was to be mindful when something wasn’t acting as expected. Rather than scratching my head for hours, immediately researching how other developers reacted to similar oddities would often reveal the problem and solution. Learning this kind of basic knowledge through trial and error was inefficient, and I found the best approach was to rely on the experiences of the many developers who came before me.
CHALLENGE #2
I did not realize how important organization was for my project until after mistakes were made. In the first portion of my schedule, Terrain, I went about learning and applying the terrain tool to create a swamp like area. I chose to work on Terrain first because I thought it would be difficult to test all of the other elements without a space to work within. After creating a satisfying terrain the first day, there was a gap in my schedule as I worked my day job. When I returned to the project I found a generic terrain object in my Assets folder. Not knowing what the object was, I deleted it erroneously thinking it must have been a junk file that I had created while taking some tutorials online. It irrevocably deleted my terrain.
RESOLUTION
I now know there may have been a way to salvage my lost terrain, but at the time it was a permanent wake up call. Immediately afterward, I started organizing all my loose assets, packages, and scripts into appropriate folder structures. Before making big decisions or sweeping changes, I created backups of essential assets. While this didn’t save me from recreating my landscape, it did increase my productivity throughout the remainder of the project.
CHALLENGE #3
One of the core mechanics that played havoc with my schedule was determining enemy movement. My attempts to make an AI smart enough to stay out of corners and pursue a player logically were getting nowhere. During my research, I came across the NavMesh tool. I realized it represented an alternative to my current approach, but I needed to abandon all progress I had made in order to begin anew with NavMeshs.
RESOLUTION
I did make the difficult call to switch approaches, but it cost me an extra day, which was ten percent of my overall schedule. This was frustrating and discouraging, but I put these feelings aside and focused on doing what I could to get back on schedule. I am sure the decision saved me time in the long run. In the end, scrapping my custom AI and integrating the NavMesh system with my Quest system was a hard choice, but the right one.
FINAL RESULTS
I believe the development and release of this first game, SwampTown, was a complete success. The most important result was my absolutely massive growth in the Unity environment. I start by barely being able to control my scene view. Now, I am confident in manipulating the environment, in the editor and at runtime. I have a firm grasp on the basics of scripting, animation, and audio. The game itself turned out short, but complete. It has an element of danger, a simple but driven storyline, and it is mostly bug free. It feels like the very first part of a greater narrative, but in many ways this is a desirable result. Overall, this experience was something I deeply enjoyed, and I am excited to build more games as part of Tim’sQuest and otherwise.
留言