itskuo

From 2003 to 2012, I worked in the videogames industry as a Game Designer, Level Designer, and Technical Scripter. Then in mid 2012, I decided to acquire some mobile development experience and worked as a Software Engineer on many gamification prototypes and web applications. From 2017 on, I've been working on a multiplayer online project as a Senior Designer. During my time in the videogames industry, I was also a Scrum Master for 2 years and am very comfortable with Agile Development methodologies. The strike teams that I have led range from as little as 3 designers to 10 developers across multiple discliplines. I am now looking for new opportunities and hope to find a great organization to join.

Education: B.S. Degree with a Major in Computer Science and a Minor in Digital Arts from the University of California, Irvine

Location: Orange County, CA

Skills: Experience with Unreal Editor 4 (Blueprint & UMG), Unity3D, 3D Studio Max, XSI, Maya, LUA, OpenGL, C++, Java, Python, Eclipse, Android, Photoshop/GIMP, MS Office/Excel/Visio, HTML/CSS/JS, JIRA/Confluence, SCRUM (Agile Development), Linux, Meteor/React.js

Platforms developed for: PC, PS2, PS3, PSP, PSN, Xbox, Xbox 360, XBLA, Android

Over the course of my career, I have shipped 5 game titles from Concept to BETA on various platforms. One project made it all the way to a playable demo at E3 before getting cancelled months later. I have also worked on numerous proof of concepts, prototypes, and cancelled projects.

UNANNOUNCED PROJECT (2020)

Genre: 3rd person melee PVP

Publisher: Nexon America

Platforms: PC, XBox One, PS4

Battleship (2012)

Genre: FPS

Publisher: Activision

Platforms: Xbox 360, PS3

MicroBot (2010)

Genre: Arcade Shooter

Publisher: EA

Platforms: XBLA, PSN

Transformers: Revenge of the Fallen (2009)

Genre: Arcade shooter

Publisher: Activision

Platforms: PSP

Lord of the Rings: Conquest (2009)

Genre: 3rd person brawler

Publisher: EA

Platforms: Xbox 360, PS3, PC

Turning Point: Fall of Liberty (2008)

Genre: FPS

Publisher: Codemasters

Platforms: Xbox 360, PS3, PC

Taxi Driver (2005)

Genre: 3rd person open world action

Publisher: Majesco

Platforms: Xbox, PS2, PC

Cancelled Summer of 2020 for Xbox One, PS4, and PC

Our unannounced project dealt with 3rd person melee PVP combat using a variety of weapons and attacks. Combat was hard hitting yet agile with a lot of risk reward tactics to consider in engagements. A progression system that allowed for player customization and expression as well as the ability to earn configurable combat bonuses provided an out of match chase for players.

+ Worked primarily on melee weapon animation timing, attack combinations, corresponding hit reactions, and transitions

+ Prototype early weapons and combat items (consumed equipment that aided fighting)

+ Balanced combat values like stamina, attack speed, damage, impact strength, etc

+ Implemented and tuned VFX on corresponding combat attacks and impacts

+ Led strike teams that focused on smaller gameplay based features

+ Presented progress, retrospectives, and future plans of action during team meetings

+ Wrote design documention, gathered work estimates from various departments, and conducted kick-off meetings for implementation

+ Proctored weekly team-wide playtests

+ Source Control: Perforce

+ Documentation: Confluence

+ Bug Tracking: JIRA

+ Development Tools: UE4

+ Created gray box maps to test multiplayer modes

+ Set up developer facing test maps to help facilate testing and debugging

+ Used Blueprint to prototype early progression systems, primitive input to combat mapping, and basic AI behavior trees

+ Prototyped combat damage logging, enemy radar indicators, and equipment purchasing interfaces

+ Assisted in the set up of a crowd reaction system that would play a specific client-side audio event and crowd animation based on a combat event occuring

+ Utilized UMG to mock-up functional prototypes for our front end menus

+ Provided HUD elements to help prove out customization, game settings, and match flow

Detailed Breakdown Of Work

The nature of working on a smaller team required me to wear multiple hats. Although I was brought on for my UE and combat experience, I would go to where I was needed. I found myself working on combat, systems, HUD, QA, and administrative tasks that come with leading strike teams.

Combat design usually started on paper and spreadsheets. It was a very collaborative process to determine the gameplay identities we wanted to provide for a specific weapon. At times, I would work specifically on a single weapon to polish it. Other times, I would help work on an aspect such as VFX that would apply to all our weapons. As the project developed and we had more Engineering time poured into our combat systems, my work shifted from Blueprints to Data Asset implementation and balancing.

Our combat touched and influenced other systems on our project and we would work together to ensure one thing didn't break another.

Coordination with our Animation Team was vital to ensure proper hand off of assets so that combat polish and timing was locked down before our animators had their chance to improve the visual fidelity.

Being a Feature Lead usually meant being the point of contact when it came to the assigned feature I was in charge of. I worked with small subset of our team to progress and prove out gameplay features. It starts with me doing the due diligence to gather the design documentation, technical specifications, and time estimates. Next I present the information to our stake holders and directors to get buy-in, address concerns, and verify a plan of action. During the course of a feature development, it was also my responsibility to alert the team before a playtest, provide a retrospective after an Agile Sprint, and to assist in Sprint Planning. At a given milestone, I could be leading upwards to 5 features simultaneously.

Our culture was playtest heavy and every Friday if we had a stable build, we would conduct a team-wide playtest. I would rally the team and detail the goal of the playtest and what to expect. While the team played the game, I walked the office to answer questions, help keep our matches moving, and to encourage feedback or bug reports.

Sometimes I would act like a pseudo-producer by constantly watching the JIRA boards to ensure a teammember wasn't overloaded, blocked, or potentially stepping on each other's toes. I combed the backlog frequently and tried to keep my strike team's board clean and accurate.

While our core Art Team focused on our production map, I would help develop a lot of test maps that helped up find the fun for various ideas. These test maps would range from completely graybox with simple primitives, maps with animated hazards or specific triggered events, and even spaces that had primitive AI. Some of the level design I worked on was meant for alternate game modes that were being considered.

Sometimes we needed something less complicated than our production map, but also something that was a little more accurate than a blank level. Working with our Environment Team, I helped spearhead the creation of a developer focused map that would contain special areas to test specific features, provide examples of our world metrics, and allow rapid tests of navigation actions. I also created a small map that allowed the Combat Team to jump in over network for smaller focused testing and debugging. It was light weight, performant, and convenient.

Before we had a core combat system, we relied on my Blueprint hacks that used logic branching to determine what kind of an attack to perform given an input. Our project also evolved from having to purchase equipment from an in world vendor which was also prototyped by myself with Blueprint to a more UI and UMG heavy approach. I used Blueprint functions on our Attack components to track information so that a combat log could be displayed which was a very useful developer facing tool to verify damage and its proper source. The multiplayer aspect of the project meant that we would need some tool to indicate other offscreen enemies to the player and for that I mocked up a radar with Designer art render on the HUD to show the relative locations of potential surrounding threats.

