Nick Crockett


Vietnam Romance

Computer game, installation, mixed-media live show, 2014-
Overview     Video + Images     Process     Features     Demos + Artifacts
(this video shows early footage)

Introduction


Vietnam Romance  recreates and interrogates the fictionalized history of the Vietnam War and its culturally commodified remains through a mash-up of cultural artifacts drawn primarily from Hollywood film culture as well as war literature, comic books, popular music, collectable war memorabilia, and adventure tourist packages.

The project takes various forms: computer game, collectable card game, live performance / puppet show/ dinner theatre, and video installation.

Vietnam Romance is a tour of nostalgia for romantics and Deathmatch veterans pitting tourists vs. adventurers, history vs. its fantasies, and games vs. cinema. Film critic Ed Halter, described a film version of the project as exploring “a peculiarly American memory-trip, one in which the legacy of a gruesome war has become indistinguishable from pleasurable, if mythic-tragic, entertainments.”

Background


Vietnam Romance is produced by a small, rotating team; many people with different backgrounds and skill sets have touched this project over the years. Eddo Stern has been working on this project since around 2012 or 2013. He works primarily as a producer and designer, collaborating with current and former students like myself.

I joined the project as a programmer after finishing my degree in 2014, and have worked on it off-and-on ever since. As people have joined and left the project, my role has expanded to include production tasks like character animation, UI design, various visual effects, and designing and prototyping many of the game's core features.

When I joined, several other people had built key features of the game, sometimes hacking things together, sometimes engineering very robust systems. This, combined with Eddo's constantly evolving vision of the game (including multiple versions like the standalone computer game, generative software installation, and live immersive theater version) has meant that the development has proceeded for a long time on an ad-hoc basis.

context:
artist assistant to Eddo Stern

roles:
  • programmer
  • animation
  • design

tools:
  • unity 
  • blender 
  • photoshop 
  • c#
funding / awards:
Vietnam Romance has been generously supported by the Beall Center for Art And Technology through an Andy Warhol Foundation grant, and by The University of California Institute for Research in the Arts and by the UCLA Council On Research.

exhibited:
  • Dundee Contemporary Arts (Dundee, Scotland) , July 2016
  • Cirrus Gallery (LA), Feb 2016
  • UCLA Game Art Festival/The Hammer Museum (LA), Nov 2015
  • Northern Spark Festival (MN), July 2015
  • Postmasters Gallery (NYC) June 2015
  • Babycastles (NYC) June 2015
  • Angeles Gate (LA), April, 2015
  • Indiecade East/Museum of the Moving Image
  • (NYC), April, 2015 -Amaze Festival (Berlin, Germany), April 2015
  • Royal Ontario Museum (Toronto, Canada) March, 2015
  • Beall Center (Irvine, CA) Jan 2015
  • Beit Ha’ir Museum (Tel Aviv, Israel), May 2014

Video


Cirrus Gallery Excerpts

Dundee Contemporary Arts, Scotland
Postmasters Gallery Installation
Vending Bahn Mi with Lu’s Sandwiches at Northern Spark Festival, MN
Deer Hunter Puppet, live at UCLA Game Art Festival


Images






Process



John Haddock and I working late into the night before Eddo’s exhibition at the Beall Center at UC Irvine, CA in 2015. John was helping Eddo with illustrations for his GoldenStern pachinko game.
Vietnam Romance is a complex project with changing needs. We alternate between long periods of more methodical work towards the standalone version of the game, and intense sprints lasting weeks at a time for an exhibition or live performance. Each exhibition is different, sometimes with scenes excerpted onto different displays, sometimes with a single instance of the game running on multiple projection surfaces. 


