H.O.U.N.D
October 2016
​
​
Sean Braithwaite ................... Programming
P.Y. Boulerice ........................ 2-D/ Prog.
Justin Sennema .......................Programming
​
1-Week Development Duration
H.O.U.N.D. Blog & Postmortem
Programming
Game Design
Ancient Idols awaken, their mossy skin hanging in bunches, and march forth. H.O.U.N.D is a cooperative fantasy hunting game with a touch of horde gameplay and twist of top-down combat. Players pick from a variety of weapons, each with a unique play style, and combine them to hunt down rampaging stone idols.
Challenge:
A. Create a game requiring player cooperation
B. Provide unique playstyles and player-choice with selectable weapons
C. Program AI to create interesting player interactions for each weapon
My Role:
A. Designed and prototyped gameplay mechanics and systems with a team
B. Researched and implemented a basic FSM system for the AI using coroutines
C. Ensure player-to-player and weapon-to-enemy interactions are engaging
Goal: Cooperative Horde
Our idea began with the desire to craft a horde game. We loved the massive amounts of enemies and the satisfying gameplay inherent to the genre and saw it as a rich area for co-operative gameplay.
Figure 1. Design sketches/ ideas for weapons, enemies, arenas (deprecated), and FSM states.
Successes and Takeaways
My favourite parts of H.O.U.N.D were its visual polish, quirky enemies, and small cooperative strategies. It was also the first game I'd made which felt like it could become something greater.
The game contained a fair amount of cohesive, legible art. Most importantly, however, was that assets were under way before the programming was in place. As a result, the artwork served as a massive inspiration and morale boost in creating the logic behind everything. I believe having some artwork or other conceptual inspirations are great for motivating the rest of the team, especially programmers, so I will make them available in coming projects.
The AI which I programmed for the project was a strange one. I had only programmed AI once before, so H.O.U.N.D's creature logic was likewise structured for a more complex AI. I ended up using a series of coroutines which would fire depending on events (A creature being shot at with magic would trigger it to dodge, etc). The coroutines would overlap occasionally and cause interesting behaviour, but I don't believe I would approach AI this way again as it was challenging to troubleshoot and difficult to control. The takeaway from this, however, is that a simple AI can still be an amusing AI if one focuses on the important bits. My next AI system will be modular and broken between smaller, self-contained scripts rather than one modifiable master logic path.
Cooperative gameplay was a goal for this project, and it came through decently. The variety of items to choose from was the most important design choice, as it made for interesting strength/ weakness interplay where players were more dependant on one another. Furthermore, it avoided dominant strategies, though some combinations were better than others, players did what they found fun, as each item was viable regardless of the partner's weapon.
Postmortem and Design Thoughts
The biggest concern from this project was one I hadn't experienced before: client vs. team goal conflicts. We were torn between staying true to the ideas we wanted to create, and satiating the client's requirements. At times it felt as if we weren’t focusing on our objective of cooperative gameplay or that it wasn't showing in the prototypes present form, even though the original design was centred on coop.
In future projects, I’m going to stand by our pre-designs unless the project is diverging from the proposed one, regardless of whatever in-development phase it’s in. I feel that this belief is critical to any creative work, they take time, and doubt will only lead to shoehorned functionality and discouragement.
In this project, the thoughts were unfounded, though this made aware the concern of design interpretation, thus one must be thorough in documentation, explanation, and implementors must be knowledgeable. Getting tunnel-visioned is dangerous when one must see the bigger picture, thus planning is paramount to success and reliable flow.
