Stir Fry Blues

Programming, Video Games

Stir Fry Blues

Last year I made a little game for Space Cowboy Jam with my good friend Matthew Breit. Inspired by one particular scene from Cowboy Bebop, we decided to make a silly cooking simulator. He modeled some vegetables, I coded some menus, we wrote some goofy dialogue, and slapped together Stir Fry Blues in a couple of weeks.

Sadly, the version we made within the time constraints of the game jam was pretty lousy (we placed 45th out of 60 overall.) It had no audio, the menus were ugly, and the NPC dialogue was repetitive. Most egregiously, we still had a placeholder screen for the cooking animations. After the jam, we simply left the project in unfinished limbo for months.

Over the Christmas holidays, I took a pass at improving Stir Fry Blues to the point that I would no longer be ashamed of it. I cleaned up the UI, added some creative-commons audio, and wrote logic for the NPCs to recognize over 30 recipes. To make the cooking animations, I took what we already had (3D modeled food) and simply added physics. Watching a loaf of bread boiling in a pot adds immensely to the game’s humour.

You can play Stir Fry Blues in your browser with the Unity Web Player, or download it:

Play Stir Fry Blues (itch.io)

Download (Windows)

Download (Mac OSX)

Though I’m quite proud of the final product, making a game that’s entirely menu-driven and has lots of custom content isn’t actually much fun. Writing the data structures for the ingredients (their prices, taste values, expiration, etc.) felt like I was developing CMS software. At least I learned a lot about C# and Unity while doing so! For my next side project, I’d definitely prefer to tackle a more mechanics-driven game.

Tags:  ·  ·  · 

The Loot Cave

Video Games

Destiny Loot Cave

“The social experience of a cave farming run is amazing: the herding to get a team of Guardians all behind the line and firing in the right direction, the rush to grab the loot, the scramble when the panic wave starts, the beckoning glow from inside the cave. The speed at which the community organized around this activity was inspiring and humbling to us.”

Destiny Dev Notes

Destiny’s loot cave is a fascinating phenomenon that has captured the interest of many journalists, critics and players. From a design perspective, it’s a potent example of emergent gameplay: the often unpredictable consequences that arise from complex interactions between individual game mechanics. I’d like to examine the details of how the loot cave works, speculate why it was difficult for Bungie to anticipate, and examine several options for fixing it.

The infamous cave is found in the Skywatch area of Destiny’s Old Russia level. The site would be unremarkable except for the gangs of high level players who (used to) hang out nearby. However, its unique geometry and the NPCs’ interactions with it are the key to what affords this particular exploit. The cave is a spawn point for low level Acolytes and Thralls, and its deep concave structure seems designed to obscure their reappearance from the player’s view. Once spawned, these creatures charge directly towards their intended combat zone on top of a nearby hill, disregarding incoming fire while in transit.

In Destiny, enemy NPCs are blocked from respawning if a player is nearby. However, the rolling hills that face this area allow players to see into the cave from a great distance. This means that player can stand outside of the range that would prevent respawning, while still firing into the cave with long-range rifles. Appearing under the player’s scope within a confined space and immediately charging towards the cave mouth, the enemies can be mown down over and over with ease.

This exploitative cycle is somewhat fragile, as it depends on the players’ ability to contain the flood of respawning NPCs within the bottleneck at the mouth of the cave. If an inopportune reload or lapse in concentration allows an enemy to escape the cave, the NPC can run free towards its destination and out of view of the ridge of snipers. Each enemy that escapes reduces the number that are spawning within the cave, diminishing the drop rate. A single player would therefore have great difficulty sustaining the loot cave; it requires two or more high level players diligently concentrating their fire. Given its reliance on the unspoken cooperation of strangers, it’s not surprising that Bungie was unable to anticipate this unusual tactic.

Map of the Loot Cave

Why would high level players opt to use this repetitive tactic, rather than participate in advanced missions as the developers intended? Firstly, there’s the unusual decision by Bungie that any NPC is eligible to drop legendary weapons and armour, even enemies that are significantly lower level than the player. Secondly is the fact that Destiny’s loot system is notoriously stingy. In the recent developer notes, Bungie had acknowledged the fact that their high level encounters and daily missions lack fanfare when loot is obtained. Furthermore, many of their systems offer faction reputation as a reward, an abstraction from the loot itself that may be difficult for players to grasp. It’s therefore understandable why some would prefer the tangible rewards and strong shiny feedback of the loot cave.

We can further examine the loot cave through the MDA framework, where mechanics describe the formal rules of the game, dynamics describe the rules acting in concert and responding to player input, and aesthetics describe the player’s experience of the game. Through this lens, the loot cave interaction looks like this:

  • Mechanic: NPC respawn points are blocked by proximity, but not line of sight.
  • Mechanic: Individual NPCs in Skywatch respawn 6 seconds after dying.
  • Mechanic: Any NPC can drop legendary items regardless of level.
  • Mechanic: Advancement beyond level 20 is only possible through gear.
  • Mechanic: Ambient multiplayer allows players to meet up randomly.
  • Dynamic: The Loot Cave™
  • Aesthetic: Periodic excitement from loot drops, boredom from repetition.

