Development Facts:

  • Genre: Adventure
  • Engine: UDK (Gears of War)
  • Development Time: 300 hours
  • Role: Sole Developer

Game Features:

  •  Old-school adventure genre gameplay in the Gears of War universe.
  • Brand new systems: inventory system, conversation system and environment interaction system.

Download Link: Reggie_Icon

High Concept:

Find Reggie, the drinking buddy of a Stranded named Germaine, after the player crashes in Germaine’s apartment complex and eats his food.

Design Summary:

“Reggie” is a single-player, standalone level for Gears of War. Unlike traditional Gears levels, “Reggie” plays like old-school adventure games, where player must talk to NPCs and solve inventory and dialogue puzzles. “Reggie” feature several new systems not present in Gears of War: a conversation system, an inventory system and an environment interaction system using hotspots.

The level takes place sometime before the events of the main campaign, and in this level players assume the role of an unnamed Stranded, who wakes up after a heavy night of partying in an unknown apartment complex. Players must first find a way to satiate their hunger, before discovering the apartment belongs to another Stranded named Germaine. As a form of compensation for eating the available food, players must find Reggie, Germaine’s drinking buddy.

Design Goals:

  • Turn Gears of War into a completely new genre. In this case, an adventure game.
  • Preserve all of the adventure genre’s systems into an engine with no native support for them, without access to the game’s source code.
  • Make a fun, light-hearted adventure experience, reminiscent of the genre’s classics like Secret of Monkey Island or Broken Sword.

Design Document: wd

Gamasutra PostmortemGamasutra



Overview Maps:



Design Challenge: Inventory Size

Adventure games tend to have inventories with lots of items that the player can pick up and use at almost anytime throughout the game.

To implement the inventory, I used Unreal’s UIScene Editor, since Gears does not have support for Scaleform. Each item was represented as a boolean in the persistent level. The main problem with this approach was that UIScenes cannot read variables from the level. As a result, I had to make a binary search tree and opening one or another UIScene depending on the combination of items the player had.

The problem is apparent here: the total number of UIScenes depended on the number of items the player could have at any given time. If the player could have 3 items at one point, that would mean 2^3 = 8 UIScenes. If it was 7, on the other hand, it would be 2^7 = 128 UIScenes. Talk about extra workload!

To solve this, I divided the level into 5 stages, with items that were present only on that stage, for the most part. I allowed some items to be used in more than one stage, to preserve the use of items in more than one instance, like adventure games do. These five stages determined the level’s streaming and packaging system, and allowed me to implement several items without creating an insane number of UIScenes. Below is the search tree for the third stage, when the player has to fix the elevator.




Design Challenge: System Design

By far the greatest challenge when creating “Reggie” was designing systems that were fully functional, bug-free and could be easily understood by players. I will talk here about each system, explaining how I implemented it on Kismet, Unreal Engine’s visual scripting language, since Gears of War does not grant access to the game’s source code.

Conversation System

This is the most straightforward of the systems. Each NPC is a SkeletalMesh that has a looping Matinee that represents their idle state. To interact with them, there is a separate stream that contains a trigger that, when pressed, starts the conversation. In the following screenshot, it is the Conversation_Germaine_Stage2_Introduction event.

In said event, I unhide the Skeletal Meshes that represents the player, open up the UIScene that represents the dialogue choice, and play a second Matinee that represents the idle state of the NPC during the conversation. Cinematic Mode was enabled when the player pressed the trigger.

At the end of a conversation, said whenever the player says “Goodbye” or presses Escape during any UIScene (a limitation of the Gears editor), I switch off Cinematic Mode, hide the player SkeletalMesh so the player doesn’t see a version of himself doing a T-pose, and finally I stop the idle animation of the NPC.

Of special mention is the bIsTalking boolean variable. The reason I put this was because the program closes the UIScene in two ways: calling a Close Scene action, needed in order to display the next bit of conversation, or by pressing Escape when the player was deciding a response). The problem of this second way was that, if executed, the player would remain stuck forever in Cinematic Mode, unable to progress. To solve this, I created this variable and called the event that signals the end of the conversation, Conversation_Germain_Stage2_Close in this case, everytime the UIScene is closed. Thus, when the player presses Escape, it immediately ends the conversation, and if the characters are talking, it doesn’t do anything.


Regular dialogue between characters is straightforward: it’s a series of Matinees where before they start I close the current UIScene and after it I either open a new UIScene or trigger events that give the player items.



Environment Interaction System

The second system present in “Reggie” is the environment interaction system, which takes the form of hotspots signaled by spinning exclamation marks. You can see these exclamation marks in the screenshots, trailer and playthrough of “Reggie”. I chose the exclamation mark because, by its very nature, is a sign that draws people’s attention. To increase player attention, I put a white material around it and made it spin using a simple Matinee. This way, people could scan a room and immediately see what were the points of interest.

