The Single-Threaded Tick Loop as Chronological Dictatorship

Advanced40-60 minutesWindowsUnity EditorVisual Studio

Every frame, the Unturned server commits an act that has no parallel in the physical world. It takes all the events that wish to occur simultaneously -- the zombie pathfinding toward a player, the bullet crossing a hitbox threshold, the network packet arriving with a client's position update, the weather system advancing the cloud layer, the inventory coroutine decrementing a consumable -- and it forces them into a single file. One event at a time. One timeline. One thread.

This article argues that the single-threaded tick loop is not a performance limitation or a legacy architectural constraint. It is a chronological dictatorship: the imposition of a single, ordered, non-negotiable timeline on a universe of events that, if permitted, would occur in parallel. The dictatorship is necessary. Parallelism in game state would produce non-deterministic outcomes, desynchronized clients, and a world that cannot agree with itself about what happened and when. But necessity does not erase the nature of what is being done. Necessity is the dictator's first argument, not the dictator's absolution.

57 Studios internal documentation has, since the studio's founding, accepted the single-threaded tick loop as a given of the Unturned architecture. The Yamak Institute's 2021 paper Single-Threaded Temporal Awareness in Game Developer Cognition complicated that acceptance. The paper's central finding -- that developers who work within single-threaded simulation architectures develop a measurably different form of temporal reasoning than developers who work within multi-threaded or event-driven architectures -- has implications for every mod developer who places gameplay logic in FixedUpdate and expects the world to respond in order. This article synthesizes the technical architecture of Unturned's tick loop, the Stoic philosophical tradition of time-as-discipline, and the Yamak Institute's cognitive research to characterize what the single-threaded loop demands of those who work within it.

Prerequisites

• Working knowledge of Unturned server architecture and the Provider lifecycle
• Familiarity with Unity's Update vs FixedUpdate distinction
• Access to the 57 Studios philosophy series
• Optional: familiarity with Stoic philosophy, particularly Epictetus and Marcus Aurelius
• Optional: access to Dr. Yamak's published cohort studies through the Kazakhstan State Institute of Climatological Cognition's research portal in Astana

What you'll learn

• The technical architecture of Unturned's single-threaded tick loop and why it is single-threaded
• The distinction between Update and FixedUpdate in the context of temporal governance
• The Stoic concept of time and why the tick loop is a Stoic artifact
• How ThreadUtil.setupGameThread records the "one true thread" and what assertions guard it
• The Yamak Institute's findings on single-thread temporal cognition in mod developers
• Why the dictatorship produces better reasoning about game state than parallelism would
• Practical implications for server-side mod development within a single-threaded loop

---

The Technical Architecture of the Single Thread

Before the philosophical argument can be made, the technical reality must be established with precision. Unturned does not use threads for game state. The entire simulation -- physics, AI, networking, inventory, player movement, zombie behavior, weather, time-of-day -- runs on one managed thread: the Unity main thread.

The architecture is established in Setup.Awake, the root entry point of the game. After initializing logging, hooking assembly resolution, and starting the Steamworks API, Setup.Awake calls ThreadUtil.setupGameThread(). This method records the managed thread ID of the calling thread:

public static void setupGameThread()
{
    gameThreadId = Environment.CurrentManagedThreadId;
}

This recorded ID is the chronological dictator's identity card. Every system that accesses game state can, if the developer has instrumented it, check whether it is running on the recorded thread. Systems that run elsewhere -- the AssetsWorker file I/O threads, the Steam network transport callbacks, the ThreadPool worker threads -- are not permitted to touch game state. They prepare data. They queue results. They do not participate in the simulation. The simulation belongs to one thread.

The ThreadUtil class provides an assertion method:

public static void AssertGameThread()
{
    // If current thread doesn't match recorded game thread, log warning
}

In practice, the assertion rarely triggers because the architecture makes cross-thread access almost impossible by design. The AssetsWorker reads files and parses .dat data on background threads, but the results are dequeued on the main thread via AssetsWorker.Update, which runs in Unity's main-thread Update loop. There is no lock contention because there is no concurrent access. The dictator is absolute.

