01
[futurisca]
The whole application, filling the width of the window whatever theme you run.
Developers
Putting it on your own site
Two WordPress plugins. The simulator runs entirely in the visitor’s browser, so the server does almost nothing and the thing scales like a static page.
The shortcode
02
[futurisca view="3d"]
Open on the globe, the flat map, or the network. The default is the globe.
03
[futurisca country="JPN"]
Open with a country already selected and centred.
04
[futurisca layer="instability"]
Open coloured by any of the hundred and eighty nine readings.
05
[futurisca height="900"]
Fix the height instead of filling the window.
06
[futurisca full="0"]
Stay inside the theme column rather than breaking out of it.
The routes
01
GET /futu/v1/world
The whole baseline state: every country, the trade ties, the levers, the parameter priors and the historical analogues. This is the only thing the app needs to start, and on a normal install it is printed into the page rather than fetched.
02
GET /futu/v1/feeds
Everything live, in one payload, already fetched and cached by the server.
03
GET /futu/v1/geo/{kind}
The heavy geometry: regions, districts, cities, towns, infra. Served as data when the static file cannot be.
04
GET and POST /futu/v1/scenarios
Saved scenarios, if saving is enabled for the visitor.
05
POST /futu/v1/brief
A written briefing from a run, through whichever model provider the site has configured.
06
Everything again over admin-ajax
The same routes, the same permissions, the same callbacks, for installs where /wp-json is closed. A test asserts the two lists cannot drift apart.
The engine is a file
engine.js has no dependencies and no imports. It takes a compiled world and a scenario, and returns an ensemble. The app runs it in a worker thread; you can run it in node, in a test, or on a server. Nothing about it assumes a browser except the worker wrapper around it.
Runs are reproducible: same seed, same world, same scenario, same result, on any machine.
What there is not
No hosted API
There is no service to call. You install the plugin and it is yours, running on your server for your visitors.
No account system of its own
It uses WordPress users. Who may run it, who may save and who may spend the model provider budget are three separate settings.
No telemetry
Nothing about a run leaves the browser it ran in unless the visitor saves it, and then only to your own database.
How the plugin is put together
Two plugins, one of which is optional
The simulator is a shortcode and a REST namespace; the site plugin is the public pages around it. Either works alone. Installing only the simulator gives you an instrument to drop on a page of your own; installing only the site plugin gives you the pages with the app page saying the simulator is not present.
No build step, anywhere
Plain JavaScript in the browser, plain PHP on the server, one stylesheet each. There is nothing to compile, nothing to transpile and no package manifest. You can read what runs, because what runs is what is in the folder.
The world is printed into the page
The one thing the simulator cannot start without is the state of every country, and asking for it over HTTP is the one step something outside the plugin can break: unbuilt permalink rules, a security plugin closing the REST API, a caching layer, a firewall. So it is printed into the page as JSON, and the app is already holding it by the time the page finishes loading.
Everything else has a second road
Saved scenarios, live feeds and the geometry packs all try the REST namespace first and fall back to admin-ajax.php, which is a real file and therefore always answers. The admin screen shows which road each one took, so a broken install diagnoses itself.
The engine runs in a worker
Two hundred and fifty futures across two hundred and thirty eight countries is several seconds of arithmetic, and it happens off the main thread so the map stays interactive while it runs. If workers are unavailable it falls back to the main thread and simply takes longer.
Running it somewhere else
Can the engine run on a server
Yes. engine.js is one file with no imports and no browser assumptions. Require it in node, hand it a compiled world and a scenario object, and it returns the same ensemble the browser would. The test suite in the repository does exactly that, which is how it is checked.
Can I use my own world data
Yes. The compiled world is an ordinary object: a list of country records and a bilateral network. Replace the records, keep the shape, and everything downstream works. The provenance marks are part of the record rather than part of the engine, so your data keeps whatever marking you give it.
Can I add a lever
Yes, and it is the change most likely to be worth making. A lever is a definition in the catalogue plus a channel in the engine. The catalogue entry gives it a name, a unit, a range and a cost; the channel decides what it actually does. A lever without a channel is a slider that does nothing, and the instrument refuses to ship one.
What does the plugin write to the database
Its settings, the cached feed state, and saved scenarios if anyone saves any. Nothing else. Uninstalling removes them, and the world data lives in files rather than in tables, so it leaves nothing behind.
Does it need outbound network access
No. Every live feed degrades to absent, and the simulator is unaffected, because the world state is in the page and the engine is in the browser. Shared hosting that blocks outbound requests costs you the live layer and nothing else.