Working with a Gameplay Engineer, Sound Engineer, and a Technical Artist; I helped develop a Crowd Reaction system that would invoke specific Audio and Animation events based on Combat Events. This involved tagging specific actions like a thrown weapon and using Blueprint logic to determine what to trigger for a player's client.

I was assigned to a strike team that handled front end UI, out of combat match systems, and maintained a secondary game mode. Working with a UI Engineer and a UX Designer, I quickly ramped up on UMG to allow myself to create prototypes that could function for our playtests. This mock-up HUD gave us a tangible way to test progression systems like unlocked purchaseable goods, skill talents, and cosmetics.

Quickly standing up the front end using Blueprint and UMG also allowed us to rapidly iterate on multiple versions to improve the UX of starting the game client, gearing up for a match, and returning back from a match to manage or view results. We were also fortunate enough to get some game settings working to allow things like keybindings or sensitivy changes.

Released on May 15, 2012 for Xbox 360, PS3

Battleship was a FPS game with low level RTS elements. The player controlled a soldier of the US Navy fighting an unknown Alien force. One of the player's tool is the ability to coordinate Naval Ships to attack Alien Ships or provide support on the ground battle via an interface loosely based off of the Battleship Boardgame grid system of gameplay.

+ Worked primarily on gameplay elements

+ Supported level designers

+ Balanced player and AI gameplay values like health, attack, weapons, spawn rate, etc

+ Brainstormed support abilities for the Naval Ships, AI enemy archetypes, and weapons

+ Implemented and tuned the values affecting the player and AI gameplay

+ Connected the localization of text for FIGS (French, Italian, German, Spanish)

+ Filled out the personnel data for the end game credits

+ Particpated in extensive level testing

+ Development Tools: Proprietary Editor and C++

+ Source Control: Perforce

+ Bug Tracking: DevTrak

+ Provide support to level designers

+ Added cinematic animations to level events

+ Connected Voice Over (VO) audio files to game assets

+ Set up the AI Naval battle scenarios

+ Staged and implemented friendly AI in various levels

+ Supported the level designer by providing special gameplay value tuning for distinct or important enemy AI

+ Added cinematic moments during boss battles

+ Connected relevant story related VO

Detailed Breakdown Of Work

My supervisor and I worked on the implementation of various gameplay features while providing support to the Level Designers and their single player missions. I also volunteered to help out production in various tasks towards the end of the project.

We had dedicated level designers assigned to sets of levels for core gameplay, objectives, and mission direction. My role was more support and included adding cinematic animations to events, connecting Voice Over, and setting up the AI Naval battle scenarios. I also staged some friendly AI in various levels to try and give the feel that the player wasn't alone in their battle.

Boss battles ranged from a larger deadlier Alien mothership to holding a position from waves of enemy AI. I helped support the level designer by providing special gameplay value tuning for distinct or important enemy AI, adding cinematic moments, and connecting story related VO.

Towards and during BETA, I was responsible for connecting the localization of text for FIGS (French, Italian, German, Spanish), filling out the end credits, and extensive level testing in addition to my daily design tasks.

Released on December 29, 2010 for XBLA, PSN

MicroBot was an arcade shooter with cooperative multi-player and lots of customizable parts for the players' ships.

+ Developed the story-based levels

+ Designed enemy encounters

+ Implemented game-play features

+ Examined other XBLA arcade shooters for inspiration

+ Development Tools: NIMBUS - a proprietary editor and visual scripting language (very similar to the Unreal Editor)

+ Source Control: Tortoise SVN

+ Bug Tracking: Mantis

+ Designed single player levels as a mix of combat oriented, puzzles, story-related, and timing game-play rooms

+ Created levels in the editor, placed enemies and pick-ups, and set up scripted events

+ Planned for co-op which used existing single player levels

+ Set up scripting that would detect co-op mode and adjust the difficulty accordingly

+ Provided scripting and testing support to the development of our boss battles

Detailed Breakdown Of Work

I worked with the Lead Designer to help develop the story-based levels, enemy encounters, and game-play features that we would need for the game. We looked to other XBLA arcade shooters for inspiration.

Development Tools: NIMBUS - a proprietary editor and visual scripting language (very similar to the Unreal Editor)

Source Control: Tortoise SVN

Bug Tracking: Mantis

Text Popups - The game's text was defined in a text file and the proprietary scripting language was used to display them.

Pick Ups - The editor allowed me to spawn pick ups like weapon upgrades, health, currency, etc.

AI Creation - In the editor I would place a spawner and set its attributes. It would then spawn enemies automatically or triggered through script.

Weapons - I helped tune the weapon attributes using the editor for the player as well as the enemies.

Cut Scenes - The editor allowed me to place cameras in the level and perform camera cuts through script.

Sounds - I helped assign sound effects using the editor and some script calls.

I would consult the GDD for general descriptions of the kind of levels that I needed to create. Most levels dealt with combat, some were story related, and a few involved puzzles or timing game-play elements.

The Art department would provide us with a library of basic pieces that we could connect together in the editor create a basic layout. This allowed us to ensure that the scope was appropriate and that each level would provide a suitable amount of game time.

I would place enemy spawners in the room depending on whether it was combat intensive or more of an exploratory room. Depending on how far in the game that the level was encountered, I would specifically spawn an enemy type or adjust the amount encountered.

Through repeated play tests or when receiving new assets from Art, I would go through the levels to update or fix issues as necessary. I would also play using various weapon configurations to determine if the difficulty felt appropriate and to check for bugs related to weapons, enemies, or combat.

We would received bugs in Mantis and fix them according to their priority as determined by our lead. We had some tester help, but the majority of bug reporting came from developers taking some time to play through the game and report any issues.

The game allowed for cooperative play so I set up the script for levels to take that into account when ramping up difficulty. I had to make sure that the levels I worked on would function properly in single player mode or co-op. I also helped play test co-op with a fellow designer to find bugs and determine appropriate difficulty scaling.

The boss battles were brained stormed by the design team and tried to take into account the features available by our tools and our remaining schedule if additional functionality was needed. I helped create a basic layout and scripted pass at a boss battle for the purposes of testing the scope and game-play.

We had a game designer focus on the boss battles. I assisted this designer in scripting the encounter and troubleshooting the issues.

Released on June 23, 2009 for PSP

Transformers: Revenge of the Fallen (PSP) was a top down arcade shooter. The player played as both Autobots and Decepticons in Single Player or Multiplayer missions.

+ Developed the systems and functionality for the game

+ Used other arcade shooters for inspiration and research

+ Tailored story and plot elements to be in line with the film

