Roadmap

This page describes where the Cade Runtime is headed after v0.2.0 “Whiffle”. It covers what the next releases focus on, in what order, and why. It is a statement of direction, not a schedule or a promise. Cade is pre-1.0, so priorities can move when table authors run into something that matters more. For what has already shipped, see the Release Notes.

At a glance

Guiding principle: one table, every host

Cade runs a table in more than one place. cade run drives a real machine, the console is the hands-on development tool, and showcade runs the same engine in your browser. Today these hosts do not all support the same things. Some features work only in the browser, and a few work everywhere except the browser.

That is going to change. The same .cade table, given the same inputs, should behave the same in every host. A feature that works in one host and not another counts as a bug in the host that is behind, and gets fixed rather than documented as a limitation. The hosts may still receive input differently (a cabinet reads switches, the browser simulates them), but what your table does with that input should not depend on where it runs.

0.2 patches and 0.3: finish what 0.2 started

v0.2.0 turned a long tail of silently ignored configuration into errors and warnings. The next releases finish that job for the cases that still load cleanly and do nothing. In the 0.2 release notes, most of these are listed as known issues:

• Computed variables. A variable with a formula will be evaluated while the game runs.
• Mode actions. award_points, play_show, stop_show and trigger inside a mode’s actions {} will work on every host, including the browser.
• Interaction contexts. Mapped edges, release edges, held_for(...) holds and context displays will take effect under cade run and the console, not only in the browser. device_control written on a context will actually inhibit devices.
• Event aggregation. Aggregation will run in the browser, and on_trigger / on_tier_change will fire their emits.
• Scoring reads. Scoring expressions will read event.* fields, so an aggregation’s event.count can scale points. Reading an undeclared var.x becomes a load error instead of silently scoring 0.
• cade validate. It will check that a device named by an action (pulse_coil, eject_ball, set_autofire and similar) exists. It will stop flagging lights declared in a different source file of the same table.
• signal.<name> in expressions. Every expression surface currently rejects these reads, because nothing supplies the value at runtime. 0.3 decides whether signals become readable everywhere or remain events only.

0.4: one table, every host

0.4 is where the guiding principle above becomes true across the board:

• Displays under cade run and the console. Display shows, display_show and display_image actions, and display-show triggers currently render only in the browser. They will drive the display wherever the table runs.
• Repeatable audio. Clip selection will honor its seed in every host, so a recorded game picks the same sounds when replayed.
• Coil sounds. Device audio routed to a coil firing will play on a real machine, not only in the browser.
• Repeatable replays. Timed events will happen in the same order on a native host as they do in the browser, so a replay reproduces the original game.
• Consistent variable-change events. variable.<name>.changed will carry the same data in every host, so handlers that read it behave the same everywhere.

After 0.4: hardware

These items matter most once a table moves onto a real cabinet:

• Physical displays. DMD and LCD content will reach real display hardware through a platform driver. Segment and alphanumeric displays will become targetable; today they can be declared but nothing renders to them.
• Matrix lights bound to real hardware outputs.
• Fault reporting. Platform drivers will report hardware faults (a stuck switch, a coil fault, a lost board). The game will degrade gracefully instead of failing silently.
• Device command coverage. Every device command a table can issue will reach the hardware over the Visual Pinball bridge, including servo moves, device state changes and machine sound.
• Credits that survive a power cycle, plus coin denominations and coin input under cade run.
• Lighting performance validated on FAST hardware, and, further out, optional offloading of light shows to a small microcontroller.

Language and editor additions

These are planned additions to .cade and to showcade’s editors. Their timing depends on demand from table authors:

• module.<name>.time_active: how long a module has been running, readable in expressions.
• for_each and count outside assemblies, so ordinary blocks can be generated from a list.
• Authored audio ducking, letting you control how much one sound lowers another. Today ducking is automatic.
• Scores that cap instead of overflowing at the limits of their type.
• Two-dimensional lighting transforms. Vertical scroll, vertical scale, vertical warp and rotation are accepted today but have no effect.
• Event cooldowns, a first-class way to ignore repeated hits for a period.
• Options that are accepted but not active yet. The flow types timed and state_machine load but do not drive anything yet. Named noise_context blocks are declared and validated, but expressions cannot select one yet. Each will be either implemented or removed, so that nothing you can write is silently ignored.
• Auditioning mix graphs and clip selections in showcade’s sound editor. Today only a synth patch can be auditioned. A selection audition will use a fixed seed, so you hear the pick the machine would make.

Not planned right now

• A separate 3D renderer (for example Godot) receiving scene data from Cade instead of finished pixels. This is deferred until there is a real integration to design against.
• Automatic migration of older table files. Cade is pre-1.0, so breaking changes come with upgrade notes in the release notes instead of a migration tool.

Have a say

The order above follows what table authors run into. If something here matters to your table, or something that matters is missing, raise it on the project’s issue tracker. Real tables move items up this list.