You've been selected for a chance to get one year of subscription to use Wikipedia for free!
This is the first in a series of Arsenal Development posts that we will be making to keep the community updated on our development progress. We put a high value on keeping our community notified of what we are doing and why, so that you don't have to question where the project is at or what we are working on. If you have any questions, don't hesitate to contact us on this site or open a GitHub issue.
After getting our first release for Arsenal out, we haven't stopped working towards getting it ready to make real games. Currently Arsenal can export the plain meshes from Blender scenes and run them in a game with an orbit camera. This was a great proof-of-concept that showed that our basic idea was going to work. The next thing we are working on is scripting support so that we can add game logic to the scene.
For Arsenal, we want you to be able to write your game logic in Python, Lua, Rust, or Blender logic nodes, but you will not be limited to those languages. The design that we have for enabling scripting will allow you to use pretty much any language you want, as long as somebody has made a language driver for it. We at Katharostech are going to put effort into making sure that there are language drivers for at least the above languages. The motivation for using each language is different:
Currently most of the discussion around scripting is happening in the Scripting Category of the Amethyst Forums. There is also a tracking issue for the topic on GitHub. As always, we will show what we are currently working on in the Arsenal Workboard.
For the people who want to know more of the technical details of what we are doing: I am currently collaborating with Amethyst team on how to create a C API for Specs, to allow you to create components, states, and systems without re-compiling the Arsenal runtime.
The C API will allow us to dynamically link language drivers, likely written in Rust, that will handle connecting other languages to the game. A more detailed description of the approach we are going for can be found in the amethyst scripting RFC.
Once we have language drivers for Lua, Rust, and Python, we also want to add a logic node system to Blender that will compile logic trees to another language, most-likely Lua. The tracking issue for visual scripting is here.
In addition to having a C API from which to script games, we will also want to have a WebAssembly API that can be used to create mods. The WebAssembly API will allow you to build mods that run on all platforms without having to be compiled for a specific operating system. Also WebAssembly can be sandboxed to prevent mods from being able to run malicious code on the user's system.
The difference between writing a mod and writing a script will hopefully be minimal to the game developer. They should have a similar API so that you don't have to learn a whole new way to write code when you go from writing a mod to writing a game or vice versa. Because of the sandboxing and safety measures, mods will execute slower than they would if they were integrated through the C API, but that should be perfectly acceptable for most mods. WebAssembly discussion is happening here.
The extra safety and cross-platform abilities that WebAssembly grants will also open up the potential in the future to create an online "mod store" that could be used to allow users to share mods online and install them right inside of the game. It's a very exciting possibility.