Last Thursday, roughly a week after being widely discovered, Bungie published a small hotfix to greatly decrease the efficiency of farming the loot cave. This was accomplished by “normalizing” the NPC respawn timers in Skywatch to 40 seconds, stymying the endless flood of monsters and effectively ending this particular instance of the loot cave phenomenon. However, the community has quickly identified new locations with a similar farming dynamic.

Bungie could continue to hotfix respawn timers, but in aggregate that might have the unintended effect of emptying out low-level patrol areas. They could prevent weak monsters from dropping legendary gear, but that might make much of their world obsolete to players past level 20. Ultimately, I think Bungie is already planning systemic changes in the right direction: making their existing end-game content more rewarding. If the strike & raid missions find an appropriate balance of difficulty, reward and fanfare, then players might stop hunting for a cave to shoot into.

Tags:  ·  · 

Solo Queue: An Exercise in Serenity

Programming, Video Games

This weekend I committed to finishing a small Twine game I’ve been dabbling with intermittently for the last year. It may seem a little esoteric (and rather silly) if you’re unfamiliar with the game genre being parodied, but hopefully it’ll still convey the general idea.

You can play it directly in your browser by clicking the title below:

Solo Queue: An Exercise in Serenity

Solo Queue is inspired by Dan Bruno’s Time for some Fire Emblem and Alex Austin’s Bioshoot Infinite + 1. I was intrigued by the notion of abstracting a game’s core mechanics into Twine as a form of critique. I wanted to apply the same approach to the lords management game (a.k.a. MOBA) I play most regularly: League of Legends.

While I was fiddling with Twine, I was also working (and eventually had some success) at climbing the season 3 ranked ladder in solo queue. There is a certain inherent insanity in attempting teamwork with four complete strangers. To quote Reservoir Dogs:

Mr. Pink: Why can’t we pick our own colours?

Joe: No way, no way. Tried it once, doesn’t work. You got four guys all fighting over who’s gonna be Mr. Black, but they don’t know each other, so nobody wants to back down. No way. I pick. You’re Mr. Pink.

Succeeding in solo queue requires diplomacy, flexibility and ego management. Ultimately, it’s a lesson in serenity; you must accept that you are going to lose many games regardless of your personal performance or skill.

Solo Queue in Twine

As I’ve indicated previously, I had some troubles working with Twine. In fact, halfway through development I moved the passages to a plain text file and began compiling them directly with twee. I also wanted to avoid mixing JavaScript code with story content, so I stored the macros in separate files and wrote a few quick Perl scripts to append them together at build time. The workflow worked quite well once I’d set all that up; I especially enjoyed being able to easily import Leon Arnott’s excellent Twine macros.

It felt great to work on a hobby game again, though I’d like to attempt something with more systemic mechanics for my next side project. In the meantime, I hope you enjoy my preposterous little game, and to all the League players: best of luck in season 4!

→ 1 CommentTags:  ·  · 

Mark of the Dishonored

Video Games

Mark of the Ninja + Dishonored

I’ve been feeling rather stealthy lately, playing through Dishonored and Mark of the Ninja over the last few weeks. Playing them back-to-back has contrasted them rather sharply in my mind, though neither title suffers for the comparison. Rather, I’d like to highlight how certain elements of Mark of the Ninja’s design align perfectly with how I like to play stealth games.

Since most stealth games allow for a great deal of player agency, there are many perfectly valid ways of playing them. Some move through the levels like a ghost, others prefer to murder everyone from the shadows. Some are willing to go loud if their stealth is broken, others hide and try again. My preferred approach is to play each scenario as flawlessly as I can. I like to ascertain a situation, determine a strategy, execute it, then figure out how I could have done better. Can I avoid alerting the guards? Use fewer resources? Turn the environment to my advantage? I treat it like a puzzle, playing it over and over to find the optimal path.

In theory, there are “try again” mechanics built into the stealth genre. Your character is weak, so the guards can kill you quickly. Alternately, you escape and wait for the alert to die down. Either way you get a chance to reevaluate your strategy. However, both of those options are time-consuming, and the delay makes it difficult to iterate on a plan. Once you sit through a death animation and loading screen you’ve already forgotten the specifics of your recent failure. I made a point to pick up Dishonored on PC, allowing me to use quicksave and quickload to narrow down my perfect approach.

I didn’t have to micromanage my saves in Mark of the Ninja. The checkpoints are generous and there’s no score penalty for death. When my plan went badly awry, the window for recovery was small; I either died or escaped within a few seconds. There’s no minute-long ambiguous alert state, just clear immediate success/fail feedback. You could say Mark of the Ninja is the Super Meat Boy of stealth games: you die a lot, but you’re already back in game before that has a chance be bothersome. Iterating on a plan isn’t a tedious process when you can immediately begin executing your next idea.

Mark of the Ninja

Another element that supports the “puzzle” approach to stealth is predictability. As Anthony pointed out, Mark of the Ninja’s clean 2D presentation and excellent UI make it an exceptionally deterministic game. You have the unlimited ability to freeze time and line up exactly where your ninja distractions are going to land. Vision cones and noise radii sharply visualize the limits of a guard’s awareness. Everything is a known quantity, making failure a fault of planning rather than execution. The ability to know the outcome of individual actions with certainty gives players the confidence to create complex plans.

When I feel comfortable with a stealth game’s mechanics, I often like to invent impromptu challenges for myself. Can I fit all the knocked-out guards into one closet? Can I reach that far ledge with a pile of physics objects? I’m always impressed when the game recognizes and encourages these actions. For instance, I grinned when Dishonored popped up an achievement for reaching the top of Kaldwin’s Bridge.

Mark of the Ninja takes this idea one step further by taunting you with challenges. A prompt appears when you enter a new area, with instructions like: “kill 3 gasmask guards while they are walking in poison gas”. It’s entirely optional and rather difficult to pull off, but who can resist the temptation to try! The fact that this challenge exists is also a hint to new players: here’s something fun you didn’t know you could do. Completing challenges helps reinforce the player’s knowledge of how certain game mechanics interact. Reifying the made-up challenges that experienced stealth gamers give themselves helps encourage an improvisational mindset in every player.

Mark of the Ninja is a spectacular game, one that makes stealth mechanics accessible and readable without reducing their complexity. Furthermore, it support the puzzle-like stealth experience that I love: figuring out a plan then executing it flawlessly. I can’t wait to see what Nels and the team at Klei come up with next.

Oh, and I completely agree with RPS: the ninja protagonist should be named Mark.

→ 1 CommentTags:  ·  · 

The Perpetual Testing Initiative

Video Games

Portal 2 Level Editor

This week saw the release of Valve’s new beginner-friendly level editor for Portal 2, dubbed the “Perpetual Testing Initiative”. Many have praised this new software for its accessibility, and have advocated it as an entry-point for first-time level designers. I had a chance to experiment with it a little myself, and I’d like to explore some of the specific principles Valve employed to create this remarkably approachable editor.

Booting up the editor for the first time gives you a simple rectangular testing chamber. The walls and floors can be dragged in any direction to expand the space or create connected chambers and corridors. Puzzle devices are dragged and dropped into the world from a tidy panel on the left side of the screen (very much like The Incredible Machine.) Right clicking these elements in the world exposes a small selection of options, and allows you to connect them to other devices. Simply moving the camera around the 3D space will likely be the most challenging interaction for a fledgling designer.

The editor is stylized like a blueprint: elements appear simpler than they do in-game, some devices (like the Aerial Faith Plate) project dashed path lines, and ceilings / backward-facing walls are automatically hidden from view. A working knowledge of Portal mechanics is assumed, as there are curiously no tool-tips to explain how the various devices function. Even I had to use trial-and-error to figure out how the Track Platform works, as the official Valve wiki is unfortunately sparse at the time of writing.

A great deal of editor’s simplicity derives from the fact that it’s not a generic tool designed to make levels, but rather a very specific tool to make test chambers. Test chambers in the Portal universe have a well-defined format. They are white, sterile, closed and grid-aligned rooms. They contain some permutation of the 32 devices. They necessarily have exactly one entrance, one exit and one observation room (which functions as the level’s main light source.) These fiction-appropriate constraints keep the editor simple by limiting the number of possible ingredients.

The devices themselves demonstrate a similar simplicity; both input devices (buttons, laser catchers) and output devices (laser emitters, piston platforms, etc.) maintain only binary states. Attaching several inputs to the same device will require them all to be active (logical AND), but there is no sanctioned way to achieve OR, NAND or XOR. Connections between devices are always visible to the player, as the editor automatically generates an in-game dotted line between them. Keeping the interaction between devices simple allows the editor to abstract away from any sort of complex scripting logic.

Fundamentally, the Portal 2 editor works so well because of the judicious use of physical constraints. In The Design of Everyday Things, Donald Norman describes how these types of limitations “constrain possible operations” such that “desired actions can be made obvious.” Since it’s almost impossible to do the wrong thing in this editor, the only possible actions are correct ones. Designers are thus free to experiment without fear of breaking the level in an esoteric way. The only clearly incorrect operation I’ve found is placing two devices in the same spot; the feedback for this error is clear and immediate.

In my few hours of experimentation I made a simple test chamber called “Ducks & Drakes”, which you can download and play by hitting subscribe in the Steam Workshop. You should also check out the Perpetual Testing Challenge over at the MapCore Forums.

Tags:  · 

© 2007-2016 Matthew Gallant, hosted by A Small Orange, powered by Wordpress.