top of page
Project Details
Title: Programming Lead My roles: Programming, Game Design, UI/UX Design
Wyrmwood developed as the capstone project of my last year of Sheridan College's Bachelor of Game Design. We were a team of 5, and we created this game to challenge ourselves with the creation of a hybrid genre game. We chose two genres we had not seen combined before- hack n' slash, and deck-building. The end result is an enjoyable nugget of gameplay we found through a lot of playtesting & iteration. We won 2nd place at Entertainment Software Association of Canada's Student Video Game Competition 2020 for our work on Wyrmwood.
As we were a very small team of students, we all had many roles to fill for Wyrmwood. In order to allow us to remain flexible as a team, we each appointed a team member to be responsible for a few specific components of the game's development. While others could contribute (which would become necessary for all components at some point), the chosen member would be trusted with all final decisions regarding their aspect.
The decision for me to be primarily responsible for the game's programming and implementation was unanimous. I also took on the responsibility of designing & iterating on UI, working closely with our artist to do so. Other members' responsibilities included game art, game design, level design, enemy design, animation, narrative, and sound.
Takeaways
HUD UI & UX: A Dance of Decks and Dashes
Wyrmwood's hack n' slash gameplay pace is one that is fought between the cards, and everything else: the player character, the enemies, and the level. Maximizing readability of everything was essential in order to keep combat running smoothly and keep the player aware.
The HUD, and its card elements, went through a number of iterations to strike a balance between clarity and distractiveness. We needed the cards to be easily read, but not loud. We went through several playtests, looking at:
-
Understanding: Asking our players what card they selected, why, quizzing them on mana usage. Post-play, asking them to interpret the game's rules from their playthrough.
-
Speed: did players get overwhelmed by enemies? How often did they stop moving in combat to look at or read UI?
We iterated on UI each playtest, in order to reduce the burden of processing the cardplay action.
The below media can be clicked to expand.
Creating Dev Tools: Data Structures for Hacking n' Slashing Cards
The Card Asset Creator was the first development tool I ever created. From the outset of the project, it was clear the team would need to prototype and iterate on cards a lot, perhaps more than anything else, so I made the tool a very high priority. I started by mapping out all the data a card would need to exist in the game.
Diagram of basic structure for card data.
Aside from the usual metadata a card would contain, cards would need a few extra specifics to let them fit into our hack n' slash gameplay.
The first to be defined was the Aim style, a UX idea we settled on early! Wyrmwood is like playing a hack n' slash where your weapons are always transforming into new ones, so being able to determine a few specific "styles" of aim would be important. We created three, and I deployed an enum in the event we would need more. Custom reticles per-unique card also came organically as a way to communicate the card a player had selected more quickly.
Directional Aim
Point Aim
The next challenge was forming how the effects of cards would be carried out. We started this process through a discussion of what felt most intuitively understood by the team's designers. We talked until we fell upon what everyone agreed: When a card is played, a "sequence" of effects based on the card would take place. This is how I came to build our Card Asset Creator tool's most important feature.
Early card designs generally fell into two camps: Element-spawning effects, and player movement effects. So I created a Base Card Effect class, and derived those two effects from it.
Diagram of planned structure for CardEffects.
These two effects were built to handle a huge variety of things, since:
-
Player Move Effect: Player mobility options are fun & common in hack n' slash games
At this point, the tool now could:
- Create and save cards, adding them to the game's database
- Load and edit existing cards
- Design the card's effects and the sequence they would follow
This saved a huge amount of time for our designers, but only really meant that we now had a pipeline for creating cards that didn't require a ton of manual setup. Creating projectiles for our cards to fire still required lots of manual setup that the tool wasn't automating. So I gathered lots of feedback on issues with the tool as well as common design features for projectiles that the tool could automate. New automations included:
- for the MovePlayer Effect, an invulnerability toggle
- For the SpawnElement Effect:
- toggle for spawning the element at the player's position or the player's cursor position
- toggle for giving elements "cleave": elements do not despawn on-hit and deal damage to all in their path
- automate damage dealt by the projectile
The process of creating this developer tool made my team very pleased and was a great learning experience for me in learning to develop tools for teams.
bottom of page