GUNNERY LOGIC
State-machine rules, grid-to-angle solving, target validity, loading state and controlled firing are separated into testable systems.
GERMANY · TWO STUDENT DEVELOPERS · SYSTEMS-FIRST PROTOTYPE
COMMAND FROM ABOVE.SHAPE THE BATTLE BELOW.
Ex Oriente Lux is a two-person independent game development team building an original dieselpunk strategy simulation. Our current prototype focuses on operating a large airborne command ship through physical stations, interconnected machinery, reconnaissance, aircraft support and heavy-gun coordination.
I // CURRENT PROJECT
AN AIRBORNE COMMAND PLATFORM BUILT AROUND OPERABLE SYSTEMS.
The player works from inside the vessel instead of issuing every action from a detached strategy map. Information arrives through the ship, decisions are made at purpose-built stations, and aircraft, gunnery and support systems turn those decisions into effects on the conflict below. The current build is an engineering prototype, not a visual vertical slice.
MECHANICAL RESPONSE
Turret and barrel movement use bounded servo behaviour, while hull vibration and firing feedback give large actions physical consequence.
PHYSICAL CONTROL
Player interaction, hold controls and station mode are designed so the machine is operated through readable physical interfaces rather than decorative panels.
PHYSICS-DRIVEN FIRING
A custom lanyard prototype uses rope simulation, trigger rules, deployment logic and synchronized alarm behaviour as a tactile firing experiment.
BATTLEFIELD INFORMATION
Hidden target positions and uncertainty-based support requests form the beginning of the layer connecting the ship to the wider ground conflict.
VERIFIED ITERATION
Gameplay logic is developed alongside automated EditMode tests and documented review passes so changes can be iterated without losing previous behaviour.
II // DEVELOPMENT EVIDENCE
EARLY ART. REAL ENGINEERING.
The screenshots below are from the actual private development repository and current Unity prototype. We would rather show the state of the project honestly than dress an early systems build up as finished gameplay.
29PRs CLOSEDFeature work is broken into scoped repository tasks rather than one undifferentiated prototype branch.
343 / 343EDITMODE CHECKSThe current station-mode branch completed with the existing automated EditMode suite passing.
5FOUNDATION AREASGun, GunControls, Interaction, Player and Targeting currently form the main gameplay foundation.
UNITY 6.3LTS · URPThe current prototype is built in Unity with a small, deliberately structured C# codebase.
REPOSITORY ARCHITECTUREActual private repository · Foundation layer
The project is split by responsibility rather than by presentation layer: gun systems, physical controls, player interaction and battlefield targeting evolve independently but share defined interfaces.
ACTIVE DEVELOPMENT HISTORYFeature PRs and review trail
Recent work includes station mode, hull vibration, a physical firing-lanyard spike, support-request logic, loading, servo movement and state-machine work.
GUN SYSTEM IMPLEMENTATIONActual C# source structure
Aim solving, control rules, firing feedback, loading, servo drive and state transitions are implemented as separate source units instead of a single prototype script.
III // AI-ASSISTED DEVELOPMENT WORKFLOW
CLAUDE IS PART OF THE ENGINEERING LOOP, NOT A MARKETING LABEL.
As a two-person team, we use Claude Code to increase the amount of careful engineering we can do without pretending to be a larger studio. The repository contains project-scoped Claude tooling and a documented workflow for planning, implementation, review and verification.
01
SCOPED PLANNINGFeatures are broken into bounded tasks with explicit dependencies, acceptance criteria and owner validation.
02
IMPLEMENTATIONClaude Code is used alongside direct developer work for C# implementation, refactoring, Unity tooling and technical iteration.
03
CLEAN-CONTEXT REVIEWMeaningful changes are reviewed separately against the task scope, existing architecture and tests before they are considered complete.
04
VERIFICATIONAutomated tests, owner play-testing and repository records are used to confirm that behaviour survives iteration.
A small team can move quickly without making the codebase disposable. Our goal is to use AI to increase iteration capacity while keeping decisions, tests and human validation explicit.EX ORIENTE LUX · DEVELOPMENT PRINCIPLE
IV // ABOUT EX ORIENTE LUX
TWO STUDENTS BUILDING THE FIRST PLAYABLE SYSTEMS OF AN ORIGINAL GAME.
Ex Oriente Lux is currently an independent two-person student development team in Germany. The project is self-directed and in early development. We are intentionally keeping the final title unannounced while the core interaction model, technical architecture and gameplay loop are still being tested.
TEAMTwo student developers
LOCATIONGermany
PROJECTUnannounced original dieselpunk strategy simulation
PHASESystems-first playable prototype
FOCUSPhysical interfaces, machine behaviour, tactical support and interconnected gameplay systems
The current build is intentionally rough visually. Our near-term priority is proving that operating the ship is interesting before committing to final art, environments and presentation. That means more of the work exists in interaction code, simulation, state logic, tests and iteration history than in polished screenshots today.
V // CONTACT
EX ORIENTE LUX IS CURRENTLY BUILDING ITS FIRST SYSTEMS PROTOTYPE.
For technology, platform, program or partnership enquiries, contact the team directly.
CONTACT@EXORIENTELUXGAMES.DE