Now, what happens when players approach the hotspot and press the trigger associated with it? Let’s use as an example the cookies the player picks up at the beginning of the level.

When a player touches the trigger or presses the interaction button, I call an event that tells the systems that the player is currently interacting with the cookies. In this case, it is called Environment_ActivateCookies_Press. This event consists of a sequence where it sets every possible hotspot as “not interacted with” (including the cookies), only to tell later that the player is interacting with the cookies, by setting the bEnvironment_Cookies boolean as true. This way, I ensure that the player is always interacting with the right hotspot, though this has the limitation that there must not be any overlapping triggers, otherwise you could try to interact with an item and get a completely different result than expected.



Now, when the player presses the trigger the hotspot, I also open the UIScene that determines the interactions with the environment. It consists of four verbs: Examine, Use, Use Item From Inventory and Take.

If players want to EXAMINE the cookies, they press the Examine button in the UIScene. This calls an event that looks between all the hotspots in the environment for the correct match. In this case, since we pressed the cookies, it will trigger the Environment_Cookies_Examine event, since from our previous pictures, bEnvironment_Cookies is true. For TAKING and USING items, the procedure is similar. However, for TAKING items, if the player can actually take the item, I destroy the trigger, so the player cannot pick up the same item twice.

The Environment_Cookies_Examine event consists of just a sound cue describing the item. However, other events are more sophisticated, as we will next see.



Of special note is the Use Item From Inventory button. This button allows players to quick-select an item from their inventory and apply it to another one directly. The first iteration of the user interface required players to approach the hotspot, open their inventory, select the item and press “Use”. After several playtesters complained this was unintuitive and suggested the Use Item from Inventory feature, I added said feature, immediately improving usability, which is crucial in adventure games.

Let’s take the example of using the towel for putting out the fire with the towel that is present on the trailer. The player approaches the lighter hotspot, presses the trigger and selects “Use Item from Inventory”. A screen like the one below appears and players select the towel. The selection of what items to display is a separate binary search tree, similar to the one display in the Design Challenge: Inventory Size section.

When players press the towel button, the UIScene calls the event that tells that you’re using the towel not from the inventory itself, but rather the environment. In the case of the towel, it is the Inventory_Towel_Use_FromEnvironment event. This event says that we’ve selected the towel from the inventory, closes the current UIScene and finally uses the towel itself and calls the Inventory_Towel_Use event.

For using items, we check if we’re using the item with the correct hotspot, since we started this interaction by using the “Use Item From Inventory” option, which opens up when we interact with a hotspot. If not, we play a failure sound cue. If true, we take the necessary actions, like putting out the fire and enabling the player to take the lighter, in this case. Other item uses follow a similar procedure.



Inventory System

The other major system present in “Reggie” is the inventory system itself, where players can see what items they’ve picked up so far, examine them, use them in the environment or combine them.

To represent items, there is a boolean for each item. There is also a “Selected Items in Inventory” section, when players click on an item button in the inventory screen.



To open the inventory, I overrode one of the game’s actions -the button that displays the location of allies in battle-. When players press that button, it checks the current stage of the quest, calling then the respective binary search tree which was already explained in the Design Challenge: Inventory Size section.  Below is the binary search tree for the third stage of the quest, when players have to fix the elevator by using the wire cutter and wires.




After this process, players see the inventory screen. To use items, they must first click on the item and then the action that they wish to perform. To combine items, they have to select one item, press the “Combine” button and then select the other item.

When the player selects an item, it triggers an event that represents that the item is currently selected. Notice the bCombine boolean check. This exists because of the procedure explained beforehand for combining items, so we always need to check, when selecting an item, if we are going to combine it now.


When the player clicks on the inventory action, one of the three actions on the picture below occurs, depending on the action clicked. For EXAMINING and USING items, I first set the boolean to that action as true, then I go to check what event to trigger, depending on what boolean is true. Finally, once we know what action to execute, we check, item by item, which one we actually clicked on the first place, executing the proper action.

For COMBINING items, we only set the bCombine boolean to true, so the next time you click on an item, you know which items to combine. So, if we want to combine the towel with the lighter, we need to make check combinations on both items, because we don’t know what item the player will click on first.



Below is an example of a successful combination, between the cheese and the bread.


Finally, here is the full Kismet for one item, the wire cutter:


Screenshots and Videos:


Screenshot Gallery

[gmedia id=12]


Full Playthrough with Commentary:

Comments are closed, but trackbacks and pingbacks are open.