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.




LS: My Time Is Now

Today is the night of the Senior Show, after a rough last final weekend, those that did not go to PAX worked very hard to make sure the game was done, pulling all-nighters, against my discretion, in order to pull it off. As a team, we decided to all wear matching Dan Shredder Shirts to the show. The shirts themselves look like a Dan Shredder Tour Shirt. All that is left is to stand in front of the audience and network with recruiters to try and find a job.

LS: We’re Going to PAX!

I’m currently writing this from the couch of the apartment I am staying at for PAX East. Half the team has come to PAX to view everything that there is to offer. I am here myself as a volunteer Enforcing. The Gold Master for Dan Shredder is due Monday evening, and I won’t be back in time to work on the game. The five who are not down in Boston for the weekend have taken the duty to work overdrive in order to finish the game. Already they have hit a breaking point. A commit from the super work meeting we had on Wednesday broke the game and we had no idea why. With anyone who could testing older commits to find out which commit broke the game (Even me, through the power of a 4G connection and remote desktop).

LS: The Importance of Project Management Software


So, ever since we have worked on teams at Champlain, we have used Redmine as our project management system. Everyone has either learned to love it or hate it, but at least learned how to use it. However, none of that matters if nobody decides to use it in a proper way. Looking at the taskboard should be something to judge the progress of a team in the current sprint. However, when I see it, all I see is User Stories with no tasks, incredibly broad tasks that are marked as “In Progress”  and many completed tasks with no one assigned to them. Everyone says they are doing Agile development, but they usually admit that they may not do certain parts of it. However, right now it seems we are doing our own development practice, and have decided to use they things from Agile development.

When being told that User Stories don’t work, something seems amiss. It’s true that User Stories don’t work when people just create them at any time and is seen as a gateway to being able to log time on a task. But if there was time spent planning before the sprint started to make sure everything was created then User Stories are great. I think part of this problem stems from the fact no one is taught how to use Project Management systems to their full potential. How does a carpenter make furniture if he does not know how to use a saw?

For this current Sprint, we have essentially abandoned Redmine in favor of the “Get Shit Done List”, which is just an excel document with a list of things that need to get done. What it looks like however, is just a spreadsheet of tasks that could be made in Redmine. Each item has a name, description, who it’s assigned to, current status, and priority. All of these things are fields for a Task on Redmine. Project Management is something everyone on a team should learn in order to be fully productive and allow everyone else to be working fully functionally.

LS: The C++ is dead, Long Live the C++


For the entire semester, the way programming duties have been split up is between gameplay and engine rewriting. Coming into this semester, the majority of Dan Shredder was written in Blueprints, and it showed, the game could not run at 60FPS on anything except for the lowest graphics settings. The goal of the C++ transition is that it would help us reach the goal of having the game run at 60fps on the highest graphics settings. Today we decided to cut the rewrite that was being worked on for over five weeks.

The visible progress that we had on the C++ rewrite in those five weeks was very little. Externally, there was none, internally, we were only getting to the point where the game would be playable, but not in the way it was currently. The player could strum notes and songs could be played and all these individual functions were written. However, when it came time to start putting everything together, things starting breaking left and right. One of the biggest perpetrators of this, was that every system was very coupled into each other, unable to be tested until other classes were done. For instance, the InputHandler class required functions in the PlayerGuitarController class to be written, which those functions required the Fretboard class to be written, which required the Note Receivers to be written. This might seem like a worst case scenario, layers of layers of requirements just to get one thing working. However, this was commonplace.

The hole that was metaphorically dug  while doing this C++ rewrite was also very deep. So deep in fact, that I never actually came out of it. I entered that hole when other team members were thinking about what to do this semester, and how we want to move forward as a new time. I emerged from that hole to a different landscape, as if someone built a city on top of that city. The game itself looked completely different. Ideas that were just that were implemented into the game. There was a very real disconnect between the C++ rewrite team and the rest of the team.

