Given a competitive multiplayer simulator game where you can program your own flight computer, what programming model would you like it to support?

- in-game programming with a DSL which can have artificial resource limits to regulate the extent of automation and can maintain the atmosphere of the game in the process of programming

- in-process Webassembly executor which makes artificial resource limits feasible to the extent that people can't just throw image recognition and AI at every problem, but it loses the atmosphere

- API-based unrestricted remote control

The idea is that there are basic programs that get the job done but do so in the simplest way possible which is pretty bad. You can progress by getting really good at using these despite their flaws, or by fixing them, or both.

I'd take radar and a PID controller over fancy AI, at least for a game, any day.

Web assembly

If you need some inspiration from an mmo, take a look at how Screeps does it.

@Lensflare My problem with Screeps when I looked at it a while back was exactly that there's no information locality because it used an API.

Maybe it changed its execution model?

I just learned that wasmer has metering, my mind is set on Webassembly now

@lorentz In screeps you send your JS code to a server which then executes it. They have also added web assembly support some time ago which I haven‘t tried. But it seems like the same model. Just wasm instead of JS.
I used Kotlin which transpiled to JS back then.

Reminds me of a game in development I saw years ago. It was a space pilot cockpit simulator. You had a bunch of steps you had to go through RTFM style, to for example, start up the engines, including injecting plasma into the reactor, warming the plasma, igniting it, etc. It was pretty cool.

I'd say if its about control, its really about procedure.

And if its about procedure its very much an element of puzzle based design.

Do you want long chains of linear steps with few decisions, or do you want short chains with many decisions based on the environment?

Short chains of input support having lots of buttons or api calls or commands, and therefore are better oriented for fast action, while long chains are better suited to either automation or turn based/semi turned based play.

Unrestricted access is nice, but puts a difficulty cliff in front of the game for sure. Try to find a middle ground. Look at Schenzen.io for example.

Good luck.

@Wisecrack The game you are talking about is Rogue System and it's my main inspiration. I tried writing a game like this 3 times in the past. It's a tall order to be sure, but given that I seem to get really passionate about it every two years I'm bound to eventually succeed.