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!

Here's a quick video demonstration of some improvements I made to my previous Metroid clone project. All of the technical details are the same as the previous project, so if you're looking for code snippets check out this article. This version is primarily an artistic improvement with some better models and a few updates that I wanted to make in the original project. Check out the video in the full article!

Spock is a project I've been working on for a while now to make using Vulkan in smaller projects a lot easier. I've been fascinated with Vulkan since I first dived into the API in a graphics class. The option to submit multiple queues at once in a parallel fashion was enticing for performance and overall very interesting. However after about the first 3 weeks of the class I was finding that setting up Vulkan for use in a project was a serious undertaking and I wanted to change that.

This is the grand finale of my OpenGL classwork and the project I had the most fun working on. This project was fun because I had to do more problem solving and engineering to really get it to work the way I wanted. In my class on GLSL shaders I tried to create a scene from one of my all time favorite games Metroid Prime. I was happy with the results of that project but since I had all the shaders and models I decided I would build on them and create an interactive scene. Check out the video and the nitty gritty after the break!

This project was really simple but was a good introduction into bezier curves and their uses. I didn't have a lot of inspiration for this project but the result was fun and it looked cool. This introduction to bezier curves was a great experience because it gave me an insight into how a lot of graphical tools create curves and splines. Check out the video and the code after the break!

This project is where I really let my creativity out of the box during my OpenGL class. This project was really about lighting, but I took things a step further by implementing my own OBJ file loader to load in a model I created in blender. All we really had to do was create two colored lights and a moving object that would move between the lights. Having done the helicopter in a previous project I thought it would be really fun to use that to animate a little city scene and the result was pretty good. It was with this project that I realized how much power OpenGL really had and what I could do with it. After this project I really started to connect the dots on how game engines work and how I could create a simple engine. Check out the video in the full article!

For my networking class we had to create a client and server to pass a file back and forth successfully. Setting up the network sockets is pretty easy, everyone has read beej's guide, but the trick was in setting up the data to send and to ensure that I was getting data I expected. I could have just sent the data and tried to deal with it but I decided I would create a basic packet header to ensure I was getting my data and the length of the data. This header is super simple and contains 3 four byte integers. The first one is actually just HEAD spelled out in ascii (which if necessary would give the endianness of the sending system, a trick I learned from the Halo 2 map file layout), the second one is the length of the message being sent in case we have to read multiple times, and the third one is a type field. All of this together allowed me to determine if the data being received originated from my server process and allowed for easier handling of data. The type field was really important for this project because we were required to emulate the way that FTP opens two connections when transferring: a command connection, and a data connection. Setting up my packet header with a type field allowed me to use the same code for both command and data connections by simply changing the type. In the end this worked out really well and proved to be a simple file transfer solution. Check out the full article for the code snippets!

This project was designed to get us familiar with the important of order when doing matrix transformations. We were challenged to animate a helicopter with both blades spinning and in the right directions. Check out the video after the break!

The first project I did when learning OpenGL was a very simple project with one goal: create something pretty. We were challenged to create an object that would render on screen with a given OpenGL project sample and I decided I would create a heart. Check out this video for the rundown on the project: https://youtu.be/HZ1ytOLi9iM. Open the article to see the code!