Mission 2.2.2: We’re not Giving Up – Part 2

Summary

Here’s a quick summary. For those of you who like to read, hit the jump for a truckload of detail.

• This mission is about protecting Rick Jones in a helicopter as he travels from rooftop to rooftop disarming bombs.
• The mission ended up very fun and memorable; this is mainly because the mission is built around a fun and novel challenge–jumping from rooftop to rooftop.
• The first major design task was to find a suitable set of rooftops to provide compelling inter-rooftop locomotion. I found this in a set of unique skyscrapers in midtown west, which offered challenging and varied locomotion challenges.
• The next task was to settle on a central challenge for the mission. I quickly decided to focus the gameplay around rapid inter-rooftop locomotion. To achieve this challenge organically, I set the helicopter to circle each rooftop, continually damaged by enemies until Hulk arrives to save it. All of this emerged from the focused premise of rooftop locomotion.
• I decided against adding peripheral challenges like protecting Rick himself when he leaves the helicopter; these proved a confusing distraction from the mission’s main trajectory.
• I did, however, throw in some unexpected variety, in the form of an emergency crash landing late in the mission, accompanied by a special objective to carry the final dispenser to Rick’s position on the ground. As a one-off event, this added some variety to the mission without throwing it off kilter.
• Hence, my recipe for a compelling mission: Hone a central challenge for your mission that drives the gameplay forward and makes a story for the player, without extraneous challenges getting in the way. Once you’ve accomplished this, throw a wrench in the works somewhere for a little unexpected variety.

For much, much finer detail, please read on!

Details

Story and Background

This is a mission about bounding from rooftop to rooftop, smashing enemies and protecting a helicopter piloted by Rick Jones. There are some poisonous chemical dispenser doohickeys on rooftops, and Rick has to land his helicopter near each one and spend a few moments disarming it.

As I’ll describe below, this mission ended up working out really well with our locomotion and combat systems; when I speak with people who have played Incredible Hulk (which is rare), they always seem to remember this mission. Furthermore, like Jesus, this mission once died and was later resurrected. It had been part of an entire storyline that was cut from the game during Alpha, but we all loved the mission so much that we rewrote it a bit and squeezed it into a different plot.

Early Layout

There are a lot of missions in Incredible Hulk that involve Rick Jones running around and disarming bombs. On paper, this mission didn’t seem a lot different than those–yes, these bombs were on rooftops, and yes, Rick had to land a helicopter on each rooftop, but otherwise it seemed pretty familiar. As it turned out, though, the rooftops and helicopter ended up making all the difference.

We recognized early in development that rooftops were some of the best locations in the city–the skyline vista is beautiful, and jumping between rooftops can be lots of fun. (Of all the minigames in Hulk, my favorite is the one that has Hulk jumping among rooftops for as long as possible without falling.)

In the early phase of implementation, I spent a lot of time locomoting around the city, looking for a good assortment of buildings to maximize this experience for this mission. My selection criteria were primarily gameplay, secondarily aesthetics. I knew I wanted to make bounding between rooftops a compelling and central experience in this mission, so I spent a lot of time finding a group of buildings that were interesting and challenging (but not too challenging) to locomote between. I also needed these rooftops to be large enough to accommodate Hulk, a number of enemies, a bomb, and a helicopter. Finally, less important but still crucial, I wanted the buildings themselves to be visually interesting and offer great views.

I was lucky enough to find a solution to all these criteria in a selection of five skyscrapers in Midtown East. It didn’t take me too long to figure out that there were a lot of interesting buildings and locomotion options in this part of the city, but I spent plenty of time identifying the best buildings and the best order. I spent, oh, at least a day jumping around and around in this area, trying to find some interesting chains of rooftops. The chain of five buildings I settled on offered a nice mix of locomotion–sometimes jumping downward from a higher roof to a lower one, other times chaining jumps over one or two intermediate buildings, other times solving little puzzles about how best to get from one area to another. I’d purposely chosen some of the tallest buildings in the city, and as such most of them have unique models with interesting architecture; their height also offers great vistas, moving from a Central Park view over to an East River view as the mission progresses. So, I had satisfied my initial criteria for gameplay and aesthetics. Check and check. It was now time to start laying out the gameplay.

