Project Details

• Year: 2016
• Role: Designer & Programmer
• Codebase: C#
• Framework: Unity 2D
• Tutorial Link

What is it:

The project is still in progress and began with a tutorial on how to create a Level Editor using Color32 to transcribe pixels in a png image.

What I did:

After the tutorial I decided to extend the functionality to allow players to add in their own png images at any point that will be transcribed into a level. How it works is that all of the colors represent a gameobject that gets spawned in based on the precise color pixels of the png image. For instance, pure black (0,0,0,255) causes grass tiles to be spawned in.

With my extended functionality players can drop the pngs they create in a folder called StreamingAssets and the levels will be interpreted automatically. To get the sequencing of the levels correct, a simple naming convention has been provided, but the files are loaded in alpahnumerically. Additionally, I added enemy AI and player attacking mechanics (in the form of throwing stars because the player is a ninja).

What I learned:

I learned a lot about Color32 and file parsing in Unity. I have used file parsing techniques before in Java and C++ but never had I used it in Unity.

What can still be improved:

There is still tons that can be added and improved, as mentioned the project is still ongoing. The sole purpose is to provide my friends who aren't programmers an outlet to create levels they can share and play without the need to code. The process is still more complex than, say Mario Maker as you need to create the level in paint, Photoshop, Gimp, etc., so it would be great to simplify the process for players.

I would also like to add different types of items, enemies, and platforms that players can have access to create but for now it's pretty simple and has basic platforming mechanics.

Project Details

• Year: 2016
• Role: Designer & Programmer
• Codebase: C++

What is it:

This was a game made in C++ for the console/terminal. The assignment was to create a resource management game based around the concept of triage. In this game, the player has been transferred to a space station populated by clones where a bad case of the space measles has taken hold. The player has been sent a group of doctors in order to treat the illness.

Unfortunately (as is typically the case), the player does not have enough doctors specialized in the treatment of space measles to treat everyone as they walk through the door so he or she must intelligently manage the doctors as the situation demands.

What I did:

This was probably one of the CS projects that I worked on as it spanned the course of half a semester. The game's requirements were:

• Prioritizing patients that way the most critical could be treated first
• Doctor/Patient classes with genetic conditions for the patients, and strengths and weaknesses for the doctors (some doctors were better at treating patients with certain genetic disorders than others)
• Implementing turn based features such as watching patients get better/worse, adding new patients to the list of waiting patients at the end of the turn, etc.
• Adding interesting elements to the game to create differences between the students' projects (modifiying the number of doctors, adjusting rates at which patients arrive, economy system, etc). Which I added a difficulty system that made the game hard or normal depending on the player's selection before the game started
• And lastly creating a test plan that adequately tests all of the functionality of the game

What I learned:

I learned a lot about priority_queues, and how different data structures can be leveraged together to create intricate collections of systems.

What can still be improved:

Just like any other project, there is a lot to be improved. My scoring system created a text file that you had to open to look at the scores from past games, this could have been improved by implementing a way to read the text file into the console so the player wouldn't have to open the file to see the scores.

Project Details

• Year: 2015
• Role: Designer & Programmer
• Codebase: C#
• Framework: Unity 2D
• Video Link

What is it:

The documentation pages are summaries of the game, Prehistoric Panic. The whole document won't be shown but in the full document it presents information regarding the layout, design, sound, budget, etc. This information consists of images, and lists of everything that will appear in the game such as art assets, mechanics, and user interface.

What I did:

The project spanned a semester, with myself focusing on the level design, overall game design, sounds, and the user interface. When the concept build came I served as one of the programmers (later I would continue to program and contribute half of the code that ended up in the release build).

What I learned:

Minimum differentiation: During our initial testing session, the moderator for that session asked a question at the end of the interview with the tester that hadn’t been asked to any of the other testers.

Acceptance and Distance: By learning to accept all feedback, and to distance ourselves from the pride of building the game, we were able to accept feedback we may not have previously. In part, our group not handling our own testing sessions after the first session helped this along.

Become familiar with the testers: When we were first given the testing template, it was stated that we should establish a connection with the tester. We realized quickly how important this was as the testers that we were able to laugh with and felt comfortable with were the ones who gave us better qualitative feedback.

What can still be improved:

Resolution: If we were given more time to work on the game one of the things we would improve upon would be making the game more presentable in a 4:3 layout. There were many different layouts and screen sizes that the game needed to be compatible with.

Additional Level: The new level would consist of new obstacles for the player to jump over and would be a continuous loop until the game ends.

Expand on Stair Mechanics: Given more time, we would work on the transition between levels to add more effects that will enhance gameplay for the player.

Project Details

• Year: 2016
• Role: UX Designer
• Framework: Invision App
• Prototype Link

What is it:

This project is a prototype made up of various wireframes made with draw.io. The idea was created to help game designers keep track of ideas they come up with for games.

What I did:

After creating the use cases, and personas I created wireframes. Once the wireframes were completed and iterated upon, I stitched them together and created an interactive prototype using InvisionApp.

What I learned:

I learned about creating use cases and personas, as well as wireframes and interactive prototypes. The purpose of the project was to teach interactive design from start to finish, which was a very insightful experience as I have never had to do anything like this before.

What can still be improved:

There is defintiely a lot that can still be worked on and improved. For instance, the interactive prototype doesn't have everything interactable. Additionally, some of the screens/states don't seem to logically connect and should be reworked.