Game Design Window Close

Experience

Playteau, Inc.
Game and Level Designer - Contract
October 2010 – March 2011 (6 months)
My work at Playteau involved both game and level design, as well as some testing, for Fortune Stones.
The game has two basic play modes: Frenzy and Strategy. On Frenzy you simply try to clear a small square board as many times as possible before the time runs out. On Strategy, however, you may play specific levels that vary in difficulty and (as the name portrays) strategy. My work as Level Designer was to create not only attractive levels for Strategy Mode, but also add some strategy and gameplay features. I always delivered my levels ahead of schedule, and had a blast creating them. I created over 150 levels; should you ever play this game, and wish to know if a level was created by me, contact me. For example, in the "Challenger 2" level set I created the first 15, and recommend "In One Move" and "ChineseDragon" (Note: sadly, they've changed the timer for "In One Move", so it is too easy now - there's nothing preventing you to complete it in more moves).
As for pure game design, I was involved in design meetings for brainstorming ideas for other games, as well as updates to Fortunes Stones, while also in charge of creating the gameplay and Game Design Document for a new game. This involved pitching several different game concepts and mechanics, meetings, and updating related documents. Unfortunately the project got canceled due to budget.
Finally, I also did some testing on Fortune Stones. I have a knack for creating AND destroying, even in unexpected ways. I was able to find several problems in the game by triggering a race scenario between competing services (particularly services regarding getting free content and money), deadlocks, hardlocks, UI inconsistencies, game design or implementation bugs, and finding new possible exploits. This was a good example of how my CS background helped me identify possible problems and how my creativity can push them even further.
1 Recommendation regarding this job: Ethan Pasternack, Game Designer, managed Erick indirectly at Playteau.