+ Development Tools: 3DS Max, LUA script, and a proprietary editor (SAVEd - Savage editor)

+ Source Control: Tortoise SVN

+ Bug Tracking: Devtrak

+ Worked on 4 mission types (Rescue, Escort, Rail, Boss Battle)

+ Wrote level design documents and provided photos for art reference

+ Designed levels as strictly linear with backtracking unallowed

+ Focused more on enemy waves, difficulty, and environment destruction

+ Shuffled around as needed to work on multiple single player levels

+ Primarily worked on missions located in the North Atlantic NEST base and US locations

+ Provided support for the design of the multiplayer maps

+ Participated in test runs and provided balance feedback

+ Hand scripted all of the boss battles for the game in LUA

+ Modelling traditional arcade shooters, the bosses were created to behave in a predictable pattern

+ Designed battles to allow the player to exploit their weaknesses to defeat them

+ Worked on their AI behaviors, camera cuts, dialog/SFX syncing, and special weapons

Detailed Breakdown Of Work

I worked with the Lead Designer to help develop the systems and functionality we would need for the game. We looked to other arcade shooters for inspiration and research in developing this PSP title. As this game was loosely based on the film, much of the story and plot was predetermined.

Development Tools: 3DS Max, LUA script, and a proprietary editor (SAVEd - Savage editor)

Source Control: Tortoise SVN

Bug Tracking: Devtrak

Text Popups - The game's text was defined in an Excel file and LUA was used to display them.

Pick Ups - The editor allowed me to spawn pick ups like weapon upgrades, health, shields, etc.

AI Creation - In the editor I would place a spawner and set its attributes. It would then spawn enemies by player proximity or by a function call in LUA.

AI Paths - A tool in the editor allowed me to specify all areas in a level that the AI could navigate to.

Weapons - I created and tuned the weapon attributes using the editor.

Cut Scenes - The editor allowed me to place cameras in the level while LUA functions enable me to do camera cuts.

Sounds - I helped assign sound effects, music, and voice over using the editor and some LUA callbacks.

Using MS Word and Google for reference photos, I would create basic level design documents for our basic, rail, and boss battle levels. The levels usually had a game type theme to them such as escorting a friendly unit, rescuing a friendly unit, destroying key objects, or racing against time.

Art would provide us with a library of basic pieces that we could connect together in 3DS Max to create a basic layout. This allowed us to ensure that the scope was appropriate and that each level would provide a suitable amount of game time. A majority of our mock ups just had street pieces and some buildings to aid navigation.

While art constantly updated the levels' terrain and objects, the designer's job was to create the AI enemies and triggered events. Using the proprietary editor, we placed triggers and spawn locations for all the levels. Then using LUA script, we linked triggers to functions that would enable a spawner so that when the player entered a particular area there would be enemies waiting or arriving. We had a couple of varieties of enemies and weapons so we tried to space them apart so that the player would encounter easy and simple AI early on. As the game progressed, the types and amounts of enemies would ramp up to keep the difficulty at an appropriate level. Below is a paraphrased example of my LUA script for AI spawning:

// This function is called on level start up

function on_level_startup( )

tf2.register_triggers( ENTER, first_trg, "first_trigger_entered" ); // This tells what function to call when the 1st trigger is entered

end

// This function is called when the player passes through the 1st enemy trigger in the NEST base

function first_trigger_entered( )

// This activates the spawner placed in the editor

game.object_trigger( enemy_spawner01, "Enable" );

// This tells HUD to display some text on the screen

game.hud_set( mainHUD, "Watch_Out_txt" );

game.hud_trigger( mainHUD, "Enable" );

end

As we zeroed in on our memory budget for levels, I would add or subtract objects that could be destroyed in the level. I would also place power ups throughout the level to aid the player. Enemy wave amounts and timing were adjusted to provide a consistent amount of action across the level. I did repeated passes on levels to optimize performance, fine tune the difficulty, and integrate newly created enemy types or weapons.

I would track all single player level bugs through Devtrak and fix them depending on their priority as determined by my lead.

I only had a support role for the design of the multiplayer maps. I mostly helped test them.

The boss battles were largely designed by another designer. However, I worked with him to make sure that I would be able to implement the functionality and behaviors desired. We made adjustments depending on what functionality would be available from the programmers.

The bosses need to follow a predictable movement and attack pattern so no real AI was used. Instead I hand scripted their behavior and created a simple finite state machine in LUA.

The LUA files would grow very large so I need to be very good about documenting my script so that I didn't get lost in it. I would make multiple scripting passes working on each boss stage at a time. There would typically be three distinct boss modes that needed to be implemented. The boss enters a mode depending on how much damage it has sustained. I worked on the boss battle for Bumblebee, Ironhide, Optimus Prime, Megatron, Starscream, Demolishor, Devastator, and The Fallen.

The following is a paraphrased example of the LUA scripting I did for a boss:

// This function is the boss' stage one attack loop

function boss_stage_one_loop( )

// The following checks to see if the boss needs to advance a stage

if ( boss_health > .7 ) then boss_stage_two_start( ); end

// The following chooses a random attack to use

attack_number = rand(1,3); // Pick a random number from 1 to 3

if (attack_number == 1) then fire_gun( ); elseif (attack_number == 2) then fire_missiles( ); else melee_attack( ); end

// The following uses a timer to loop the function

game.time_set( 10, boss_stage_one_loop ); // After 10 seconds, loop this function

end

We had QA testers from Activision that would report any bugs or difficulty issues regarding boss battles. Members of the development team also play tested and provided feedback. I would fix these issues along with any assigned to me in Devtrak depending on their priority as determined by my lead.

Detailed Breakdown Of A Boss Battle

The level took place in Shanghai and is one of the earliest boss battles encountered. The first phase of the boss battle takes place on the freeway and the later boss phases occur in the parking lot below.

I wanted to show off the large size of the boss as well as the presence of the Autobot's human allies, the NEST forces. The boss takes up a good portion of the screen and towers over parked vehicles. It is also able to destroy the highway overpass that the player is fighting on. Just before the boss fight, the player can see NEST vehicles retreating while leaving behind power-ups for the player. The human forces are not powerful enough to defeat Demolishor and can only provide support for the player. I drew inspiration from how I would have played with the toys back in the 80s with a large Transformer causing destruction with every move or step he took when trying to destroy a much smaller enemy. At the time of development, we only had vague details about the story and an image of what Demolishor would look like.

The goal for this boss battle was to have the player constantly moving while attacking. The player is to take advantage of the boss' lower agility to combat its raw power. There is also a predictable pattern to the boss' attacks that the player should exploit to optimize the timing of their counterattacks. The boss is scripted to growl, telegraph a move through animation, and repeat the offense behaviors to clearly communicate to the player on how it fights so that the player can react appropriately regardless of what character they chose to play as.