I've arrived at a workflow for implementing new features that looks like this:
  • Meet with Eddo to discuss a new feature or level. Usually I come away with a handful of bullet points. Sometimes we work together to create other visual aids to clarify the design.
  • On my own, brainstorm what the feature needs to do in detail. Sometimes think of this as a user story, a series of drawings, but often bullet points suffice. Because it these materials are for my own use I avoid being too precious with them.
  • Sketch out a preliminary idea (often in a text doc) of how a new feature could reasonably be structured from a coding perspective, including some pseudocode.
  • Iterate on prototypes, using stub functions with debug statements to gradually test and build out the feature. At this point I begin preparing a demo scene with a variety of use-cases and example scripts.
  • Once basic functionality is in place, review how the prototype feels from a polish / game-feel perspective and iterate on my implementation / design. At this point I will sometimes generate some documentation and review it with Eddo before continuing, but it depends on schedule and on the feature.
  • Once I am happy with the basic behavior, review the code and tidy it up with an eye towards maintainability. Is it human-readable? Is it structured logically? Are there dependencies I can reasonably get rid of? Is it resistant to human error or vulnerable to typos or missing references in the editor? etc.
    • In general, I avoid adding many comments to my code, and instead give classes, methods, and variables descriptive names without abbreviation. There's no reason for abbreviated variable names when working with intellisense.
    • I avoid leaving blocks of commented-out code. I've found I almost never come back to 'restore' them, and it can be confusing later when trying to identify bugs.
    • Where reasonable I extract large blocks of code into their own named functions to prevent confusion later on.
  • Once I am basically happy with the organization of the code, I start to consider what it will be like for one of my (non-coding) collaborators to work with the feature. I've found a good and simple stress-test is to try to set up a new level from scratch that incorporates the feature. This usually prompts some further iteration.
    • Is it painful to set up, with a variety of interdependent scripts and prefabs?
    • Is it prone to breaking if not set up exactly the right way?
    • Is it easy to get started, just a matter of refreshing a prefab instance or dropping a prefab into the scene?
  • Finally, I generate some documentation of what I did, and how it works, including a short tutorial video on how to set it up, and/or a video demo of the feature in action.


Sketch by collaborator Michael Luo illustrating a possible layout for a hub environment.

Having a background in art and design, this was the first time I had worked as a programmer on a large software project, and along the way I've come to rely on a variety of concepts like model view controllers, state machines, and the observer pattern to build code that is more dependable and maintainable.

We use a 'systems' paradigm for organizing many features of the game.
  • Features are organized into a handful of related scripts, often using a model-view controller and a few other helper scripts.
  • The scripts within the system are allowed to be fairly interdependent, with only a small handful of public, static methods and events made available for other classes to interact with the system.

Scene Organization
Scenes intended for production follow a fairly strict organizational convention, with objects and scripts sorted into empty game objects for static environment elements, interactive 'actors', gui elements, and managers, among other things. Scripts pertaining to the sequence of events in a level are nested inside an object called "events" and put in chronological order.

To manage events that unfold in a level, at first I wrote a huge array of tiny interconnected scripts, which I imagined my teammates could use to add complex interactions to a scene. This proved to be extremely difficult to maintain in the long run, as control was distributed across many scripts in many different places. It was easy to introduce bugs by rearranging or deleting objects in the editor, and very difficult to track what had gone wrong.

Now in the interest of creating a single "source of truth" about the sequence of events in a scene, I usually create a single unique 'level manager' script for each scene that interacts with the more general-purpose game systems. Often implemented as a simple state machine (or even a list) which uses delegates with anonymous functions and editor-accessible unityevents for flexibility If a level has major logical divisions (a first and second section that are dramatically different, for instance) I may separate these into their own scripts for simplicity and brevity, and have one 'hand off' control to the other.


Features


