"A Tale of Arms and Ale" is a story-driven RPG in which the player takes on the role of an amateur bartender after their parents’ unexpected retirement.
It was developed over the course of 14 months as part of You can download it here for both PC and Android!
For the duration of my junior year, two close friends and I were elected to run AlphaLab, Columbia College’s game development club. AlphaLab had been around for three years prior, and would traditionally switch out its leadership at the end of each school year.
The club’s main purpose was to help teach the fundamental tools, and skills, new students would need to be successful in their individual fields, and to give them opportunities to put these skills to the test. Alongside holding weekly lectures and workshops, we would schedule several 30-hour game jams throughout the year. Students would sign up a few weeks in advance, and we would ensure that the teams were both balanced and diverse, encouraging students to collaborate with new people each time.
At the end of each jam, every student that participated would have the opportunity to add one new project to their professional portfolio, and a better sense at how to interpret a game’s scope.
The first of many schedules we drafted over the course of the school year, detailing the club’s weekly events over the course of the next two months.
Students hard at work during one of the game jams, after having come up with an idea based on the jam’s theme, and delegating roles.
A panel of upper-classmen judges, hand-picked by AlphaLab leaders, playing the games at the end of the jam.
Two of the three AlphaLab leaders (the third took the picture) at Student Convocation, advertising the club to the doe-eyed freshman that walk by.
Pitchlings is one of the few educational games I’ve had the pleasure of developing. It came into being over the summer of 2016, for the annual Columbia College “Summer Challenge”. A team of talented developers and I were tasked with creating a game that helped young children develop skills in pattern recognition, and a pitch involving music theory was soon drafted.
The gameplay is relatively simple: a chord will be played on the on-screen keyboard, and the player will have to repeat it. The more chords the player gets correct, the closer the island of “pitchlings” (the cute little musical note folks) will get to the lone pitchling, until they’re reunited.
We opted to make the game compatible with a MIDI keyboard as well, to help make gameplay more intuitive, and in hopes that the ability to use a keyboard as a controller would help some of the game’s teachings stick. There were some issues getting everything to work properly, but we managed to fix them by the end.
For more information on the Summer Challenge, click here!
Gram of Thrones is a competitive bake-off in which both teams are tasked in baking as many cakes as they can for their grandmother, before the time runs out. This is the result of one of the many AlphaLab-run game jams I participated in at Columbia College, during my tenure as President.
Typically during an Alpha Lab game jam, each team would be headed by one of the leaders to ensure there would be someone available to extinguish any “fires” in the development process. However, since this particular game jam happened later in the year, our members had grown more confident in their individual abilities, and I was able to focus more on my role as lead programmer.
To play the game, visit the college’s Itch.io!
This particular game was one I developed as a sophomore, over the course of a nine-day course, titled “Indie Game Sprint”. As the class’ name suggests, the enrolled students were charged with developing a single game over the course of a short sprint, to better come to terms with the task of scoping games.
I paired up with two close friends of mine- one and artist, and the other a composer- and together, we decided to create a competitive towing game. At the time, my programming skills were much weaker than they are now, and being the only designer/programmer on the team didn’t help; but the challenge appealed to me, and I decided to give it a shot.
Over the course of that class, I taught myself a great deal about the Unity API (which the game’s systems relied heavily on) and programming etiquette, that I’d butchered far too often beforehand. The final result, thanks to the efforts of the three of us, turned out better than expected, and we were proud to have a playable game to show for it.
The game has a few kinks in the system still, but can be played here, on itch.io!
Happy Heist was developed over the course of nine days, by a small team of five. The concept stemmed from our desire to create an asymmetrical multiplayer game, in which one player would play against several. One of my teammates was hoping to utilize the game’s cameras in an interesting way, and from that point, it didn’t take us long to land on the pitch of a museum security guard, surveilling a heist in real-time.
At the beginning of the game, Player 1 is presented with four security cameras- each one displaying a different corner of the museum. Immediately, the location is populated with anywhere from 20-30 different characters, who begin touring the museum at their leisure. Unfortunately, some of these characters will turn out to be thieves. The game can be played with as few as two players, to as many as five, scaling up in difficulty depending on the number of thieves. The more mustachioed men the security guard has to keep track of, the more loot is required of them to steal, before they can succeed. In order to trick the security guard and make off with their loot, the thief players must try and mimic the movements of the AI characters and hide amongst crowds, waiting until the optimal point to snag a precious artifact.
At any point during the game, the security guard can execute a “lockdown”, forcibly stopping the movement of all in-game characters for a short amount of time. During the lockdown, the security guard can hover over any of the characters on-screen and select them with a cross-hairs. If they’ve selected a thief, that player is removed from the game, and play continues (unless no thieves remain). If the security guard is incorrect, however, they get a strike. If the security guard accumulates three strikes, or the thieves steal enough loot, the game’s over, and the thieves win.
As one of the game’s two programmers, I had to be thoughtful about how we would delegate tasks; I didn’t want to be stepping on the toes of my teammate. We eventually were able to divvy up the various game’s systems for us to work on, one of which was scripting the museum-goers’ AI. I opted to give it a whirl, despite the fact that I’d never programmed even basic AI before. It proved to be a much greater challenge than I’d thought, not just because of my unfamiliarity with the task at hand, but because I had to make sure the NPCs would behave normally enough to be believable as human players. Towards the end of the project, I managed to create AI that did just that… for about 30-45 seconds. After that point, NPCs would start behaving erratically, often running in circles for the rest of the game. Although it wasn’t exactly what we’d envisioned for the game’s NPCs, it was pretty amusing.
The game’s up on itch.io if you’re interested in playing it, despite its shortcomings. I’d love to hear feedback, and would even love to revisit the project one day, with a fresh set of eyes.