The player starts on the freeway next to a weapon upgrade. In script, I have a text box appear briefly to inform the player of their goal. When the player moves to the right, a quick cut scene occurs. NEST allies flee the scene in their vehicles and leave some useful power-ups. Demolishor then threatens the player and the first stage of the boss battle begins. I set up the camera cuts and used AI vehicles to set up a retreat scene.

Demolishor switches between two different attacks. First, he'll use a ground slam attack that will knock the player down and do splash damage around the point of impact. He will then switch to his upgraded plasma cannon to fire at the player. This continues until the player reduces Demolishor's health to a certain level. Through callbacks in LUA, I have a decal of the impact crater appear during the ground slam attack as well as having a growling SFX play.

Demolishor becomes enraged and smashes the freeway. I trigger the freeway to play an animation and lose its collision. The player is now on level ground and follows Demolishor to the parking lot for the next phase. Here, Demolishor will use three different attacks. In addition to the ground slam and plasma cannon, Demolishor will throw debris at the player. There are also two Decepticons that will transform and ambush the player. The enemies provide power-ups if they are destroyed. I also set up Demolishor's health bar to be yellow for this stage as opposed to green for the first stage. While this boss is mostly stationary, in other boss fights I use LUA to randomly choose from a set of locations to move to before initiating an attack.

Demolishor's health is in the red now. He replaces his debris throwing attack with a charge in the hopes of running over the player. Again, his attacks are in a predictable pattern implemented through LUA.

I set up Demolishor to play a special death animation while triggering explosions around him. I also had to sync VO and set up the text that flashes across the screen. I added points to the player score and did HUD cleanup through script. The boss battle and level has been completed.

Released on January 13, 2009 for Xbox 360, PS3, PC

Lord of the Rings: Conquest was 3rd person brawler which featured Good and Evil Campaigns as well as a variety of Multiplayer modes.

+ Brainstorm game play mechanics

+ Provide systems designers with feedback during play testing

+ Translate design from Pandemic's Battlefront series to Lord of the Rings

+ Work on level design for single and multiplayer maps

+ Development Tools: XSI and a propriety editor (FED - Fantastic Editor)

+ Source Control: Perforce

+ Bug Tracking: Devtrak

+ Worked on single player missions for the Pelennor Fields and Mount Doom locations

+ For Pelennor Fields, worked on the Single Player Good Campaign

+ For Mount Doom, worked on the Single Player Evil Campaign

+ Created level design documents for both levels

+ Designed and implemented player objectives for the levels

+ Based the Pelennor Fields level loosely on the events of the film

+ Created original scenarios for the Mount Doom level

+ Created mock up of the levels using the editor and XSI

+ Placed the spawners for AI and set up the script for objectives and special events

+ Designed layouts with Multiplayer in mind first

+ Carve out a single player experience from the Multiplayer layout

+ Prepare layouts for Capture the Ring (CTF), Conquest (Battlefront style capture), and Deathmatch game modes

+ Perform nightly Multiplayer tests cycling through various maps

+ Created Bosses for the Single Player campaign

+ Tuned difficulty using health levels, minion support amount, and frequency of boss special abilties

Detailed Breakdown Of Work

I attended discussions on game play mechanics and would help brainstorm. We had systems designers that we would provide feedback to when play testing. Much of the design was already based on Pandemic's Battlefront series. My tasks were more level design oriented.

Development Tools: XSI and a propriety editor (FED - Fantastic Editor)

Source Control: Perforce

Bug Tracking: Devtrak

I was assigned two locations to work on single player missions for; the Pelennor Fields and Mount Doom. For Pelennor Fields, I would be working on the Single Player Good Campaign. For Mount Doom, I would be working on the Single Player Evil Campaign. I started with level design documents for both levels that would describe the type of objectives the player needed to accomplish. The Pelennor Fields needed to loosely follow the events of the film while the Mount Doom level would allow for artistic liberties.

I created a mock up of the levels using the editor and XSI to make sure the scale worked out. Then following the design document, I placed the spawners for AI and set up the script for objectives and special events. I would iterate and review with my lead often.

When drawing up the layouts for both levels, I actually designed with Multiplayer in mind first. For me, it would be easier to design a Multiplayer map and then carve out a single player experience from it. The design documents included sections for Multiplayer modes that had to use consistent game mechanics across different maps. We had to prepare layouts for Capture the Ring (CTF), Conquest (Battlefront style capture), and Deathmatch.

Once we had basic functionality up, the Design Team would do nightly Multiplayer tests cycling through various maps which were pretty fun when the levels worked.

Detailed Breakdown Of Pelennor Fields

This is a campaign that loosely follows Frodo quest to destroy the One Ring. Pelennor Fields is a linear, objective based defense map that has the player completing objectives that aid in the defense of Minas Tirith. The player plays as one of the Rohirrim and battles against the forces of Mordor.

The difficulty of Pelennor Fields was how to capture the large and crowded scale with our limited resources and technical constraints. I used XSI to create a mock terrain of the fields and using our proprietary editor I painted grass, dirt, and scorch mark textures onto the terrain. The art team also provided me with two versions of fake background characters. One was just a simple animated .gif to be used for far distances in the background. The other was a simplified 3D model playing a set of canned animations to be used closer to the game play's borders. These background characters contained a mixture of Rohirrim, Easterlings, and Trolls. In the editor I would spray these elements on the borders and beyond to help create an illusion of an ongoing battle. If the player wandered too far from the battlefield, they would be warned with voice over and text. This level had almost everything including Horses, Warge, Trolls, Catapults, Oliphants, Fel Beasts, Emplaced Ballistas, and Siege Towers. Memory and performance were our greatest concerns.

My inspiration for this level was obviously the battle as portrayed in the The Lord of the Rings: The Return of the King. I needed to attempt to recapture the feeling of an intense, epic, and chaotic battlefield given our technical constraints. Elements that stood out in the film included a flying Felbeast, catapults, siege towers, trolls, and the elephant-like Oliphants. These elements are what I would focus objectives around or use as landmarks within the level.

Two siege towers being pushed by Trolls are getting dangerously close to Minas Tirith, the player must destroy them. The siege towers were connected to splines in the editor and AI Trolls would push them along these splines until destroy or passing a trigger for mission failure. I had to create a lot of tutorial text and there were a lot of new game play mechanics the player would learn. These included defense zones, sabotaging siege towers, and climbing an Oliphant for an instant kill. The player could destroy the siege towers in many methods: by sabotage (quickest), by catapult or ballista (average), or by regular attacks (slowest).

The next objective was to stop the Oliphants, the giant elephant-like creatures. I set up the cut scene camera that heralded their appearance and displayed tutorial text. I also give the player the chance to play as Legolas to tie in to the events of the film. The Oliphants were large and could easily rush the fail zone so I had their AI follow a specific set of waypoints around the map to give the player more time to kill them. The quickest way was to complete a set of Quick Time Events to perform a flashy kill, but arrows and catapults are just as effective.