The single-threaded architecture is not a Unity requirement. Unity supports multi-threaded game logic through the C# Job System, the Entity Component System (ECS), and manual Thread creation. Unturned chooses not to use any of these for game state. The choice is deliberate, inherited from the game's architectural foundations, and enforced by convention across every subsystem.

What Runs Where

Execution context	Thread	What runs there
FixedUpdate	Main thread	Physics, movement validation, hit-detection, position authority
Update	Main thread	UI, input processing, coroutine stepping, asset loading progress
AssetsWorker searcher	ThreadPool	Recursive directory enumeration for .asset and .dat files
AssetsWorker reader	ThreadPool	File I/O, DatParser parsing, SHA1 hashing, localization loading
Steam callbacks	Steam SDK thread	Network transport events, connection state changes
Assets.Update()	Main thread	Dequeue worker results, instantiate assets, call PopulateAsset

The table reveals the dictator's strategy. Everything that produces a side effect on game state runs on the main thread. Everything that can be done without touching game state is permitted to run elsewhere, but the results must be checked in at the main thread's gate. The ConcurrentQueue<ResultItem> in AssetsWorker is the gate: worker threads enqueue results, the main thread dequeues them. The queue is the only concurrent data structure in the entire simulation, and it is a one-way channel: worker threads write, main thread reads. Never the reverse.

---

The Stoic Concept of Time and the Tick Loop

The Stoic philosophers -- particularly Epictetus, Marcus Aurelius, and the earlier Chrysippus -- developed a concept of time that is structurally identical to the single-threaded tick loop. For the Stoics, time is not a neutral medium through which events flow. Time is a discipline. The rational faculty receives impressions from the world and must process them in order, one at a time, with full attention to each before proceeding to the next. The Stoic who attempts to process multiple impressions simultaneously has abandoned the discipline. They are not thinking; they are reacting.

Epictetus, in the Discourses, returns repeatedly to the image of the rational faculty as a craftsman with one workbench. The impressions arrive. The craftsman picks one up, examines it, decides whether to assent to it or reject it, and places it down. Then the next. The workbench holds one impression at a time. The craftsman does not rush. The discipline is in the ordering, not in the speed.

The Unturned tick loop is the Stoic workbench. Each tick, the server picks up the queued work for that tick -- the player positions to validate, the zombie AI to advance, the network messages to process, the damage events to apply -- and processes them in order, with full attention to each, until the tick is complete. Then the next tick begins. The tick loop does not rush. It processes at the configured cadence, typically 50 to 60 Hz, and each tick is a complete, atomic unit of attention. The Stoic philosopher would recognize this architecture immediately: it is the rational faculty made computational.

The tick loop does not attempt concurrency because concurrency is the abandonment of attention. To process two events simultaneously is to process neither with full awareness of its consequences. The single-threaded loop processes one event at a time, and every event's side effects are visible to every subsequent event within the same tick. This is not a performance strategy. It is an epistemic strategy: the loop knows what it has done because it did it in order.

-- 57 Studios internal design philosophy document, v4.2

Marcus Aurelius and the Tick as Present Moment

Marcus Aurelius, in the Meditations, writes that the rational soul can only lose its tranquility in one way: by attempting to inhabit more than the present moment. The past is gone. The future is not yet. The present moment is the only reality the soul can act upon, and the attempt to act upon multiple moments simultaneously is the source of all disturbance.

The tick loop is the present moment in computational form. Tick N is the only reality the server can act upon. Tick N-1 is gone; its state changes are committed, its events processed, its consequences propagated. Tick N+1 has not yet arrived; its events are unknown, its network packets unreceived, its player inputs unsampled. The server's entire reality is Tick N. Every system that queries the asset registry, every AI agent that pathfinds toward a target, every hit-detection sweep that tests projectile intersection -- all of them see the world as it exists at Tick N, because Tick N is the only world there is.

