TheosDev

PRESENTATION ARCHIVE

Jump to each week separately.

01ConceptWeek 0102Market researchWeek 0203Production pipelineWeek 0304Prototype & testWeek 0405Week 05 presentationCore loop & game feel ↘06Technical progressPhase 12—19 ↘
06 / BUILDDownload the Week 6 buildProject: Nightwatch · ZIP archive
THEOSDEV / LAB/PROJECT FILE 001 · WEEKS 01—04

DEVELOPMENT JOURNAL / PROJECT OVERVIEW

PROJECT: NIGHTWATCH

A night shift. One wrong decision. Something may have already entered.

A security guard at a secret laboratory must verify personnel and distinguish Skinwalkers hiding in human identities. But once the guard leaves the checkpoint, danger is no longer limited to the decisions made at the desk.

IN DEVELOPMENT · DEBUG PROTOTYPE
GENREFirst-person horror · Deduction
ENGINEUnity 6000.5.9f1
TEAMNazım · Ramtin
COURSE TARGET10–30 min vertical slice
00

Turning a concept into a production process

The first four weeks come together in one story: what the game is, what we learn from comparable titles, how the team plans to produce it, and which systems are present in the current prototype.

01↗

PLAYER FANTASY

Be the night guard

Decide who people really are while carrying responsibility for the shift, limited resources, and your own safety.

02↗

CORE HOOK

Verify more than an ID

Documents, remembered conversations, and UV-reactive traces provide complementary pieces of evidence.

03↗

DESIGN PILLAR

Information + time + risk

Decisions at the checkpoint combine with the dangers of physically moving through the facility.

04↗

PRODUCTION APPROACH

Prove it, then polish it

Mechanics are tried in a Sandbox/debug environment; integration and visual polish remain separate production steps.

WEEK 01

CONCEPT / PROJECT DEFINITION

Built around one strong core idea

The project entered the team's workflow with an existing concept. Rather than inventing three alternative ideas after the fact, this presentation documents the selected concept's design logic and production potential.

ONE-LINE PITCH

A first-person horror and deduction game: verify staff using documents, memory, and UV traces; complete facility duties; and stay alive while away from the checkpoint.

Three design pillars

01—03
01

Information & deduction

Compare identity records, remember earlier conversations with scientists, and interpret physical evidence.

02

Time & resources

Prioritize personnel checks, feeding, generator repair, and the limited equipment you can carry.

03

Physical risk

Leaving the booth makes tasks possible, but open doors and creature encounters increase danger.

Core gameplay loop

CORE LOOP
01Prepare the shift
02Inspect personnel
03Make a decision
04Manage facility duties
05End the shift at 09:00
06Carry outcomes into the next day
WEEK 02

MARKET RESEARCH / CONCEPT DECK

Adding a different kind of risk to a familiar fantasy

The game starts from legible interactions such as document checks, observation, and evidence evaluation. Its distinction is the combination of those decisions with first-person movement through a facility and physical threats.

◎

Target audience

PC players who enjoy first-person horror, observation and deduction, job simulation, and system-driven tension.

✳

Core distinction / USP

Players do more than inspect documents: they can recall earlier conversations, interpret UV traces, and face creatures when leaving the checkpoint to handle facility duties.

Five design references

05 REFERENCES

These are not templates to copy. They are references for studying adjacent player expectations, strong interactions, and the spaces in which our design can differ.

01

That's Not My Neighbor

Identity checks / doppelgängers

Deciding who should be admitted by examining documents and visual details.

Design opportunityProject: Nightwatch expands this into a 3D facility, conversation memory, UV evidence, and physical danger.

Official page
02

Papers, Please

Document inspection / consequences

Rule-based document checks, time pressure, and consequences for decisions.

Design opportunityOur focus adds memory consistency and the interpretation of supernatural evidence beyond paperwork.

Official page
03

Contraband Police

First-person checkpoint

Combining document inspection with a physical work area and additional duties.

Design opportunityFacility maintenance creates a similar workload, while horror and the Skinwalker threat form the key distinction.

Official page
04

I'm on Observation Duty

Observation / memory / anomalies

Spotting unusual events during a night shift by using attention and memory.

Design opportunityInstead of surveillance footage, our game relies on direct NPC interaction, identity checks, and UV traces.

Official page
05

The Operator

Digital evidence / investigation

Gathering information and connecting clues through computer tools.

Design opportunityThe facility computer remains an information hub, while the player must leave the desk and take physical risks.

Official page

* These comparisons are qualitative design readings based on the core interactions described on each game's official store page and the goals of this project. They are not claims about sales or market size.

WEEK 03

PRODUCTION PIPELINE / V1

Two production tracks, one shared goal