A non-exhaustive list of the features I've designed and prototyped for the game:
  • A system for steering cars in 3D space from a side-on perspective, allowing the player to veer off the main road and explore deeper in the environment. This is different from most 3D driving games, which either situate the camera behind the vehicle facing forward, or allow the player to manually control the camera view.
  • Vehicle status overlays which display various information for each vehicle, and can be toggled on and off.
  • Vehicle engine maintenance / boosting mechanics:
    • A speed boost which consumes 'turbo fuel' and heats up the engine.
    • A "water can" consumable item which immediately cools a heated engine.
    • Motor oil consumable item which prevents the engine from heating for a limited time.
    • Vehicle breaks down when "overheated" forcing the player to stop for a limited time. A minor annoyance on tour levels, but a potentially fatal situation in combat.
  • Flying planes and docking with a refueling plane mid-flight.
  • Tank-based combat, where the player drives a vehicle in 2D and can also operate variety of weapons including:
    • A mortar launcher, which can be armed with exploding mortars, smoke bombs, flares, and practice mortars.
    • A front machine gun, which can overheat if fired too frequently and has limited ammo.
    • A grenadier riding atop the tank. The player can control the trajectory of the grenade by pressing and holding the grenade button.
    • An animatronic rambo that allows precision shooting with a bow and arrow.
      • The player can arm normal arrows, long-range arrows, multi-arrows (which split into 5 projectiles at the top of their trajectory), and the classic rambo exploding arrow.
    • A battering ram that allows players to smash obstacles with the vehicle without sustaining damage. Many equippable rams were planned, but the only one we have kept in the game is a mounted deer head.
    • A scope for sighting and estimating the distance of enemies and other points of interest.
  • Boat-based combat, similar to the tank except the boat always drifts forward with the current of the river, and no battering ram is available.
  • Various systems for tracking player's progression and achievements.
  • Systems for synchronizing a player's inventory and achievements with their account on the Vietnam Romance website, so they can participate in leaderboards and show off their loot.
  • Ebay: a satirical "computer-within-a-computer" interface for buying and selling items on a fictional ebay account, including a personal ebay page for selling goods, a vietrom store ebay page for buying goods, and an email inbox that displays messages from characters in-game.
  • Voiceover and subtitles system that parses a text file with timestamps to match audio recordings.
  • Helicopter combat, landing, and rescue missions:
    • Controls for dropping a rope to rescue npcs.
    • System for landing / damaging the vehicle if landing too hard.
    • Machine gun and hellfire missiles.
    • Formation flying (npc helicopters that fly in fixed formation near the player).
  • Menu screens and animations including a modified UI text box that displays text in an intentionally illegible tight justified format. Background elements change based on the level just completed, and in post-game scenes, the vehicle and background elements change to match the level just completed.
  • A "popup" system which
    • Dynamically displays mission objectives, newly acquired items, notifications about phone messages, emails, depleted ammo, and other in-game events.
    • Displays nearby points of interest, incoming projectiles, and nearby boss enemies with additional cameras and render textures.
    • Sorts these various types of popups into four positions on screen according to a complex system that accounts for message priority and type.
  • Level editing tools, including
    • A "vietnamese countryside generator" that creates an endlessly driveable map of Vietnam.
    • Modular building generator for city scenes.
  • Spline-based traffic control systems that (mostly) spawn vehicles just off screen - including:
    • A physics based system for cars that the player can collide with.
    • A more deterministic / less computationally expensive version for background elements like distant traffic jams and scooter mobs.
    • Honking your horn causes vehicles ahead of the player to briefly speed up.
    • Ox-cart obstacle including ox animation.
  • In-game projection mapping tools for exhibitions, including tools for reconfiguring most UI elements in-game, supporting multi-channel display. This includes things like migrating the 'hand of cards' interface to a separate monitor for projection mapping, and adjusting the size and position of most of the primary ui elements to account for "extreme-wide mode" projection.
    • These tools had to be accessible from a build, so that we could modify how ui elements are projection mapped based on the sculptural objects we were projecting onto
  • "Game master mode" in-engine theater tech tools for the live theater version, allowing me to intervene in the game in various ways with a wireless keyboard during a live show.
  • NPC minesweepers that walk slowly in front of the tank to intercept / get blown up by mines including animations for various animals that can be used for sweeping mines including monkeys, tigers, and elephants
  • Background NPCS: systems for spawning modular, generative tourists
  • NPC Enemies a wide variety including:
    • Stationary and mobile machine gunners.
    • Grenadiers that hide in foxholes.
    • Stationary and mobile rocket launcher (which fires a large, slow projectile in a straight line at the player).
    • Stationary mortar launcher, which calculates a trajectory based on desired enemy accuracy and fires a slow projectile in a high arc.
    • Magic evil parrots that fly in formation and dive-bomb the player.
    • Deer that you can hunt with a bow and arrow.
    • Small birds that can be shot for extra loot in hunting scenes.
  • Destructible obstacles including bunkers and barricades.
  • Tank-based karaoke level, where players shoot down floating text that is synchronized with music.
    • Including a system to facilitate placing text in the level to correspond accurately with music.
  • Systems for camera control, dynamically framing monuments and landmarks as the player drives through a level, framing the characters when using healing items, and more. We started production on this game well before cinemachine was released.
  • "Male gaze" minigame where the player can direct the camera's gaze at Nancy Sinatra's body parts during a USO show.
  • Tutorial modes which display gameplay instructions with a series of text boxes, and which can lock specific inputs depending on the demands of the tutorial.
  • Self-playing "attract" modes of various levels for gallery installations.
  • Input management systems wrapped around the old unity input manager and the incontrol asset from the asset store.
  • Inventory management systems - I didn't develop the original version of our inventory system, but it has required extensive modification over the years to meet the project's changing needs, including animated cards such as an analogue watch that displays the in-game time of day, a system for managing a ‘stash’ of cards vs cards in hand, auto-sorting cards in hand by type, and more.
  • Integration with the vietnam romance site, so players can participate in leaderboards, show off their stash of cards, and transfer save data between computers.
  • Weather system for swapping out weather patterns mid level, including dramatic storm effects.
  • Speech Bubble system for displaying minor / background dialogue.
  • "Flashback" system, where the player can dynamically switch between a tour bus in modern day, and an armored personnel carrier mid-level.
  • In-scene UI elements for shopping, opening gates, and other interactions.
  • "Happy Funtimes" platform integration for local multiplayer with smartphones connected over wifi for a one-night-only event.