Design

Establishing a central challenge

In laying out and scripting the gameplay, one of the first things I needed to figure out was how I wanted to challenge the player. When laying out gameplay, it’s tempting to dump the whole bag of tricks on the player and give him 10 different challenges all at once; this is a terrible idea though, because the player will lose track of his objectives, and besides, he can’t make a story out of a mishmash like this.  Instead you need to take on the much harder task of honing your challenges into one or two things that unify into a central, driving purpose. In this mission, I could ask the player to survive challenging brawls, to protect Rick’s helicopter, to protect Rick himself, to complete the mission within a time limit on the chemical dispensers, to smash some other chemical dispensers before they explode, to stop a group of enemies from reaching a rooftop, etc., etc. But that would have been too much.

I decided to focus the challenge on the locomotion between rooftops, which I knew to be both a fun activity and something that wasn’t used much in other missions. I played a bit with using timers to require the player to arrive at rooftops before chemical bombs exploded, but this felt arbitrary and gamey. A more natural solution, I realized, was to tie this challenge into protecting Rick Jones, which is the central narrative point of this mission. This led me to the basic mission structure that would survive in the mission’s final form: for each rooftop, Rick’s helicopter flies straight to the roof area and circles. The helicopter is vulnerable to damage, and its health meter is onscreen throughout the mission. Enemies spawn on the rooftop and shoot at the helicopter; the helicopter won’t land until the player arrives and defeats all the enemies. This is a simple setup for players to grasp, and it creates the locomotion challenge organically–needless to say, if the player does not quickly locomote from one rooftop to the next, the helicopter will be destroyed and the mission failed. With this, the need for contrived devices like timers is obviated by a challenge that emerges (or at least seems to emerge) directly from the story.

When adding challenges is a bad idea

I also spent a little time toying with additional challenges. In the initial design doc, Rick is vulnerable during the portions of the mission when he leaves the helicopter. (The plan was for him to leave the helicopter after landing, and go over and disarm the chemical dispenser.) I toyed with this, but it confused players–it required a second health meter, one for the helicopter and one for Rick. Furthermore, this challenge detracted from the central premise I’d established of protecting the helicopter as it pushes forward. So I was much happier to simply make Rick invulnerable and have all enemies target Hulk and the helicopter, rather than Rick himself. This worked just fine, and kept the player focused on the other challenges.

This decision was definitely for the best. The AI programming team ended up so overworked late in the project that we were never able to properly locomote Rick out of the helicopter after landing–it was hard enough just to get the helicopter to move around and land. Since Rick’s leaving the helicopter was not an essential part of the mission, it was easy enough to cut this behavior from the mission and say instead that he was disarming the chemical bombs “remotely.” Okay, this sounds a little odd, but it was not nearly as bad as seeing Rick materialize out of thin air next to his chopper.

When adding challenges is a good idea

I was pretty happy with the basic mission structure at this point; it seemed to offer these periods of intense brawling spaced out with different-feeling, but equally intense periods of rooftop bounding. I liked this flow a lot. But some of my guinea pigs said it felt monotonous after a couple of rooftops–after all, there were five rooftops at this point, all of them with similar objectives. I knew that some of the monotony could be alleviated by adding enemy variety, but that probably wouldn’t be enough.

So I added a separate objective late in the mission, which comes as a surprise to the player: Rick’s helicopter is hit and needs to set down on the ground, so Hulk is tasked with grabbing the chemical dispenser on the final rooftop and carrying it down to Rick. This provided that “oh, awesome!” moment that broke up the mission a bit and gave it some variety; everyone seemed happy with this, and so was I. Luckily this was still early enough in the project that I was able to request all the necessary VO to support this turn of events, and it worked out beautifully.

This is an example of when it’s a good time to add an extra challenge to your mission, something which deviates from your central premise: to add something unexpected to the mission flow. In this mission, it was the unexpected helicopter crash; in the tank escort mission, it was the sudden appearance of a drop ship. Here’s what I’m saying, my recipe for a compelling mission: Hone a central challenge for your mission that drives the gameplay forward and makes a story for the player, without extraneous challenges getting in the way. Once you’ve accomplished this, throw a wrench in the works somewhere for a little unexpected variety. Bake it just right and you will find you’ve cooked up one tasty mission.

