Game Development Experiments
Some game development experiments made in Unity3D that showcases my hunger for knowledge in the space. I am also using these experiments to grow my ability to code in C# and build games. Some of these experiments may lead to full game releases under my own company. None of these were made in cooperation with anywhere I have been employed.
Project #3: 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 eachother.
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.
Project #2: The Character Movement Limbo
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.
Project #1: 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.