Architecture, Game Design and Performing Arts

01Purpose and scope

• This manual describes the working methods shared by people who design buildings, interactive games and live performances. All three fields shape how a person moves through space over time, how attention is directed, and how an audience or player understands what they are experiencing. A set designer, a level designer and an architect may all block a route, control a sightline and decide where a moment of pause or tension should land. This manual treats those shared decisions as the core subject and explains how the work is actually carried out on real projects. It supports the Architecture, Game Design and Performing Arts course.
• The scope is practical rather than theoretical. It covers how projects are scoped, how teams prepare, how drafts and prototypes are tested, how risks are controlled and how decisions are recorded. It does not replace licensed architectural practice, engineering judgment, building code review, stage rigging certification or any approval required by a venue, fire authority or accessibility regulator. Building codes, occupancy limits, accessibility rules and public safety requirements depend on jurisdiction and change over time, so the current text from the local building authority or other competent body is the authoritative source. Qualified professionals must make final calls where those rules apply.

02Core principles

• The first principle is that space is sequenced. Whether the space is a house, a levels map or a stage, people experience it one step at a time. Good practitioners plan the order in which spaces are revealed, the points where a viewer or player can orient themselves, and the moments where they are asked to slow down or make a choice. A corridor that opens onto a courtyard, a cave that leads to a boss arena and a stage entrance that delivers an actor into a pool of light all depend on controlling what comes next.
• The second principle is that a design is tested only when someone uses it. Drawings, scripts and prototypes are useful, but they describe intent rather than outcome. Practitioners arrange early contact with real users, audience members or playtesters and observe where they hesitate, misread a cue or walk past something important. Iteration is expected, and the schedule should allow for it.
• The third principle is that constraints are design material. Budget, structural spans, hardware limits, venue sightlines and rehearsal hours all push the work in particular directions. Experienced practitioners record constraints early and treat them as inputs rather than obstacles. A narrow lot, a tight memory budget and a black box theater with low ceilings each suggest different solutions, and the best work often comes from choosing a constraint deliberately and designing around it.

03Planning and preparation

• Planning starts with a brief that states who the work is for, what it must accomplish, where it will be experienced and when it must be ready. For a building, the brief usually includes program areas, occupancy estimates, site conditions and client priorities. For a game, it covers platform, target session length, input methods, performance targets and the core loop the player will repeat. For a performance, it covers the venue, audience capacity, running time, technical capabilities and rehearsal availability. Vague briefs cause most later rework, so the first task is to make the brief specific enough that two people would reach similar conclusions from it.
• Next, the team identifies roles and decision rights. A typical team may include a lead designer or architect, a technical lead, a producer or stage manager, specialists for lighting, sound, structure or systems, and representatives of the people who will use or experience the work. Each decision should have a named owner. A common failure is letting several people approve the same change without knowing who has final authority.
• Tools are chosen to match the phase and the audience for the output. Architects commonly use CAD and building information modeling software such as Revit or Rhino, and the IFC format is a widely used open standard for exchanging building model data. Game teams often work in engines such as Unity, Unreal Engine or Godot, supported by a version control system and a shared asset pipeline. Performance teams rely on drafting tools for floor plans, lighting plots, cue sheets and rehearsal schedules. The choice of tool matters less than whether everyone can read the output and whether files are kept in one agreed location.
• Schedule preparation should include time for review, revision and failure. A realistic plan builds in at least one full review cycle before any irreversible step, such as pouring concrete, locking a level build or booking a final tech week.

04Recommended workflow

1. 1
   : Write a one-page brief and confirm it with the client, producer or creative lead. List the core experience, the main constraints, the success conditions and the decisions that are already fixed. Ask each stakeholder to sign off on the brief before concept work begins, and record any open questions in a visible list.
2. 2
   : Build a concept model at low fidelity. For architecture, this may be a massing study or a simple axonometric. For games, it may be a grayboxed level or a paper prototype of the core loop. For performance, it may be a rough blocking diagram or a model box. The goal is to test sequence, scale and flow before details consume time.
3. 3
   : Run an early test with a small group. Walk a client through the massing model, have a playtester attempt the grayboxed route without instructions, or ask two performers to run a short scene on a taped floor plan. Note where people stop, hesitate, ask for help or take an unexpected path. Treat these observations as data about the design, not about the people testing it.
4. 4
   : Develop the detailed design in parallel with technical checks. Architects coordinate structure, mechanical systems and egress. Game designers coordinate level geometry, navigation meshes, performance budgets and input mapping. Performance teams coordinate sightlines, lighting angles, sound coverage and entrances. Hold a regular coordination meeting where each discipline reports one risk and one dependency.
5. 5
   : Freeze and document the design at a defined milestone. Issue drawings, level documents or cue sheets with version numbers and a change log. Make it clear which elements are locked and which may still change. A frozen version gives production teams a stable reference and limits late surprises.
6. 6
   : Test the built or prototyped result under realistic conditions. Walk the building with a fire and access consultant, run the game on target hardware with a representative group, or hold a full technical rehearsal with lights, sound and set in place. Log every issue, assign an owner and decide which issues must be fixed before release or opening.
7. 7
   : Review outcomes after the first real use. Collect feedback from occupants, players or audiences and compare it to the success conditions in the brief. Record what worked, what did not and what the team would change next time. Store these notes with the project files so future teams can learn from them.

