Procedural Level Generation
I have worked on multiple projects which made use of procedural content creation to make levels for the player to play. The two largest examples are for the platformer Beard and for a prototype of the level design portion of the dungeon crawler, project TECA.
As a platformer in which the player traverses primarily horizontal floors in order to locate a path up to the next floor of the level, the primary concern of this system was to ensure that there would always be a way for the player to climb up to the next floor and that they could never become stuck, such as by falling into a pit that is too deep or passing an obstacle that can only be cleared in one direction. This is already complex when only taking into account the basic building blocks of the world, but Beard also adds in special types of platforms with unusual behaviors, optional prefabricated hand-crafted chunks with arbitrary entrance and exit points, various other hazards, enemies with specific placement rules, and visual elements built on top of the level and dependent on its shape. All of these pieces needed to be taken into account while still not sacrificing the basic functionality of ensuring a winnable level, and making the experience fun and unique each time.
The first two images below are of an iteration of the game where we had scrapped most of my random platform generation aside from the final path between floors, so most of the platforms in areas in between are instead hand-crafted segments (hence the floating block areas with no way to access them – they were intentionally designed that way for some reason). The later four images are of an early version where the terrain was much more mountainous and floors had occasional pits to drop you down to a lower level.
A top-down dungeon crawler by design, TECA is designed in a completely different way from Beard. The level generator accepts dozens of parameters from the user to create a dungeon layout filled with rooms, tunnels, doors, and/or irregular caverns. The system first places all rooms, then begins connecting them to each other with tunnels using A* pathfinding to find the most efficient route. The pathfinding algorithm can have costs determined by the user, along with optional cost randomization factors so that the tunnels end up more or less direct and predictable. A start and ending location are then determined based on additional placement rules, and the system ensures that all open locations can be reached from the start.
Each game has its own logic that must be programmed unique to that game. This can include AI, character controls, object interactions, dialogue trees, or just about anything else you can think of.
In addition to the level generation, I was responsible for most of the more complex controls and behaviors in Beard. Development on the game halted before I had a chance to do much with the AI, but I did create most of the basic platforming controls, including getting the jump feel just right and allowing the character to grab onto the edge of ledges. I also worked on the camera tracking, getting it to feel like it's following both the player and the level (not dropping below the platform when you reach a new floor) but not keeping the player centered all the time. The video to the right shows some basic gameplay from a test build of the game, and the gifs below were used on the KickStarter to show some of the items in use.
I was the sole programmer on this project. It initially began as a school assignment. In approximately six weeks, we had made a completely playable game that could have been considered beta ready if not for the fact that we wanted to add so many extra features to expand it even more beyond the core gameplay. The game was designed for mobile devices, so the controls needed to be simple. I programmed the character controls, the enemy AI, weather effects, tool effects, plant growth, NPC conversations, a merchant/trade screen, and anything else that needed to be done. We worked on the game after the initial assignment was over, but were forced to stop due to other school assignments taking too much time, so the game now feels less complete, despite having more features, since some were only started and never finished. Play it here.
I was also the lead programmer on this school project, doing nearly all of the programming myself. This is an RPG that features time-based combat akin to the Super Nintendo and PlayStation Final Fantasy games, an interactive dialogue system with branching trees and responses available based on previous actions, and active puzzle-solving and adventure sections. This was one of my earliest attempts at more sophisticated AI and at pathfinding without a grid system of some sort.
Exploring the tunnels
Fighting some bats
Combat radial menu
Checking the character's status and equipment
School Projects and Educational Demos
These are small and quick projects that I made either for school or to teach myself something I didn't already know.
Z-SPLAT: Revenge of the Undead
This was started as a school project, but eventually taken to completion and released on the app store. This game was built using GameSalad, which does not technically allow programming, but I had to get pretty creative with their scripting language in order to get it to do anything close to what we wanted. I was the lead designer, in charge of scripting, asset integration, team coordination, testing, and delivery of the final product. The game is no longer available for download. Additional information and screenshots are available.
A simple educational game of Memory I built for a class when I was just learning Unity, designed to help teach the kanji for numbers 1-10. Play it here.
A game I wrote in a few hours to teach myself C#. I had no meaningful prior knowledge of the language, but had some experience with the Unity game engine and programming in UnityScript. The graphics... aren't. The gameplay is just what you'd expect from whack-a-mole. Play it here.
In my final animation class, we had to import a character into Unity and have it controllable by the player to trigger all the specified animations. Unsatisfied with the teacher's provided character controller, since my character had additional animations and more complex transition states, I decided to make a more universal animation test controller to use in my project. It allows for character movement with custom speed and acceleration, arbitrary buttons assigned to each animation, determining a character's grounded state to decide what animations should play, and so on.