-
Notifications
You must be signed in to change notification settings - Fork 13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
In-game extensibility at runtime using JavaScript and/or TypeScript #24
Comments
For extensibility in the native platform (not web), perhaps embed a (small) JavaScript engine, either: ala Lua in fogleman/Craft#146 - but on the web, instead use the browser's JavaScript. Emscripten supports calling compiled C functions from JavaScript using |
JavaScript calling C shouldn't be too difficult (I tried `Module.ccall('on_right_click') in the console, no such luck, maybe needs to be exported), and to wrap it, but what could be really nice is wrapping the API for TypeScript, in order to allow a candy from JSweet the Java-to-JavaScript/TypeScript transpiler, to consume this API. To ease porting Java code, perhaps along with satoshinm/WebSandboxMC#51. |
Looking into how the Minecraft modding community has dealt with extensibility, some observations: Minetweaker (http://minetweaker3.powerofbytes.com): a mod allowing writing scripts (in a custom language ZenScript, compile to bytecode) letting the server make various tweaks: modify or add or remove recipes, including support for modded machine recipes, or renaming items, and so on, beyond what the mod configurations allow themselves. Minetweaker is extensively used by modpackers to better integrate mods with each other or balance the game, make it harder or easier as desired, or remove duplicate content or add or tweak other ways to get it. Very handy. I am using it myself here: https://github.com/satoshinm/modpack/tree/master/scripts Coremodding: Now here is where it gets interesting, most mods only add "content": new items, blocks, recipes, etc. But this is not nearly all that is possible with modding. "Core mods" can make literally any change to the game, even if there is no exported interface. How it accomplishes this is clever (and technically novel?): the game as it loads can be passed through ASM, allowing coremods to disassemble, looking for specific landmarks and patch the bytecode arbitrarily. As this is unlimited in power, it is understandably controversial, recent policy changes: https://forum.feed-the-beast.com/threads/1-12-mod-policy-change.243990/ - but surprisingly many mods rely on it, like Inventory Tweaks: https://github.com/Inventory-Tweaks/inventory-tweaks Allowing customizing recipes etc. is definitely a must, consider making it reasonably data-driven to make this easier to change. Coremodding, will have to think about it more, in theory, runtime patching of WebAssembly is possible. Is it a good idea, especially for an open source project? The modder could recompile the open source game from source and redistribute it, after all. But this kind of patching scheme may have some advantages, too: other parts of the game, or other mods, can change or make changes and the "coremod" would still work, as long as it didn't change the same piece of code or code that depends on it. Nifty. |
Allow game content to be added at runtime.
If by the user, then JavaScript is a natural choice for the web, but then how would it be available in the native version? (embed JS interpreter?) JavaScript API to add new blocks, items?
The text was updated successfully, but these errors were encountered: