In Runic, players must stealthily navigate through challenging encounters with enemies and environmental hazards.
I took on the unofficial role of lead developer and set out to develop fun, challenging AI for the player to avoid. I took a hand in coding the player power-ups and their associated HUD elements, but I am most fond of the checkpoint system and how far it has come along.
Get the game here
Runic began as a very different game compared to the end product. We initially sought to create a collect 'em all style game in the vain of Pokemon. We got as far as developing a working battle state machine with turn based combat, but when it came time to implement all the other features like traps and cages, we found that the true fun of our game lay in the evasion and outwitting of enemies. The battle system was scrapped and we never looked back.
The enemy state machine is very rock solid. We put the majority of our development time into nailing down the enemy functionality. Two developers took on the tasks of programming the enemy movement, sight cone, attacks, and other interactions with the player. We could build entire levels using just enemies, geometry, and tall grass, as shown in level 1. But players need to feel a bit empowered right? We brainstormed every other day how to balance the power-ups, and extensive playtesting provided the data needed to make those decisions.
The success of any team endeavor hinges on the team's communication. With so many means of sharing ideas and broadcasting a message, developers have more tools than ever before to meet and collaborate. We relied a bit too heavily though on old fashion text messaging via Discord or email. It is important not to read too much into the tone of a written message. Take the words for face value, and if someone has a problem, they'll let you know. As our game grew, ideas to improve the gameplay would creep in. While we want to see each person's ideas expressed, team members must recognize when it is a good time to say "No." There are times to experiment and times to polish, and they should rarely intersect.
While it is thrilling to see a game come to life, grow, and evolve into a fun, playable experience, I look forward most to learning new skills. I learned several new techniques in C# and Unity, like how to make enemies navigate along a mesh, avoid obstacles, and behave according to complex algorithms. A game like this requires constant communication to the player. Are they in stealth or have they been detected? When are the power-ups ready? Where is my objective? Through research and creativity, we applied new concepts and visual effects to ensure the player always knew the state of the game.
While we worked fairly well together most of the time, there was not a complete lack of toxicity during the most tense moments. Things break and do not always go well. Sometimes the world breaks down moments before a big milestone date. Those are the truest tests of one's character. Ideal team mates lift each other up when the going gets tough. They seek solutions, not scapegoats, and they mind their tongues when critiquing work. Each member of our team, including myself, has much to learn on their game design journeys. In this regard, I have concluded that now is a good time to part ways with Blue Team and set my sights on what lies ahead.