Current Work

Since August 2018, I have been employed as part of a five-person team that is making educational games for PBS Kids. I am working for the University of Central Florida, under a professor in the College of Community Innovation and Education, Dr. Eleazar Vasquez. He has been contracted by PBS to make a browser-based game that will tie into an unannounced TV series for PBS Kids, and he assembled a team of FIEA graduates, including myself, to produce the games, which are intended to teach children between ages 5 and 8 about various scientific subjects. Our first game was about sound, and our second is about light and shadow.

As the accompanying TV series is still in development as of this writing, I’m not allowed to divulge too much information about the world the game occupies, but I can certainly discuss the work I’ve done from a technical standpoint. This project has been an interesting one: not only was I learning a new language (as this is a browser-based game, it is written entirely in JavaScript), but I’ve also been given the opportunity to flex my software design muscles to a wonderful degree. (We are not using a traditional engine with an editor, so I had to do a fair amount of work from scratch. Ask me about my Asset Placer class sometime.) I’ve really been enjoying the work I’m doing, and I like the team I get to work with every day.

In addition to my job, I’m working on other personal projects in my spare time. I’ve been working to polish and refine my Ticket to Ride project since its first stage ended in August 2018. I’m also practicing C++, as I don’t want to lose the knowledge I acquired in FIEA while I’m working in JavaScript. (I was afraid I’d go back to C++ after a long time and start prefixing method calls with the “this” keyword. The horror!)

Speed Limit



Speed Limit was made in Gamelab, a course that was designed to expose FIEA students to making games for reasons other than entertainment. My 12-student team was tasked with making a game that would teach police officers to be safer drivers. We worked under the guidance of a representative of the Federal Law Enforcement Training Centers to create a game that was similar to an endless runner (you could call it an “endless driver”, I suppose): players were placed behind the wheel of a car and asked to identify potential hazards on the side of the road. We used eye tracking to determine where the player was looking, and if they were looking at a potential hazard, like a stop sign, or someone walking while talking on their phone, not looking where they’re going, then the player would have to press a button and make it known that they see the hazard. However, a player would only get credit for identifying a hazard if it was done at least two seconds in front of the car, and as speed increased over time, the distance also increased. In order to continue identifying hazards, players would have to look further down the road in order to see them in time to react in case that potential hazard turned into an actual hazard.

We found that this game was very helpful in training people to move their eyes further down the road. Several members of the team took a trip to the Federal Law Enforcement Training Center campus in Georgia, and we were able to get police officers in training to playtest our game. Several of them said they could already tell, in the short amount of time they were playing, that their field of view was moving further down the road. This, we think, will make people safer by giving police officers more time to react to situations in the road because they will notice them sooner.


My Contributions

I had two primary responsibilities for this project. The first was to research Tobii eye tracking and see how we could use it for our game. I did all the initial legwork for understanding how to incorporate eye tracking into our game: I did research, wrote a document detailing how we could use it with Unity, and performed all the hardware and software setup for programmers and tech designers who would be using eye tracking throughout the development of the project.

My other primary responsibility was to work with our UI artist to ensure the UI in our game worked. I engineered the functionality of the car’s speedometer, the scoreboard, the health meter, and the leaderboard.

In addition to those, I wrote various small parts of code; I engineered the game’s loss state, I set up the hazards to have varying point values based on their type, and I set up the car’s rear view and side view mirrors to be special hazards: players would have to look at them at least once every 5 seconds, or else they would be penalized.

FIEA Game Engine

Over the course of a semester, I built a game engine in C++ from the ground up. It parses JSON files to construct Worlds, Sectors, Entities, and Actions, all of which are C++ classes I wrote and tested. It has an asynchronous event system that processes custom events, reactions, and messages; dynamic binding of names to values; and a variety of custom replacements for STL classes, including a hash map, a vector, and a linked list. Over the course of this project, I gained an appreciation for the complexity of engine development and general software design. The creation of such foundational classes as Datum (for storing arrays of values of various types), Scope (for storing names and pairing them with Datums), and Attributed (for Scopes that had either prescribed or auxiliary attributes of various types) provided insight into the design of Unreal Engine 4 in particular and the design of that engine. Working on this project also taught me to be diligent with documentation and unit testing.

At the end of the semester, I worked with a team of 6 other programmers to create a simple game in the engine. We created a clone of the original prototype for Baba Is You. We created each level as a World in JSON, we used the asynchronous event system and Reactions to capture and represent player input, and we formed each level as a grid of stacks of Entities. I created the Entity subclass RuleCheck Entity, which scanned the board each frame to look for rules to apply, and then applied them.

