Operation: Phoenix

Detailed Design Notes

PRIMARY TECHNICAL CONTRIBUTIONS:

-Tutorial system

-UI design and integration

-Sound design and audio progamming

-Control scheme design, diagrams, and programming

-Gameplay design

-UML and design documentation

I encountered a number of problems while working on Operation: Phoenix. Below are solutions I implemented, along with a summary of results achieved.

 

I have included visuals whenever possible; these can be expanded by clicking on the image/video.

REsult

Simplified control scheme as much as possible while maintaining a sense of realism. Created tutorial system that progresses at player's pace with clear, simple instructions. Made and displayed control scheme UI for tutorial system.

 

PRoblem

"Non-gamers" struggled to master the controls in early playtests.

 

Solution

Simplify the control scheme. Create a tutorial system that progresses step-by-step as the player demonstrates mastery of the controls.

Building the tutorial UI for Operation: Phoenix

REsult

Created multiple control schemes, programmed to auto-select based on players' initial inputs. Created quick-reference diagrams for default control schemes, accessible via pause menu.

 

PRoblem

Different playtesters expressed preferences for different control schemes (e.g., inverted, regular).

 

Solution

Offer multiple, customizable control schemes (keyboard - regular; keyboard - inverted; controller - regular; controller - inverted; HOTAS). Create quick-reference diagrams for default control schemes.

 

(Scroll through control scheme gallery or click to enlarge.)

REsult

Created a dynamic, location-based audio system for the texture-driven fire simulation, allowing players to hear flames from different directions without requiring thousands of individual fire actors.

This approach scaled efficiently across large environments with minimal runtime overhead and no manual setup.

 

PRoblem

Unreal Engine's actor-based sound-emitting system was incompatible with the game's texture-based fire system.

 

The game's dynamic fire-spreading system uses a texture applied to all terrain to track the location of the fires: the higher the texture's Red channel value within a given area, the more aflame that area is.

 

The fire's audio should correspond to its location (i.e., beginning or becoming louder as the player approaches the fire.) However, in Unreal Engine, sounds are "emitted" by objects placed in the world. Because the flames spread via a texture, not as actor-objects, the engine could not locate the flames to create sound emitters.

 

Solution

Break terrain into segments ("chunks"). When the level loads, create a list of each chunk's location and generate an invisible actor with an audio emitter in the centre. The actor is now linked to the chunk at its location and begins the looping flame audio when terrain within the chunk is on fire.