A combination of a Siege Tower and an Oliphant now approach the player's defense zone. The player is hopefully aware of how to deal with these types of enemies and can choose any method they like to complete this objective.

This was simply a way to get the player in the area we wanted for the next segment of the level. The player is also given the option to play as Eowyn, the one that kills the Witch King.

I set up the cut scene announcing the arrival of the Witch King, Theoden's death, and the final objective. When the player is victorious; I did a camera pan, fired off some explosions, and gave retreat commands to the enemy AI.

The design also required for me to set up a lot of reminder voice over to play off of timers and set up the visual indicators to help guide the player around the level.

This is a Multiplayer mode in which players fight each other as either Good or Evil. Teams must achieve enough kills to reach their goal before their opponents do. For Pelennor Fields, this map is well suited for ranged characters or the use of mounts and siege units. There are pieces of cover scattered about to provide sniping areas for archers. Mages also play an important role as their shield can help other team members cross the field safely.

This is a Multiplayer mode in which players must acquire and deliver a ring to their opponent's starting location. They are using the ring's power to damage their opponents. A player on the good team could play as a soldier of the Rohirrim while a player on the evil team could play as a soldier of the Easterlings for the Pelennor Fields. If a player is doing especially well, it is possible to unlock a greater Hero like the Witch King or Aragorn depending on the player's faction. Whichever side delivers the maximum amount of rings first wins.

For this "Capture The Flag" mode, I drew on my past experience playing other multiplayer games. I wanted a relatively balanced or symmetrical map and put in elements that the players could interact with to affect gameplay. These included towers for sniping positions, mines that could be detonated with damage, and mounts for faster navigation.

The Pelennor Fields is a large map. For this, I provided Mounts and Giants to utilize for both factions. The ring is placed in the middle of the map and each side must first pick it up and then carry it into the enemy's starting position. This kind of mode encourages players to have defenders for their base. I placed watch towers that could be climbed by archers for sniper's nests. There are also catapult bombs in the field that can be detonated with damage.

The overall size of the map is relatively large to encourage the use of mounts and teamwork. Mages are able to protect against sniping shots from an archer especially in areas with little cover. However, there is still enough cover and resources to help a player navigate the map alone.

Detailed Breakdown Of Mount Doom

This is a 'what if' scenario in which Frodo fails to destroy the One Ring and Sauron becomes whole to rule Middle Earth. Mount Doom is the first level in this alternate story campaign. It is a linear, objective based mission that gives the player control over a Nazgul hunting Frodo.

The only thing we had for reference with Mount Doom was the exterior and the iconic precipice from which the One Ring is destroyed. Design and Art had to fabricate what other parts of Mount Doom may have looked like. For inspiration, I thought about how the lore says that Mount Doom was where the One Ring was made and could be unmade. With that in mind, Mount Doom became an environment that reinforced the idea of ring creation. We would show the player a mine for the minerals and metals used for the rings, an Orc encampment where the workers or guards lived, and an actual forge in the center of the volcano.

I enjoyed working on Mount Doom a lot. The location is very memorable and visually appealing. We had to be creative as we didn't know what the inside of Mount Doom looked like. For the game, it starts an interesting scenario that allows the player to play as the bad guy. Mount Doom is also a rare instance in the game that the player is allowed to use a Hero for the entire level. The player is also on the evil faction, but is forced to kill Orcs. This level felt like a special reward for the player that completed the Good Campaign.

For me it was easier to design Mount Doom's layout with multiplayer in mind in order to carve out a suitable linear path. Mount Doom's design centers around 6 key locations and the tunnels that link them together. For the purposes of single player, I blocked access in a way that would force the player to visit all 6 locations in a specific order.

The fiction is that Sauron will use his magic toresurrectthe Witch King, but requires his mask which was taken back to Mount Doom by Orcs after the defeat at the Pelennor Fields. The player starts out in the first key location, an Orc encampment on the exterior of Mount Doom. Here the player starts as a Nazgul and has other AI controlled Nazgul for allies. I spawn a small legion of grunts and a pair of Orc Warriors for the player to defeat. I also set up a simple lever and gate to slow the player's progression down and allow for me to shift resources from one zone to the other. When the player opens a gate, I stopped the spawning of more enemies in the current location and initiate the script set up for the next.

After entering the gate into the interior of Mount Doom, the player will cross an iron bridge over lava to enter an old prison. This is the second key location and if the player looks carefully; they will see cages, prison cells, bones, and instruments of torture. The Witch King's mask is being kept here and the player just needs to pick it up. In this section, I spawn more grunts and a squad of Orc Archers. I place some archers on the ledge that overlooks the prison area. With the mask in hand, the player will advance past another gate to the next key location.

The player will deliver the mask to thethirdkey location, the Forge, which is infused with dark magic. Here the player must kill Orcs so that their blood will help power the magic. In this room I spawn a group of Orc Mages for the player to fight. I also added a timer for pressure and ramp up the challenge in this section. When the player is successful, the Witch King returns. The player can now be the Witch King. However, if the player chooses not to do so, I set up the script to spawn the Witch King as an AI controlled character.

Two Orc Captains are responsible for leading the uprising for the One Ring and must be killed. I spawned an Orc Warrior Captain and an Orc Mage Captain which are stronger versions of their normal classes. They are supported by a legion of grunts and Orc Warriors. The battle takes place in the fourth key location, the Mine. The player might notice mining equipment, mine cart tracks, and a large pit in the center of the room. I have it set up so that a lucky or clever player can knock the captains into the pit for a quick victory.

After defeating the captains, the player is instructed to go to Sauron's Road (fifth key location). Frodo is hiding on the road that leads to the Crack of Doom. I spawn a Troll, a legion of grunts, and Orc Scouts for the player to fight through on the way to the road. When the player arrives, I set up a quick cut scene showing Frodo nearby.

The player must now kill Frodo. The design required that Frodo retreat closer and closer to the Crack of Doom as he nears death. The Crack of Doom is the sixth and final key location of Mount Doom. The fights and follows Frodo to the precipice overlooking the Crack of Doom. Whether or not Frodo is killed on the ledge or tossed into the lava, the One Ring will appear on the precipice for the player to pick up. Once the ring is in possession the player wins and Sauron is able to manifest in his old form.

The design also required for me to set up a lot of reminder voice over to play off of timers and set up the visual indicators to help guide the player through the level.

This is a Multiplayer mode in which all players may choose a Hero to fight without having to unlock it. A player on the good team could play as Gandalf, Frodo, Legolas, or Gimli while a player on the evil team could play as The Mouth of Sauron, Wormtongue, Lurtz, or a Nazgul for Mount Doom. If a player is doing especially well, it is possible to unlock a greater Hero like Isildur or Sauron depending on the player's faction. Whichever side reaches the maximum amount of kills first wins.

