Beat Em’ Down (Unreal C++)

Late in 2016, having spent close to 3 years working on the Unity engine, I decided to branch out and try something new. In September I met with the Video Game Development club at UC Irvine to sign up for a game using the Unreal Engine hoping to get more experience with C++. Enter Beat em’ Down.

Beat em’ Down is a beat em’ up game, much in the style of the Streets of Rage and the Final Fight games for the Sega Genesis and Super Nintendo.

Unlike any game I had worked on previously, Beat em’ Down has involved a lot more development with developing the artificial intelligence. Where in previous titles I had mostly worked with a “follower” AI, this game involved helping create a more complex state machine system, to more easily prototype and develop enemies that the character would encounter.

We also are working on enhancing collision physics in the game. Instead of simply going for a basic collision box, where instead of the player being hit based on a single damage value through a collision box, the character has defense and resistance stats. Furthermore, the damage can be changed based off of states the player character is in and what angle of attack the player is approaching the enemy with.

Overall, while I think the Unreal engine isn’t as refined as the Unity engine is with regards to 2D, it has still remained an interesting challenge getting used to the new technology and game design.

Advertisement

Overwatch Sounds (Lua Mod)

When I was a kid, I spent a lot of my spare time playing World of Warcraft. I also spent a lot of time toying around with different addons, excitedly looking for new ways the modding community had tried to enhance the game’s UI.

One of my favorites was one named Shao Khan FTW. With this mod, specific actions in the game would trigger sound files from the original Mortal Kombat to play. Such as the “FINISH HIM” line when an enemy would reach 20% health.

It wasn’t until later when I decided to try and play around with the Wow API and develop my own version of this mod, instead using Overwatch sound files. It’s the same concept as the original Shao Khan FTW mod, but with a little bit of added detail. For example, I hooked more specific code calls to different spell IDs to be able to play sound files when a player uses a certain spell. For example, playing Reaper’s “Death Walks among you!” when a Death Knight begins summoning ghouls using Army of the Dead. Or Soldier 76’s “I’ve got you in my sights” when a Hunter casts Hunter’s Mark

Video Game Development Club @ UCI

In September 2015, I was fortunate enough to be able to join the Video Game Development Club at UCI, despite being an alumnus. I was hoping that by joining the club, I would gain experience using Unity that I would have otherwise missed in my personal projects and even professional life. In addition, I was hoping to get team experience working on a game with other people who shared my passion, and most importantly, to have fun!

The project I am currently working on with a group of students is called Soulstealer. Essentially, it is a fantasy card game based off the Mega Man Battle Network series. The player can walk around an overworld as normal, but when they enter combat it is a completely different scenario. The player spawns on a the friendly half of a grid (usually 3 x 6), while their enemies (or bosses) spawn on the unfriendly side. Before the match, the player can choose their deck based off of cards they have collected by playing through the game. Each turn, they choose 5 cards to put into their “battle queue”, and resume combat. At any time, the player can trigger the next card, which can do damage, debuffing or buffing depending on the way the card interacts with the grid. For example, the player can either play an AOE debuff for all enemies on the grid, or play a lightning bolt that arcs straight down the middle, and more.

Overall, I’m pleased with the experience I have had with the team. The game is progressing along nicely, and I am learning more not just from a development standpoint, but also design and team management perspective. Most importantly, I am having fun working on a project that every member is passionate about. We all like developing games!

Dungeon Smasher

Github

Dungeon Smasher is a 2D top down semi-procedurally generated Dungeon Crawler and collection game that I began on my own using Unity 2D in February 2015.

For Dungeon Smasher, I wanted to be able to make an exploration game without having to spend a lot of time designing levels and, in addition, allow the player to collect more gems by utilizing randomization. To do this, I needed to focus on and more effectively utilize the power of prefabs in Unity, which would allow me to make the game easier to edit, easier to add to, and easier to remove.

In dungeon smasher, the player is collecting gems in a series of rooms. The player is always in a room with four exits. Using these exits, the player can move to a similar room and collect more gems. The object of the game is to collect as many gems and collectibles as the player can before they are killed by demons, who all have a chance to spawn in each room when the player enters it. Each room is similar in that it has a decorations, gems, and demons, but each room is different in its presentation both empirically and how the user enters the room. Each time may be different- more or less hazardous- all depending on the roll of the dice