Technical systems and visual content progress in parallel. Mechanics do not need to wait for final models; placeholder assets are acceptable during the first implementation. The pipeline aims to prove systems first and then move them into the main game flow.

Tools in use

TOOLKIT
↗

Unity 6000.5.9f1

Game engine / runtime

↗

Blender

3D modelling and asset creation

↗

VS Code

Code editing

↗

GitHub

Version control / repository

↗

Notion

Documentation and project notes

Team responsibilities

TEAM / 02

Technical development

Nazım

Unity, C# systems, Sandbox, integration, and technical validation.

Art production

Ramtin

Modelling, textures, and production of visual assets.

Design and quality

Shared

Game decisions, scope, content, balancing, and test review.

Production flow

PIPELINE
01

Design & data

Define mechanics and keep adjustable values configurable.

02

Core systems

Build player, interaction, identity, memory, UV, task, and creature systems.

03

Sandbox

Trigger mechanics in isolation and use debug tools to test different states.

04

Integration

Check how systems work together through shared time, inventory, door, and error flows.

05

Main game

Connect stable systems to the real facility and content.

06

Vertical slice

Build a short but representative playable section.

07

QA & polish

Repeat tests, fix bugs, and improve visual and audio feedback.

Production principles

RULES
  • Sandbox first; main scene later.
  • Numbers and balancing values should be adjustable through data/configuration where possible.
  • A feature is not complete when merely coded; it must be integrated and tested.
  • Unknown folder, naming, or build decisions should not be presented as finalized.
WEEK 04

RAPID PROTOTYPING / PLAYABLE PROTOTYPE

Making mechanics visible and testable

The current build contains multiple gameplay systems at prototype level. The goal is not to claim final visual quality, but to show how the systems behave, test them, and validate the core loop as they work together.

SYSTEMS PRESENT IN THE CURRENT PROTOTYPEDEBUG BUILD

The status below reflects the prototype scope reported by the team. It does not imply final polish, bug-free operation, or that every system combination has passed QA.

01✓

FPS movement & interaction

The player moves through the facility and interacts with world objects.

IN PROTOTYPE
02✓

NPCs & identity checks

Personnel encounters and a decision flow based on identity data.

IN PROTOTYPE
03✓

Scientist memory

Earlier conversation information and consistency-question mechanics.

IN PROTOTYPE
04✓

UV detector

Inspecting Skinwalker traces as physical evidence.

IN PROTOTYPE
05✓

Facility tasks

Shift duties such as feeding and/or generator repair.

IN PROTOTYPE
06✓

Creature encounters

Direct attacks, ambushes, or open-door infiltration scenarios.

IN PROTOTYPE
07✓

Daily schedule / shift

A daily structure that organizes NPC flow and event timing.

IN PROTOTYPE
08✓

Sandbox debug tools

Testing days, time, NPCs, items, and events in a controlled way.

IN PROTOTYPE

Test scenarios to demonstrate

QA / PROTOTYPE

These are validation scenarios. Unless a recording, result, or measurement is attached, the deck does not claim that every scenario has fully passed.

TEST 01○

Identity verification

FLOW

Normal NPC → valid data; suspicious NPC → field mismatch

EXPECTED

The player can inspect the data and choose whether to allow passage or intervene.

TEST 02○

Scientist consistency

FLOW

Talk to a scientist → meet again later → ask about earlier information

EXPECTED

The consistency of a real scientist is compared with an impersonator's memory limitation.

TEST 03○

UV evidence

FLOW

Inspect a normal NPC and a Skinwalker with the UV detector

EXPECTED

UV provides evidence for the player to interpret rather than an automatic identity label.

TEST 04○

Task and physical risk

FLOW

Leave the booth → perform a task → trigger an open-door / creature event

EXPECTED

Task management and facility danger meet within the same shift.

TEST 05○

Daily flow and debug

FLOW

Change day/time → trigger an NPC or event → inspect shift state

EXPECTED

Systems can be exercised repeatedly under different conditions.

WEEK 05

CORE LOOP & GAME FEEL / PHASE 11

Making the integrated systems feel like one shift

Week five is not about adding more mechanics. It is about connecting the integrated systems into a short playable flow where the player's actions are readable, consequential, and felt.

Confirmed milestone

PHASE11

Phase 11 — System integration in Sandbox is complete. Task, leaving the booth, door risk, creature encounters, and returning to the checkpoint can now be exercised in one connected flow.

The night-shift loop

CORE LOOP / 05
01

Prepare

Review the computer, daily list, and emails.

02

Verify

Evaluate identity, memory, and UV evidence together.

03

Decide

Allow passage or intervene.

04

Respond

Manage the facility task, inventory, and creature risk.