When designing Mount Doom's layout, I always had multiplayer in mind. My approach was to create enough space to support multiplayer modes and then use art assets to seal off sections of the level to create a more linear experience for the single player campaign.

For Hero Team Deathmatch, I wanted the layout to be like a hub with a couple of corridors branching out. Specifically, the hub would take place in Sauron's Forge which was a circular room with lots of space to fight. There would be four corridors connected to the hub. Each faction would spawn in one of two corridors to decrease the possibility of 'spawn camping'. The corridors also provided changes in height and straight views for archers to take advantage of.

The overall size of the map is relatively small to encourage constant battle and to ensure enemies will run into each other quickly and often. Players will not get lost and can easily figure out where the action is.

Released on February 26, 2008 for Xbox 360, PS3, PC

Turning Point: Fall of Liberty was a first person shooter set in an alternate history where Nazi Germany succeeds in invading the Eastern Coast of the United States.

+ Provide feedback and contributed to discussions on the game's overall design

+ Set up standard FPS game play with some extra features like human shields and environmental kills

+ Managed SCRUM Agile Development meetings as a Scrum Master

+ Development Tools: Unreal Editor 3.0 and Kismet scripting language

+ Source Control: Perforce

+ Bug Tracking: Codemasters Proprietary Software

+ Implementated levels based on design documents

+ Worked in strike teams that had a part in working on almost every level in the game

+ Set up mock layouts, populate it with enemies, and set up cut scenes

+ Led daily morning meetings as a SCRUM master

+ Conducted task coordination and level review within strike teams

+ Rotated on various teams to make design adjustments and fix bugs

+ Test multiplayer map gameplay and provide feedback

+ Instead of traditional boss battles, I helped script and set up cinematic epic moments

Detailed Breakdown Of Work

Under SCRUM agile development, our project team split up into various groups to allow for rapid prototyping of features and levels. I wasn't part of the group that worked on the game mechanics, but I provided feedback and testing.

Development Tools: Unreal Editor 3.0 and Kismet scripting language

Source Control: Perforce

Bug Tracking: Codemasters Proprietary Software

As a SCRUM master, I held daily morning meetings to help a level team coordinate their tasks, track progress, and resolve any obstacles to their work. After receiving updates from the team, we would review our level in its current state then proceed as we had planned. I would coordinate with other SCRUM masters if a shift in resources or personnel was needed.

Most of our level design documents were created by a planning team. However, I would go over the layouts with our level group to make any necessary adjustments.

Using the Unreal Editor, I would create a basic layout of the level in BSP. The mock up would have basic colors, textures, and some art assets. Once the mock up was complete, I would walk the rest of the team through the level. This allowed artists to see where the game play path was and what art assets were needed. I also called out areas that would need SFX and particle FX attention. It was important to make sure everyone was on the same page and that they could get started on their work.

(Unreal Editor: This is what the editor looks like and is not an actual screenshot of my work)

This is where all the level design happens

The AI system used Kynapse middleware for our AI. However, in many cases where I needed a scripted event then I would use waypoints and send AI commands to follow a specific path. The Unreal Editor and Kismet allowed me to set up scenarios showing civilians fleeing in a cut scene or enemies charging a position. In the editor I used a lot of AI Spawn Factories to create enemies, allies, and civilians. The editor allowed me to specify the character model, weapons, and animations for spawned AI. I specified spawn locations, cover points, and areas for special animations like wall vaulting or rappelling down ropes. Waypoints were also used for vehicles and using the editor's Matinee system, I would create cut scenes or apply simple animations to objects.

The majority of my level work was done through the Unreal Editor. I placed triggers to fire off events and advance the game. The editor's scripting language Kismet, allowed me to modify AI creation, play sound or music, initiate cut scenes, and control asset streaming. I would play through the level and make adjustments after reviews with the team. The script could get pretty elaborate so it was nice that Kismet allows from grouping of objects to ease the organization of our logic.

(Kismet: This is what the scripting tool looks like and is not an actual screenshot of my work)

The Unreal Editor allowed us to monitor our memory usage. To make sure performance was acceptable, designers would have to set up the level to stream out parts of the level that were no longer used. This involved strategically placing triggers and setting up the level so that the only the environment that the player was immediately in was loaded. We would also work with the artists to optimize the number of triangles used in models and texture sizes.

Since team member shifted back and forth from various levels, bugs would be assigned to the person who lasted worked on a particular level.

My involvement was limited in multiplayer as there was a separate design team tasked to it. I helped test initial map passes.

Detailed Breakdown Of Levels

The National Guard has set up a barricade to hold off Nazi forces while they evacuate the citizens through the subways.

I created the initial layout in BSP and then worked on the initial framework. I did a lot of the set up for this mission before being assigned to another level.

I set up the sequence where the truck with the soldiers drives to the barricade using Matinee. I used special animations for the soldier's talk and dismounting from the truck. In the editor I placed waypoints for the civilians to leave the bus and head to the subway.

When the player hits a trigger around the volunteer, he'll lead the player to the barricade. Another trigger will start the logic to spawn enemies to attack the barricade, the player, and any allies nearby. The player is fighting at a T intersection so enemies will be spawned from 3 different directions and scripting to run to assault positions in front of the barricade.

Using Matinee, I animate the vehicles to come in and drop off soldiers for the player to attack.

A blimp is animated into the scene and when it hits a trigger, the soldiers inside attempt to rappel to the ground.

At this point, the lag is actually the game streaming the next section and unloading the previous section. I block the player form back tracking with some collision, debris, and FX.

At the smaller barricade, the player is told to destroy a tank by planting explosives underneath it. I spawned Nazis to snipe from the cracks in the street above the sewers.

I script the soldier to lead the player back to the other side. The AI follows a series of placed waypoints. There are triggers along the way so that when the player enters them, they would hear an explosion and see debris or dust. There is streaming trigger as well to load the main barricade section and unload the area the player had been.

The player is scripted to get knocked off their feet. AI are set to fall back to the subway for a retreat while the Nazi's attack intensifies.

The player must destroy a Atom bomb laboratory housed beneath the Tower of London. The resistance team will attack a secondary target to distract and pull away security from the Tower while the player infiltrates the lab.

I worked in the editor to create the layout of the tower in BSP and scripted the enemy encounters up until the lab.

I set up the camera work and the animations for this cut scene. The aerial shot of the tower and spotlights was actually a camera zoom on a painted billboard with animated cones of light and particle FX.

I placed a sniper rifle for the player to use. The enemies I spawn here are stationary and taking up defenses positions. The player can snipe or attack through normal methods. In my logic, I have a kill counter tracking the number of enemies that the player has killed. When that number is reached or surpassed, some enemies will be scripted to open a tower door to come out and attack. The player will just need to kill off this small squad and then can proceed into the Tower of London.