Demos + Artifacts




Postmasters Gallery (NYC)


The show at postmasters had the most complex projection setup of any of our installations. Four projectors were used together to show the game in 48:9 “extreme wide mode”, on a custom built plywood projection surface, with several “popup” details mapped onto separate floating objects. I had to develop an in-game UI editor to allow us to modify the precise position of each floating popup. The second projection surface from the left includes the full projection to allow for subtitles and other information to be displayed outside of the letterboxed game view.

I had to quickly modify our camera systems to support this extreme wide view, pulling the camera way back and reducing the field of view to prevent extreme distortion from occuring at the periphery of the screen. The camera system now supports several “camera modes” corresponding to our various installations and performances.

This is also where we first tried moving the hand of cards interface to a separate projection, although we decided to not go forward with it for this show.

The Postmasters  show is also the only time we exhibited the Vietnam countryside generator, which spawned a continuously scrolling environment with various biomes and random enemy encounters. The gallery insisted that we design scenes like this to work as self-playing attract modes that allow players to pick up and play the game at any point.



Dundee Contemporary Arts (Scotland)

The main game installation was composed of two overlapping projections: one for the main game and hand of cards, and another for the four excerpted “popup windows”, which show details of objects in game.

This installation required the tutorials and shopping scenes to be excerpted into their own build for a second projection on a giant sculptural computer monitor.



UCLA Game Art Festival (Los Angeles)

This installation had two projections: a main screen and a second projection displaying the player’s inventory as a hand of cards.

