A technically ambitious Unity product that combined a compiler built from scratch, user-authored assembly programs, modular robot components and physics-driven 3D competition.
Assembly League is an INESSOFT-developed experimental game and technical product released on Steam. The case study focuses on the public engineering work rather than presenting the title as a major commercial success.
Assembly League asked players to build robots from modular parts and program them using an in-game assembly language. That required far more than ordinary game scripting: a language definition, tokenizer and parser, instruction model, compiler or interpreter behaviour, virtual-machine state, debugging feedback, component interfaces and integration with real-time 3D physics.
The project grew from INESSOFT's game-development history and interest in systems that expose underlying logic to users. The goal was to make programming part of the game world itself, allowing behaviour to emerge from a player's code and physical robot configuration.
User-authored programs had to be parsed safely, converted into executable instructions and run inside a controlled simulation. The virtual program then needed to read sensors, control modular components and interact with a physics environment without destabilising the host game.
Language tooling and real-time simulation have different failure modes. A syntax error needs precise feedback; a valid program can still create an infinite loop; component availability changes according to the robot build; and physics outcomes can make debugging appear non-deterministic from the player's perspective.
INESSOFT designed a small assembly language and built the compiler/runtime pipeline from scratch. The runtime exposed a controlled instruction set and interfaces to modular robot components. Execution limits and debugging feedback protected the simulation, while Unity handled the 3D environment, component hierarchy and physics interactions.
Assembly League became INESSOFT's strongest public demonstration of low-level language design, modular architecture and simulation thinking. Although commercially experimental, it proves the ability to build unusual technical systems rather than only conventional CRUD applications.
This is a content-based reconstruction, not a client screenshot. It shows the kinds of live inputs, controlled states, modules and evidence the delivered system had to bring together.
The player assembles a robot from supported modular components.
The available hardware determines which sensors, outputs or interfaces the program can use.
The player writes assembly code in the in-game editor.
The compiler tokenises and parses the source while retaining line-level diagnostics.
Exact client throughput, time-saving and financial figures are not published for this system. The case study therefore limits itself to implemented controls, workflow changes and verifiable system capabilities rather than manufacturing a percentage improvement for marketing purposes.
Each layer had a specific operational responsibility. This made failures easier to diagnose and prevented one screen, service or database field from becoming the accidental owner of the entire process.
Specified syntax, operands, registers, instructions, labels and error conditions.
Converted user text into structured tokens and program representation with source positions.
Resolved labels, validated instructions and executed code within a constrained virtual machine.
Mapped instructions or ports to sensors, motors and modular robot capabilities.
Managed robot construction, scenes, physics, collision and visual feedback.
Reported syntax, compile and runtime issues in terms the player could act on.
A case study is useful only when the flow can be understood. The sequence below shows where users, devices, databases or external systems entered the process and how responsibility moved.
The player assembles a robot from supported modular components.
The available hardware determines which sensors, outputs or interfaces the program can use.
The player writes assembly code in the in-game editor.
The compiler tokenises and parses the source while retaining line-level diagnostics.
Validation resolves labels, operands and component references.
The runtime executes the program under defined limits.
Instructions read simulated inputs and command the robot's components.
Unity physics produces the resulting movement and competition behaviour.
Errors or unexpected state can be inspected and the program revised.
These were not isolated feature requests. Each module supported a specific part of the operational lifecycle and shared the same data, state and accountability model.
Allowed players to write and revise robot programs.
Tokenised, parsed, validated and prepared instructions for execution.
Maintained registers, program counter, memory and execution constraints.
Exposed only the capabilities present in the player's physical robot design.
Connected simulated perception and movement to the virtual program.
Ran programmed robots in physics-driven scenarios.
Separated syntax, compile and runtime problems for the player.
The important work was often deciding what not to combine, automate or assume. These decisions made the resulting system easier to support and more honest about its boundaries.
A small purpose-built instruction set was safer and more teachable than exposing general scripting inside the game.
A compiler is unusable if it reports only that the program failed.
User code needed cycle or instruction controls to protect the simulation from infinite loops.
The runtime had to validate capabilities against the components actually installed.
The project prioritised engineering exploration, which created strong proof but a narrower commercial audience.
The project was broken into phases that reduced the highest-risk uncertainty first. This prevented a broad implementation from hiding an unproven data or workflow assumption.
Prove parsing, labels, instructions, registers and bounded execution outside the full game.
Connect runtime instructions to modular sensors and actuators.
Create scenarios where programmed behaviour produces visible outcomes.
Improve editor, errors, onboarding, packaging and Steam deployment.
The controls below reflect the kinds of failure that could produce wrong records, unsafe assumptions, hidden exceptions or a system users would bypass.
Executed programs inside a constrained runtime rather than the host application's process model.
Applied execution limits and controlled update scheduling.
Retained source positions and distinguished syntax from runtime problems.
Validated program access against installed robot modules.
Separated virtual-machine behaviour from Unity physics and component state.
Presented the project as technical proof rather than claiming mass-market success.
The exact sector or technology may differ. The closer match is usually the workflow shape, source data, failure modes and operational responsibility.
Training systems that need controlled scripting or programmable behaviour.
Engineering simulations with modular equipment or component interfaces.
Interactive tools where users define logic rather than only select options.
Projects requiring parsers, domain-specific languages or constrained runtimes.
Buyers assessing INESSOFT's Unity and low-level software capability.
The case study provides evidence. The service pages define the current delivery boundary, first-step artefacts, exclusions and technical scope for a new engagement.
Use Unity experience for practical simulation, training, visualisation and interactive technical tools.
Build the smallest working system that can prove a risky workflow, integration or operational assumption.
Turn an operational problem into a phased, evidence-based system scope before committing to the wrong build.
Build or extend a maintainable Microsoft-stack application when the required business system is already clearly defined.
Technology is listed for precision, but the system boundary and operating process determined the architecture.
Yes. The project included its own language definition, parsing, validation and controlled execution model.
A constrained purpose-built language made it possible to control capabilities, execution and integration with modular robot components while keeping the programming model part of the game design.
It was an experimental public product rather than a major commercial hit. Its value on this site is technical credibility, not inflated market claims.
The same skills apply to simulation, training, rule engines, domain-specific languages, modular architectures and systems where user-authored logic needs safe execution.
A portfolio of 12 games and applications, including the King management series, that reached more than 2 million active user accounts at peak.
A complete prototype workflow that connected physical electronics, firmware, user interaction, test sequencing, logged evidence and a clear handover boundary.
A long-running electronics commerce and operations platform that grew from surplus imported components into a technical catalogue, fulfilment system, internal-tool ecosystem and commercial engineering asset.
Bring one real artefact: a report, spreadsheet, machine signal, job record, certificate, import file, device or system error. INESSOFT can map the current process and define a credible first phase.
