Skip to content
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

Support a script language #74

Open
rodrigocam opened this issue Feb 18, 2020 · 8 comments
Open

Support a script language #74

rodrigocam opened this issue Feb 18, 2020 · 8 comments
Labels
enhancement New feature or request

Comments

@rodrigocam
Copy link

A scripting system allows game customization without recompile rust code, improving speed on the game testing.

It would be good if:

  • A script runner that runs another language (Lua, Python, etc)
  • Scripts can create ECS systems and use the ECS capabilities
  • Scripts can create arbitrary data structures
  • Close to no speed overhead
@rodrigocam
Copy link
Author

I and @pablodiegoss are working in a scripting system that can be customized to accept multiple languages for Amethyst Game Engine as our undergraduate thesis. Maybe the solution we are developing can be used here, we definitely can try to implement this!

@rodrigocam
Copy link
Author

Our first POC can be found here we managed to run lua and python scripts. We started to work on an Amethyst fork too, that already has a specs system that runs lua and python scripts, can be found here

@thebracket
Copy link
Collaborator

That's definitely an interesting idea. I think I need to consider the best approach; offering it as an option at the bracket-lib level makes it available to projects that use it, which is great - but I also need to avoid constraining the choices made available to the user too rigidly (I have users going with Specs, Legion, and various other setups - don't want to make them miserable!).

@thebracket thebracket added the enhancement New feature or request label Feb 24, 2020
@erlend-sh
Copy link
Member

but I also need to avoid constraining the choices made available to the user too rigidly (I have users going with Specs, Legion, and various other setups - don't want to make them miserable!).

Sure, but it also doesn't seem unreasonable to just concede that scripting utilities (which is just an added bonus after all, not critical to use bracket-lib) will only work with a certain type of setup. As long as scripting is guaranteed to work with the default setup that 50-80% of users will want, it'll serve the majority of bracket devs well.

@thebracket
Copy link
Collaborator

Absolutely! The question in my mind is more "where does it go in the stack". It needs to retain some platform abstraction, or be tied to a back-end; the former is much nicer to work with, but much harder to write scripts for. In an ideal world, some kind of hook to the actual back-end would be really nice to have (I'm working on a generalized, non-scripted form of that right now).

@Zireael07
Copy link

I just found someone's toy language: https://github.com/JohnBSmith/moss
Not 100% sure if it works in WASM target, but I like the simple syntax.

@oubiwann
Copy link

Being a Lisper, I am (of course) quite partial to https://github.com/murarth/ketos (written in Rust; installable with cargo ;-) ).

@Zireael07
Copy link

Since I last wrote, we have two candidates that apparently work in WASM too: https://gamelisp.rs/ and Rhai https://github.com/jonathandturner/rhai

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

5 participants