As the player enters the interior of the level, I spawn Nazi Officers that visually look different and are not as well armed. They call in reinforcements to help attack the player.

I worked with the artist to place a bunch of glass objects in this room hoping that crossfire or splash damage from grenades will trigger some nice destruction.

Here's another set up that gives the player some cover and an opportunity to destroy the environment as well as the enemy.

I spawn enemies hiding behind pillars and expecting the player to come through the door. Depending on the difficulty setting, there could be grenadiers and snipers on the second floor.

I helped set up the switch and animations for the false wall as well as the elevator in Unreal Matinee editor. There are streaming triggers in the elevator to load the underground lab and unload the tower.

Everyone's favorite instance of an environmental kill.

From this point on, I help support the lab section by helping place enemies, making sure the doors work correctly, and setting up triggers to prepare for level streaming. Another designer would take responsibility for the underground lab section. Since we were working under SCRUM, I would be moved onto a new level that needed more attention.

Cancelled Summer 2005 for Xbox, PS2, PC

Taxi Driver was a 3rd person action open world shooter with driving elements. The game was comprised of a city to navigate and 10 separately loaded missions.

+ Participated in brain storming sessions for gameplay systems

+ Wrote design documentation

+ Tuned settings gameplay systems

+ In-game testing of levels

+ Assisted in story development for side missions

+ Development Tools: 3DS Max with in-house plug-ins, LUA script, and an XML compiler

+ Source Control: Alienbrain

+ Bug Tracking: Bugzilla

+ Design and build world map

+ Design open world driving and side missions

+ Plan neighborhoods, landmarks, and streets then decorate the world with art assets

+ Create AI data so that AI vehicle and pedestrian traffic would know where to navigate

+ Worked on 10 separate on-foot story levels with boss battles

+ Wrote level design documents

+ Coordinated with artists for game assets and programmers for gameplay functionality

+ Mocked up levels in 3DS Max that included enemy AI, inventory items, and event triggers

+ Iterated implementation of levels while maintaining and testing them

+ Tuned the balance for level difficulty

+ Fixed bugs

+ Designed boss battles to include an environmental or strategic gimmick

+ Scripted behaviors and tuned boss battles

Detailed Breakdown Of Work

I personally worked on all 10 levels in 3DS Max and helped stitch together the open world of the fictionalized streets of New York City.

I was involved with brain storming sessions to help develop the systems and functionality we would need for the game. After these meetings, I would write up a design document or specification for a programmer to reference. My responsibilities also included tuning the settings for the systems and testing them in the game. Systems included cover, elimination moves, vehicle side missions, boss battles, AI types, inventory, and weapons. I had some input as far the game's story went, but I mostly followed the GDD and my lead's direction.

Development Tools: 3DS Max with in-house plug-ins, LUA script, and an XML compiler

Source Control: Alienbrain

Bug Tracking: Bugzilla

Player start/checkpoints - I placed 'markers' using a special naming convention in 3DS Max to denote the points where the player would spawn or respawn. Triggers created in Max would set up checkpoints in LUA script when entered by the player.

Pick Ups - A Max plug-in allowed me to place 'markers' that would create pick ups such as ammunition, health pills, or cash.

AI Creation - This was handled mostly by LUA functions that defined all the attributes of an AI to create. I would place location 'markers' and triggers in Max so that the script new when and where to create AI.

AI Paths and Cover - Another Max plug-in allowed me to specify all areas in a level that the AI (pedestrian and traffic) could navigate to. It also allowed me to place cover points, orient them in the proper direction, and select from standing or crouching cover.

Streaming Volumes - Through the use of a Max plug-in, I created streaming volumes in Max so objects would be rendered only where the player could see to help performance and memory management.

Weapons - I used a LUA file to tune the weapon attributes such as ammunition capacity, damage strength, reload speed, etc.

Vehicles- I used a LUA file to tune the vehicle attributes such as top speed, acceleration, inertia, turning radius, etc.

Cut Scenes - In 3DS Max, I was able to create and animate cameras for in game cut scenes and other camera work.

Sounds - I helped assign sound files to sound banks specified in a LUA file.

The world would be a scaled down and fictionalized version of Manhattan. It would maintain it's grid-like street layouts and have distinct neighborhoods delineated by landmarks and different architecture. Designers and the lead artist helped map the world onto graphing paper so that we could build the assets in compartments. Sections of street and buildings would be created in units of 20, 30, and 60 meters to provide a flexible library of assets to create the world with. Neighborhoods included Union Square, Chinatown, Chelsea, Meatpacking District, and Little Italy.

The art team had provided us with basic building blocks to place in 3DS Max. Using this library of assets, the world was created in a rough pass with basic shapes and colors to denote object type. This was compiled, exported, and tested on the PC to test how well the scope and size fit. We would make adjustments and perform a quick review with the leads before it was approved for the next phase.

The programming team provided us with 3DS Max plug-ins that would enable us to lay down AI paths so that AI pedestrians and vehicles could move around the world. I also helped set up the traffic light system that used a LUA script to set up the timing of lights at intersections. A LUA file was also used to store what types of vehicle makes to spawn and what kind of clothes pedestrians would be wearing. This was set so that in certain areas, different vehicles and pedestrians would spawn to reflect the neighborhood that the player was in.

Another 3DS Max plug-in allowed me to define volumes that represented where a player was located and what objects to stream in and what to cull. This allowed our game to provide a large world without any loading times. Objects would be dynamically loaded and unloaded depending on which streaming volume that the player was in. For object culling in the world, it was important to test with our fastest vehicle in the worst situation like a 4 way intersection with a long view distance. We would then have a memory budget set so that the world could dynamically stream in sections without the player noticing any hitches or visual popping of objects.

After a basic pass had been done to the world, I would periodically play test the world and make adjustments. Assets from art and functionality from programming are created concurrently with the world. As new assets like pedestrian and vehicle variety become available, I would add them to the world and test them.

Our in-house QA plays the build on a nightly basis and writes up bugs using Bugzilla. Bugs get forwarded to me by my lead and I fix them or work with other departments to resolve the issue.

I would create a design document for a separate load level using MS Word and reference pictures pulled from the Internet. The document would provide details of how the level fit with the game's story and how it would advance the plot. I would draw a rough layout of the level and note how navigation would proceed. My drawing would also mark the approximate locations of enemy placement, inventory pick-ups, and the locations of triggers for special events. I also included a list of proposed art assets like environmental objects, animated props, or special effects that I would need which were accompanied by pictures for reference. Level settings included an apartment complex, a 3 story office building, a pawn shop, a factory, a 70s disco, a Chinatown open market, a brothel, a theater, a cemetery, and a penthouse apartment.

Using a set of basic building blocks provided by the art team, I would create the layout in 3DS Max that gave a good estimate of the scope and game play path. I would make adjustments and have a quick review with the design lead.