Technical Challenges

I knew of course that rooftop brawling would be a critical part of the mission, essentially making up half the gameplay. The enemies needed to be (1) tough enough with projectiles to damage the helicopter; (2) tough enough to provide at least a little bit of a melee challenge for the player after he arrives; and (3) varied enough to keep things interesting throughout the mission. Satisfying any of these requirements, let alone all three, was a challenge through most of the dev cycle, for several reasons.

• The enemy and weapon data underwent continuous tweaking throughout development, without ever getting locked down. I’m not complaining–this is pretty much necessary under such an accelerated development schedule–but it makes the mission designer’s job pretty damn hard. I had no way of knowing, for instance, what the range of various weapons would be, or how much damage they would cause to the chopper. I could have put off balancing the mission till the last minute, but I wanted to have some assurance that the mission would actually be fun. So at several points in the dev cycle I made sure I balanced the mission to the current state of the enemies and weapons, making sure that fun was achievable.
• Throughout much of development, I was not sure whether I would be able to spawn enemies on rooftops. I and several other designers pushed hard for rooftop spawners (rooftop stairwell exits), but for a couple of reasons they were caught up in the art and programming pipeline for a long time. I had to script out the whole mission on the assumption that I wouldn’t get rooftop spawners. To avoid popping enemies in right in front of the Hulk, this meant spawning all enemies on rooftops before Hulk arrives. Any extra spawns had to be flying soldiers that could be spawned out of sight below rooftops. It worked okay this way, but I really wanted the flexibility to spawn extra guys from rooftop spawners; this could provide for more intense encounters when I needed them. Finally, within a week or two of final lockdown, we got those rooftop spawners, and I scrambled to re-implement the mission to accommodate them. It was totally worth it–the brawls got crazier and more substantial, with greater variety both in enemies and in pacing.

The rooftop locomotion provided its own challenges. From time to time, the environment team would move buildings around in the city. This drove the designers crazy, because this was the city where we’d laid out all our gameplay–our spawn points, our way points, our bombs and cleansing devices. At one point, one of my skyscrapers was moved. It had been so perfect for my mission that we got it moved back. I’m very glad we made that happen.

Lessons Learned

Lesson 1: If you discover an awesome moment in your video game, make sure you construct a mission around that awesome moment. You’ll achieve a unique and compelling mission–like this mission, which took the awesomeness of rooftop locomotion and ran with it. Never push the crazy, wonderful stuff to the periphery of a mission, even if it’s not central to the story–rest assured the player will make his own story out of it.

Lesson 2: As a designer, be flexible. Know that you may not get what you asked for (e.g., Rick leaving his helicopter), and your colleagues’ iterations can and will require you to change everything once, twice, x times throughout the dev cycle (e.g., the constantly evolving enemy data and the uncertain availability of rooftop spawners). Each time a new constraint requires you to rework your mission, treat it as an opportunity to improve your mission.

Wow, this is starting to sound like the transcript of a motivational speaker. I better stop.

I returned from Toronto a couple of days ago. Toronto was really great. Everyone was riding bikes around–and as a means of transportation, not as a sport. How refreshing. Ji-Ming and I thought the busy, happy urban atmosphere felt a lot like Taipei; of course, we were staying in Chinatown.

I was up there for Flash in the Can, a very fun Flash conference. This was my first Flash conference, and it was very interesting to discover how the Flash community is different from the game development community. Their terminology is all backwards–they say “developer” instead of programmer, and “designer” instead of artist. Oh, and there are actually women in the Flash community.

What I didn’t like is that Flash developers tend to be so reverent of advertising. Someone might say to me, “yeah, my company worked on campaigns for Nike and McDonalds,” and they expect me to be impressed. I know that ads drive most of the money in the Flash world, but it makes me uncomfortable to think about this. One of the reasons I first went into game development, having happily left careers in science and education, was because I wanted to make things for real people. I wanted my paychecks to come from people who pay for my stuff because they want it, rather than because I convinced the government or some agency that what I’m doing is valuable. Of course, once I got into the AAA game industry, I quickly realized how shallow and non-artistic it is, and (like most people in the industry) I yearned to break off and go indie. So now I’m doing small games on my own, and I’m doing whatever I want, even if that is sometimes an experimental train wreck like this. But in order to actually make some money, I find myself signing contracts and making deals with marketing companies. So without realizing it, I’ve started drifting back toward the situation I fled–I’m making things for agencies rather than real people. Maybe I’m just complaining too much, but I feel very conflicted! I mean, for heaven’s sake, back when I had functional convictions I subscribed to Adbusters! Now look at me, making art for ad men who live in L.A.

Okay, I’m done. Back to FITC. I was attending the conference as a representative of actionscript.org, and I ended up posting a bunch of blogs over on their site. Here they are:

FITC Day 1: The intersection of math and art
FITC Day 2: Flash in Console Games
FITC Day 2: Running a Freelance Business
FITC Day 3: Dimension Wars
FITC Day 3: Cool Japanese Stuff

Mission 1.1.3: The Enclave and Rick Jones – Part 3

Summary

What follows is a brief summary of the much longer essay that follows the jump. If you are in a reading mood, feel free to skip past this summary and jump right into the meat.

• Mission 1.1.3 is an escort mission in which Hulk protects a tank as it travels through a series of Enclave roadblocks.
• I took over this mission very late in the dev cycle, so I had no access to additional VO or tech.

When I received it, the mission was in very rough shape:

• The basic setup: Tank moves continuously forwards, with enemies spawning in random positions.
• This design created boring gameplay due to our AI and systems design–enemies would have trouble reaching and keeping up with the tank.
• Hazy mission objectives. The player had no idea what to do, whether to stay with the tank or hunt down the soldiers.
• Overall, no excitement, no challenge, and a lot of homogeneity.

My redesign centered on one core concept: breaking the mission into a series of constrained encounters with clear objectives.

• Instead of spawning randomly, all enemies are hand-placed at intersections, forming roadblocks.
• The tank comes to a stop at each roadblock, and does not move on until all enemies are defeated.
• The player is told explicitly to defeat all the enemies.
• The player is also told to bound ahead to the next roadblock as soon as the current roadblock is cleared.
• As a whole, these edits discretize the mission into a series of brawling scenarios (at roadblocks), interspersed with a series of locomotion scenarios (between roadblocks). This provides a basic heterogeneity to the mission flow, as well as establishing clear objectives and rewards for the player.

The mission played much better at this point, but monotony remained an issue. I did my best to maximize variety as follows:

• Varying the enemy types, numbers, and positioning at the different roadblocks (as much as I could).
• Adding a drop ship encounter in the middle of the mission. The drop ship is placed at the end of a long corridor down Broadway, which naturally draws the player’s eye to the surprising reveal.
• Adding several waves of enemies at the final encounter (after the tank has arrived at its safe house), to provide a longer, more challenging fight as a climax.

Reasons why this mission (and the game in general) thrived on carefully scripted encounters like these rather than more open-ended objectives:

• Unpolished systems due to the compressed dev cycle; rewarding gameplay could not be left to chance, and had to be carefully scripted.
• Basic gameplay in Hulk was a very focused brawler system without extraneous elements; there is rarely more than one way to accomplish a given task, so why confuse the player with vague objectives?
• The game’s target audience is the mainstream audience of the film, quite the opposite of core gamers. Thus, careful player direction was a priority.

Details

Story

Rick Jones has stolen a tank and is attempting to drive it to his safehouse in midtown Manhattan. Naturally the Enclave (enemy military) is attempting to stop him. Hulk’s job is to protect the tank and clear out the enemies at a series of Enclave roadblocks.

Background

I took charge of this mission very late, just two or three months before the game shipped. This may sound like no time at all in the dev cycle of a AAA game, but this game was so rushed that those two or three months were when everything got done. The previous owner of this mission had been so busy with other tasks that it was still in an embryonic state when I took over. This was actually a good thing, because I didn’t have to worry about her being too attached to her baby and I was free to totally overhaul the mission–which I did.

Design

A basic escort mission, right? Well, yeah, I guess so. But that doesn’t mean it was easy to design or implement. Generally, escort missions tend to be boring or frustrating (or both). So I had to make it interesting and forgiving, somehow. I also had to deal with a myriad of constraints in our engine and gameplay systems, which I’ll detail below.