For the live performance version, players sat on stage and interacted with Lucas Near-Verbrugge, who also provided the voice and likeness of the in-game tour guide. For this show I included a variety of audio cues that told us the state of the game (a distant bird call when the deer was scared off-screen, for instance) to signal how we should advise players.

This version also included a large, physical Rambo puppet, which players manually held and rotated to aim. I helped with the electronics inside the puppet: an arduino reads a rotary encoder and converts the data to mouse movement on the vertical axis, which I map back to the character’s rotation in the game engine.


Vehicle Controls


Vietnam Romance features several vehicles with unique controls. At this point I’ve had a hand in developing all of these systems.

Stationwagon and Bus Controls

One unusual feature of Vietnam Romance is that the tour bus and stationwagon are able to drive in full 3D from a side-on perspective.

To make this feel “right”, I decided that the heading from the joystick should always correspond directly to the vehicle’s apparent motion on screen. To put the vehicle in reverse, players simply tilt the joystick opposite the way the vehicle is facing. Therefore, I had to convert WASD or Joystick input into engine torque and wheel angles which differ depending on the vehicle’s heading relative to the camera, and flip those for instances where the vehicle travels in reverse. This was tricky to get right.

The camera also shifts it’s focal point relative to the vehicle depending on which way the vehicle is facing, to allow a view ahead of the vehicle.

Engine Maintenance

The first levels we built were primarily about driving an unreliable vehicle in heavy traffic. The player can use fuel for a speed boost, but runs the risk of overheating. When the vehicle overheats, the player has to sit still for a moment while the engine cools down. Water and other liquids like coca cola and vietnamese iced coffee can be used to cool the engine immediately. Motor oil prevents the engine from heating up for a limited time, allowing the player a longer duration of boosting before they need to rest. This clip also shows the UI elements I designed to communicate engine status and later weapons and other features to the player.

Armored Personnel Carrier


The armored personnel carrier (APC) is outfitted with a huge variety of weapons including mortars, grenades, machine guns, battering rams, and an animatronic rambo that shoots a variety of arrows. This vehicle travels in a 2D plane to simplify aiming in combat.


Healing
Each weapon is manned by a passenger on the tour. Passengers each have their own health meter, so if they die, the weapon they operate becomes unavailable. In earlier versions, healing items had to be used on one character at a time, but this made healing during a heated moment in combat too cumbersome.



Flashback system
One idea was to have “flashbacks”, where the tour bus magically transforms into the APC, and the player characters are transported to Vietnam in the late 1960’s. We never resolved whether this should happen at specific places in a level, or if the player should be able to trigger these flashbacks at-will, but I did prototype both possibilities. 


PT Boat


The PT boat is similar to the APC except that it always moves forward down river. The player is able to accelerate or slow down, but never stop or reverse. In addition to the vehicle controls, I did the texture mapping for the boat, particle systems, and animation.


Plane

The player begins their adventure by flying a small plane across the pacific. Along the way, the refuel over Hawaii and must avoid seabirds. I did a lot of the technical art for this scene, and designed and developed the plane’s flying mechanics, including a brief midair refueling mission.



We have experimented a lot with the lighting in this level.



Helicopter


We wanted to include helicopter combat missions which recreate famous scenes from Mash, Apocalypse Now, the Deer Hunter, and more. The helicopter can fly vertically for a limited distance, and automatically avoids crashing into the ground. It is armed with a machine gun like the APC, but has a missile launcher which fires rockets in a straight line (as opposed to the mortars which fire in arcs). We also prototyped other interactions like dropping “Psyops” propaganda leaflets and dropping a swinging rope for rescue missions.



This clip shows a prototype for a reenactment of the “ride of the valkyries” scene from Apocalypse Now. The player controls one helicopter, and the others fly in formation matching it’s altitude, while the camera cuts between different angles at random.

Idle Screens