Using 3DS Max plug-ins, I set down AI paths so that enemies would be able to navigate the level. I was also able to set Cover Points that enabled enemy AI and the player to use walls, doorways, and low objects for cover. With LUA script I created AI enemy types and defined their appearance, weapons, and behavior pattern. Invisible triggers were set throughout the level so that when the player enters one, groups of AI will spawn and the game play advances.

The process here was almost identical to how I did the streaming pass for the world. Although for an individual level I have a controlled environment, it meant that we had more memory to add more objects. The majority of my streaming work for individual levels dealt with fixing bugs with visual popping.

I would play through the level to make sure that the special events and enemy waves trigger appropriately. At this time I would also add item pick-ups to help balance the level's difficulty. Sometimes I would receive a new AI type or weapon that I would retro-fit into a level that had already been given a first pass. Daily tests would help identify bugs or other problems with level flow and balance.

The following is an example of the LUA scripting I did for the levels:

// This function is called when the player enters the disco’s restroom

disco_player_entered_restroom = function( )

// This defines the type of AI encountered

disco_enemy = { aibehavior = ‘basic_gunner’, aiweapon = ‘handgun’ aimesh = ‘thin_ai’ }

// This tells the AI handler where to spawn an enemy. Points are placed in 3DS Max to define

// these locations.

disco_enemy.position = ‘mark | pos | disco_bathroom’

// This tells the AI handler to create the enemy

mission_create( disco_enemy )

end

Our in-house QA plays the build on a nightly basis and writes up bugs using Bugzilla. Bugs get forwarded to me by my lead and I fix them or work with other departments to resolve the issue.

Detailed Breakdown Of E3 Work

The E3 Trailer

The level chosen to be demoed at E3 was Mission 5: The Disco.

The player was told that the owner of a local disco has information he needs. The disco is full of civilian patrons and mobsters already alerted to be watchful of a vigilante cab driver. The player will need to make their way to the second floor office and confront the disco owner.

Since this was a demo at E3, the person playing the level will do so in a way that is able to showcase some features of the game.

I personally worked on this level; creating a design document detailing layout, enemy placement, and special events. I saw this level from a basic mock-up with blocks to its final polished stage shown at E3.

The player starts in the rear entrance of the disco that leads into a kitchen where the bar food is made. The E3 demo demonstrates the player's ability to use a doorway as cover.

Cover prompts appear near areas that can act as cover

Upon entering the kitchen, the player will see a typical armed mobster. The demo then shows a special elimination move that was inspired by (ripped off of) God of War. If the player targets and shoots an enemy's leg, they will fall to the floor in pain. The player then has a short amount of time to walk up to them and initiate an elimination move. A series of button presses will appear on the screen and the player will need to mimic the button presses right after they appear. If successful, the player will be treated to a nice animation and quick kill of the enemy. The elimination move is different for each weapon. In the demo, the player is equipped with dual .25 pistols.

As the player leaves the kitchen to enter a coat room in the disco, the player will be given a the freedom or choice of where to go. While the level is ultimately very linear, there are many opportunities to take an alternate path. This allows the player to explore in order to find helpful pick-up items or approach an enemy from an angle of more cover. In the demo, the player could go left to the bar or go right to a storage room.

In the storage room, the player encounters two mobsters for a little gun fight. Here I've placed a small stack of money on the table for the player to pick up as well as some health pills on a shelf. Money allows the player to purchase weapons and ammunition when they go to the gun store. Health pills restore the player's health and can be carried for later use.

After the leaves the storage room, the player can check out the bathrooms and get an easy kill off of an enemy AI relieving himself. The player will then enter the main dining area and dance floor. The game will take over and the camera will pan, showing the dancing patrons and well as moving up to show the office the player needs to get to. I did the camera work using 3DS Max and trigger volumes. I also had to hack the script so that when the player fired their weapon in this room, all the dances would run away or cower in a cover point.

When the player comes across a new weapon for the first time, there will be a short cut scene and animation activated. New weapons were visually placed in weapon suitcases for the player to identify and find. When I had to place a new weapon in a level, I made sure it would be in the player's main game play path and that the area had enough room for a camera cut to work.

The remaining portion of the demo has the player fight additional enemies with the shotgun and try out an elimination move with a different weapon like the .44 Magnum.

At Metronome Software, I am a part of a software engineering team that works on Web and Mobile Applications. The following are marketing materials that describe the nature of just some of the applications I programmed for:

I'm always interested in hearing about up and coming projects. I may not be in a position to accept new opportunities, but at the very least I'll want to expand my network and keep in touch. If you've got a LinkedIn account, check out my profile here: http://www.linkedin.com/in/designkuo

Kuo

Kuo

itskuo | Professional Portfolio

[ pronounced: \itz koo\ ]

Find out more about Kuo and his work in videogames and software.

Learn About Me

PROJECTS I HAVE WORKED ON

UNANNOUNCED PROJECT (2020)

Battleship (2012)

MicroBot (2010)

Transformers: Revenge of the Fallen (2009)

Lord of the Rings: Conquest (2009)

Turning Point: Fall of Liberty (2008)

Taxi Driver (2005)

Nexon OC: Unannounced Project | (2020)

From November 2017 to July 2020, I was a Senior Designer at Nexon OC.

Combat Design

Production

Level Design

Systems Design

UI & HUD Design

Detailed Breakdown Of Work

Combat Design

Production

Level Design

Systems Design

UI & HUD Design

Double Helix Games: Battleship | (2012)

From October 2010 to April 2012, I was a Gameplay Designer & Technical Scripter at Double Helix Games.

Game Design

Production

Level Design

Single Player Levels

Boss Battles

Detailed Breakdown Of Work

Single Player Levels

Boss Battles

Production Work

Naked Sky Entertainment: MicroBot | (2010)

From June 2010 to October 2010, I was a Senior Level Designer at Naked Sky Entertainment.

Game Design

Level Design

Single Player Levels

Multiplayer Levels

Boss Battles

Detailed Breakdown Of Work

Editor Work and Scripting

Single Player Levels

Blueprinting:

Mock Up:

AI Pass:

Iteration:

Bug Fixing:

Multiplayer Levels

Boss Battles

Blueprinting:

Scripting Pass:

Savage Entertainment: Transformers: Revenge of the Fallen | (2009)

From October 2008 to May 2010, I was a Senior Game Designer at Savage Entertainment.

Game Design

Level Design

Single Player Levels

Multiplayer Levels

Boss Battles

Detailed Breakdown Of Work

Editor Work and Scripting:

Blueprinting:

Mock Up:

AI Pass:

Iteration:

Bug Fixing:

Multiplayer Levels

Boss Battles

Blueprinting:

AI Pass:

Iteration:

Bug Fixing:

Detailed Breakdown Of A Boss Battle

Visual Goal

Gameplay Goal