Luy: Rou: you want to write your own programming language? Why not use JS for that too?
Mikos: Won’t that allow too much control over what you can do?
Ozaki: Rou: you mean sth like LUA?
Miyose: Rou: is that a bad thing?
Bankes: Rou: because you really just want to provide a good API for people to write their games with your engine
Fritzpatrick: Rou: well, let’s talk about specifics: what do you want to allow, what do you want to prevent?
Mikos: Dash: Gameplay within the bounds of their own peer to peer server.
Hooe: So the players use code to play the game?
Fritzpatrick: Rou: i don’t understand how that answers either question
Lynde: Rou: can you be more specific?
Mikos: Allowing conditionals, events, ect. for UI/Sprite loading/Animations/Physics/ect. Which syncs across all clients on a specified server.
Mikos: And only specific users on said server would have access to the embedded scripting language
Nicolls: Rou: so, players in the game can write code in this language and interact with the game resources?
Henshaw: So you play the game by coding Rou? like ‘player.moveright, 2;/
Krystal: You can do this with a good js game api
Lipani: Rou: right. In that case sandboxing JS would be hard. The simplest thing would be to write an interpreter for a Lisp-like language, and give it only the features that it absolutely needs to have.
Fritzpatrick: Neonakis: mmm, why would sandboxing js be hard
Hufford: Dash: from what I understood, the code would run in the game server, which means making sure arbitrary JS code has only access to the things you want to is going to be a pain.
Steeby: Sure you can use something like the VM module, but you still risk people being able to leave the sandbox
Anderberg: And an isolated process would be expensive/require serialisation/etc
Bazata: Or crash the game using infinite loops etc
Mikos: That’s why I’m asking if something like this has already been written that I can look at
Fritzpatrick: Oh, well if it runs on the server then yes, different story
Mikos: Like this for Haxe: https://github.com/HaxeFoundation/hscript
Redding: Rou: writing an interpreter for a Lisp dialect is probably going to be much easier than trying to adapt some other general-purpose language for your particular case here.
Fritzpatrick: In fact if it’s running on the server, it doesn’t need to be js at all
Waycaster: You can write your own interpreter. like in the early larry games
Mikos: Well I’m using Node.JS and socket.io
Abston: You can do the simplest thing that could possibly work, and write a simple p****r with a tree-walking interpreter. Just make sure you kill things that don’t have a fixpoint for recursion/loops
Klien: You should be able to do that for a Lisp interpreter in less than 100 lines of code, really
Dursch: Just use some verbs and objects. no loops at all
Schaarschmidt: Like the old text-adventures
Heberling: Text adventures have some pretty sophisticated NLP these days
Mincer: Like, understanding “under the bed, open the big red box with the golden key”
Mikos: Well not having loops would really limit things
Mikos: I’m fairly sure most sandbox games allow loops, it’s just your server will be laggy / framedropey as **** if your scripts are bad.
Hornoff: I imagine: “under the bed” to be difficult
Merlo: Also i can imagine sophistication can reach a high degree here
Mikos: At the very least you’d need an update function which is called every frame
Mikos: And throw whatever you need conditionally under that
Westveer: But that’s not what players do rou. that’s what the gameengine will be responsible for.or not?