AC: Custom Logic for XR

Description

This assignment centers on the scripting backbone of XR in Unity. You will implement one small XFactory logic subsystem using C# MonoBehaviour scripts. The goal is clear architecture, state management, decision logic, collections, and testability.

Scope note: Do not build oversized “mega-projects.” This can be a simple Unity scene with UI buttons and console logs. You should not build a full interactive XR scene for this assignment.

Goals

  • Implement clear decision-making logic and reusable methods in C#.
  • Use collections (List<T>, Dictionary<TKey, TValue>) for managing state and groups of entities.
  • Author and correctly use MonoBehaviour scripts with appropriate lifecycle methods.
  • Communicate architecture and behavior through documentation and a testable driver harness.

Structured Core Tasks

Implement one approved logic subsystem as a small, testable C# module with a driver scene that demonstrates state changes, decision logic, and clear code structure.

Choose One Approved Subsystem Template

Choose one of these three templates. You may customize names and details, but must stay within one template:

  1. Drone Inspection Coordinator
    • Manages inspection targets.
    • Tracks drone status: idle, scanning, issue found, returning.
    • Queues failed inspections for retry.
    • Raises alerts when mismatch count exceeds threshold.
  2. AGV/AMR Delivery Queue Manager
    • Manages delivery requests.
    • Prioritizes urgent requests.
    • Tracks vehicle status.
    • Reassigns or delays tasks when obstacles/failures are simulated.
  3. Workstation Safety State Manager
    • Tracks station mode: normal, warning, emergency, reset.
    • Reads simulated sensor inputs.
    • Locks/unlocks virtual zones.
    • Raises tiered alerts.

Required Code Structure

  • 3 custom MonoBehaviour scripts minimum:
    • Manager/controller script
    • Entity/state script
    • UI/driver/simulator script
  • Namespace: XRE.Assignments.AC.FirstNameLastName (or similar).
  • At least one List<T>.
  • At least one Dictionary<TKey, TValue>.
  • At least one if/else branch.
  • At least one switch statement.
  • At least one loop.
  • At least one method with parameters and return value.
  • Lifecycle methods:
    • Start()
    • Update() only if needed; do not force unnecessary frame logic.
    • OnEnable() / OnDisable() for event subscription if events are used.
  • At least one simulated event or input trigger.
  • A simple driver scene or UI harness with at least four buttons or triggers:
    • Add/input event
    • Process/update state
    • Trigger failure/warning
    • Reset
  • A visible output: UI text, console logs, status panel, or simple scene object color/status changes.

Suggested time: ~4–6 hours.

Evidence Checklist

Include this table in your PDF and fill it in with file names and video timestamps:

Required item File/object name Video timestamp
Manager script    
Entity/state script    
Driver/UI script    
List usage    
Dictionary usage    
Decision logic    
Simulated event/input    
Reset behavior    

Graduate Extension

Complete the core assignment and submit a short Research-Informed Design Memo. Your goal is to connect one or two peer-reviewed research findings to a specific design or implementation decision in the assignment.

This is not a full literature review, a separate project, or a baseline-vs-variant study. The research connection should visibly inform one part of your existing assignment work.

1. Research Reading

  • Read 2 peer-reviewed papers related to the assignment topic.
  • Papers must come from credible XR, HCI, engineering, manufacturing, robotics, simulation, training, visualization, or human factors venues.
  • At least one paper should have a clear engineering, industrial, training, robotics, manufacturing, maintenance, healthcare engineering, infrastructure, product design, or systems-engineering connection.
  • Avoid generic papers that only discuss broad UI design, general education technology, or unrelated VR/AR experiences without a clear connection to the assignment.

Suggested topics for Assignment C:

  • Adaptive XR systems for engineering work,
  • Context-aware industrial XR systems,
  • Operator attention and alert prioritization,
  • Human–robot/machine teaming logic,
  • Safety-state monitoring,
  • Robotics/AGV/drone coordination,
  • Decision support systems,
  • Simulation-based training logic,
  • Modular software architecture for XR or digital twins.

Avoid generic “state management” papers unless they clearly relate to XR, simulation, robotics, manufacturing, training, or engineering systems.