Before I got my hands on it

I will be saying a lot of negative things in the next few paragraphs about the state of the mission when I received it. I want to emphasize that none of this is a criticism of the other designer’s work–she had simply no time to work on this mission. Given the little time she had, it is actually impressive that the mission functioned at all. So what I’m describing here is an example of institutionalized neglect, not bad design.

When I first took over this mission, it was fully playable but deeply boring and tedious. The mission had mostly been laid out at an early stage of development, before any of our gameplay systems were functional–and it showed.

The gameplay had been laid out as so:

• The tank was set on a path from the NY Public Library through Midtown to Rick’s safehouse on the West Side.
• The tank was set to move forward at a constant speed from start to finish, without stopping.
• The mission was completed when the tank reached the safehouse; the mission was failed if the tank was destroyed.
• Roadblocks consisted of barricades, crates, and other destructible objects placed in intersections along the tank’s path.
• Enemies were set to spawn randomly near the tank as it progressed, and attack the tank.

In this design, the designer had used a very light touch, allowing the tank, the enemies, the barricades, and the player to interact as they will, and utilizing very natural-seeming complete and fail conditions. I would describe this design as extremely optimistic–in the ideal open-world game, perhaps, game systems (AI, physics, and combat mechanics) would work together to create interesting behavior from an open setup like this. But of course, this was not the ideal open-world game. Generally, as I had learned, our systems did not work together on their own in any way, unless they were carefully laid out and scripted to do so.

Here is how the mission played:

• Due to lots of issues with physics and vehicle behavior, the tank regularly got stuck on obstacles and ended up stationary or driving in circles until Hulk smashed the detritus.
• Enemies, spawning in random locations near the tank, had similar pathing problems, and tended to be very slow in reaching the tank; even if they did reach the tank, their movement speed was about the same as the tank. As a result, the mission experience consisted of one or two soldiers straggling along loosely behind the tank, meekly firing off shots as the tank barreled onward. Obviously not the most exciting (or challenging) of scenarios.
• The player had no idea what he needed to do–should he hunt down the enemies stuck on hot dog carts and scaffolding at the edges of his minimap? Should he focus on the enemies tagging along behind the tank? Or should he focus on smashing the obstacles that the tank kept getting hung up on? There were no clear objectives, and in any case it didn’t much matter, since it was almost impossible to fail the mission.
• The mission was long and repetitive; there was no variety at all in the gameplay.
• When the tank did finally reach its destination, the mission would end abruptly, even if Hulk was busy fighting enemies.
• One thing I liked: the path of the tank, which took the player on a dramatic trip through the Times Square area, one of the most beautiful areas in our game. This was only the fourth mission in the game, so for many players this would be their first time in the neighborhood.

After I got my hands on it

I spent a few hours playing through the mission, and getting others to play it as I observed. All the while I took down lots of notes, which culminated in a list of what worked and what didn’t, very similar to the list above. As I planned out my redesign, I was careful to address each of the negative points individually, so that I would have a way to hopefully deal with them all when I sat down to rebuild the mission.

Discretizing the gameplay into a series of encounters

As a result of many iterations of redesign, I came up with a number of design decisions to address the issues I’d identified. In general, my redesign had restructured the mission as a series of encounters with strictly defined objectives.

Here are the two fundamental decisions that inspired the redesign, in detail:

Design Decision 1: Spawn all enemies in clusters at intersections, at hand-placed spawn points instead of random positions. Set the enemies’ AI to guard their spawn positions until the tank reaches them.

• This addressed the issue of enemies getting lost and stuck, because enemies would not leave their post until the tank arrived in front of them.
• The clusters of enemies provided a nice visual representation of a roadblock, so I was able to remove the barricades and other obstacles that had been tripping up the tank. Good riddance–other than visuals, the only possible gameplay function the obstacles could have served is to require the player to smash them, which isn’t fun.
• Spawning all of the enemies in groups provided some ebb and flow to the action, which is always extremely important in an action game. When enemies are continually spawned at random positions and a fixed spawn rate, the mission feels monotonous; when enemies are spawned in groups with a short lull in between, things instantly get a lot more exciting.

Design Decision 2: Have the tank stop moving when it reaches each roadblock, and not start moving again until all enemies are defeated. Provide a clear text objective to the player to “defeat all the enemies so Rick can continue.”