The problem with a hole is that by the time the hole is fully dug, there needs to be more added. We realized that by the time we rewrote the entire game, we would have to rewrite the new features that were implemented  to work with the non- C++ code. And by the time we were finished with that, there would be new things to write. We would always be playing catch up, never fully being caught up to the rest of the team.


LS: Dr. Unreal or: How I Learned to Love the Crash


One of the most annoying parts of transition from Unity development to Unreal development is crashing. In Unity, if a project crashed, someone did something wrong, very wrong. Usually Unity will just throw exceptions and break out of the current function. Unreal on the other hand, seems to not believe in exceptions, and if one is thrown, will straight up crash to desktop. Unreal will even go as far as to not allow try catch statements in C++ code and will not let the code compile. I can see both the pros and cons of the Unreal approach to error handling compared to Unity’s handling.

On the pro side,this ensures that you know when something goes wrong in your game, you know something went wrong. This helps make sure that when your game is packaged into an executable, that it should not ever crash. I know other developers who when they see the red error text in Unity, they just not pay attention to it and just accept it happens. If it doesn’t break the game, then it never gets fixed. When Unreal forces you to crash to desktop, it makes sure that  you know that the error is not good. This might be a good thing to experience in school now since in the game development world there are no exceptions, so making sure to not create any now is a good thing.

However, the downsides to crashing whenever an error is thrown is the frustration factor. When the process of getting back to the point you were at includes having to reopen UE4, hope you saved before you pressed play, and then you can start making changes again. When this happens multiples times in a night, it becomes demoralizing. Spending a few minutes getting back to the spot you just were at and then it crashes within seconds. Thankfully, Unreal provides a stack dump of when it crashed to help you know exactly where things went wrong. However, sometimes it provides no help, as in the feature image of this article. When this happens, you just have to start commenting out recently written code. Which can be a fun process in itself.

Reading from the Hivemind: TwitchPlaysYourGame


Over the past couple of years, there has been a surge in popularity of the Twitch streaming platform and due to this a few interesting phenomenon has happened. One of the largest and most well known ones was “Twitch Plays Pokemon”. The objective of Twitch Plays Pokemon was simple, Twitch-plays-pokemon_(1)beat one of the first Pokemon games via sending input commands through Twitch chat. It seems like a simple task, however, having thousands of people control a single character in a game turns into utter madness very quickly. It was a massive success and has even spawned it’s own category on Twitch. The most popular way to add Twitch Plays functionality to a game usually relied on a very roundabout way to grab input and manipulate the game. An external script to grab IRC input from Twitch and then send those inputs to the game. What I wanted to accomplish with this library is allow the developer to integrate the ability for their game to be played through Twitch without being too intrusive on the development of the game.

One of the first tasks that I had to implement for the library would be the ability to actually connect to Twitch Chat and read the IRC channel. Twitch chat is operated off of basic IRC principles except it uses OAuth authentication. Using a simple Unity Twitch IRC chat reader on GitHub I set up the library to open the IRC stream and read from it. The Library then will run two loops on different threads, reading input and sending pings back to Twitch’s server.The real part that allows for easy integration is the ability to bind commands to functions easily. A developer just needs to call the function that takes in a string and a raw function and will add it to a Dictionary. The thread that parses message input will now keep track of how many times that string command was said. All that needs to be done now is to ask the library for the most said command, tell the library to run that command, and then clear the previously said messages.

Things that I want to add in the future is an event system to the library. Currently, there is no way to know when you are connected/disconnected, when a message arrives or what it’s contents is, and  when other seemingly nice to know things that happen. Allowing a developer to subscribe to message received events would allow for more diverse gameplay and could allow for using a different system than the default and only implemented, “Most Common is the most said” way of doing commands.

What I learned from this is how to interact with IRC Chat on a web socket, and how to think about library development from a perspective of, “The DLL is everything I can use, I can’t just go and make an edit to it.”