For as long as I have been playing games, I have also been thinking about making them. When I was much younger, I would draw ideas for levels on paper. My game development journey properly began when in 5th grade, I got a book that teaches how to make Minecraft mods using Java. I worked my way through it and learned the basics of Java and OOP. Over the years since then, I have experimented with many different engines and tools including unreal, unity, and godot. Most recently, I have been interested in lower level c++ programming and graphics, and thus have been working on creating my own game engine from the ground up.

Skyline Engine is a custom 3D game engine written from scratch in C++. The project began life in fall of 2024 when myself and three other Northeastern students met up over a shared interest in game engine/graphics programming, and decided we wanted to start a project together, and more people have come and gone since. Over the past year, it has gone from a simple 2D bouncing balls demo to a robust and flexible 3D engine with an ECS architecture and basic map editor. My primary contributions have been the Vulkan renderer, and automatic serialization system. 

Renderer

The Vulkan renderer utilizes modern vulkan features and paradigms including dynamic rendering, bindless textures, and vertex pulling. It employs rendering optimizations such as cascaded shadow maps and instanced drawing. It interfaces with the game through a common interface that allows us to maintain multiple rendering backends written in multiple languages. We currently have the Vulkan backend that I have created and a WebGPU backend created by another team member.

Serialization

The auto serialization system is the backbone of the map loader and map editor. I realized that it would quickly become a pain to have to define load and save functions for every new component type when you add it, so I created the auto serialization to alleviate that. It utilizes a combination of macros, template functions, and static initialization code to automatically generate load and save functions for every component type that load and save all of the fields that are specified for serialization. It also creates a mapping from names to functions to allow the map loader to be able to load components by name from the map file.

Kill That Guy was a game created in under 72 hours for the Ludum Dare 56 game jam. It was created by a team of 8 students in the northeastern game studio club. We used unity because that was what the majority of the people were familiar with. The original concept for the game was a kind of “reverse mario maker” where instead of trying to make a level that would be fun for other players to play, you make a level designed to most effectively kill an AI character. I took the task of creating the AI logic for the titular “guy.” We originally had plans to have levels where the character got smarter each level, so I first started by creating an interface where you could specify different brains for the character to have. The brain interface took in various values and decided whether to continue in the current direction, turn around, small jump, or big jump. I was able to make a basic brain that was smart enough to be able to navigate through various different terrain shapes and jumps without falling or getting stuck unnecessarily. I wanted to make it also be able to avoid the traps that the player places, but did not have time within the short development period to accomplish that.

Gloop Planet Uncharted was created as my final project for my game programming class by myself and one other student. It was created in the unity engine as was required by the class. We wanted to make an FPS game of some sort, and so we had the idea to make a game where you are on an alien planet and have to fight against the native species of the planet. We decided very early on that the enemies were going to be styled after the slimes from slime rancher, because we liked the idea of taking this very cutesy design, and turning it into an enemy. I mostly worked on the modular weapons and ammo system that allowed us to quickly define new types of weapons and implement their behavior, and have the player automatically be able to pick them up and select them. I also implemented the player controller and the weapons themselves. Additionally, I refined the enemy behavior created by my groupmate, adding fleeing behavior when the enemies got low on health. Finally, I also did most of the map creation itself.

This project was something I worked on with a couple of my friends in high school. We decided to use godot because I had heard very good things about it and we were interested in trying it out. The plan was to make a tower defense game where rather than having full towers that you could place that would function on their own to defend your factory, you would instead have these modular pieces that wouldn’t do a whole lot on their own but could be combined to make effective traps and defenses. We accomplished this by creating a system similar to redstone from minecraft where you could place wires and components on a tile grid. There were detectors that would output a signal when an enemy moved onto their tile that would be used to activate the traps. There were Inverter and delay tiles that could be used to manipulate the signals and create timers. Then there were several activatable components that could be used to build traps such as pop up spikes and arrow shooters.