RAM/visual limitations are quite easy to make in my opinion. 8-bit computers like ZX Spectrum had RAM bound to screen, settings, code etc. Implementation could be simulated by byte array. Console code puts data there, host code interprets it. You can have part of code which reads specific range of array data as pixels and display it on screen (GPU), the other range is sound (Sound chip), the other sprites, palette, etc. ROM can be set of sprites, letters, maybe some global parameters like palette. I think the hardest restriction is console language and sandboxing
I'm new here but in the middle of making my console. Generally speaking you have to choose your host system, i.e. language, libraries for graphics, audio, etc. And you have to decide what is your console language/interpreter/simulator you want to give for creators. All interacions with PC (like drawing on canvas, playing sound, read input, write to output) you have to code on your host. Host should be able to evaluate console code and gather results/interactions. Eg. calling `spr(...)` in your console should call host function you write. The same for executing init, draw loop, etc.
Examples:
C/C++ as host with Lua as console lang is great combo, because Lua is designed to interoperate with C and has it's own VM to separate from host (pico8, tic80, neko8).
Lua with Love as host + Lua for console is great as well (liko12).
C with processor simulator + ASM (zenith80).
My choice is Clojure as host + MAL subset (make-a-lisp) as console.
For JVM (Java) you can probably choose groovy, python, ruby as console language.
The most important thing is sandboxing console language, ie separate from host functions. You don't want to allow anyone to access PC directly.
Thx! Yes, controlling is hard and annoying :) Terrain has big influence on forces. You have gravity here. Rocks are higher than water, water and mud have bigger friction, collisions are elastic.