• This prevented the very unexciting effect of enemies feebly chasing after the tank.
• This also provided a clear objective for the player. This was very important, due to the confusion and frustration the player would feel otherwise.
• When the tank arrived at a roadblock and stopped, I was able to tell its AI to begin attacking enemies. This added a lot to the “awesomeness” of the mission–seeing the tank take out the final mutated soldier at a roadblock with a well-placed cannon blast can be very cool. This had not been possible in the previous design, because the game’s AI is not capable of reliably following a path and fighting at the same time.
• This design further emphasized the burst in action at each roadblock; when the tank actually stopped instead of continuing on its way, a static encounter was created for the player, which was full of action and alternated with less frenetic scenes, for a nice roller-coaster effect. I had learned as a mission designer (as I will discuss at length later on) that creating fun within the auspices of Hulk’s game mechanics depended on carefully defined encounters like this.
• Continuing with this design pattern, I made the obvious decision to require the player to defeat all the enemies at the safehouse before the mission completes. The alternative, ending the mission immediately when the tank reaches the safehouse, is anticlimactic and illogical.

To implement these changes, I had to dump the mission script and start over, as well as laying out a series of separate tank paths instead of one long path. I did keep the overall path from the original design, because it offered such a dramatic path through Times Square. Once implemented, these changes instantly made the mission much more exciting. It had a nice rhythm to the action, the player was no longer confused, and with some tweaking of the enemy spawns and tank health, it could have some real challenge appropriate to this point in the game. It was finally a solid mission–nothing to be ashamed of.

Of course, it wasn’t perfect yet.

Adding more variety and polish

To begin with, the ebb and flow of the action was too severe–there was a lot of action at the roadblocks and then a complete absence of action as the tank drove between roadblocks. I smoothed this out by pointing out the next roadblock to the player ahead of time. As soon as one roadblock is cleared, the next roadblock is roundeled and added to the minimap, so that the player can run ahead and try to take out as many enemies as possible before the tank arrives.

With this design, the action of the mission never dies down entirely, though the quality of the action alternates between heavy combat and rapid locomotion to the next roadblock. The player is always given a chance to take a bit of a breather if he needs it, before locomoting to the next checkpoint. In my experience, this is a critical trait of compelling scenarios in action games: the gameplay never lets up for long, but the quality of the gameplay constantly varies. In an FPS like Half Life 2, this can mean alternating between shooting scenarios and gravity gun puzzle scenarios; in a brawler like Hulk, it means alternating between combat scenarios and locomotion scenarios. The player doesn’t get tired from doing one thing repeatedly, nor does he get bored from doing nothing.

At this point the mission was in pretty good shape, but with six roadblocks all containing similar encounters, it still felt rather monotonous. It was especially difficult to incorporate any variety to the enemies, because at this point very early in the game, only two types of Enclave soldier had been exposed to the player. I did my best to vary the numbers and proportions of these two enemy types through the different road blocks, but this wasn’t quite enough.

To further address enemy variety, I utilized the one available enemy vehicle, a huge drop ship that flies in and drops enemies. A drop ship is a pretty serious encounter, so I didn’t want more than one in the mission. I thought about it for a while, and came up with an excellent reveal position for the drop ship. Several of the mission’s roadblocks lie along a long, open stretch of Broadway that runs through Times Square, forming a corridor. The player’s eye is naturally guided down this corridor, so I spawned the drop ship around a corner toward the end of the corridor, and sent it after the tank as it approaches the roadblock. I tested the mission on some colleagues around the office, and was very happy to discover (pending some tweaks to positioning and timing, of course) that in most cases, players would spot the drop ship just as it rounded the corner and barreled toward the tank, and exclaim either “awesome” or “shit.” This was exactly what I had hoped to achieve, so I added a target objective and called it a day.

In addition to adding some enemy variety, this change also added a little bit of gameplay variety–this is the one case in the mission where the tank is attacked while in transit. Thus, the player needs to decide whether to bound ahead to the next group of enemies, or hold back and destroy the drop ship first. This one minor tweak to the rhythm of the mission did a surprisingly great job of breaking up the monotony.

