Ceylon Development Log — September 18, 2026: Why an Operating System Needs a Game

Today Ceylon's first native game stopped being a side idea and became something much more useful: a plan for a real application that can entertain people, stress the operating system, test recovery, and teach us how third-party software should be built on the platform.

Project Ceylon Nightly: Why an Operating System Needs a Game

There is an easy way to demonstrate an operating system.

Draw a window.

Put some text in it.

Move a mouse cursor.

Play a sound.

Save a file.

Those are all important milestones, and Ceylon needs them.

But eventually a collection of technical demonstrations stops answering the harder question:

Can this machine actually run something interesting?

That is why I have been spending time on a native game for A1.

Not a port.

Not a browser game.

Not an SDL demo quietly carrying another operating system's assumptions underneath it.

A real Ceylon application.

Why a game is a useful systems test

Games are brutal in useful ways.

People notice input lag immediately.

They notice timing glitches.

They notice dropped frames.

They notice audio hiccups.

They notice when controls feel wrong.

They notice when a pause in storage, logging or background work interrupts the foreground experience.

A benchmark can tell me that Ceylon completed a million operations.

A game can tell me whether graphics, input, audio, timing, memory, storage, scheduling and application lifecycle can all cooperate while somebody is actively using the machine.

That is much more interesting.

The goal is not to write a fake game whose only purpose is to tick API boxes.

If we do this, I want the game to actually be worth playing.

That matters because an entertaining game creates design pressure that a technical demo does not.

Controls have to feel good.

The world has to make sense.

Difficulty has to be fair enough that people can learn.

Sound has to communicate something.

The graphics have to remain readable under pressure.

Those are human-factors tests as much as software tests.

The research started with Sinistar, but it did not stop there

The historical starting point was Williams' Sinistar.

Not because I want to remake Sinistar.

I do not.

What fascinated me was how much that game managed to do on extremely small hardware.

The world did not simply wait for the player.

Workers collected resources.

Other enemies hunted you.

The larger threat was being assembled while you were busy elsewhere.

The player was constantly deciding between the problem directly in front of the ship and the bigger problem developing somewhere else.

And under all of that, the programmers built a tiny multitasking-style executive to coordinate the game's independent behaviors.

That is the part I care about.

They were not building a miniature operating system because that sounded clever.

They were solving a game-design problem: how do you make many things appear alive at once when the machine cannot afford heavyweight machinery for every object?

That is a remarkably relevant question for Ceylon.

Looking beyond one game

One of today's research goals was deliberately broadening the survey so the new game does not become "Sinistar with different artwork."

I have been looking at preserved source and development material from a number of early games and asking what each one did unusually well.

Defender made a world larger than the viewport and compressed that world into a useful radar display.

Robotron produced overwhelming actor density while keeping the player's controls extremely crisp.

Joust got enormous depth from a tiny control vocabulary and a good movement model.

Tempest treated demo and self-test behavior as part of the machine rather than as an afterthought.

Missile Command used hard object limits and irreversible world damage to turn constrained resources into game rules.

Centipede let enemies modify the environment instead of merely moving through it.

Battlezone created convincing spatial scale from minimal geometry and instrumentation.

Elite generated an enormous perceived universe from compact deterministic data.

The point of this research is not to copy old routines.

It is to identify ideas that survived their original hardware.

What made a game readable?

What made it feel larger than memory?

What let many autonomous actors appear active?

Which limitations produced elegant design?

Which limitations should be discarded because modern hardware no longer requires them?

That is the research question.

Old source code is a textbook, not a parts bin

I have said this before about the Amiga and Video Toaster work, and the same rule applies here.

Historical source is useful because it exposes decisions.

It shows what people were trying to accomplish when memory, CPU time and storage were painfully finite.

But source being visible does not mean we should translate it into Ceylon.

The new game needs original code, original art, original audio, original fiction and its own behavior.

The historical material belongs on the research side.

The implementation side should receive independent requirements and design lessons.

That gives us something more valuable than a clone.

It forces us to answer the same kinds of engineering questions ourselves.

The game is starting to take shape

The current idea is a large-feeling field where the player and autonomous machines compete for the same resource.

The machines are not simply enemies waiting to be shot.

They are trying to accomplish something.

They collect.

They transport.

They build.

Other actors defend that process.

If the player ignores it long enough, the world changes.

That gives us a natural game loop:

explore;
collect;
intercept;
prepare;
disrupt;
survive;
and eventually deal with the thing the autonomous system has been building.

