c#

In my last post I talked about a world editor tool that I've been working on for a while, and how I implemented a C++ rendering system in a C# UI. With a robust user input system now in place, I have the ability to move around throughout the editor. The next step is to enable user input so they can move objects around, edit their properties, and so on. In the tech demo I worked on to prove the concept of this editor, I had the ability to select an object from a list and edit its properties, but most game editors worth their salt allow the user to simply click on an item in the viewport to edit its properties. To achieve this, I needed two things: 1) A way to cast a ray from the camera, through the mouse, and into the world 2) A way to test if that ray hits an object in the world. Both of these are not terribly complex concepts, but having never implemented them it was a fun challenge! Check out the rest of the article to see how I tackled this task and achieved my goal!

For about a year now I've been somewhat quietly working on a new game project. This has been a really fun project based on the idea of the "Backrooms", a strange space where you go when you clip through reality. I fell down the rabbit hole when I saw a youtube video by Kane Pixels, and almost immediately wanted to build a game based on the idea. Right away I had some challenges to tackle. The world in the "Backrooms" is a sprawling maze that seems to go on forever, and generating an infinite maze in Unreal Engine was not a challenge I wanted to tackle. Primarily I wanted to create a rich gameplay experience based on this concept, and making this happen in a procedural world would be a huge undertaking. So I thought outside the box a bit, and realized that if I could create a maze big enough and use world partitioning to slice it up, it could seem infinite to the player. So the first step then was to see what it would take to actually generate a maze in code. It turns out that generating a perfect maze is pretty straight forward with a modified depth-first approach. Once I had a basic maze generator built, the feature set of the tool exploded as I was able to add more and more features to create a richer world. Check out the full article to join me on my journey from a simple 2D tool, to a more complex 3D tool using C# and WPF!

I spent a lot of time last year studying and implementing quad trees to try and add some extra tools to my game programming tool kit. It didn't take long to grasp the concept and get a working implementation, and that implementation led to both the 2D and 3D demos I presented previously. While both demos do what they're supposed to, I noticed that the 2D version had some performance issues that I wasn't happy with. The issue is that at each step of the simulation the number of quad tree searches increases exponentially. I already made a simple optimization that ensured objects in the center of a cluster did not continue to check for neighbors, and that did help a lot but it wasn't enough. Check out the full article to see how I tackled this issue and to get a real time look at how well it performs!

For my senior capstone I worked with a small group of people to develop an interactive factory training simulation with Unity. In large scale production factories it can often be costly to train new workers and can use up valuable factory resources. With the advent of Virtual Reality technology, it is now possible to create virtual scenarios that can allow new workers to learn their job before ever stepping foot on the factory floor. The goal of this project was to create a VR simulation to teach workers how to work in one specific production unit for manufactured housing. The goal of this project was to create a simulation that would teach new workers with simple instructions and guidelines, but also be easily adaptable to other production units in the factory. See the video in the full article!

Here's a fun project I worked on to try and keep some of my skills sharp. Conway's Game of Life is a simple simulation of sorts that operates on a few very basic rules. I've been fascinated with it for a while because of how versatile it can be and the things people can create with it. I knew the rules were simple so I decided I would take a shot at creating a simple implementation. The original implementation was super simple and very easy to implement, but I wanted to take it a step further and set it up to handle much larger grids. So instead of using a single thread to process the whole array, the next best thing is to use multiple threads and decompose the problem. My first thought was to create multiple threads each frame and explicitly tell each thread which portion of the grid to work on. While this does work, the overhead for spawning multiple threads each frame caused some serious performance issues. In fact it was less performant than the single threaded version. I haven't done a lot of multi-threading work in C# and this was a good reminder that those underlying system calls take just as long in high level languages. So instead of creating new threads each frame, I needed a rudimentary job system with semi-general purpose worker threads. Originally I toyed with mutex locks to keep the workers and the control thread synchronized, but I couldn't readily come up with a good design for that. The solution that I did come up with was much easier to implement and very straight forward. During my parallel programming class we had an assignment to implement a basic ecosystem simulation where different parts of the ecosystem needed to be simulated at different stages in each frame. We used wait barriers to keep everything synchronized, and that problem was similar enough to this problem that wait barriers worked really well. With this design I only need one mutex lock for the work queue, and three barriers for each processing stage. Some careful loop placement in the worker threads allows for more work units on the queue than worker threads, and my basic job system works very well! Getting rid of the many system calls per frame, but keeping multiple threads brought the performance back up to where I wanted to see it, and now the simulation runs well at larger scales. Check out the video and the code in the article!