Mario AI

Mario Learning AI

Github Link

Video link

Mario AI is a group project I worked on for the project course CS 175: Project in Artificial Intelligence during the Fall 2013 quarter at UC Irvine.

While deciding possible group projects, a group of us suggested we work on a AI platformer that would be able to make its way through the level, having been inspired by seeing this video while taking the introductory Artificial Intelligence course.

When the game starts, Mario processes the environment around him. The system is given everything that is in a surrounding 40×40 grid, with Mario at the center. Classes implementing the IEnvironmentProcessor interface, such as our main processor, EnvironmentProcessor, iterate through each row and column starting from the left edge of the grid through to the right. EnvironmentProcessor does this three times as it processes for three different types of sprites (the iterations are defined in Table 1). The first iteration looks for enemies, and for each enemy, records information about it. Most values are saved as booleans in order to accommodate the neural network. The enemy values are recorded as follows: relativex, relativey, canStomp, canFireball, dropsShell, isFlying, score, and isPiranaPlant. Each coordinate position is relative to where Mario is positioned.
The second iteration focuses on bonus or goal items and records the following information: pointvalue, relativex, relativey, and canMove. The third iteration searches for environment pieces, anything Mario can break or walk on. For each of these features, the program records the following values: canbebroken, candisappear, relativex, relativey, and canproduceitem. These denote how Mario can interact with the objects and from that, what course Mario should take. This process outputs an array of float values that the neural network processes to further decide what to do.

The decision-making logic of Mario is done by a neural network. The output of the environment processor serves as the input for the neural network. The output of the neural network consists of six booleans which map to corresponding values that make up Mario’s actions (up, down, left, right, jump and speed buttons). As Mario runs through a level, for each game tick the following happens: 1) the environment processor generates an array of values representing Mario’s interpretation of his surroundings at that tick and 2) the array is passed through the neural network to determine Mario’s action for that tick. This process is repeated until Mario’s run on the level is complete, either by death, victory, or time running out.
The implementation of the neural network provides methods to set and get an array of all of the weights that are contained in the neural network. This array representation of the neural network (given that the size of the neural network remains the same) enables us to use a genetic algorithm to let Mario learn what weights for the neural network lead to a higher score.

The program uses a genetic algorithm to gather the best runs and weights from the neural network. For each generation, it runs through the level a set number of times (determined by the main method), configurable in the java file. The score for a given run is computed by the computeWeightedScore() method, provided by the Mario AI Coding Competition engine. The genetic algorithm gathers the top scores and creates the next generation of weights based on these collected scores. What weights helped produce the top scores of the previous run are inherited into the next run. From there, the AI determines what moves to make based on scores gathered by said weights. The game runs through another configurable number of generations before running the Mario program.
The genetic algorithm itself runs similar to how it is outlined in the Russel and Norvig book, where each “chromosome” is defined as a set of weights which are computed by the neural network. The algorithm creates descendents by taking two chromosomes as input, picking a random pivot point located between 0 and the length of the chromosome, and then swapping values of each chromosome at the pivot point and beyond until the result is the same length of the chromosome.
A mutation is defined as a random chance to mutate one of the weighted values within the chromosome. We set the chance to mutate as 1 in 10 (10% chance of mutation). Upon iterating through the entire chromosome, the AI randomly generates a value between 1 and 100 on each weight. If the value is between 1 and 10 the value mutates, if not, it does not. If the value is chosen to be mutated, a new value is computed that is the weight value multiplied by 0.1 (10%). The AI generates a random value between 0 and 2. On a 0, the new value is decremented from the weight value, and on a 1 it is added.
A Genetic Manager class helps keep track of all agents used, storing their final score and weights at the end of their runs. Statistics such as the highest, lowest, and average scores of a generation are made available through here, in addition to the highest scoring agent across all generations. When a new generation is to be created, a pool of agents is created by tournament selection, and 2 agents from that pool are selected at random to determine the next generation of agents. This is done by sending their weights to the genetic algorithm to create a new child.