The large threat should not be a recognizable copy of Sinistar.

I am much more interested in something geometric, mechanical or energetic—a system event rather than a giant face with a health bar.

Why this structure is useful to Ceylon

The nice thing about that design is that the gameplay itself generates a useful operating-system workload.

Autonomous actors need scheduling.

Resources need state.

Projectiles and effects need bounded pools.

The player needs responsive keyboard, mouse and gamepad input.

The scanner needs a second view of the same world state.

Audio can warn about activity that is not currently visible.

Storage can preserve settings, scores and replays.

Structured logging can record faults and unusual conditions.

A developer overlay can expose real frame times, pool usage, task counts and audio problems.

None of that has to be bolted on merely to make a benchmark.

The game naturally needs it.

A hidden player that never gets tired

One of the stranger ideas may also become one of the most useful.

The game should have a hidden CPU-controlled player that uses the same logical controls a human uses.

No cheating.

No directly changing the world.

The bot generates movement and action commands exactly like a keyboard, mouse or joystick adapter would.

That means Ceylon could run the game by itself for hours.

It can win.

It can lose.

It can recover.

It can create crowded situations.

It can stress object pools.

It can exercise audio, rendering, storage and telemetry repeatedly.

Then it can stop cleanly and leave behind a report.

That turns the game into a soak-test harness without turning the public experience into a benchmark utility.

A visible version could even double as an old-fashioned arcade attract mode.

Replay as a flight recorder

The same design points toward deterministic replay.

If the world starts from a known seed and consumes a known input stream, then many failures can be reproduced rather than described vaguely.

A useful replay can contain:

world seed;
input changes;
important events;
periodic state hashes;
performance checkpoints.

If a bug only appears after 43 minutes under a particular load pattern, the goal is to replay the conditions that created it.

For an operating-system alpha, that is extremely valuable.

CPU first, on purpose

The first game does not need a GPU.

That is deliberate.

A1 should be able to demonstrate itself with software rendering through Ceylon's native display path.

Later systems can add acceleration.

But the first application should prove that the underlying machine is useful before future graphics hardware becomes a requirement.

This also creates a stable reference path.

If a later accelerated renderer behaves differently, we have a known software implementation to compare it against.

The research is also changing how I think about development tools

Another idea emerged from the game research today.

If we eventually build more than one kind of game for Ceylon, we should probably not build one giant universal game engine.

A scrolling arcade game, a sector-based first-person game, a polygonal 3D game and a flight simulator need very different world models.

What they do share are things like:

graphics access;
input;
audio;
timing;
storage;
logging;
asset handling;
packaging;
telemetry.

That suggests a reusable framework underneath multiple engines.

The first game does not need to wait for that framework.

In fact, it is probably better if it does not.

We can build the game first, discover which pieces are genuinely reusable, and then extract those pieces after they have survived real use.

That is safer than designing a giant abstraction around games we have not written yet.

Assets may become their own platform

The same logic applies to game assets.

Not every asset belongs in every engine.

A 3D character model may become a full animated model in one engine and a prerendered sprite set in another.

A sound effect may work everywhere.

A collision mesh may only matter to certain engines.

So the longer-term idea is an asset store that preserves a canonical source, tracks where it came from and how it is licensed, then lets engine-specific processors generate only the runtime representation a game actually needs.

That could eventually let first-party and independent engines share one asset ecosystem without requiring them to share one runtime architecture.

It is a larger idea than today's game, but today's game gives us somewhere concrete to start.

Why this may matter to outside developers

Ceylon is eventually going to need software that I did not write.

If an independent developer already has an engine, I do not want the platform to say:

Throw it away and use ours.

I want Ceylon to say:

Bring your engine.

Use our engine.

Use part of our framework.

Use our asset system.

Or just use the native APIs and build your own tools.

Keep ownership of your work.

The platform should make development easier without demanding control of the developer's engine.

That is a much better way to earn serious developer interest.

Certification and compatibility logos may make sense someday.

That is later.

First we need to make the machine worth developing for.

Where this leaves A1

The immediate target remains practical.

Build a standalone native game.

Keep the architecture clean enough that reusable pieces can be extracted later.

Use the game to pressure-test the APIs.

Add deterministic replay and zero-player testing.

Make it fun.

Make it measurable.

Make it shut down cleanly.

And learn everything we can about what building a real native Ceylon application actually requires.

If the game succeeds, the most important result may not be the game itself.

It may be everything Ceylon learns while building it.

— Mike