2. Reading Evidence

For each paper, include a short reading note with:

  • Full citation,
  • Research problem or application domain,
  • Method or study type,
  • One specific finding relevant to the assignment,
  • One sentence explaining why the finding matters for your design.

Do not submit AI-generated paper summaries. The notes should show evidence that you actually read the paper, such as a specific method, condition, design factor, measured outcome, limitation, or finding from the paper.

3. Research-to-Assignment Connection

Choose one research-informed decision you made in the assignment. Explain:

  • What you changed, emphasized, configured, or evaluated,
  • Which paper finding informed it,
  • Where it appears in your Unity scene, script, interaction, UI, validation, or evidence PDF,
  • What trade-off or limitation remains.

This can be a small design decision inside the normal assignment work. It does not need to be a separate variant, extra feature, or full comparison study.

Paper Engineering/XR relevance Specific finding used How it influenced my assignment
       

4. Graduate Research Memo

Submit AC_GraduateMemo_FirstName_LastName.pdf as a separate PDF, 2 pages maximum. Include citations, reading notes, and the research-to-assignment connection.

Submission

Because Unity projects can become large and difficult to submit, the default submission is a short demo video plus a concise PDF evidence document. Submit source files only as requested below. The TA may request source files if a feature cannot be verified from the video.

Required

  • Demo video (4–5 minutes): Show the four driver inputs and output changes in order with narration or captions.
    • The video does not need to be professionally edited. A clear screen recording with narration or captions is sufficient. Make sure UI text, scene objects, and required interactions are visible.
  • AC_Evidence_FirstName_LastName.pdf (≤ 2 pages) including:
    • Project title and student name,
    • Evidence checklist table with timestamps,
    • Selected template,
    • Script list and responsibilities,
    • Namespace,
    • One decision-flow diagram,
    • Collection usage table,
    • Video link and timestamps.
  • Scripts ZIP or lightweight UnityPackage containing the scripts and driver scene. The Scripts ZIP should include your C# scripts, driver scene if feasible, and any small supporting assets needed to understand the logic. Do not include the full Unity project folder or generated Unity cache folders (Library/, Temp/, Obj/, Logs/, etc.).

If You Are a Graduate Student

AC_GraduateMemo_FirstName_LastName.pdf (≤ 2 pages) — separate from the undergraduate evidence PDF. Include citations, reading notes, and the research-to-assignment connection.

Fallback

If file upload, recording, or Unity packaging fails, submit the evidence PDF by the deadline and sign up for a brief TA demo during office hours. TA demos must be scheduled by the assignment deadline. The TA demo is a fallback verification method, not an extension.

Submit individually via Canvas.

Grading Rubric

If a required feature is not visible in the video or TA demo and not clearly documented in the evidence PDF, it may receive little or no credit even if it exists in the Unity scene.

Core (100 points)

Criterion Objective evidence Points
Template completion Chosen subsystem matches one approved template and has coherent behavior 10
Script structure At least 3 MonoBehaviour scripts with clear responsibilities 15
Decision logic Uses if/else, switch, and loop appropriately for subsystem behavior 15
Methods Reusable methods with parameters and return values are present and meaningful 10
Collections and state List and Dictionary are both used correctly to manage dynamic state 15
Lifecycle/events Lifecycle methods and at least one simulated event/input are used appropriately 10
Driver scene/testability Four required inputs/triggers demonstrate behavior clearly 15
Documentation/evidence PDF includes flowchart, collection table, script overview, and timestamps 10

Graduate Requirement (20 points)

Criterion Objective evidence Points
Paper relevance 2 credible peer-reviewed papers; at least one has clear engineering/industrial/training/robotics/manufacturing/systems relevance 5
Reading evidence Notes identify problem/domain, method or study type, specific finding, and limitation or design implication 5
Research-to-assignment connection One specific finding is clearly connected to a design, implementation, UI, interaction, validation, or documentation decision 7
Memo clarity Memo is concise, cited, within 2 pages, and not just a generic literature summary 3

If you are a graduate student, this graduate requirement is required—not optional extra credit. Your assignment grade includes the core rubric above plus these graduate criteria.