05Quality checks, risk controls and compliance

• Quality checks differ by field, but several are shared. Sightlines must be verified from every seat, camera position or viewing point that matters, not just the main one. Circulation must be checked for width, turning radius and congestion at peak times. Lighting and visual effects must be checked for intensity, contrast and rate of change, since flashing or strobing content can trigger seizures in some people. Accessibility should be considered from the start, including step-free routes, readable signage, captioning and control options. Published game accessibility guidelines and the accessibility requirements that apply to buildings in a given place are useful reference points, but the specific legal obligations depend on jurisdiction and should be confirmed with the relevant authority.
• Structural, fire, electrical and rigging safety are regulated in most places and require qualified engineers, licensed contractors or certified riggers. Nothing in this manual replaces those professionals, their calculations, the approved procedures of a venue or any authorization required before occupancy or public performance. Where a design relies on a load, a fire rating or a rigging point, the responsible professional must review it and sign off in writing.
• Risk controls work best when they are written down in a register. Each entry should describe the hazard, the likelihood and impact as the team understands them, the control, the owner and the status. Common entries for performance include trip hazards on stage, sudden blackouts and audience crowding at exits. Common entries for games include performance drops on low-end hardware, softlocks that trap players and content that conflicts with rating requirements. Common entries for architecture include blocked egress, inadequate daylight and overloaded floors.
• Privacy and data handling deserve attention when a project records player behavior, tracks visitors through a building or uses cameras in a performance space. Local data protection rules govern what may be collected and how long it may be kept, and the team should check them before collection begins.

06Collaboration and documentation

• Good collaboration depends on shared artifacts. A design bible or project brief holds the intent, the constraints and the decisions made so far. Drawings, level documents and cue sheets hold the detail. A decision log records who decided what, when and why, along with any alternatives considered. A risk register and an issue tracker record problems and their resolution. Each artifact should be versioned and linked to the thing it describes, so a reader can find the current answer without asking around.
• Meetings should be short and tied to decisions. A weekly coordination session works well when each discipline brings a list of open questions, a list of changes and a list of blockers. Notes should name owners and dates for follow-up, and they should be circulated the same day.
• Documentation also protects the team. Clear records show why a choice was made, which helps when a client asks to revisit a decision or when a regulator requests evidence. They also support handover to maintenance staff, live technicians, live operations teams or the next group that inherits a project.

07Measures and continuous improvement

• Measures should reflect what the work is supposed to achieve. For architecture, useful indicators include the time needed to reach a destination without signage, the number of revisions to a drawing set after a coordination review and the count of unresolved code questions at each milestone. For games, useful indicators include the share of playtesters who complete the first session without assistance, the frequency of softlocks or crashes per hour of play and the proportion of players who reach a defined teaching moment. For performances, useful indicators include the number of full run-throughs completed before opening, the count of cues that missed their timing in rehearsal and audience comments on sightlines or sound.
• Targets for these measures depend on the project, the audience and the venue. Be cautious about adopting numbers from other projects or from general guidance without checking whether they fit your context. Teams should set their own thresholds during planning and revise them when evidence shows they are unrealistic or too loose.
• Continuous improvement means turning findings into changes in method, not just in the current project. A retrospective after each milestone can identify which tests caught real problems, which steps were skipped under pressure and which tools slowed the team down. Record the lessons in a short, searchable form and review them before the next project begins.

08Common mistakes and how to prevent them

• One common mistake is treating the first concept as final. Teams become attached to a layout or a level flow and resist changes after the first test. Prevent this by scheduling at least one early test before detailed work begins and by agreeing in advance on what evidence would justify a change.
• A second mistake is designing for the most convenient viewpoint or the most experienced user. A stage that looks excellent from the director's seat may hide half the action from the balcony, and a level that a designer finds intuitive may confuse a newcomer. Prevent this by checking every important viewpoint and by including people who do not share the designer's background in testing.
• A third mistake is leaving technical checks until the end. Structural, fire, lighting and performance budget problems discovered late often force expensive redesign. Prevent this by running technical checks alongside concept work and by naming a technical owner for each system.
• A fourth mistake is weak documentation of decisions. Teams later cannot explain why a door was moved or why a boss room was reduced in size, and they repeat old arguments. Prevent this with a simple decision log that is updated the same day a decision is made.
• A fifth mistake is ignoring accessibility and safety until a late review. Retrofitting a ramp, adding a second exit or redesigning flashing effects after release costs more and sometimes compromises the original concept. Prevent this by including access and safety criteria in the brief and in the first review.

09Practical checklist

• Confirm the brief in writing and list the decisions that are already fixed.
• Name an owner for every major decision and for every technical system.
• Build a low fidelity concept and test it with at least one real user group before detailed work begins.
• Check sightlines, circulation or navigation from every important viewpoint and start position.
• Verify accessibility, egress or safety requirements with the relevant authority or licensed professional for your location.
• Keep a versioned design record, a decision log and a risk register, and update them on the day changes occur.
• Run a full technical rehearsal, build walkthrough or performance test under realistic conditions before release.
• Review results against the success conditions and record lessons for the next project.

★Learning sources

• Micro Degree: Architecture, Game Design and Performing Arts
• Micro Degree: 2D Animation Fundamentals
• Micro Degree: 3D Animation Techniques
• Micro Degree: Illustration Fundamentals