05

End the shift

Leave at 09:00, record the outcome, and continue.

Integration flow

PHASE 11
01

Task triggers

A generator failure or feeding task creates a new priority.

02

Leave the booth

The player commits time and limited inventory.

03

Door risk

An open door increases the chance of infiltration.

04

Encounter

A creature may attack or ambush the player.

05

Return to checkpoint

Reconnect with the identity and UV decision flow.

Art prototype and environment

ART / WIP

The retro workstation, security booth blockout, metal door, and wall clock document the current visual production stage. They do not claim final materials or a locked art direction.

WORK IN PROGRESS

Retro workstation

CRT monitor, keyboard, mouse, and PC tower form the low-poly information hub.

WORK IN PROGRESS

Security booth

An early environment blockout testing the desk, door, and readable interaction space.

WORK IN PROGRESS

Base model set

A character head blockout, metal door, and wall clock establish scale and the long-shift time reference.

Current prototype statusSANDBOX / INTEGRATED

These systems are reported as working in the Sandbox flow. Balancing, usability checks, main-scene content, and polish remain ahead.

01✓

FPS movement & interaction

IN SANDBOX
02✓

NPC & identity check

IN SANDBOX
03✓

Scientist memory

IN SANDBOX
04✓

UV detector

IN SANDBOX
05✓

Facility task

IN SANDBOX
06✓

Creature encounter

IN SANDBOX
07✓

Shift schedule

IN SANDBOX
08✓

Sandbox debug tools

IN SANDBOX

This week's evaluation target

PLAYABLE SEQUENCE
  1. Review the shift information.
  2. Inspect a person and gather evidence.
  3. Make a consequential decision.
  4. Handle one facility task or threat.
  5. Return to the checkpoint and continue the flow.

Game feel checklist

CHECKLIST
Readability

Can the player understand what can be interacted with?

Feedback

Do actions communicate success, failure, or danger?

Control

Do movement, looking, and interaction feel predictable?

Pacing

Can inspection and physical tasks alternate without confusion?

DONEPhase 11

System integration in Sandbox

NEXTPhase 12

Main game construction

AFTERPhase 13

Campaign, progression, and ending

LATERPhase 14

Balance, QA, and polish

PHASE 12—19

ENGINEERING LOG / TECHNICAL PROGRESS

From Sandbox systems to an integrated game experience

The Phase 12–19 report brings atmosphere, debug tools, player-facing interfaces, NPC lifecycle behavior, input stability, and procedural facility prototyping into one technical progress line.

A first-person retro-horror and deduction game built with Unity 6 and URP. Nazım leads programming, technical architecture, and integration; Ramtin leads modeling, textures, and visual production. This stage moves validated Sandbox systems toward a more integrated and presentable game experience.

Implemented technical milestones

12—19
12

Atmosphere, lighting & shift reporting

AudioManager centralizes audio. FacilityLightingEffects handles emergency lighting and implemented flicker feedback during events such as generator failure. ShiftReportUI presents performance and relevant outcomes at shift end.

13

Isolated debug & runtime state

DebugController toggles the developer panel with F1. PauseMenuUI handles ESC pause behavior, cursor state, and UI/gameplay input transitions. Debug controls remain separate from the intended player experience.

14—19

Main technical development

Dialogue memory, NPC facility lifecycle, input conflict resolution, and procedural 3D facility blockout connect multiple systems into a shared gameplay flow.

Scientist Dialogue UI & Memory Architecture

UI / MEMORY

Dialogue presentation moved from an OnGUI-dependent approach to Unity UGUI Canvas components. The UI uses existing scientist data, answer tables, and memory systems instead of duplicating gameplay logic.

  • ScientistDialogueUI, ScientistComponent, ScientistSystem, and ScientistDataSO keep presentation, data, and gameplay logic separated.
  • Dynamic question generation provides fallback behavior when predefined question lists are empty.
  • EventSystem and InputSystemUIInputModule are initialized where necessary; the latest transcript can remain visible after reopening.
  • Repeated-question counts can trigger the existing complaint behavior.
  • Consistency checks remain gameplay logic; the UI does not label a character as a Skinwalker or reveal the correct decision.

NPC Facility Lifecycle & Exit Check

NPC / EXIT

CheckpointManager, NPCController, and TimeManager work together to establish the facility entry and exit cycle.

  1. An NPC passes the entry checkpoint.
  2. Facility presence is tracked using existing runtime data.
  3. An exit time is scheduled through the game-time system.
  4. The NPC returns to the checkpoint.
  5. The player performs an exit inspection.
  6. The NPC can leave after the exit decision.

Input & Event Conflict Resolution

INPUT / UI

