The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.
As part of the Directed Focus Study I course at The Guildhall at SMU, we were asked to do a solo project in the Gears of War engine that really pushed its boundaries. Since I've always been a lifelong fan of adventure games like Monkey Island, The Longest Journey and Grim Fandango, I decided to make an adventure level into the engine that played like one of those classics.
This was a very challenging project, since Gears of War is a third person shooter, and that meant that none of its core mechanics, like cover or shooting, would be useful for my purposes. This meant that I had to design and implement all the gameplay systems from scratch, only using Kismet, Unreal's visual scripting language (Gears of War does not grant access to the source code).
After 300 hours of work, which include documentation, prototyping, building, testing, re-building, re-testing... (you get the idea), I can finally say that I'm proud of turning a third person shooter into an adventure game. I learned a LOT from the development, and these lessons are what I'm sharing with you in this feature.
What Went Right
1- Scripting Pipeline Figured Out Early: The first big challenge of this project was figuring out how would I be able to implement an inventory system that allowed for item combinations and was scalable, so if I wanted to add more items, or more hotspots, I could do it easily. For this, I approached the problem by dividing it in two: inventory items and hotspots, and creating a dedicated, though similar, pipeline for each of them. This also meant that any item that could be picked up had to be treated in two different ways, depending if the player had picked it up or not. The nuts and bolts of the pipeline are on the project's page (http://www.joseabalos.com/solo-projects/reggie/), but sufficient to say, I managed to implement all the major systems of the game, including most of the level's scripting, by our Whitebox milestone.
2- Design Given Technical Constraints: One of the first constraints I found was the communication between Gears' UIScene editor (Scaleform before Scaleform) and the level. The idea was to make it so whenever I opened the inventory, the inventory scene could read what items I had and display them, That was not the case: basically, the inventory scene could not read anything from the level. This meant that I had to make one inventory scene for any possible item combination, selected by a binary search tree. This tree can quickly grow out of control: if the player could have 3 items at the same time, that was 8 scenes (2^3). 4 items, 16 scenes. 5 items, 32 scenes. And so on...
Since adventure games usually allow the player to pick up several items, this meant that there could possible be thousands of different scenes, and I wanted to keep my sanity. Instead, I designed the stage in five "stages" that represented important story beats and had items that could only be picked up and used in that individual stage (with a few exceptions, to keep things interesting). This decision influenced everything from level streaming structure to package convention and naming conventions of files. Thankfully, I was able to figure this out quickly and design the level around this problem instead of charging head-on and possible become insane.
3- Atmosphere: One of the core tenets of adventure games is a strong sense of atmosphere, which invites players to explore the world around them instead of plowing through it. To achieve this goal, I used music from games like Grim Fandango and the Telltale Sam & Max games, with a smooth, jazzy vibe, which reinforced the idea that this was a relaxed, lighthearted level. Other ways in which I tried to add atmosphere to the level are the story and the dialogue with characters: the story is about a Stranded who looks for the titular Reggie in the hopes of getting free booze (or a unicorn that poops rainbows, if the player chooses the appropriate response). On the dialogue side, many of the dialogue trees have a non sequitur answer, in the spirit of The Secret of Monkey Island (when asked who they are, the player can respond “I’m a banana”, along with the more straightforward answers). This all reinforced the idea that this was a Gears of War level unlike any other.
4- Environmental Storytelling: Another way in which I tried to add atmosphere into the world was making every area visually distinctive, where just looking at the space could tell the story and personality of its inhabitants. This implied making lots of custom posters and models like microwaves or lighters.
5- Communication: Since I was teaching new mechanics not featured in Gears of War, communicating them to the player was crucial. Using tutorial messages at the beginning of the level, using custom exclamation marks to denote the hotspots in the level, and forcing the player to take, use and combine items before proceeding with the rest of the level, testers understood how to play the level and proceed without any difficulties.
What Went Wrong
1- Scope: Trying to make a completely new game, with completely new mechanics, turned out to be incredibly time consuming. This is because Kismet does not feature classes or functions, so adding a new hotspot to the game could take a long time, since I needed to propagate the changes throughout many places in Kismet, even if it was well-organized. Even though I’m quite proud of the end result, it took way more time than I thought it would.
2- Limited scope in puzzles: Adventure games usually feature many items and hotspots to incite players to poke around the world and explore. Because of the technical difficulties mentioned before, I limited myself to only have three items at any time, so the solutions to the puzzles were fairly straightforwards.
3- Not much room for dialogue iteration: Dialogue trees were especially time consuming to create, since I had to record every single line of dialogue by hand, import it into a package, creating a corresponding sound cue and adding it to the corresponding Matinee. Since I was short on time and I also had to create every other aspect of the level (lighting, clutter, etc.), I could only make a first pass on the dialogue. If I revisit this project again, I’d make sure to write a second pass on the dialogue, so it feels more natural.
4- Naming convention of audio files: Related to the dialogue trees, there were a lot of dialogue lines in the level. I used a naming convention that made it difficult to track down which sound cue to add to the conversation, or what name a new cue should have. This is a problem when the name is comprised almost entirely on numbers instead of a more descriptive name.
5- Visual Detail: My strengths lie mostly in scripting, and the part of the level design that I enjoy the most. Still, I tried to push my limits in visuals, by making a believable environment. Still, I think I could’ve done a better job with lighting and clutter.
What I Learned
1- Iterate on Feedback: Creating intuitive systems was a pretty challenging process, but testing the systems early helps you see what is right and what can be improved. As an example, players who wanted to use an item in the environment had to open the inventory, select the item and select “Use” while standing next to the hotspot. However, testers had a hard time understanding this process, so instead I enabled an extra option called “Use Item From Inventory” when interacting with a hotspot. It took a fairly long time to implement, but the end result was more intuitive gameplay.
2- Organization: There were a lot of custom assets and scripting elements that went into making this level. As such, being organized, keeping a consistent naming convention across assets was crucial for keeping tabs on the project packages. This organization has carried over to my following solo and group projects.
3- Adventure Games are a lot harder to do than they seem: I’ve always loved the adventure genre because of the unique combination of story and gameplay. What I did not expect to find, while creating “Reggie”, is the sheer amount of work that is behind them, especially in writing. Having four verbs for every hotspot meant that I had to create four audio cues for every possible combination. Players want to take a piano? That means an extra line of dialogue. Want to use the lighter with the elevator? Another line. Trying to think of all those possible combinations, while showing the character’s personality through those actions, was a very challenging process.
4- Humor is harder to make than it looks: Knowing what makes people laugh, and trying to convey that through dialogue is a pretty challenging process. Many times, the reason why it succeeds is because of the combination between the dialogue and the voice acting. Relying only on text makes it harder to make people smile. Still, learning this was a great learning experience.
5- Be careful when mixing genres: Since Gears of War is a third person shooter, and there is one area in the level that shows the aftermath of a massacre, I thought it would be a good idea to put a short firefight between the player and the Locust, in order to keep the player on their toes. However, it made for a pretty jarring experience, since players had spent the entire time solving inventory puzzles, without worrying about combat, when suddenly they were thrust into traditional Gears gameplay. In the end, I eliminated the fight and learned a valuable lesson: if you want to add different genres, show to the player those types of gameplay as early as possible, so they know what to expect from the level.
In the end, “Reggie” was a fun, challenging and rewarding level, which pushed the limits of what I could do with visual scripting and prove that, yes, you can make a completely new game in Kismet. It just takes a lot of time to get it working properly.
If you want to see more of my projects, you can always visit my portfolio website: http://www.joseabalos.com. Thanks for reading!