My Work
In this project I mainly worked on the engineering and design of gameplay, AI, and progression systems. Since this game was made with a small team of 4, I also had the opportunity to work in many other aspects of game development such as audio, VFX, and animation.
This project tested my ability to quickly architect and implement new solutions. After our first alpha test, we decided that our large monsters needed substantially more depth to their AI. Our original finite state machine couldn’t feasibly support this new requirement. To make matters worse it was blocking our next sprints, so the issue needed to be resolved quickly.
To solve this challenge, I started with an analysis of our design goals and quickly decided on using a modified version of a behaviour tree. After moving our exisiting AI components and adding new requirements, I used a visual node asset to create the behaviour tree. Unfortunately, this asset’s performance was inadequate for our target platform. Lacking on time I instead transitioned to a quicker solution that used the engine’s inspector window to complete the rework before it became a blocker.
Monster Castle is a two week, two man prototype made to validate a game design as my partner and I search for our next large indie project. The prototype was made over a period of around 70 man hours. The first week encompassed the initial development, while the second week involved live player feedback with iteration based off of the feedback.
As neither of us had made a Real Time Strategy game before, the biggest learning point was UX and clarity. As this was a fast prototype, we did not put much work into having clean UX. Ultimately that backfired, as throughout our week of testing, the biggest pain point was the amount of time it took for the testers to understand the gameplay.
As there are many things happening at once in an RTS, players would ignore the economy aspects of the game without a safe introduction. Additionally, without visual feedback, many controls such as movement would be difficult to fully grasp.
This experience goes to show the importance of early playtesting through fresh pairs of eyes. What a developer thinks should be obvious can easily be lost on players, and catching this early on will only lead to greater success in validation and production.
This prototype stems from the goal of making a successful Steam game, and could be considered the third point of interest in my partner and I’s process.
1. We did market research on what game genres do well on steam, searching for popular tags and niches with high gross revenue which interested us. This led us to discovering Roguelike Deckbuilder hybrids do very well on Steam.
2. We attempted forming our own combination of a small minigame with the Roguelike Deckbuilder genre. After creating a list of potential options we decided on one which we thought would fit the genre and made a rapid prototype. Ultimately this led to complete failure, as we could not create a compelling hybrid.
3. We took a step back from market research and thought of themes that we would be interested in exploring. This exploration led to this design, and after cross-referencing it with our marketing research, led to this prototype. Despite the genre not being the same as our initial target, the inherent cohesion of the design and still solid market viability made this approach much more practical.
Spaceway is a small endless runner I made in a day’s time. All assets other than the background and sound were made by myself. I made this game to put into practice rapid Prototyping, build debugging, and a full 3d workflow.
This was the first project I uploaded online, and also the first I created 3D models for. This game taught me the importance of knowing the target platform. When building for WebGL, I learned that Unity’s scene lighting renders completely differently than I had intended on that platform. While working with Studio Javelin, this knowledge helped the team and I avoid multiple potential pitfalls. Furthermore, this project let me experience the peculiarities of the 3D asset import pipeline. After importing the 3D assets, I learned that any material that required transparency had to be duplicated as a second material inside Unity for proper rendering.