Game Architecture

Game development typically happens in statically typed and Object-Oriented programming languages. In stark contrast, Clojure is a dynamically typed, multiple paradigm programming language, with different strengths and weaknesses depending on the application domain.

Object Oriented (OO) game design

A typical game loop in a typical OO-language consists of the following four steps repeated in an (endless) loop:

1. Handle user input
2. Update the game state
3. Render the game state
4. Wait until the designated time span has passed

Keeping everything sequential has some advantages for a OO-programmer, of which the major one would be that no coordination of access to mutable state is needed. A disadvantage of this approach is the fact that modern hardware has support for lots concurrently executing threads, but this capability is left unused when using this simple design.

Clojure's multiple paradigm game design

Clojure borrows heavily from functional programming languages, but still manages to combine several FP concepts with tried and tested OO techniques. As such, Clojure provides the concurrency primitives which are needed to break free from the restrictions of typical OO-languages.

Instead of viewing the game as a repeating sequence of operations, a Clojure game can be seen as a set of asynchronous processes operating on a (set of) concurrency primitives representing the game state. By leveraging closures, callbacks and higher-order functions, one can totally decouple rendering, physics, animation, input handling and even AI subsystems from each other\cite{ztellman-game}. Combining these techniques with existing OO libraries leads to a maintainable, testable and above all, simple system which utilizes the capabilities of modern hardware.

Scheduling

Built into the Java platform is a task scheduler. Using this scheduler, tasks can be scheduled to either run once at some defined future time or run repeatedly until stopped. Using this scheduler all game actions that are time-based (i.e. rendering) rather than event-based (i.e handling user input). can be scheduled, ensuring that the game engine does not need to have a dedicated timed loop for them.

Thread safety

A primary reason why many games choose for a single-threaded model is thread safety. Thread safety would normally require careful locking of shared data, but due to Clojure's data immutability and shared data constructs, much of the work for reasoning about thread operation has already been done. Thread safety is no reason to avoid a multi-threaded program.