I had a lot of fun building this project with my group, I was fortunate enough to be in a group with people who knew more about machine learning topics (an area in artificial intelligence I was fascinated about) and was able to learn much more than I had already known about more areas of AI. Unfortunately, through several attempts at optimization we were unable to make the AI finish the level, as we had hit a plateu around 3/4 of the way through a level, and due to severe time constraints within which we were required to finish the project it remains as such. We can say, however, that it accomplished its goal and that the AI does learn. Through more training generations it allows itself to get farther and farther through the level. So in that respect I can say the project was a success. AI is an incredibly difficult subject, as we had learned deeper into the project we got, and I can say I’m proud of the team for accomplishing what we did

Mobile

Professionally

Professionally, I worked with iOS and Android during my time on the mobile team at Kofax, working on the Kofax Mobile SDK. While I was there, I contributed to both the iOS and Android versions of the SDK, writing demo and test applications for the team to use using Objective C, Cocoa Touch, as well as Java and the Android API. Additionally, I pushed the mobile team from testing the SDK entirely manually, to using automation using the XCTest and JUnit frameworks.

Personally

I have been working personally with iOS and Android since I was in college, from simple little games to utility applications to use when my friends were playing Dungeons and Dragons. You can find github links and descriptions to these projects below:

Rod of Wonder

Rod of Wonder is an application I created purely in Objective C on iOS/Cocoa Touch during the Fall of 2014.

Rod of Wonder is a simple application with a hilarious backstory. As a fan of D&D, I get together and play many tabletop RPGs with my friends from time to time. One of these includes Dungeon World, which I can describe as a simplified version of Dungeons & Dragons. Here, we came across an item known as the “Rod of Wonder”. Which, put simply, can generate any random effect when the player uses it.

Now, as there are literally thousands of possible combinations of effects from this item, it often took several minutes for the DM to be able to find an effect to use. As any sane programmer would do, I decided to automate this task.

The app itself simply parses a text file and generates a random line of text from the file to display on the screen in a small animation. Simple, but incredibly useful and time-saving.

EDM Droid

Github Link

EDM Droid is a project I completed for Informatics 133: User Interaction software as a final during the Fall 2013 quarter.

The project description itself was fairly simple. We had one task: make the application play different sounds using the accelerometer. The bare minimum was 5 sounds, but I had a different idea. As a fan of electronic music, I have had a lot of fun in the past working with launchpads, I decided to put my own spin on them using the Android accelerometer. End result: endless fun making a simple mix simply using gestures on your phone.

Spam Filter

Spam filter was an idea that came to me while trying to clean out an old Yahoo email account that I wanted to delete. As I was just beginning development on Pop The Bubbles, the idea immediately came to me that it would be really fun to do a visual representation of a spam filter, where the user controls an electronic representation of a “shredder” to represent the filter. There are rewards for shredding the correct types of emails, and penalties, of course, for shredding non-spam or really important emails (i.e. Bills).

Pop The Bubbles (Android)

Github Link

Pop The Bubbles in Android was my first Android project. The object of the game is to pop bubbles. Bubbles, of course, have different colors and will offer different point values depending on that color, which leaves the user to choose which they will prioritize before the bubbles reach the bottom and pop. The game is just a simple design I could base the application on while I learned how activities, views, and XML worked in the context of Android applications. A few new implementations were added, including an options activity which allows the user to choose how often bubbles spawn, as well as a score-saving system, which records the player’s score when the back button is pushed, and asked the player when they return whether or not they would like to continue with that score.

Outbreak

Github

Gameplay Footage

Outbreak is a 2D sidescrolling game I created during CS 113: Project in Computer Games, during the Winter 2014 quarter at UCI.

The game is simple: kill as many zombies as you can before you get hit too much. It’s not a very original concept, but we thought that for a game where many of us were using Unity 2D for the very first time it would be a nice introduction to making games on that engine. And in any case, who doesn’t like killing hordes of zombies?!

The final version of the game featured four different maps with different zombie spawning points. The zombies spawn endlessly in about 30 second cycles. Each level also feature spawning points for loot crates, which have a chance to drop a new power up, such as jet pack or invincibility, or a new weapon, such as a machine gun or a rocket launcher.

The graphics aren’t the best 2D sidescroller graphics I’ve seen, but with a team of four dedicated programmers, there wasn’t much we could do but try our best. The most important part is that we all thought it was fun to play (albeit a little challenging), and that it was incredibly fun to make.