Game Development

A collection of experiments in game development. The projects range from expeditions towards project I would want to release, as well as learning projects to around various mechanics.

Dusk Keeper

My most recent project was too ambitious but I learned quite a bit making a complex. Original concept was to make an adventure game with a deep story and and the mechanic that differentiated itself in the genre had to do with using different weapons withing a combo system. Each weapon would have it’s own combo of moves, and the player could chain other weapons in the middle of the combo. An example in a 3 hit combo, would be, 1st attack - sword, 2nd attack - hammer, and 3rd attack - spear.

The goal would be that each attack in a single weapon would be for a different use case. so you can line up 3 AOE abilities from different weapons lined up, or 3 single target attacks from 3 different weapons, giving the player freedom in agency to line up attacks based on intention, or in response to the current scenario. This was too much work, on top of all the other stuff I wanted to make in this game. By the time I realized this, we were in to deep and I changed focus to build toward a polished standard adventure game experience.

Aside from building toward the above system I learned how to build a lot of interesting systems. I learned a lot of things I need to keep in mind early when building a project from scratch as it made it hard to build later mechanics when I didn’t approach some things well.

Game build available upon request.

  • Isometric movement & dash

  • Ability & combo based attack system

  • Cinemachine camera follow and encounter cameras

  • Setting up combat zones for enemy encounters

Features Built or Learned Skills

  • Enemy State Machine

  • Created 4 unique enemies and 4 variant enemies that have distinct behavior trees.

  • Experimented with various toon shader solutions

  • Character modeling and texturing

  • Character and monster Animation

  • Environment Modeling and texturing for toon shaders

  • Dabbled in VFX

Horse Racing Auto-battler

I was hanging out with some friends and we were talking about finding a game to quickly make, and ship. I offhandedly joked about an idea, “What if we made a horse racing game called pony up, where players would set up actions for the horses to take during the race with abilities like an auto battler.” This started our attempt to reclaim horse racing from purely being perceived as a gambling mechanism.

This was a completely different mechanic system than I have ever worked on as most of the games I had worked on up to this point, the player has full control of the moment to moment action, where as, in this project, I was building toward making a queue of actions the player would have agency for that needed to be stored and played in order. Also the other horses needed to respond to the abilities and actions of each other.

During this project I learned about:

  • In-game Architecture

  • Data storage

  • Creating independent mechanics / prefabs that don’t overly rely on general game systems.

  • Parallax backgrounds

  • different ways to move characters in a straight line with a fixed beginning and end point.

  • adjusting values during run time by external forces.

  • and much more…

If you wanted to see the intended vision of the experience, check out the Figma prototype. When you reach “transition to buff" phase,” you have reached the end. Press “R” to return to the beginning. This is the moment when the player would jump back to the buff purchasing moment and repeat the race till someone, won 3 times in a row.

Note: This project was started a few years before Umamusume: Pretty Derby came out. It doesn’t reclaim the genre from gambling because it is a gacha game, but I’m happy to see a fun “horse” racing game come out.

The Character Movement Animator Blend Trees

I fell into a bit of a trap trying to make the best movement I could. Most people would just grab a movement system from the asset store for quicker returns these days and focus on refinement when they are farther along in development of a game. I being new to C#, didn’t really understand how other people coded yet, and therefore, using other peoples completely set up asset, was scary because I had no idea how it was built and how to adjust it. So, I went on a journey to build a movement system that facilitated my needs.

The first version of this movement system was hard coded via script. But i wanted more customization with animation that correlated to speeds without any sliding, which led me down the path of using the animator as the place i stored speed variables and that speed variable would be adjusted by button presses to shift from walking and running or smoothly via joystick movement. I learned a lot. Similar to traps I’ve fallen into with art; paintings, drawings and now… movement systems… these things could be refined forever, but, sometimes you just need to call it done and “move” on.

Isometric Shooter with Basic Enemy

Prior to this project, I had attempted to learn how to code and build games via coding, without much success. This projected really solidified. “how I am best able to learn.” in this “engineering mindset” that I hadn’t delved into. I learned I can’t really focus on theory, and learn by sitting through a course. I really needed to focus on some goal to get my self to wrap my head around how to use concepts. With that In mind, I began by deciding what I wanted to make!

I was very enamored by games like Transistor, Hades and Hyperlight Drifter at the time, and wanted to make some sort of Isometric adventure game. (still want to) In this project, I had built a little demo for a moving character, that could shoot where the mouse was pointing and enemies that spawned out of view and pursued the player. Also the camera would follow the player and there would be some buffering to make sure the camera didn’t feel jerky. Bullets would knockback the enemies a bit. The enemies logic was pretty simple and built on Unity’s NAVmesh system, the enemies would walk toward where the player was, if the player was within a certain radius of the enemies, they would take a moment and then “lunge” quickly at the player. This was before I knew anything about behavior trees and state machines.

I learned a lot of about building these mechanics for the first time and repeated refinement. I fell into a trap of focusing so hard on figuring out what good movement in a video game looks like. As you will see I have a separate post all about that.