Flying Lab Software
Game Design Intern
August 2008 – May 2009 (10 months)
During my internship at Flying Lab Software I learned certain details about MMO and social game design. UpperDeckU gave me the opportunity to design and create game design documentation for mini-games and in-house tools, creating in-game content, design bug finding and fixing, plus other smaller tasks. I worked directly under the Lead Designer, doing the same work than the game designers. I created brand new content and mechanics, had meetings with the leads of each area (Production, Design, QA and Dev) and was given responsibility over specific areas. Lastly, my role also included testing, verifying and fixing existing design bugs and bug fixes through our bug database. My fixes were corroborated by my Lead and uploaded to the main build. Throughout this job I had personal and team milestones, which were delivered completed and ahead of schedule. Thanks to our drive our teamwork paid off, as we were ahead of schedule by a month, reached a record in bug finding and fixing, and had complete and revised documentation of future features.
For Pirates of the Burning Sea I was given the task to study new game content for incoming patches, with emphasis on the (then) new talent trees. I was able to find certain unbalances and, more importantly, a typo in a spreadsheet that caused a talent to give the wrong modifier.
1 Recommendation regarding this job: Drew Clowery, Lead Game Designer, managed Erick directly at FLS.
Bungie
Test Associate - Contract
June 2010 – August 2010 (3 months)
My first AAA game, HALO: Reach. I joined the test team during the last two months of crunch time to focus on back end files, which focused on content, challenges, achievements and multiplayer. My test lead considered it "gray box testing" as I needed to understand what the files did (and the code related to them), when they were uploaded/downloaded, and the integrity of those files. However, it wasn't white box testing as I only had access to the files, and not the code. I was assigned test passes, as well as allowed to test ad-hoc (particularly for possible exploits by modifying those back end files). I always delivered my test passes successfully and on-time, which allowed me to lend a hand in other areas such as DLC, performance, and XBOX Live, be it independently or as part of a team.
1 Recommendation regarding this job: Andy Howell, QA Consultant, worked with Erick at Bungie.
Microsoft Studios GTO Reserves
Test Associate 2 (Kinect) - Contract thru Aditi Technologies
March 2011 – April 2011; October 2011 - Present
Some time after getting my own Kinect I jumped at the opportunity to test Kinect: Disneyland Adventures for Microsoft Studios. Since I joined the project in a very early stage we were tasked on focused ad-hoc testing and reviewing the content and gameplay of the game. This included score, gameplay, Kinect motion sensor reading, difficulty and game flow. Entirely black box, we used specialized Microsoft and MS GTO custom testing tools to obtain data and write bugs. My time at MS GTO had to end early due to personal reasons, but in October 2011 I was available once again and they were happy to have me back for another, currently undisclosed, project. In this project I am currently testing back end files, as well as sensor readings, UI, gameplay, and other features.
Ominous Development
Beta Tester - Voluntary
June 2008 – August 2008 (3 months)
While studying my master's I became Beta Tester for the indie game Strange Attractors 2. While most Beta testing involves just playing the game and submitting a small report on your experience, this one was practically a full test job - I interacted directly with their designer, who asked me to focus on level playability, progression, design, gameplay, UI, difficulty and game flow. The reports I was asked to report were very detailed, and I took it in stride to not only answer the fully but added further details on design flaws, soak testing, compatibility testing, and gave suggestions on how to correct and improve any encountered deficiency. Despite the fact that I was able to work on this only for a summer I feel it was very important in my understanding of design and testing, not to mention the iteration it takes to polish a game to launch.
DigiPen Institute of Technology
Game and level designer, music and sound creator, tester, and programmer.
January 2008 - May 2008 (5 months)
A game project at DigiPen developed as far as First Playable, Drones was a gesture-based RTS/Puzzle game. As part of a 4-man team, I wore many hats: game and level designer, music and sound creator, tester, and programmer. This was my second game design at DigiPen, and I feel it can be explored further (even perhaps as a commercial game).
The premise is simple, yet the game mechanic make take a moment to grasp (I'd say similar to the learning curve of portal mechanics in Portal).
The player is in control of Drones, little robots that are trapped in an old laboratory. He must help the Drones escape the maze-like lab by opening doors, freeing other Drones, pushing objects and getting to the exit. However, each door is linked to at least one circular terminal, and at least one Drone is required to stay within the circle to keep the door open. Blue terminals require at least a drone in ANY of the different circles connected to the door (an OR gate), and Pink terminals require at least a drone in ALL the different circles connected to the door (an AND gate). What's more, these circular terminals come in different sizes, which means they require more Drones to remain active. The player then has to be smart about how he moves his Drones around, which part of the maze level to tackle first, and figure a way to have at least one Drone reach the exit.
Drones © 2008-2010 DigiPen (USA) Corporation, all rights reserved.

Game Design Skills

  • Game Conceptualization
  • Game Design Documentation
  • Creative Documentation
  • Technical Documentation
Creating and designing games is definitely what I enjoy the most in game development. To bring an idea down to a solid concept is a vital step that I have learned to do. I focus on bringing an idea from sketches down to a foundation, helping grow some areas and pruning down that which deviates from the essence of the game. It has to be fun; it has to be engaging; it has to make people excited so they embrace the concept and make it flourish to a project. This is when documentation comes in. Be it the entire game design documentation, some creative writing to bring life to the in-game world or technical documentation for our dev team, writing (and the deep organizational need of these documents) is vital to communicate my concepts and ideas. I have trained and worked on all areas of documentation at DigiPen, Flying Lab Software and Playteau. If you wish to see an example you may go to the Sample area further below, or click here.
  • Game Systems & Player Investment Design
Game Systems Design encapsulates the design, test, simulation and balance/tuning of game systems (eg. monetizing or an encounter system). The design of these systems can be complex, and is definitely intrinsic to solid gaming experiences.
Player Investment Design, as part of Game Systems Design, encapsulates the design, test, simulation and balance of incentive game mechanics. The goal of this type of design is to define a fair (subjective) and proportional (objective) challenge/reward to the player. This can be summed into a simple yet tricky rule: the best reward is not just what is expected based on the difficulty of the challenge, but also adding a little something for the player’s trouble.
I have been training myself in these areas, using my experience in game design and knowledge as as a gamer to create interesting and solid samples. If you wish to see them you may go to the Sample area further below, or click here.
  • Level Design
  • Scripting
I've had the pleasure of designing and implementing levels (including behavior, triggers and events) in concept, XML, Valve’s Hammer Level Editor (Half-Life 2's and Orange Box's engines), Blizzard’s Starcraft and Warcraft 2 Map Editors, as well as in-house editors. Recently I've created puzzle levels for Fortune Stones for Playteau. I've also fixed pre-constructed levels with the mentioned tools, as well as Adobe Flash during my time in Flying Lab Software and at DigiPen.
My scripting experience has focused around basic LUA, in-house languages, AI scripting (FSM, planning) and Valve's Hammer scripting. The in-house scripting I've done have been very similar to LUA, while Hammer's scripting is more "user-friendly" and similar to what I know is used in most FPS. As you may see in the Level Design Sample section I've been using their scripted_sequences and other entities to create levels. However, in terms of coding/scripting, I feel comfortable enough with my programming skills that I'm open to the idea of scripting in the language you need. If you'd like to see an example of a particular type of scripting, please contact me.
If you wish to see three different samples of Level Design you may go to the Sample area further below, or click here. You can also try my levels at Fortunes Stones.
  • Gaming knowledge
  • Tabletop gaming knowledge
  • Pen-and-paper gaming knowledge
  • Avid reader (fiction & non-fiction)
I have been playing video games and tabletop games since I was a small 8 year old. The very first game I saw was Zelda for the NES, and was hooked immediately. Since then I've played every genre on several platforms and consider myself an expert. As any technology, it is all about keeping up-to-date, and I do it in my free time for fun. In the last few years I have been following the commercial trend playing console games (including the newer interfaces -Kinect and Wiimote-), social games (including MMO, browser and facebook games), PC games, and mobile games (including iPad, iPod and similar devices). I have also worked on three of these areas (social gaming, console and PC), which gives me an understanding of both the game dev and the gamer in that market.
As for tabletop and pen-and-paper, I have been playing different kinds of games for a while. From classic Monopoly to Risk to Blokus, Dungeons and Dragons (started on 2nd Edition) to online roleplaying with different rules and universes. Losing myself in a game or a universe is a favorite pastime, that I also feed with books. Reading helps my mind relax and my imagination thrive. I particularly like to read historic accounts (particularly ancient history and war-related books) as well as sci fi and fantasy (with the occasional novel). I learn from books about strategies, places, ideals, but mostly about people and their interpersonal relations. Fiction helps me learn about different ways plots may develop, how characters are affected and how the environment affects the narrative.
From video games I have learned how games work and are fun, from tabletop and pen-and-paper games I have learned how rules dictate a game's pace and fun, and from books I have learned about stories: all foundation for game design.
  • MS Visio
  • MS Project
  • MS Excel
  • MS Word
  • MS Office
I have singled out Visio, Project and Excel from the rest for specific reasons. Visio is an excellent tool for creating UML and other diagrams (eg. game flow), Project is a must for defining schedules, milestones and goals, and Excel because of how handy it can be (game design, numerical analysis, statistics, etc.). Regarding Word, it simply comes down to be able to use features regular people don't use (particularly comments, balloons and other useful features when working on shared and/or big documents, ie. GDDs).
I also use the rest of MS Office programs, and consider myself an expert (hard not to when you've used them since the Windows 95 version).
  • Photoshop
  • MS Paint
  • Illustrator (basic)
A picture may not say more than a 1000 words (in well-written sentences), but they do say a lot. As a visual person I always want to have graphical explanations of layouts, designs and concepts in my documents, as well as knowing how to use these programs for game content creation (when applicable). I have been using Photoshop for a while now (in fact, used it for all the images in this website), and MS Paint when I don't have a choice or want something simple. I have not used Illustrator as much, even though I know it is a lot handier than Photoshop for certain tasks (particularly when you're creating images that may need to be scaled up/down liberally). Using vectors is a lot cleaner. I feel I can learn it fully with ease, should the need arise.
  • Valve's Hammer Editor (and other level editors)
  • Flash (basic)
  • 3DS Max 9
  • Maya (basic)
  • Audacity
These are programs that I've used for level design. Hammer is a rather friendly level editor from Valve that uses Half-Life 2's (or the Orange Box's) engine and allows you to create levels and script encounters with relative ease. I used Flash for level design at Flying Lab Software for UpperDeckU (using the Fancy Pants Adventures engine). As for 3DS Max 9 and Maya I used them at DigiPen for particular projects. Audacity is an audio editor for recording, slicing, and mixing audio which I used to create music and sound effects for Drones, at DigiPen.
If you wish to see samples of Hammer Editor you may go to the Sample area further below, or click here.
  • Cross-disciplined
  • Communications (listening, verbal, written)
  • Analytical thinking
  • Adaptability/Flexibility
  • Leadership/Management
  • Teamwork
  • Planning/Organizing
  • (Creative) problem solving
  • Dependability
  • Reliability
  • Willingness to Learn
  • Professionalism
As a BS and MS in CS, I know a lot about the development part of software and gaming. However, my knowledge and creativity helps me take that technical foundation to a higher level, and makes me a truly cross-disciplined professional.
I consider myself to have excellent communications skills. I listen attentively, and effectively convey my ideas and information verbally or in writing. As a game designer and dev, I have been writing creative and technical documents that require to be clear and precise. When discussing, I prefer to not interrupt, which helps not only in the communication flow but with interpersonal relations and teamwork. Getting along with team partners is vital for maximum efficiency, trust, and achieving our goals. Additionaly, having the ability to listen is key in leadership/management positions. When I lead a team, I listen and give clear focus to our goals, seeking to motivate my team partners to reach it within the constraints defined when planning/organizing. When it is my job to organize milestones and goals, I mediate between quality and quantity of work while paying attention to detail. It is important to be adaptable to the situation and flexible to allow sudden changes to be merged to our workload. This also describes the personal ability to keep your mind open to new concepts and ideas, to work independently or as part of a team, and to be willing to learn from anyone. I don't let ego get in the way.
Both of my degrees have required I use my analytical thinking to identify, scrutinize, improve and streamline my work or that of others. This is definitely paired with creative problem solving: after assesing a situation, seeking multiple perspectives, gather information, and identify key issues I'm able to formulate one or several solutions. Sometimes the solution(s) might be creative, as it involves an unorthodox approach.
Finally, I believe in being professional. I have a strong work ethic, can always be depended on and take responsibility over my work. If I am paid to do my work, the least I will do is the most I can do.

Samples

Game Design Docs

To show my skill in writing a GDD I wrote the following example: a flash mini-game entitles "Flying Pancakes!".



Download this Game Design Document here (PDF): "Flying Pancakes!"

Technical Docs

Technical design and documentation marries my programming background with design.

Similar to Game Design Documents, in TDDs I've used pictures, layouts and flowcharts to support the design suggested. At Flying Lab Software and at DigiPen I was given the task of creating and designing tools and technical features. To develop them I used Microsoft Word, Excel, Visio, XML and Adobe Photoshop, as well as all my BS in CS and my MS in CS knowledge.

To show my skill in writing a TDD I wrote the following example: an in-house level editor for a flash game.

Target users: Design and Art Teams.

Game overview: This editor is for a non-existent flash game called "Play House!". The players are able to create their single-room house and decorate it with furniture. The design team needs an in-game tool to test the content, and create rooms for non-playable characters. Rooms are divided in cells. In each cell the player can place different floor tiles, furniture, and other in-game items.

Goal: The design focuses on user-friendliness and simplicity. A log display shall show each process handled by the tool enabling the user an easy way to find errors.



Download this Technical Design Document here (PDF): "Play House!" Level Editor

Level Design

In this section I present three different samples of 3D Level Design with Valve's Hammer Editor: Jumplatform, Mazescape and the Combine Church. Each sample shows different aspects of Level design, such as basic level design, environment focus, triggers, functions, scripts and logic.
UPDATE (02/19/12): The zip files for Jumplatform and Mazescape are missing, and I haven't found any copies. Until further notice, these samples will not be downloadable. Sorry for the inconvenience.
UPDATE (02/19/12): A new level sample is on the works. Will add it as soon as it is finished!

Jumplatform

This first sample is a small level with puzzle and platformer elements, using Source Engine 2009 and Portal.

Jumplatform
"Tasty stuff at the end!~"


The player's goal is to jump from column to column to the cake poster at the other side. However, sentries are located around the level, each on top of a special column and surrounded by bullet-proof glass (with the exception of a small gap). As the player jumps to a nearby column a trigger will cause the descent of one or more of the sentry's column, thus allowing the sentries to fire at the player with more ease (through the gap in their bullet-proof glass). Every bullet pushes the player, making it harder to stay on a column. If the player falls, he will be teleported to the starting point just as he's about to plunge in Portal's classic "hazardous liquid".


Think of it like a Mario platformer. Just 3D. With bullets.


The design of this level was mostly focused on showing a sample of my use of triggers, outputs, inputs, functions and logic. In terms of gameplay, I decided to keep it simple: you can see the exit and the easiest path to it is laid out before you at the start, yet you have to deal with jumping and keeping track of the sentries's columns. To make it easier, I added a logic_auto to make the player invincible, and added a teleport trigger and destination, to avoid a) killing the player in case of a fall or b) making the player travel up again. For the columns, I tied a func_door entity to them, and made it open "down". This causes the columns to go downwards whenever I trigger them (triggers on each columns opening different "doors" or sentries' columns).


Image just to point out I'm not making this up.


I wanted the level to feel player-friendly by changing the goal from "reach the end and survive" to simply "reach the end". A player might try to figure out which columns trigger which sentries, then choosing the best path. Then again, a player might just keep jumping and trying to get to the other side before the sentries push him to the edge. Either way, the goal is simple, easy, and fun (unless, of course, you are a great and fast jumper, thus making this very easy).

Downloads (in ZIP files)

Download the uncompiled map (VMF): Jumplatform_ErickReyes.vmf
Download the compiled map (BSP): jumplatform_erickreyes.bsp



Mazescape

The second sample is a wider maze level, using Source Engine 2009 and Portal. Unlike most mazes, you're not the one that needs to find the end, but an NPC!


Just don't ask me how they get inside the room. God just pops them there.Maybe I'll add a door later...


In this Portal-based level the player stands on a glass floor, and underneath it lies a maze. The player must guide a npc_civilian (the guy or gal dressed in blue in the maze) through the maze by stepping on the dark squares. Each time the player stands on a square the civilian will run to it. But beware! There are sentries around, and the civilian might get riddled with bullets! The real goal is to find the best route to the area under the blue X.


Triggerland.


In this level I wanted to create something using scripts, and ended up using scripted_sequences, triggers, npc_maker, and nodes. I wanted to give the player a refreshing change in perspective and role. The player is still the hero, but he's not in danger's way: he has to be careful guiding the civilian. For this design to work the places where the player triggers the civilian needed be very clear, and the AI had respond accordingly and immediately. After several tests I found a good combo that worked for me.


Allies only trigger in case other NPCs have funny ideas.Actually, that'd be because there used to be zombies...


I put a scripted_sequence under each dark glass square, and on top a trigger_multiple that would turn on the sequence; the player stands on the square and the NPC walks there. However, you don't want to have several sequences working at the same time, especially since the design called for several dark squares and a precise AI movement. To avoid conflicts, I added another trigger underneath the dark squares, cancelling that scripted_sequence's sequence and flagged to be only triggered by allied NPC. This way every time the civilian reached the destination that particular script would be turned off, avoiding conflicts.

In the end, the level is fun and strategic. I placed sentries in specific places to push the player to think, rather than simply run and stand on the X to make the NPC run there. There is a path to a medkit, or to a crowbar, as well as dead ends and suicidal runs, all in a rather small package. If your civilian dies, don't despair: another will spawn shortly. Try to do it with the less number of civilians killed!

Downloads (in ZIP files)

Download the uncompiled map (VMF): Mazescape_ErickReyes.vmf
Download the compiled map (BSP): mazescape_erickreyes.bsp



The Combine Church

The last sample is a bigger level with pure environment elements based in the Half-Life world (pre-HL2). My goal was to design a church for the Combine. No game elements or challenges. This is purely for environment 3D level design using only what is available.

The Combine or Universal Union is a multidimensional empire in the world of Half-Life. It consists of human, synthetic and alien beings, who dominate Earth and other planets. They are harsh rulers, and use violence freely.

When I designed this level, I focused on specific characteristics of what I imagine in a Combine Church.


With these characteristics in mind, I designed a three-leveled church. The upper level is the "priviledged humans" area, with their own screens, comfortable seating and a view of the attending commoners. The floor level is for the commoners, with simple seating and a big screen where to worship the Advisors. The basement level is the cells and torture area, where all the dirty work is done.

Floor level


Design of the first level, made in Visio (hence the funny little men)


Upper level


Made also in Visio. Notice a pattern?

Basement level


Now, guess which program I used for this.

Downloads (in ZIP files)


Download the uncompiled map (VMF): CombineChurch_ErickReyes.vmf
Download the compiled map (BSP): Combinechurch_erickreyes.bsp
Download the layout document (VSD): CombineChurch_ErickReyes.vsd




An earlier level sample: Drones

Another project I worked as a level designer was in Drones. This is the very first level of the game, presenting a very basic level:



Unfortunately, I was not able to translate most of my designs from concept to actual levels. Time was against us, and most of my levels were constructed on XML. Later on we had a level editor, but time was up and we had to shut down the project.

Game Systems & Player Investment

Let's recap: Game Systems Design encapsulates the design, test, simulation and balance/tuning of game mechanics. The design of these systems can be complex, and is definitely intrinsic to solid gaming experiences. My goal in this page is to present an example of Game Systems Design, and I'll focus on a part of it, named Player Investment Design.
Player Investment Design, as part of Game Systems Design, encapsulates the design, test, simulation and balance of incentive game mechanics. The goal of this type of design is to define a fair (subjective) and proportional (objective) challenge/reward to the player. This can be summed into a simple yet tricky rule: the best reward is not just what is expected based on the difficulty of the challenge, but also adding a little something for the player’s trouble.

To exemplify my skills in both Game Systems & Player Investment Design, I have designed a Team Point System for a multiplayer FPS. The system’s objective is to award the players points based on their team effort during the matches: the more the player cooperates and helps the team win the match, the more points he earns. As the players accumulate points, they will be able to trade them for prizes, ranging from new armor to better looking weapons, plus other possibilities (note: prizes not discussed in these documents – that is part two of this design, and I’m open to chat about it!).

Once designed, the next step was to find the best mathematical formulas to simulate it. The idea is to run a simulation before it is implemented (which gives us an idea of how good the design might be for the player), and then compare it with real data. This comparison will help find any discrepancies with the system, and tune it to offer a better experience.

You can find the spec, the document describing the simulation and the simulation below.



Download this Team Point System Spec here (PDF): Team Point System Spec



Download this Team Point System Simulation Document here (PDF): Team Point System Simulation Document

Download the Team Point System Simulation Excel Document here (XLS): Team Point System Simulation

Download the zip of the Team Point System Simulation Excel Document here (ZIP): Team Point System Simulation zip

Creative Writing

Writing lore and stories for games can be slightly different from simply writing fiction. While you still follow the concepts of narrative (story, character and setting) you also need to take into account the player's sense of character(s) identification and ownership, immersion and reward.

Most game lore, when looked at closely, resembles a short story told in plain text, images, or cut-scenes. Its complexity ranges from simple and straightforward (e.g. Mario saving Princess Peach from evil Bowser) to profound (e.g. Max Payne). As a designer and writer it is necessary to decide in which part of the spectrum our game is, and that in turn is based in our target audience and the game itself. "Is the game for everyone, only teens or for a mature audience?"

The real question, of course, lies with the simple truth: "Does the game need lore to be complete?". Tetris doesn't need drama between their blocks.

Uncharted 2 wouldn't be the same game without it.

Here I show you two examples of an extended introduction I wrote aimed for teen and mature audiences of both sexes. The goal was to introduce the story of a fictional action-RPG game named "Hartwell". The first version is a introductory story, should our players read the story instead of watching it through a cinematic. The second version is the script for a cinematic.

To see how well I have introduced it I explain the overall game concept at the end of the file. If it matches your first impression, then I have succeeded.



Download the introduction story (PDF): "Hartwell"



Download the intro cinematic script (PDF): "Hartwell"





About me

My name is Erick F. Reyes and I am a
Game Designer & UI Software Engineer
residing in the Seattle area. I have
been professionally designing and
testing software & games since 2008
in companies such as Bungie, Flying Lab
Software, Concur and Microsoft.

In depth, I am a creative and visual
thinker with a deep tech background.
This allows me to visualize concepts
from the general to the tech-deep specific,
analyzing features from all angles.
This comes quite handy when dealing with
problems: figuring out how to create and
design software and features under certain
constraints, defining milestones and
schedules, finding/fixing bugs and code,
math, or any other problem using any
tools at hand.

In my spare time I love to play games,
drink wine, read books and play any
musical instrument within reach.

    View Erick F. Reyes' profile on LinkedIn

A UI that copies Windows XP's UI?
Of course there are better UIs, but Windows'
is easily recognized. I chose to follow the
paradigm to get your attention.

Last Update: 07/21/2013