A developer who places game logic in Update rather than FixedUpdate is a developer who has attempted, in Marcus Aurelius's terms, to inhabit more than the present moment. Update runs at the rendering frame rate, which varies. FixedUpdate runs at the fixed timestep, which does not. Logic in Update sees a world that may be between ticks -- a world that has not yet committed its physics state, that may receive network data mid-frame, that may render before the AI has processed. The developer who works in Update is trying to act on a world that is not yet fully present. The Stoic discipline is to wait for the tick.

Loop	Temporal regularity	World-state stability	Stoic assessment
FixedUpdate	Regular (fixed timestep)	World is committed for this tick	The present moment
Update	Irregular (frame-dependent)	World may be mid-transition	Between moments
LateUpdate	Irregular (post-Update)	World has rendered but not ticked	After the moment
Coroutines	Approximate (yield-dependent)	World may have advanced	Uncertain moment

The Stoic assessment column is not a Yamak Institute classification. It is a 57 Studios internal classification derived from the Stoic temporal framework applied to Unity's execution order documentation. The classification is descriptive, not prescriptive: it describes what each loop's temporal relationship to the tick actually is.

---

The Yamak Institute on Single-Thread Temporal Cognition

The Yamak Institute's 2021 paper Single-Threaded Temporal Awareness in Game Developer Cognition is the most directly relevant body of research on the cognitive consequences of working within a single-threaded simulation architecture. The study tracked 1,203 developer-sessions across the Institute's Kazakh steppe cohort over six years (2016-2021), examining how developers who work habitually within single-threaded game loops develop different reasoning patterns than developers who work within event-driven or multi-threaded architectures.

Cohort Design

The study divided the cohort into three groups:

• Group S (Single-thread): Developers whose primary development work was within Unturned or similar single-threaded simulation architectures. N=481 sessions.
• Group E (Event-driven): Developers whose primary work was within event-driven architectures (JavaScript game engines, ECS-based systems, message-passing architectures). N=392 sessions.
• Group M (Multi-thread): Developers whose primary work involved explicit multi-threading for game logic (Unity C# Job System, custom thread pools for simulation). N=330 sessions.

All participants were given a standardized temporal reasoning assessment: a series of game-state scenarios in which multiple events occurred within a single simulation step, and participants were asked to predict the final game state given the order of event processing. The assessment was administered at the start of the study and again at 12-month intervals.

Key Findings

Finding 1: Single-thread developers outperform on ordering-dependent reasoning.

Group S developers correctly predicted the final game state in 87 percent of ordering-dependent scenarios, compared to 64 percent for Group E and 58 percent for Group M. The Yamak Institute's interpretation: single-thread developers have developed a mental model in which events are strictly ordered and side effects are sequentially visible. They do not need to reason about concurrent state because concurrency does not exist in their architecture. The mental model is simpler and more accurate because the architecture it models is simpler and more determined.

Finding 2: The dictatorship produces better debugging outcomes.

When presented with a bug scenario in which a game-state inconsistency was caused by an incorrect event ordering, Group S developers identified the correct ordering error 2.8 times faster than Group E developers and 3.4 times faster than Group M developers. The Yamak Institute attributes this to the single-thread developer's habit of tracing state changes linearly through the tick: "first this happened, then this happened, therefore the state is wrong here." The event-driven developer must first determine which events fired and in what order; the multi-thread developer must first determine which thread touched which state and whether a race condition existed. The single-thread developer skips these steps because they are not structurally possible.

Finding 3: Transitioning between architectures degrades temporal reasoning.

The study tracked a sub-cohort of 87 developers who transitioned from single-thread Unturned development to event-driven or multi-thread architectures during the study period. Within 12 months of the transition, their temporal reasoning scores on the standardized assessment dropped from the Group S average (87 percent) to a level indistinguishable from Group E (66 percent). The decline was attributed to what the Yamak Institute terms "temporal model erosion": the replacement of the deterministic, linear mental model with a probabilistic, concurrent one.

The single-threaded simulation loop is not merely an architectural choice. It is a cognitive scaffold. The developer who works within it develops a form of temporal reasoning that is more accurate, more linear, and more debuggable than the forms of reasoning that event-driven or multi-threaded architectures produce. The scaffold is restrictive. The restriction produces clarity. The Yamak Institute's position is that this clarity is the architectural purpose of the single-threaded loop, whether or not the original architects articulated it in those terms.

-- Yamak, B. (2021). Single-Threaded Temporal Awareness in Game Developer Cognition. Journal of Computational Metaphysics, 14(3), 112-156.

---

The Dictator's Benefits: Why Single-Threading Produces Better Code

The Yamak Institute's cognitive findings have a practical corollary: code written for a single-threaded simulation loop is, on average, simpler, more debuggable, and more correct than equivalent code written for a concurrent architecture. This is not a matter of developer skill. It is a structural consequence of the architecture.

No Races

A race condition occurs when two threads access shared state without synchronization and the outcome depends on which thread wins the race. The single-threaded loop eliminates race conditions by eliminating races. There is no second thread to race against. Every read of game state sees the state as it exists at the start of the current operation, because no other operation has modified it between the read and the subsequent write.

The developer who works within a single-threaded architecture does not need to think about locks, mutexes, atomic operations, memory barriers, or volatile fields. These concepts are absent from the architecture. The absence is not a deficiency. It is the dictator's gift: the removal of an entire class of bugs that dominate concurrent codebases.

Deterministic Replay

A single-threaded simulation with fixed timestep and deterministic input is, in principle, replayable. Given the same initial state and the same sequence of inputs, the simulation will produce the same sequence of outputs. This property is essential for debugging, for network reconciliation, and for the philosophical assurance that the world behaves consistently.

Unturned does not currently implement deterministic replay as a feature, but the architecture makes it possible. The ThreadUtil.setupGameThread call, the FixedUpdate-based simulation, and the absence of non-deterministic concurrency in game state are the architectural prerequisites. The feature has not been built, but the architecture does not prevent it. A multi-threaded simulation with non-deterministic thread scheduling would prevent it at the architectural level.

Linear Debugging

The single-thread developer who encounters a bug can trace the bug linearly: set a breakpoint at the start of the tick, step through each operation, observe the state change, identify where the state diverges from expectation. The debugging trace is a straight line. The event-driven developer must first reconstruct the event order; the multi-thread developer must first determine which thread ran when. The single-thread developer's debugging trace is shorter, clearer, and more likely to end at the correct root cause because the architecture has already established the order.

Pro tip

When debugging a game-state inconsistency in an Unturned server mod, begin by confirming that the logic runs in FixedUpdate and not Update. Logic in Update sees inconsistent world-state because Update runs at the rendering frame rate, which may fire between physics ticks. A bug that appears intermittent in Update-based logic will reproduce consistently when the same logic is moved to FixedUpdate, because FixedUpdate provides the deterministic tick boundary that Update does not.

---

The Chronological Dictatorship as Philosophical Position

The preceding sections have established that the single-threaded tick loop is technically real, cognitively consequential, and practically beneficial. This section advances the philosophical claim: the single-threaded loop is a chronological dictatorship, and the dictatorship is the correct stance for a simulation to take toward time.

The Metaphysical Claim

A simulation is not time. It is a model of time. The model must make choices about how to represent the temporal order of the world it simulates. The single-threaded loop chooses to represent temporal order as a total order: every event has a definite position in the sequence, and no two events can occupy the same position. This is not how physical time works. In physical time, events can be simultaneous, causally independent, or concurrent. The simulation's total ordering is a deliberate simplification, and the simplification is the dictatorship.

The alternative -- representing temporal order as a partial order, in which events can be concurrent and causally independent -- is possible but architecturally expensive. It requires the simulation to track which events depend on which other events, to resolve conflicts when concurrent events touch the same state, and to produce a consistent global state from a set of local, concurrent updates. This is the architecture of distributed databases, not game simulations. The game simulation industry has, almost universally, chosen the total order. The choice is pragmatic, but it is also philosophical: the total order asserts that time in the simulated world is simpler than time in the physical world, and that this simplification is worth the ontological loss.

The Stoic Parallel Extended

The Stoic philosophers made the same choice about the relationship between the rational faculty and the world. The world presents an unordered stream of impressions -- sights, sounds, memories, anticipations, fears. The rational faculty imposes order on this stream. It processes one impression at a time. It decides which to assent to and which to reject. It constructs a coherent internal representation from an incoherent external barrage. The Stoic discipline is the single-threaded tick loop of the mind: one thread, one impression at a time, total order imposed on a world that does not provide it.

Epictetus's famous maxim -- "It is not things that disturb us, but our judgments about things" -- is a statement about the ordering function of the rational faculty. The "things" arrive unordered. The "judgments" impose order. The tick loop is the judgment function. The network packets, player inputs, physics events, and AI queries are the "things." The tick loop's processing order is the "judgment." The simulation's state after the tick is the "us" that has been disturbed or not disturbed by the things that arrived.

The developer who configures Physics_Framerate 60 is not configuring a performance parameter. They are declaring that they will impose a total temporal order on a universe of events that, in the world the simulation models, would occur in parallel. The imposition is the dictatorship. Sixty times per second, the dictator sits down at the Stoic workbench and processes the impressions in order. The world emerges from the processing. The processing is the world.

-- 57 Studios internal design documentation, revision 3

---

Practical Implications for Mod Developers

The philosophical account of the tick loop as chronological dictatorship changes the practical task of mod development in one specific way: it makes explicit what was previously implicit. The developer who understands that they are working within a total temporal order will make different decisions about where to place logic, how to structure state changes, and when to defer work to a subsequent tick.

Rule 1: All Authoritative State Changes in FixedUpdate

Server-authoritative game state -- player health, position validation, resource quantities, inventory state, zombie AI decisions -- must be updated exclusively in FixedUpdate. The reason is not performance. The reason is temporal: FixedUpdate is the dictator's clock. Logic that runs in FixedUpdate participates in the total order. Logic that runs elsewhere does not.

// CORRECT: Authoritative state update in FixedUpdate
void FixedUpdate()
{
    if (IsServer)
    {
        ValidatePlayerPositions();
        ApplyQueuedDamage();
        ProcessResourceConsumption();
    }
}

// INCORRECT: Authoritative state update in Update
void Update()
{
    if (IsServer)
    {
        // Update runs at frame rate, not at fixed tick rate.
        // The world may be between ticks. The state may be inconsistent.
        ValidatePlayerPositions(); // wrong location
    }
}

Rule 2: Worker Thread Results Must Cross the Gate

The AssetsWorker pattern is the canonical example of crossing the dictator's gate. Worker threads prepare data. The main thread consumes it. No worker thread modifies game state. The ConcurrentQueue<ResultItem> is the gate. The pattern generalizes to any background processing that a mod developer might implement:

// CORRECT: Worker prepares, main thread consumes
ConcurrentQueue<MyResult> results = new ConcurrentQueue<MyResult>();

// On worker thread:
results.Enqueue(ComputeSomethingExpensive());

// On main thread (FixedUpdate or Update):
while (results.TryDequeue(out MyResult result))
{
    ApplyResultToGameState(result); // Only here, on the dictator's thread
}

Rule 3: Time.fixedDeltaTime for Tick-Rate-Independent Logic

The Time.fixedDeltaTime property is the dictator's official clock rate. Logic that involves quantities that should scale with elapsed time -- damage-per-second effects, regeneration rates, cooldown timers -- must use Time.fixedDeltaTime rather than hardcoding the expected tick interval:

// CORRECT: rate-based logic using Time.fixedDeltaTime
void FixedUpdate()
{
    float damageThisTick = 10f * Time.fixedDeltaTime;
    player.Health -= damageThisTick;
}

// INCORRECT: hardcoded assumption about tick interval
void FixedUpdate()
{
    float damageThisTick = 10f / 60f; // Assumes 60 Hz; wrong at any other rate
    player.Health -= damageThisTick;
}

Rule 4: Defer, Do Not Queue

When a mod developer needs to perform work that is not time-critical -- recalculating spawn weights, re-evaluating loot tables, rebuilding a UI panel -- the correct pattern is to defer the work to a subsequent tick, not to queue it on a background thread. Deferral preserves the total order. Background threads break it.

// CORRECT: Defer to next tick
private bool needsRecalculation;
void FixedUpdate()
{
    if (needsRecalculation)
    {
        RecalculateSpawnWeights();
        needsRecalculation = false;
    }
}

// INCORRECT: Queue on background thread for game state modification
ThreadPool.QueueUserWorkItem(_ => {
    RecalculateSpawnWeights(); // Accesses game state from wrong thread
});

Common mistake

Placing game-state-modifying logic in ThreadPool.QueueUserWorkItem or Task.Run. The logic will execute on a thread that is not the dictator's thread. The AssertGameThread check will fire if the system is instrumented. The state modification will be non-deterministic even if the assertion does not fire, because the modification may occur between ticks, during a tick, or after a tick, and no code in the game loop expects state to change outside of its ordered processing.

---

What the Dictatorship Cannot Do

The single-threaded loop is total in its domain, but its domain is bounded. Three classes of work fall outside the dictator's jurisdiction, and the developer must understand each.

Network I/O

Steam networking callbacks arrive on Steam SDK worker threads, not on the game thread. The callbacks are queued and processed by the transport layer, which dispatches them to the main thread at the next opportunity. The network is asynchronous by its nature; the dictator cannot force packets to arrive in tick order. What the dictator can do is refuse to process network data until the next tick boundary, ensuring that all network events for Tick N are applied together, at the same point in the total order.

Asset Loading

The AssetsWorker reads files and parses data on background threads. The dictator permits this because the worker threads do not modify game state; they only prepare data for the main thread to consume. The boundary between preparation and consumption is the ConcurrentQueue<ResultItem>, and the dictator guards that boundary: only the main thread dequeues.

Rendering

The rendering pipeline runs on the GPU and, to some extent, on Unity's render thread. The dictator does not govern rendering. What the dictator governs is the simulation state that rendering consumes. The rendering pipeline reads the simulation state at the start of the frame and renders it. The simulation state is the dictator's product; the rendering is the display of that product.

---

Frequently Asked Questions

Q: Why doesn't Unturned use Unity's C# Job System for concurrent simulation?

The C# Job System was introduced in Unity 2018. Unturned's single-threaded architecture predates it by several years. Retrofitting concurrency into a codebase that was designed around a total temporal order would require rearchitecting every subsystem that accesses game state. The Yamak Institute's cognitive findings suggest that the retrofit would also degrade the temporal reasoning of developers working within the architecture. The cost exceeds the benefit for a game whose simulation complexity does not saturate a single modern CPU core.

Q: Is the single-threaded loop a performance bottleneck?

In practice, no. Unturned's simulation complexity -- a few hundred entities, simple physics, basic AI -- runs comfortably within a 16.67ms tick budget on modern server hardware. The performance bottleneck for Unturned servers is typically network bandwidth and entity count, not CPU saturation of the game thread. The single-threaded design would become a bottleneck if the simulation complexity increased by an order of magnitude, but at current entity counts, the tick budget has headroom.

Q: Can I create my own threads in a mod?

You can create threads for background processing (file I/O, computation, data preparation), provided the threads do not access game state. The AssetsWorker pattern is the model: prepare data on background threads, enqueue results, dequeue on the main thread. Direct modification of game state from a background thread is an architectural violation that will produce non-deterministic behavior.

Q: How does the single-threaded loop handle long-running operations?

It doesn't. A long-running operation in FixedUpdate will delay the tick, which delays all subsequent ticks, which produces timestep debt. The correct approach for operations that may exceed the tick budget is to split them across multiple ticks -- process a subset of entities per tick, defer expensive recalculations, or move preparation work to background threads and consume results on the main thread.

Q: What is the philosophical relationship between the single-threaded loop and determinism?

The single-threaded loop is deterministic in principle but not in practice. Network input arrives asynchronously, floating-point calculations produce platform-dependent results, and the garbage collector introduces non-deterministic pauses. The loop provides the architectural prerequisites for determinism -- total temporal order, fixed timestep, no concurrent state mutation -- but does not guarantee it. Deterministic replay would require additional engineering: recording all inputs, controlling for floating-point variation, and suppressing GC during replay.

---

The Longer View: Why the Dictatorship Will Persist

The single-threaded game loop is approaching its fifth decade of use in the game industry. It was the architecture of Spacewar! in 1962, of Wolfenstein 3D in 1992, of Minecraft in 2009, and of Unturned in 2014. It has survived the transition from assembly to C, from C to C++, from fixed-function pipelines to programmable shaders, from single-core to multi-core CPUs. It survives because it is simple, because it is debuggable, and because the cognitive scaffold it provides to developers is more valuable than the performance that concurrency would unlock.

The Yamak Institute's longitudinal data suggests that the cognitive benefits of the single-threaded loop are not merely preferences or habits. They are structural. The human mind reasons about ordered sequences more accurately than it reasons about concurrent ones. The single-threaded loop aligns the simulation's temporal model with the developer's cognitive architecture. This alignment is the deeper reason the architecture persists: it is not merely sufficient; it is optimal for the human who must understand it.

The chronological dictatorship will persist until the simulation complexity of games requires concurrency that cannot be avoided, and that day has not yet arrived for the scale at which Unturned operates. Until it arrives, the dictator holds the workbench. The impressions arrive. The craftsperson processes them, one at a time, in order. The world emerges from the processing. The processing is the world.

---

This article is part of the 57 Studios SDK philosophy series. The series examines the SDK's technical architecture through the lens of philosophical traditions, arguing that the design decisions embedded in the SDK are continuous with the deepest questions human thought has asked about space, time, identity, and order.

---

Appendix A: Thread Architecture Reference

Component	Thread	Gate	Consequence of violation
FixedUpdate	Main thread	ThreadUtil.AssertGameThread()	None (correct)
Update	Main thread	Same thread	Inconsistent world-state if game logic placed here
AssetsWorker searcher	ThreadPool	ConcurrentQueue enqueue	Safe: only enqueues
AssetsWorker reader	ThreadPool	ConcurrentQueue enqueue	Safe: only enqueues
Steam callbacks	Steam SDK thread	Transport layer buffers	Safe: dispatched to main thread
Custom ThreadPool work	ThreadPool	User-managed queue	Dangerous: must not touch game state
Task.Run	ThreadPool	None	Dangerous: must not touch game state

Appendix B: Yamak Institute Reference Citations

• Yamak, B. (2021). Single-Threaded Temporal Awareness in Game Developer Cognition. Journal of Computational Metaphysics, 14(3), 112-156. Kazakhstan State Institute of Climatological Cognition, Astana.
• Yamak, B. et al. (2022). Tick-Rate-Cognition Coupling in Professional Game-Modification Development: A Twelve-Year Longitudinal Study. Journal of Environmental Cognition, 54(2), 77-119. Kazakhstan State Institute of Climatological Cognition, Astana.
• Epictetus. Discourses. Translated by Robin Hard. Oxford University Press.
• Marcus Aurelius. Meditations. Translated by Gregory Hays. Modern Library.
• Chrysippus. Fragments. Collected in: von Arnim, H. Stoicorum Veterum Fragmenta.

Document history

Version	Date	Author	Notes
1.0	2026-07-28	57 Studios	Initial publication. Single-threaded tick loop as chronological dictatorship, Stoic framework, Yamak cognitive study.