I made one more small tweak to the mission flow: at the final encounter at the safehouse, I decided to spawn several waves of enemies in addition to the enemies initially placed at the roadblock. This is a subtle change, but it has a noticeable effect on the feel of the action. I had experimented with spawning waves at other roadblocks, but I scrapped this because it made the encounters too slow and static. I wanted the persistent movement of the tank to drive the mission, and long encounters detracted from this. But at the final safehouse encounter, the tank has already reached its destination and is waiting for Hulk to finish off the enemies. This provided an opportunity for a more drawn-out brawl; here I spawn three waves of guys, and tell them all to attack Hulk rather than the tank, for an all-out brawlfest. I tweaked this encounter to be slightly more challenging and about twice as long as the other roadblocks; thus it serves as a climax for the player. It’s always a great idea to provide a climax like this, because in addition to providing a satisfying end to the mission, it gives the player something a little different to do (even if the only difference is extra challenge).

Missteps

So far so good, but not everything went so well. I made lots of missteps, most of which were easy to identify and fix through copious playtesting. One thing I ended up wasting a lot of time on was an aborted branch toward the end of the mission. I spent a day or two setting up an elaborate scenario in which the path of the tank branches away from the path of the player, but later the tank is ambushed and calls the player back. In my mind this was an awesome scenario, and I had a lot of fun playing through it.

Of course, I’d made the classic designers’ mistake–I was assuming players would all play the game the way I do. I also had a story in my head for why the tank was branching off, which made perfect sense, but I had done a terrible job of relating this story to the player. It was far too late at this point to request any new VO, so I had cobbled it together from existing VO and objectives; for me it worked, but for everyone else it didn’t. So the player was left confused about what to do, unclear about why the tank was branching away from the mission objectives. This became clear immediately once I tested the mission on other players. I had wasted a couple of days on it, but when I scrapped it I knew I’d done the right thing. There was already enough awesomeness in the mission, anyway.

Done at Last

Once all these fixes were in place, the mission was very solid. It was exciting and varied, and everybody enjoyed playing it. At this point the game was going to ship in like a couple of weeks, so the mission was quickly signed off by the senior designers and locked down. I was done with it, and pretty satisfied.

Lessons Learned

As I had learned time and again in my missions, creating fun within the systems of Hulk depends on creating tightly constrained encounters with clear objectives. Some games thrive on open-ended objectives; Hulk is not one of them. Here are some of the reasons why:

• Being a movie game, Hulk was inevitably unpolished and rushed. Its various systems (environment, AI, locomotion, combat) did not work together smoothly; the only way to create reliably entertaining gameplay was to script it carefully. I could have ignored the lack of polish in the game’s systems and tech, set up a looser, more open-ended mission, and blamed the terrible gameplay on the systems and tech guys. Instead, I treated this issue as a constraint and did my best with it. By carefully scripting constrained encounters, I could ensure that the player would experience the game’s fun side.
• Simple brawlers, even of the open-world variety like Hulk, don’t naturally lend themselves to open-ended gameplay, because from a gameplay perspective there usually isn’t more than one way to accomplish something. Hulk consists of a straightforward combat system and a locomotion system, without a lot in between; no secondary or tertiary combat mechanics, no car jacking, no gravity gun, no stealth. This is a good thing for a primal game like Hulk, because it allowed us to develop a tight, satisfying combat system without extraneous distractions. To support this core experience, it was necessary to construct appropriately restricted missions.
• On top of this, we were making this game for kids and the mainstream audience of the film. We had to be especially careful not to make hardcore assumptions and lose the player. This was no place to take risks with loose player direction.

Therefore, in lieu of any physical documentation of my labors on Hulk (save the game itself), today I venture to document what I recall from some of the missions I designed and scripted–the things that worked, the things that failed, and my reasoning.

I don’t want to spend these posts griping about the shortcomings of the publisher or the developer; that would be easy and probably quite satisfying, but my intention for this series is to focus purely on design, as experienced by me personally. Target audience? Anyone interested in how design works on a major console video game, and/or how David R. Lorentz approaches scenario design.

I will pick several of the more interesting missions, create a unique post for each, and link to them here once they’re done.

Mission 1.1.3: Escorting a Tank
Mission 2.2.2: Escorting a Helicopter