About MeI am a graduate from the University of California, Irvine with a B.S. in Computer Game Science. My long term goal is to become a Senior Software Engineer. Before I get there, I am seeking work to begin my career within the industry an associate/junior programmer. The most important thing to me is my team. I want to work for a company where team collaboration, creativity, and growth is at the core of everything.
SKILL LIST
|
WORK EXPERIENCE
Crystal Rescue (2017)
|
|
Release Dates
iOS: September 12th, 2017 |
The Project:
I was contracted with a small independent developer to take one of their existing titles and port it over to Unity. The purpose of porting to Unity was to enable the developer to easily make their game available on more platforms.
My Contribution:
I created all new scripts in almost all aspects because the developer initially had built a custom Android game engine. A good portion of their code could not be used because of this. Example: menus and user interfaces were all handled within their rendering code. A straight port does not work because Unity handles almost all their rendering behind the scenes. With several Unity games in my portfolio, I was able to quickly implement a window system, game manager, effects manager, sound manager, user input, user interfaces, and more in a short amount of time. From there, I was tasked with porting over the core game logic from Java into C#. This was the hardest part of the port as there were many portions of the core game logic which were built around their custom game engine. To faithfully port this over into C# and Unity, I had to fully understand what the code was doing and why to achieve the desired results. In certain situations, such as how the crystals interacted with the player, I was forced to create new solutions to achieve similar results.
My Contribution - Highlights:
The system I feel I implemented exceptionally well was the Window Manager and Level Management System. One of the major problems with the game in its previous engine was its load times. Every time the user would enter a new level, there was a small loading screen, stopping the player from playing as much as possible. My goal was to eliminate all loading after the user had initially booted up the game. I achieved this with the Window Manager and Level Management System.
To solve our problem, the game never leaves the first scene which is initially loaded. Upon loading the first scene, the Level Management System takes all the possible prefabs and catalogs them into dictionaries so they can be indexed as quickly as possible when needed. When this completes, this system disables itself for the time being. Now, the Window Manager simply enables and disables game objects which make up the user interfaces and menus. When a user selects to play a level, the Window Manager enables the in-game UI and the Level Management System. The Level Management System then reads a file associated with that level and instantiates all the prefabs it needs from its various dictionaries. With these two systems working together, players are never bothered with any loading screens.
What I Learned:
The biggest take away from this project was the importance of clearly and effectively articulate your thoughts with others. Since the developer had used a custom game engine from the original iteration, communication was of the utmost importance. I would look at the core game logic and understand it to the best of my abilities. When I would get stuck or did not understand something, it was critical that I ask the right questions so that I may receive the answers I needed. I learned that asking too general of questions does not help progress and only wastes everyone's time. Being able to speak knowledgeably about a system that you did not write helps you understand the program as a whole, correctly identify and fix bugs, and improve when necessary.
I was contracted with a small independent developer to take one of their existing titles and port it over to Unity. The purpose of porting to Unity was to enable the developer to easily make their game available on more platforms.
My Contribution:
I created all new scripts in almost all aspects because the developer initially had built a custom Android game engine. A good portion of their code could not be used because of this. Example: menus and user interfaces were all handled within their rendering code. A straight port does not work because Unity handles almost all their rendering behind the scenes. With several Unity games in my portfolio, I was able to quickly implement a window system, game manager, effects manager, sound manager, user input, user interfaces, and more in a short amount of time. From there, I was tasked with porting over the core game logic from Java into C#. This was the hardest part of the port as there were many portions of the core game logic which were built around their custom game engine. To faithfully port this over into C# and Unity, I had to fully understand what the code was doing and why to achieve the desired results. In certain situations, such as how the crystals interacted with the player, I was forced to create new solutions to achieve similar results.
My Contribution - Highlights:
The system I feel I implemented exceptionally well was the Window Manager and Level Management System. One of the major problems with the game in its previous engine was its load times. Every time the user would enter a new level, there was a small loading screen, stopping the player from playing as much as possible. My goal was to eliminate all loading after the user had initially booted up the game. I achieved this with the Window Manager and Level Management System.
To solve our problem, the game never leaves the first scene which is initially loaded. Upon loading the first scene, the Level Management System takes all the possible prefabs and catalogs them into dictionaries so they can be indexed as quickly as possible when needed. When this completes, this system disables itself for the time being. Now, the Window Manager simply enables and disables game objects which make up the user interfaces and menus. When a user selects to play a level, the Window Manager enables the in-game UI and the Level Management System. The Level Management System then reads a file associated with that level and instantiates all the prefabs it needs from its various dictionaries. With these two systems working together, players are never bothered with any loading screens.
What I Learned:
The biggest take away from this project was the importance of clearly and effectively articulate your thoughts with others. Since the developer had used a custom game engine from the original iteration, communication was of the utmost importance. I would look at the core game logic and understand it to the best of my abilities. When I would get stuck or did not understand something, it was critical that I ask the right questions so that I may receive the answers I needed. I learned that asking too general of questions does not help progress and only wastes everyone's time. Being able to speak knowledgeably about a system that you did not write helps you understand the program as a whole, correctly identify and fix bugs, and improve when necessary.
DOWNLOAD FROM ITUNES
SENIOR CAPSTONE PROJECT
Vector Recoil (2017)
1st Place Winning Game at IEEE GameSIG 2017 Orange County, CA
|
|
DOWNLOAD THE GAME HERE:
The Project:
This project was assigned to senior students as part of the Computer Game Science Capstone class at UC Irvine. We were given complete freedom in what kind of game we wanted to create. So naturally, I pitched a 2-D action platformer where the character cannot jump! Instead, players rely on the recoil from a machine gun like weapon, called "The Persuader", to glide and hover and a shotgun like weapon, called "The Joule", which propels them in the opposite direction the they are aiming. In this world, a money hungry organization has developed a new plague to unleash upon this world, but they have also developed two prototypes which are the only weapons which can destroy them. Create the problem to sell the solution. Evil... I know. Players must use these prototype weapons to overcome treacherous obstacles and eradicate this new virus like weapon called "Vectors."
My team and I set out to create a game we wanted to play for countless hours and I firmly believe we accomplished our goal. We are extremely proud of our work and hope you enjoy, VECTOR RECOIL.
My Contribution:
Since I was the one to pitch the initial idea for the project, I became the team leader. Because of this, I was a part of practically every aspect of the game. However, for the purpose of this section entitled "My Contribution", I would like to focus on the areas I was directly and/or solely responsible for. As a team, we quickly identified this game would need to have top-notch controls. My partner and I worked on player controls for the first four weeks. This may seem like a lot, but this game would not work any other way. We had to consider details such as: how much each shot would move the player, how their running velocity would affect each shot, how quickly falling is neutralized, how changing directions is handled, etc..
Once we felt we had the controls nailed down as best as we could, we adopted the divide and conquer approach to the rest of our work. As a broad overview, here is a list of systems and game features I am exclusively responsible for: game state manager, window manager, save system, main menu scripted events, user interface, in-game HUD, in-game hint system, dynamic cameras, scripted cameras, camera effects (chromatic aberration and screen shake), checkpoints, battle rooms, effects manager, input manager, collision detection (everything in the game), weapon manager, both player and enemy projectiles, animations for both player and enemies (using SpriterPro to create them and writing scripts to use them), player movement manager, sniper and charger enemy actions, and health systems for both player and enemies.
My Contribution - Highlight:
The system I feel I implemented exceptionally well is the Effects Manager. When creating this system, its first purpose was to resolve an issue we were continually having with Unity. Most of the time, if you want a game object to instantiate another game object, you are instructed to have a public game object variable within a script and manually drag the prefab into the slot in the Inspector. The problem arose when we were pulling changes from other team member's computers. The prefab connections would be deleted and we would have to manually drag each prefab to the appropriate game object and script. This became extremely time consuming and frustrating.
To resolve this issue, I created a scriptable object (Unity specific class) as a singleton class with an enum which contains the names of all the effects we have in the game. My original idea was to break these up into several enums, but it did not make a significant enough impact since the game is relatively small. Once the game is initially launched, the Game Manager calls a function call "LoadEffects()" which has a foreach loop run through ever single enum. These enums are used to look into the Resources folder and load the appropriate prefab into a dictionary called m_Map. At this point, other game objects simply had to request an effect from the Effects Manager by passing in the name of one of the enums and the position to instantiate it in world space. This solved our initial problem as effects were no longer the responsibility of the requesting game object. To ensure we have enough flexibility with this system, I also allow game objects to optionally specify an angle or directions to allow for moving and direction dependent effects, such as bullets and impacts. Lastly, the implementation allows for game objects to control the lifetime of the instantiated effect.
After completing this script, adding a new effect was just a matter of importing in the asset into the appropriate folder and adding its name to the enums.
What I Learned:
This was the largest project my team and I have every worked on which took place over the span of six months. Because of our allotted time, I rapidly learned the details make the all the difference, iteration is vital, and, as cheesy as it sounds, believe in the work you are doing.
There is a saying, "When you have done your job right, no one will know you have done anything at all." This was my goal when I would work on anything in the game. I never want the player to take notice to something. It should always feel as if it should be there and it should work that way. I want the player to focus solely on the experience. When we began to pay attention to the smallest of details, our play testers would tell us, "I don't know why, but the game feels really good." These details can make a world of difference and time should be allocated to make ensure the experience is the best it can be.
This game has come a very long way since its initial prototype. In the first week, we had an extremely crude example of what the player would look like using his guns' recoil to traverse the environment. We must have gone through at least 6 iterations of the controls and the "gun physics." We would work then test, work then test. Every time we did this, we could feel the gameplay getting better with every pass. We applied this method to almost everything we touched in game from player controls and player movement to audio effects and level design. This process also helped us determine when something was just not working. We felt we could always do better and iterating allowed us to produce the best work we could.
Lastly, you must believe in the work you are doing. Throughout the development of Vector Recoil, the team and I received less than positive feedback regarding our ideas. From the beginning, we could see what this game would look like and we worked tirelessly to turn our imagination into reality. When we finally showed the game at an event at school, it was very well received where many of our doubters turned into believers. Remaining positive and believing in your choices as a developer was a standout lesson in this development process.
This project was assigned to senior students as part of the Computer Game Science Capstone class at UC Irvine. We were given complete freedom in what kind of game we wanted to create. So naturally, I pitched a 2-D action platformer where the character cannot jump! Instead, players rely on the recoil from a machine gun like weapon, called "The Persuader", to glide and hover and a shotgun like weapon, called "The Joule", which propels them in the opposite direction the they are aiming. In this world, a money hungry organization has developed a new plague to unleash upon this world, but they have also developed two prototypes which are the only weapons which can destroy them. Create the problem to sell the solution. Evil... I know. Players must use these prototype weapons to overcome treacherous obstacles and eradicate this new virus like weapon called "Vectors."
My team and I set out to create a game we wanted to play for countless hours and I firmly believe we accomplished our goal. We are extremely proud of our work and hope you enjoy, VECTOR RECOIL.
My Contribution:
Since I was the one to pitch the initial idea for the project, I became the team leader. Because of this, I was a part of practically every aspect of the game. However, for the purpose of this section entitled "My Contribution", I would like to focus on the areas I was directly and/or solely responsible for. As a team, we quickly identified this game would need to have top-notch controls. My partner and I worked on player controls for the first four weeks. This may seem like a lot, but this game would not work any other way. We had to consider details such as: how much each shot would move the player, how their running velocity would affect each shot, how quickly falling is neutralized, how changing directions is handled, etc..
Once we felt we had the controls nailed down as best as we could, we adopted the divide and conquer approach to the rest of our work. As a broad overview, here is a list of systems and game features I am exclusively responsible for: game state manager, window manager, save system, main menu scripted events, user interface, in-game HUD, in-game hint system, dynamic cameras, scripted cameras, camera effects (chromatic aberration and screen shake), checkpoints, battle rooms, effects manager, input manager, collision detection (everything in the game), weapon manager, both player and enemy projectiles, animations for both player and enemies (using SpriterPro to create them and writing scripts to use them), player movement manager, sniper and charger enemy actions, and health systems for both player and enemies.
My Contribution - Highlight:
The system I feel I implemented exceptionally well is the Effects Manager. When creating this system, its first purpose was to resolve an issue we were continually having with Unity. Most of the time, if you want a game object to instantiate another game object, you are instructed to have a public game object variable within a script and manually drag the prefab into the slot in the Inspector. The problem arose when we were pulling changes from other team member's computers. The prefab connections would be deleted and we would have to manually drag each prefab to the appropriate game object and script. This became extremely time consuming and frustrating.
To resolve this issue, I created a scriptable object (Unity specific class) as a singleton class with an enum which contains the names of all the effects we have in the game. My original idea was to break these up into several enums, but it did not make a significant enough impact since the game is relatively small. Once the game is initially launched, the Game Manager calls a function call "LoadEffects()" which has a foreach loop run through ever single enum. These enums are used to look into the Resources folder and load the appropriate prefab into a dictionary called m_Map. At this point, other game objects simply had to request an effect from the Effects Manager by passing in the name of one of the enums and the position to instantiate it in world space. This solved our initial problem as effects were no longer the responsibility of the requesting game object. To ensure we have enough flexibility with this system, I also allow game objects to optionally specify an angle or directions to allow for moving and direction dependent effects, such as bullets and impacts. Lastly, the implementation allows for game objects to control the lifetime of the instantiated effect.
After completing this script, adding a new effect was just a matter of importing in the asset into the appropriate folder and adding its name to the enums.
What I Learned:
This was the largest project my team and I have every worked on which took place over the span of six months. Because of our allotted time, I rapidly learned the details make the all the difference, iteration is vital, and, as cheesy as it sounds, believe in the work you are doing.
There is a saying, "When you have done your job right, no one will know you have done anything at all." This was my goal when I would work on anything in the game. I never want the player to take notice to something. It should always feel as if it should be there and it should work that way. I want the player to focus solely on the experience. When we began to pay attention to the smallest of details, our play testers would tell us, "I don't know why, but the game feels really good." These details can make a world of difference and time should be allocated to make ensure the experience is the best it can be.
This game has come a very long way since its initial prototype. In the first week, we had an extremely crude example of what the player would look like using his guns' recoil to traverse the environment. We must have gone through at least 6 iterations of the controls and the "gun physics." We would work then test, work then test. Every time we did this, we could feel the gameplay getting better with every pass. We applied this method to almost everything we touched in game from player controls and player movement to audio effects and level design. This process also helped us determine when something was just not working. We felt we could always do better and iterating allowed us to produce the best work we could.
Lastly, you must believe in the work you are doing. Throughout the development of Vector Recoil, the team and I received less than positive feedback regarding our ideas. From the beginning, we could see what this game would look like and we worked tirelessly to turn our imagination into reality. When we finally showed the game at an event at school, it was very well received where many of our doubters turned into believers. Remaining positive and believing in your choices as a developer was a standout lesson in this development process.
Gameplay Footage |
|
- Github Repository: https://github.com/theJeeves/CapstoneProject
MINOR PROJECTS
Super Surfing Volcano Tiki Pong (2016) |
|
The Project:
This originally started out as a school assignment in my 2015 spring quarter at UC Irvine. My partner and I were asked to design a game based on the classic game "Pong" using Scratch, a drag and drop programming website by MIT. We designed the game to be a boss only version of the base game. During the summer of 2016, I decided to remake the game from the ground up using Unity 5 to further hone my programming/game development skills.
My Contribution:
All code found in the Unity version was written and designed by me. The Scratch version is written and designed by me except for the ball acceleration code. I give credit to the original author in the game's credits. In both versions, I was responsible for the following: player controls, user interface, collisions, scripted scenes, camera, animations, the health systems, and more. All aspects of design and art style were created and developed by both my partner and I. All art was created by my partner.
What I Learned:
The biggest lessons came from when I remade the game in Unity 5. Throughout the game, I was having to keep Boolean variables and check on them in Update functions in many of the scripts. While researching how to optimize within Unity, I learned about Delegate and Events. Utilizing this technique enabled me to decouple many of the scripts and reduce the amount of memory the game required. Also I learned using this technique is faster than using Unity's Update function, which meant the game was running faster as well. These were not issues to begin with for a game of this size, however knowing how to leverage these functions will be key in future, larger projects.
This originally started out as a school assignment in my 2015 spring quarter at UC Irvine. My partner and I were asked to design a game based on the classic game "Pong" using Scratch, a drag and drop programming website by MIT. We designed the game to be a boss only version of the base game. During the summer of 2016, I decided to remake the game from the ground up using Unity 5 to further hone my programming/game development skills.
My Contribution:
All code found in the Unity version was written and designed by me. The Scratch version is written and designed by me except for the ball acceleration code. I give credit to the original author in the game's credits. In both versions, I was responsible for the following: player controls, user interface, collisions, scripted scenes, camera, animations, the health systems, and more. All aspects of design and art style were created and developed by both my partner and I. All art was created by my partner.
What I Learned:
The biggest lessons came from when I remade the game in Unity 5. Throughout the game, I was having to keep Boolean variables and check on them in Update functions in many of the scripts. While researching how to optimize within Unity, I learned about Delegate and Events. Utilizing this technique enabled me to decouple many of the scripts and reduce the amount of memory the game required. Also I learned using this technique is faster than using Unity's Update function, which meant the game was running faster as well. These were not issues to begin with for a game of this size, however knowing how to leverage these functions will be key in future, larger projects.
Screenshots |
Play (Scratch Version) |
|
- Download the Unity version HERE or you can play the original Scratch.mit.edu above.
- Github Repository: https://github.com/theJeeves/SSVTP
The Lytic Cycle (2015) |
|
The Project:
While attending U.C. Irvine in the 2015 Spring quarter, my two team members and I were tasked to create a 3-D game in Unity using C# which would help high school students understand a specific academic subject matter. This project set out to teach them about the lytic cycle which is when a virus attaches itself to a cell to replicate itself. The two other members used Blender to create all the models used in the final game.
My Contribution:
I was responsible for almost all the programming in the final game. This included: the user interface, player controls, camera, collisions, animations, the health system and more. As a team, we designed the concept, art style, and game-play.
What I Learned:
This was the first time I had really focused on both player camera and user interface. For both of these, I learned I had to rely on player affordances so the player would know what to do just by looking. For the camera, I accomplished this by using the standard control scheme for most PC games; WSAD to move and the mouse to look around. For the user interface, I learned I had to include not only visible buttons to navigate through the menus, but also keyboard shortcuts which were found in almost all PC games.
While attending U.C. Irvine in the 2015 Spring quarter, my two team members and I were tasked to create a 3-D game in Unity using C# which would help high school students understand a specific academic subject matter. This project set out to teach them about the lytic cycle which is when a virus attaches itself to a cell to replicate itself. The two other members used Blender to create all the models used in the final game.
My Contribution:
I was responsible for almost all the programming in the final game. This included: the user interface, player controls, camera, collisions, animations, the health system and more. As a team, we designed the concept, art style, and game-play.
What I Learned:
This was the first time I had really focused on both player camera and user interface. For both of these, I learned I had to rely on player affordances so the player would know what to do just by looking. For the camera, I accomplished this by using the standard control scheme for most PC games; WSAD to move and the mouse to look around. For the user interface, I learned I had to include not only visible buttons to navigate through the menus, but also keyboard shortcuts which were found in almost all PC games.
- Download the game HERE
Tiny Explorer (2015) |
|
The Project:
While attending U.C. Irvine in the 2015 Winter quarter, my partner and I were tasked with creating a story driven game using Scratch. We had several inspirations when creating this game. We love the Indiana Jones movies and were playing a lot of The Binding of Isaac Rebirth at the time, so this was the child of the two. The game is about an explorer trying to find an ancient artifact to redeem her family's name. Players must avoid death traps, navigate a dungeon like structure, and solve puzzles.
My Contribution:
For this project, I purposely teamed up with an artist because I wanted to up the ante in terms of art and mechanics. All art assets were created by the artist and all scripts were written by me. This included: the room mechanics, player controls, collisions, animations, dialogue, health system, inventory system, and more. This was the second game I had created and it had about 10 times more scripts than my first, totaling at 442. All aspects of design and art direction were developed by my partner and me.
What I Learned:
The thing I am most proud of in this game is the room mechanic. In Scratch, it is not possible to have different "rooms" or "levels", so I developed a way which gives the illusion the character is moving in and out of different rooms. The lesson learned was, as a game developer, you must figure how to implement your designs within the constraints of a platform. Being creative and thinking outside the box is an absolute must.
While attending U.C. Irvine in the 2015 Winter quarter, my partner and I were tasked with creating a story driven game using Scratch. We had several inspirations when creating this game. We love the Indiana Jones movies and were playing a lot of The Binding of Isaac Rebirth at the time, so this was the child of the two. The game is about an explorer trying to find an ancient artifact to redeem her family's name. Players must avoid death traps, navigate a dungeon like structure, and solve puzzles.
My Contribution:
For this project, I purposely teamed up with an artist because I wanted to up the ante in terms of art and mechanics. All art assets were created by the artist and all scripts were written by me. This included: the room mechanics, player controls, collisions, animations, dialogue, health system, inventory system, and more. This was the second game I had created and it had about 10 times more scripts than my first, totaling at 442. All aspects of design and art direction were developed by my partner and me.
What I Learned:
The thing I am most proud of in this game is the room mechanic. In Scratch, it is not possible to have different "rooms" or "levels", so I developed a way which gives the illusion the character is moving in and out of different rooms. The lesson learned was, as a game developer, you must figure how to implement your designs within the constraints of a platform. Being creative and thinking outside the box is an absolute must.
Play |
|