Transitions between PlayerWeaponHandler, PlayerItemHolder, PlayerInteraction, PlayerHUD, PauseMenuUI, and ScientistDialogueUI use safeguards that reduce same-frame input leakage.

  • Weapon firing and reloading are blocked while protected UI interactions are active.
  • UI clicks do not trigger unrelated gameplay input.
  • A JustClosedThisFrame-style guard reduces input leakage when interfaces close.
  • Cursor state and UI/gameplay input transitions are managed together.
  • Legacy IMGUI and UGUI Canvas layer interactions are handled explicitly.

Procedural 3D Facility Map Builder

LEVEL / BLOCKOUT

FacilityMapBuilder and FacilityMapEditor translate a hand-drawn facility plan into a testable 3D blockout using Unity primitives and colliders. Architectural_Facility_Map.prefab can be produced as an architectural prototype.

GROUND FLOOR

Security/inspection room, central observation area, airlock, and locked archive.

UPPER FLOOR

Containment sector, security bridge, gate, and six containment cells.

BASEMENT

Technical areas and connections for testing the facility maintenance flow.

* Ramps, doors, collision geometry, and TextMesh labels make the space navigable and testable. The generator works in an isolated coordinate region to protect existing scene objects; this is a level-prototyping output, not final environment art.

Technical architecture & integration

DEPENDENCY MAP
01

Core & time

TimeManager maintains the shift flow; CheckpointManager and NPCController connect the facility lifecycle.

02

Deduction systems

ScientistSystem, ScientistComponent, ScientistDataSO, and SkinwalkerComponent separate data, memory, and consistency checks.

03

Player & input

PlayerInteraction, PlayerItemHolder, and PlayerWeaponHandler handle gameplay input; UI guards manage transitions.

04

Presentation

ScientistDialogueUI, PauseMenuUI, PlayerHUD, and ShiftReportUI manage player-facing presentation.

05

World feedback

FacilityLightingEffects and AudioManager produce lighting and audio feedback for events.

06

Level prototype

FacilityMapBuilder and FacilityMapEditor generate the procedural facility blockout.

Validation & engineering quality

BUILD CHECK

The reported command `dotnet build "Assembly-CSharp.csproj" --no-restore` completed with zero compilation errors. This is a C# project compilation check; it is not a complete Unity Play Mode test, regression suite, performance test, or release build validation. Unity 6-compatible APIs replaced older APIs that had become obsolete.

COMMANDdotnet build "Assembly-CSharp.csproj" --no-restore0 compilation errors

Current state & next direction

STATUS / NEXT
REPORTED COMPLETEPHASE 12—19

Technical systems and tools are reported as implemented; the complete final game is not claimed.

BLOCKOUTFACILITY MAP

The procedural output is a testable architectural prototype, not final environment art.

NEXT FOCUSMAIN SCENE

Player-facing UI, interaction polish, feedback, and campaign reliability.

QUALITYVERIFY & TEST

Integration, usability, and gameplay flow require broader validation.

NEXT

SCOPE / DELIVERY TARGET

Separate the course target from the long-term vision

The project aims for a longer demo, but the course submission should first deliver a small, complete, and representative playable section.

COURSE SUBMISSION

10–30 minutes

Playable vertical slice

A short experience that demonstrates the core hook, gameplay loop, feedback, and a controlled rise in tension.

LONG-TERM TARGET

3–4 hours

Expanded demo

More shifts, events, and content; treated as an ambition to revisit as scope and production capacity are validated.

Next milestone

01—04
  1. Test identity, memory, UV, tasks, shift flow, and creature mechanics in one representative sequence.
  2. Keep a short recording or test note for each scenario.
  3. Fix the highest-priority integration issues and review the prototype flow from a player's perspective.
  4. Lock the 10–30 minute vertical slice scope for the course; keep longer-term features in a separate backlog.

Scope risks to watch

WATCHLIST
Too many systems

Response: validate the core flow first and attach additional features to milestones.

Integration complexity

Response: test systems in isolation and with combined Sandbox scenarios.

Limited polish time

Response: keep the course vertical slice separate from the long-term demo scope.

CURRENT STATUS

From a concept to a testable gameplay loop.

The first four weeks focus on explaining the idea, reviewing design references, defining the production method, and clearly showing which mechanics the current prototype can demonstrate.

PROJECT: NIGHTWATCH · WORK IN PROGRESS
TEAM

Nazım — Technical

Ramtin — Art

TOOLS

Unity · Blender · VS Code

GitHub · Notion

COMPETITOR SOURCES

Game descriptions link to official Steam store pages. The comparisons are qualitative design analysis for this project.

That's Not My NeighborPapers, PleaseContraband PoliceI'm on Observation DutyThe Operator