Note: This post was originally published on August 10th, 2017.

The Lesson of Simplicity

Using what I have learned about the power of simplicity, I want to jump right in and tell you about the week of July 17th. I had just finished my GMTK game jam submission, and I was feeling fairly optimistic about my ability to quickly prototype and program concepts. I thought it was time to focus on creating larger, more complex worlds, and I had an ambitious vision of creating a stealth game using the trigger-locomotion method I created in my horror demo. However, as I starting working towards this idea, I found myself so caught up in perfecting the smallest of details that I became very unfocused and unproductive.

After telling myself that my next project would be a stealth game (but not thinking through the game’s enemies, mechanics, or levels), I started working on the first thing that might work in this genre of game: giving the player a ‘cool-looking’ crossbow as a weapon to defeat enemies. I pictured a crossbow that required its strings and levers to be pulled and pushed in order to be fire-ready, and without much thought in how I would program this, I jumped into constructing this idea into reality. However, I ended up wasting a whole week trying to figure out how to make the different pieces of a crossbow model attach and detach to the Vive’s controllers, and overall didn’t make much progress.

After that week was over, I forced my self to find another way for the crossbow to reload; I came up with a simpler solution that got the job done…and did so in about 2–3 hours. The point isn’t to brag about how fast I could program a solution, but to show how by thinking in simpler terms, I achieved the same result in a fraction of the time. This lesson of simplicity domino-ed into another important lesson; to understand priority.

The Lesson of Priority

It is now the week of July 24th, and I had just wasted the past week trying to program a very complex and time-intensive task…with no results. But looking back on that task I had to ask myself — was that task the most important to prototype a stealth game? No, it was not, but at the time I had an idea and I thought it would be beneficial to learn ‘on-the-job’. As I found out, this is not always the best thing to do, and although priorities can be very subjective, the whole concept of the game needs to be analyzed to construct priorities that make the game.

Since I was making a stealth game, I came to the conclusion that my game’s enemy AI would make or break the experience for the user. Hence, I started learning about Unity’s enemy AI system, navigation meshes, interesting behavioral patterns, all of which strengthened my own VR programming skills. 4–5 days had passed, and the enemy AI was in good shape; it had a patrol state where it would rotate between different waypoints, it had a search light that would search for the player, and if the player was spotted, it would chase the player and attack while keeping its distance. Now I came to a very familiar road — I caught myself trying to perfect the enemy AI, constantly tweaking things until the distance to the player was perfect, the angles at which the enemy swiveled from waypoint to waypoint was perfectly timed, and the search light/enemy field of view moved in the way a robot eye moved. In fact, I had programmed a workable version of the enemy AI in just 2 days, but I spent the other 3 days trying to tweak and perfect things.

It was then I realized that although working on the enemy AI was a priority, as soon as it ‘good enough’, it should not stay a priority. Otherwise, days will go by with there being no real progress on the game as a whole.

The Lesson of Learning

After (somewhat) understanding the values of simplicity and dynamic priorities, these past two weeks have really been about learning and expanding my knowledge in more interesting directions. After about a week and a half of working on my stealth game, I went on a mini-vacation where I got the chance to see family and friends. Talking to them about my work as a VR programmer, they gave me feedback about not only being in a new industry but also about life. They asked me not only what I was programming, or what industry events I was going to, but asked what I was reading, what were my hobbies outside of my personal work schedule, and where I was investing my extra money. My empty-handiness for many of these questions made me realize that learning is not exclusive to one’s professional work, but continues in many other areas of life, including relationships, books, and money.

As a result, I let my curiosity wander outside of VR, and I made time to learn about new perspectives (historical or present), new ways of thinking, and new skills. Learning doesn’t just mean focusing on one thing, but having the dedication to listen to all perspectives from all mediums.

See you in the next blog post,

Tejas