See the source code for my engine here!

The Diner



This was my first project in UE4 and my third project overall. This was made on an interdisciplinary team of four people as a part of Rapid Prototype Production (RPP), a course designed to teach students how to work with other people in other fields and get a prototype produced quickly. My team wanted to make a narrative experience for this project, and we created this survival horror-inspired short subject that told the story of a man who, after being stranded in the desert, comes upon a seemingly abandoned diner and finds himself trapped within. This was my first experience with visual scripting, and I was resistant to it at first, but having become more experienced with UE4 since then, I now recognize it as an important tool for communicating to non-programmers what your program is designed to do. This was a very simple project; most of the functionality we needed was already present in UE4 by default, but it was an important introduction to what is now my preferred engine.


My Contributions

As stated on the left, much of the functionality for this game was provided in UE4 already, which was fortunate, as it allowed me time to learn about and come to grips with Blueprints. I did, however, manage to set up a system wherein the player could bring environmental objects close to the first-person camera to look at them in more detail. I also handled the non-standard input for the game, which meant everything the player could do except walk around and jump.



Tablecraft was my second project. Like The Diner, it was made over a period of two weeks in RPP. My interdisciplinary five-person team experimented with VR in this one, developing it in Unity for the Oculus Rift. It was an educational game designed to teach children about the Periodic Table of Elements. The central mechanic was picking up objects in the room and breaking them down into their component elements to complete a Periodic Table that had some elements missing. Of my RPP projects, this one had the longest lifespan: the project lead, Rafael, decided to run with it in the following semester and expand it, adding a number of new mechanics and playtesting it with a group of elementary school students.

UPDATE: Rafael has co-founded a company with Guillaume, one of his teammates from the Gamelab version of the project. Their company is called Not Suspicious, and since they recently acquired a sizable grant from the National Science Foundation, they’re starting to expand their team and hire more people. I highly encourage you to visit the Not Suspicious website at; it’s a very interesting game!

My Contributions

I worked side-by-side with the tech designer on my team, Quinn, to produce all the C# scripts for this game, employing the pair programming paradigm. The core of this game's functionality entailed creating a mapping of environmental objects to lists of elements, and a mapping of elements to lists of other elements and environmental objects that could be formed from those elements.

After these maps were completed to a satisfactory degree, we created the script for the machine, which would break down objects into elements and fuse elements into objects. We placed an invisible sphere above the machine, and we set up the buttons on the machine to check if this sphere was overlapping with any items that could be transformed, whether that meant looking for environmental objects to break down into elements or looking for groups of elements to fuse into environmental objects.

Sisyphus: Reaching Redemption



Sisyphus: Reaching Redemption was my very first project. It was a simple game in which the player was asked to roll a boulder through an obstacle course. As the only programmer on an interdisciplinary team of five people, I was responsible for programming all the behavior for this game. It served as a good introduction to a video game engine; I learned a great deal about the fundamentals of Unity (and team-based project completion, for that matter) in working on this game. As this was my first RPP game, I also learned that it was possible to quickly produce a prototype in a relatively short amount of time.

Sisyphus was a figure in ancient Greek mythology who was punished for his deceitfulness by having to roll a large boulder up a steep hill over and over again, only for it to roll back to the bottom of the hill just before he made it to the top. He was stuck doing this same strenuous task for eternity. In the premise of our game, Sisyphus had been offered a way out of this torment: Zeus had said that he would release Sisyphus if Sisyphus could remotely control the boulder through obstacles to a goal, rather than roll it up a hill. However, the boulder continuously shrank the more it moved, so every mistake that Sisyphus made, every pit the boulder fell in, made getting to the goal harder to reach, because he would then have to repeat what he had just done, but with the boulder smaller, meaning it would be harder to get it to build momentum and cross gaps.

My Contributions

I was the only person on the team who’d had any coding experience whatsoever, so I wrote all the C# scripts for this game. I got the boulder to roll around upon receiving player input; I made the boulder shrink proportionally to the amount it had moved while touching the ground since the previous frame; I changed its movement dynamically when it went through fire, which sped it up, or ice, which slowed it down; I created gusts of air that could be used to lift the boulder up in the air; I implemented a timer that would measure the fastest runs through each level; and I used file I/O to store and display a leaderboard containing these times.

I was also the primary engine consultant. My team was using Unity for this game, and I was the only one who had studied it in advance, so I took the time to sit down with people on the team and show them the basics of how to use the engine.