[HELP] General Skookum+Blueprint workflow guideline?


a coworker recently pointed me to Skookum and i while i was peeking through the docs the “oh” moment came at this:

concurrent-block = sync | race | branch | divert

While this concept of “latent” execution can also be handled by other languages, c# + Unity CoRoutines comes to mind, i never have seen it work “nicely” and in a easy to understand way.

So now i try to understand the workflow to use Skookum and UE4 blueprints. The videos so far where not this helpfully, since the ai bot showcase don’t represent your normal Ai in UE4 and i could not find a guide how Skookum and blueprints should be utilized in practice?

The normal UE4 showcase would be a blueprint, with a bunch of components that are wired together via event nodes. Ideally the components are reusable and there logic might not depend on the top level BP logic. So that you can easily slap components together to quickly form a new object, thats also similar to how Unity works.
So we mainly let all our components send event to the “owner” and the top level BP handles the object specific logic, utilizing the component events.

The main “headache” in BP comes from very complex if/else and loop + array operations. More subtle is also the growing “visual” complexity you have to handle, depending on how big your top level BP logic becomes.

Here are my main questions atm:

  1. How does Skookum fit into BP event handling? Do i just do the heavy lifting in script and still wire the logic together in BP or can Skookum handle BP/Component events as well in a elegant manner?

  2. Can Skookum handle the BP ctors or do i always need a working BP skeleton and let the script handle the more complicated parts?

  3. Can Skookum handle EventDispatchers?

  4. Is there a easy, fast way to create custom BP nodes in Skookum?

Are there any workflow examples? Would be nice to see how skookum would handle the security camera and door examples, where multiple components communicate via events/interfaces/dispatchers.

As you can see i’m mainly concerned how the workflow/communication between blueprints, components and level is handled via Skookum or if its better to keep the event skeleton in BP nodes and just use Skookum for the internal logic? So just replacing the “web” of nodes that actually do “stuff”, with a script.


1 Like

Hi Andy - sorry it is a busy day over here! Thanks for checking out SkookumScript and for the great questions - I will get back to you with answers very shortly.

Currently, Blueprint custom events, interfaces or Event dispatch/message nodes are not natively supported in SkookumScript. The components of the workflow are at the moment:

  • You can create custom Blueprint function calls by prefixing a SkookumScript method with the &blueprint annotation before the parameter list which will automatically make it available for placement in the Blueprint graph. You can then have your Blueprint custom events or interface events call these SkookumScript methods via the exposed function nodes.
  • You can also expose SkookumScript functions to Blueprint graphs as event nodes by creating a method without a body and prefixing it with &blueprint before the parameter list. You can then call these SkookumScript methods from SkookumScript which will trigger things inside your Blueprint.
  • You can add a SkookumScript Component to your Blueprint which allows you to specify a SkookumScript class belonging to it, so that the SkookumScript constructor ! and destructor !! are called when an instance of that Blueprint is created/destroyed.

You currently still need to create Blueprints to receive events from other Blueprints and invoke SkookumScript from there. You might not want to entirely get rid of Blueprints anyway as they such an integral part of how games/levels are constructed in UE4.

We will be looking into ways to integrate SkookumScript tighter into the Blueprint event system, such that less extra plumbing is needed. The more insight we gain into how users build their games, the better we can tailor the UE4 integration of SkookumScript to everybody’s needs.

Converting the security camera logic to SkookumScript is a good idea - we already created a converted butterfly in the same project - I assume you have seen the post about it. We’ll get on it as soon as we can.

I hope this answers your questions - let me know if things are still unclear!

Thx this explains the basic workflow and matches what i assumed to-be the case.

Yes i saw the Butterfly example code, which is great to see the language syntax differences from your average c++/c# programmer. I was like “WTF” is this wizardry and while i disagree with the [] syntax decision, its ofc not a deal breaker. I would argue that we already code c#/c++/java/lua inside VS 2015 + VA or Reshaper and i rarely have problems noticing what syntax to use, because we only use one language per project/user mainly. In contrast Skookum has its own IDE, which already is a much bigger visual hint.

Like noted more examples that emphasizes on multi component BP communications to the owner and level BP would help. As for AI, skookum will be mainly used inside custom services and decorators, since the main decisions/movements are nicely handled inside the behavior-tree.

I’m also a little baffled on how skookum class inheritance/interfaces will work together with BP classes/interfaces and whats best practice to setup a object hierarchy.

I guess i have to figure out some stuff on my own and see what works best. So far Skookum looks very similar to the way Unity is utilizing c#, but with better CoRoutines.

Btw thx for sharing your “lifetime” work with the UE4/gamedev community.


SkookumScript can be used in many ways and the best workflow for UE4 and particular genres of projects is still evolving.

More docs, video tutorials and examples in this area are on their way.

We appreciate any self-directed discovery and please don’t feel shy about asking questions.

Also feel free to voice your opinion on how things can be improved - particularly any points of irritation or unintuitiveness.

[Square brackets]

One of SkookumScript’s biggest oddities is definitely that it uses square brackets [ ] for grouping. This is actually by design. It started out using square brackets since it was initially patterned after Smalltalk which also uses them. On one project we experimentally changed them to use curly braces { } such as C++/C#. The results were surprising - people made more mistakes. If you were working with both SkookumScript and C++ code your brain didn’t change gears and people would try to write C++ in SkookumScript and SkookumScript in C++. If the languages are visually different at a glance it is easier for people to switch between them. As you say - the IDE is a big visual cue - but it is hard to disagree with statistics.

Yes the SkookumScript syntax looks a bit unexpected at first but is really easy to pick up once you start using it. I guarantee you that any programmer will happily program away in SkookumScript after using it for just a day. Non-programmers can pick it up in a week or two (has happened!) - this is to a large degree due to the REPL architecture (interactive power console that allows you to run code snippets of any complexity on the running game).

As far as the class hierarchy goes, SkookumScript automatically provides an equivalent class for each built-in engine class (Actor, Pawn etc.) and each Blueprint in your project (e.g. BP_Butterfly). The obvious idea here is that you place code related to each of your engine or Blueprint classes in the respective SkookumScript class. You can also extend the hierarchy in SkookumScript and create Sk-only classes (e.g. MagicButterfly derived from BP_Butterfly) by adding a SkookumScript component to your Blueprint.

In addition to this, SkookumScript has internal classes of significance such as the Mind - read more about Minds here. You can for example place a Mind in your level so it constructs and destructs along with your level (via the SkookumScript component), or attach one to any Blueprint.