LS: No More All Nighters

It has become almost a weekly thing for a few members of the team to pull an all-nighter the day before/of class in order to make sure that the game is ready for presenting. In my entire career as a college student I have never pulled an all-nighter in order for school work, or really anything. One of the main reasons is that I would much rather prefer sleep over none. But also the mental impact of working on the same thing for over 10 hours straight with no breaks is huge. It is neither healthy or good for the team. I’m suggested that we have another work meeting during the week instead of everyone rushing at the 11th hour to make sure everything is ready and bug free before hand, but it falls on deaf ears.

LS: Being The Support Character

I take pride in being the support programmer. Usually this ends up with me not being able to say “Hey, I made this section of the game”, but  it does leave me as the person who helps the Designers be able to do the cool things they do. One example of this was abstracting out the QTE that another programmer wrote to allow the Designers to create QTE events at specific points in the game, and not tied to a single enemy. This process usually works out that I create helper objects that act as a facade for what is going on much deeper in the game logic. Along the way I usually end up refactoring parts of existing code to make it more accessible for other parts of the game or less of a mess. The final step is making sure the Designers know how to actually use the system I helped make. This usually involves setting up an example in the level and then telling them how to recreate it and being available for questions when they are first implementing it.

Swiping To The Answer


I’ve got a confession to make, I love Tinder. Not because of the dating aspect, but because the swiping just feels so good. However, objectifying into a Yes or No within a couple of seconds is morally questionable. Because of that, I decided to write a game to quench my swiping thirst and not be interrupted by being notified I have a match

It feels so good

Because I do not own a Mac or an iOS device, I decided to use libGDX to build an Android game. After following the setup guides, I was all set to start making a game within an hour. Looking at the examples games, I noticed that libGDX is very similar to XNA. Because of this, I started to structure my code as I did in a Graphics/Game Engine Programming class I took years ago. Having Managers that would process multiple entities, and making each entity responsible for updating and drawing itself. However, just like the Game Industry, I started to realize that a Manager system is not the best way. In hindsight, I should have made this game in a more Entity Component way. The actual game itself could be seen as a rhythm game such as Tap Tap Revenge, Notes in different lanes travel down the screen. However, one must swipe the note into a collection bucket at the bottom of the screen when the note is ready to be. After reading a Reddit/Ludem Dare post about how to make a rhythm game and not have it fall out of sync, I decided to adopt the Conductor system described in the post. The system essentially works by tying the position of things that are dependent on rhythm to the music’s current position, and never updating a variable without applying the musics crotchet to it (the crotchet is the length of time for a single quarter note of a beat). The “Game” itself was never really finished due to other mandatory projects taking up time, so the current state of the game can be found on my GitHub Here

Gotta Go Fast: Image Based Comparisons For Speedrunning


Within the past couple of years, Speedrunning has emerged as a form of popular entertainment. For those that do not know, Speedrunning is Capturejust trying to finish a game of the Runners choice as fast as possible. Usually, this amounts to breaking the game in ways that were not known to the developers. In order to gauge ones progress throughout a run, most runners use a program called LiveSplit. This Open Source program allows the user to set up named “Splits” and then move through them and record the time when they press a button. This allows a Speedrunner see if they are ahead or behind their Personal Best times for a segment of the game. One problem that this leads to is when the competition between first place is very close, as in less than half a second, the reaction time of a player pressing the button could be a factor into the final time. What I aimed to achieve was to remove the human component of splitting, and make it an automated process based off of a user-supplied image.

The first task I attempted was to just receive a live video feed from a USB capture device. Since LiveSplit it written in C#, I started writing a simple program just to capture the input. Thankfully, I discovered AForge, a group of libraries which includes both video capturing and image comparisons. After looking over some documentation and making a simple video viewer that compared every new frame with a given image, it was time to implement it into LiveSplit.

Forking LiveSplit itself was no problem, as it should be, however, working through the program was a much more arduous task. There is little to no documentation on how anything functions, and even less comments. After F12’ing and Finding All References enough times, I figured out what I needed to do. Looking at how the already made AutoSplitter component works (Which the AutoSplitter works off of by observing RAM values). The following code snippet is the primary code that is run within the update loop:

                if (currentFrame != null && ComparisonImages[state.CurrentSplitIndex] != null)
                    var matchings = tm.ProcessImage(currentFrame, ComparisonImages[state.CurrentSplitIndex]);
                    if (matchings[0].Similarity * 100 >= 100 - state.CurrentSplit.ImageSimilarityThreshold)

The main problem with this section of code is not a problem if you do not need to have image comparison done in quick manner. The primary method of image comparison I was using was exhaustive template matching. Template Matching is where you exam each image on a pixel by pixel basis. When dealing with comparing two 1920×1080 images, then the amount of calculations that are performed is a large amount that needs to be done in a very short time. When finally getting everything working, I found out that the amount of time it takes to process even two 640×480 images was enough to make the timer chug.