Every scene includes a short idle screen (attract mode) to set the tone for the level. Almost all of these involve a ‘self-driving’ version of the vehicle, which drives forward for a limited time, and then rewinds back to the start.

Ebay Shopping

A jokey computer-within a computer interface controlled with the joystick or WASD keys. This clip demonstrates browsing by item type.
The interface also features the ability to buy and sell items on your own ebay store and read emails from other characters.

This is effectively also the “loadout” and “level select” menu - players purchase their next tour through this interface, and then print out a receipt including items that are required and recommended for each tour.

UI Mockups

We spent a long time iterating on the vehicle status overlay.
Our first pass at these features, Eddo asked for a very busy, text heavy design with white text with solid lines connecting information to its relative position on the vehicle. This worked for us for a while, but as the game got more complicated a more robust solution was needed.



We had gone through many iterations by actually implementing designs in Unity, which was very time intensive. I decided to spend some time mocking up ideas in illustrator instead. I thought I could reduce clutter and use familiar icons from the UI of real cars, combined with color coding to clearly indicate status. Eddo insisted on some kind of tail or line connecting the data to the vehicle. I wanted to try a dark transparent background, thinking it might reduce visual clutter but still help the icons read on various backgrounds. I like our environments a lot, and wanted to avoid overwhelming them with UI overlays.


Eddo insisted on something that more closely resembled other UI elements in the scene, which were typically small gray or yellow boxes. The design evolved from having weapons, characters, engine, and vehicle health all in separate boxes but grouped visually, to having the relevant weapons “nested” inside each character’s box. Finally we made the UI boxes a neutral gray to make them less glaring in dark environments. Each vehicle has a different UI layout with this same system.




Modular Building Generator



To help with environment design, I created a modular building generator, which assembles a variety of buildings out of prefab pieces.  There is a complex system that attaches various awnings and balconies to the sides of buildings. Balconies can spawn additional decorations like potted plants and clothes at predetermined positions.


Feature Prototypes and Demos


Because we worked remotely for so long, I began recording short demo videos to help document new features for the rest of our team. 


Rain System

This video explains the weather system, which controls rain and lightning. I used scriptable objects to make weather presets, which the system can smoothly interpolate between. Later, I added triggers that could be placed in a level to control when different weather occurs.



Word Bubbles

This video explains the word bubble feature for others to work with. This is the latest of many systems we’ve used to display dialogue in game. For practical reasons, we decided to reduce the amount of voiceover work in the game, and needed another solution for incedental dialogue.

Helicopter Rescue Prototype

This video shows a prototype of a helicopter rescue. We wanted to recreate the scene from “the deer hunter” where a character is rescued from the water via helicopter while vietcong are shooting from the riverbank. In this scene I did basically everything except the texture assets, including atmospheric effects, lighting, animation, controls for the helicopter, sound design, and the character animation for the character being rescued.

Human Minesweeper

This video shows a prototype of a tense minesweeping level. We wanted to be able to carefully control the character’s feet as they walk through the minefield.

I accomplished this effect by using a blend tree when the player was moving quickly to lerp between a run, a jog, and a walk (as normal). Then, to allow the character to stop dramatically mid-stride, when the character’s movement speed approaches zero the playback speed of the walk cycle becomes tied to the character’s overall movement speed.

When a mine detonates, the terrain deforms slightly to give the impression of a crater. I use a projector to add bloodsplatter and to darken the crater, and a particle system produces smoke for a while.




Animal Minesweepers

We also discussed having an elephant, a monkey, and a tiger be useable as a minesweeper. I rigged and animated these characters myself, and used the same technique as the human to allow them to stop mid-stride. Longer animals like the tiger and elephant rotate to match the slope they are standing on.

Whereas the human uses the word bubble system to indicate when they are in danger, it seemed silly to do the same for animals that can’t speak. Instead, I used a woodblock sound effect that increases tempo with proximity, borrowing the sound cue from kabuki theater.
.


< Features