Is there an eval?

Is there something like eval in skookumscript? If there is what all can we do with it and could you give me a code example of it in use?

btw, I bought the pro version, very nice skookum team =)

1 Like

Do you mean can you evaluate an arbitrary hunk of text as a snippet of SkookumScript code and then execute it?

From within SkookumScript code itself or through the C++ API?

What are you trying to do?

Thanks for buying the Pro version of the SkookumIDE!


Preferably Skookum.

You really do not want to know :slight_smile:

You are welcome, thanks for making an awesome language!

I always want to know. I can give the best answer that way. :madsci:

Here is a related answer for someone asking to do something similar through C++.

1 and 5 are the interesting ones to me.

I am trying to create a macro like facility ala lisp… just having some fun while I am waiting on a new microphone :slight_smile:

Edit: I guess I don’t understand the purpose of stripping out the text parser.

One of the things we were planning to do is load text files and run their scripts during game play.
Perhaps I misunderstand.

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 :sk: 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. :grin:

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. :madsci:

You mention that it costs extra, extra in addition to the pro license?

Yes, demand script loading costs an extra $5,000 USD for a project.

It should only be needed for big projects like open world games or massively multiplayer games where there is so much script code that the whole game cannot fit in memory at once.

If an indie team feels that they need it and cannot afford the price, they can always let us know and we can negotiate a price that fits their project’s budget.

I have a number of questions that really belong in a separate thread.
I noticed there was a thread here:
that was relevant so I just posted there.

1 Like

This is a really good post and a very interesting discussion.
Coincidentally I have been looking at SkParser recently and saw this discussion and have some thoughts.
Especially the last 3 bullet points are very convincing and make a good case to separate the parser.
Resources are scarce.

I think a division here is between those who are shipping highly optimized and streamlined products
and those who are experimenting with ideas and see it as a (very powerful) neat feature.

I hope it will stay available in one form or another.

Some potential use cases I could think of:

  • a game where you have to program/hack some terminal inside the game using Sk
  • very advanced console functionality inside a game
  • an rts/building game with user programmable macros/nodes based on Sk
  • user scripting in general (adding mods)
  • adding new functionality to a live (maybe server side) app

Just some thoughts, I’m not building any of it (right now).


If in-game user scripting that needs a game specific UI is desired (as with your first 2 suggestions) then you may need the SkookumScript parser API. It might be possible to externally call the SkookumCompiler or SkookumIDE to build a little binary and still keep it out of the main game. We’ll always ensure that you can get what you need.

If it is end-user or remote modding (such as your last 3 suggestions) then I would 100% lean towards using the SkookumIDE. This would give the best user experience and take advantage of the power and evolution of the SkookumIDE. It would depend on a few different factors though even in its current form this would be possible with the SkookumIDE. The SkookumIDE Standard is free and probably has everything that an end-user will need. We plan to tailor the SkookumIDE for more modding features including being able to skin it to the theme of your product, sandboxing so you can ensure that end-users can only mod a subset of all the game features and even making it so that you can extend and modify the SkookumIDE using SkookumScript code.

I’ll expand on end-user modding in this thread: