We haven’t removed parsing of text scripts from the runtime yet and we could always allow an add-on library that adds the capability if you really need it. We don’t want to take away capabilities though we do want to help out.
All of our reasoning for this is to try to ensure the best possible development experience, awesome products and a great mechanism for updates and add-ons.
I’ve been on projects where text scripts were loaded, parsed and then executed at runtime and they had a number of issues, recurring headaches and runtime implementation problems. However, there are superior alternatives that are simple and awesome.
First the issues. They may all sound manageable, though every one of these listed here happened again and again and caused either hours, days or weeks of problems. They were also some of the most common sources of bugs after a game shipped.
compile errors happen at a different time than other scripts. Whenever you run the SkookumIDE it should know about all the scripts. That way if some routine changes and some script used that routine you’ll know about it right away and can either update the script or revert the changes to that routine.
runtime non-deterministic parsing. Either the text scripts will be parsed depending on game progression which can make it easy to miss errors if some logic paths are not tested or you must load them all at the start which loses the benefit of delayed loading of the scripts.
extra mantainence complexity due to different location. Usually the text scripts are stored in some location different from the standard scripts and there will always be various tools and operations that expect to globally operate on all the scripts such as search and replace which can easily miss the text scripts.
can’t use SkookumIDE editing tools. The SkookumIDE editor is still new and evolving, though you won’t get language aware syntax highlighting, auto-complete, auto-parsing (little red underlines with mouse hover of error/warning), jump to definition, plus a bunch of other features and all the other cool stuff we have planned for the future.
can’t use SkookumIDE workbench/REPL. The SkookumIDE won’t know about your code added via text scripts on the runtime and so the workbenches may think that script snippets that reference them have parse errors.
can’t use SkookumIDE to change the scripts while running game live. You can roll your own mechanism to reload script files though it can be a very complex problem - especially with scripts that are in-use in the runtime. You could just lean on the SkookumIDE which already works great for hot-reloading and will constantly get more sophisticated in this area.
can’t use SkookumIDE debugging. If the SkookumIDE doesn’t know about some script text’s location then you can’t set breakpoints on it or do step-wise debugging through it.
runtime memory bloat. The parsing system requires quite a bit of memory. If it isn’t used during runtime then all that memory can be freed up for other needs. This is especially important on mobile games or big projects.
runtime code complexity and size. The SkookumScript parser is fairly complex and pulls in a lot of other systems and code. Another huge hurdle is that the runtime must work on every target platform whereas the SkookumIDE only needs to work on a Windows desktop (and Mac and Linux in the future) so requiring the parser to work on all platforms is an extra challenge. Likewise, the parser should not be needed in a shipped game. Such a streamlined runtime and shipped build would be much easier to maintain, optimize and debug.
runtime optimization. The runtime and the parser are at odds with each other since we want the runtime to be simple and fast whereas we want the parser to be sophisticated and do as much work as possible for us mere humans with our puny brains.
Before I can best get into the alternate methodologies, the most important question is always:
I can think of a number of possibilities though best to ask rather than guess.
Here are two solutions which you can do right now.
Basically, just write SkookumScript code as usual.
Closures are portable objects that you can call at will and have lots of flexibility. They are also supported by the SkookumIDE. The only downside is that their script’s compiled data-structures are always in memory just like normal code - though they are tiny in the grand scheme of things and it shouldn’t matter with most projects.
Demand loaded classes are a great solution for large games such as open world games and it has already been battle tested though it costs extra.
Option 5 would be the best of all worlds. You would probably add an annotation such as
&embedded to a routine so that the SkookumIDE would know to save it out as its own little tiny binary or some sort of embedded binary archive. We would also make a bunch of API calls to be able to easily interact with it with custom tools. Main issue with this solution is we haven’t written it yet since no one has presented us with a prioritized use case for it yet.
Happy to discuss this further to figure out the best solution.