Live++ and SkookumScript


#1

Hello,

I am trying to find out whether investing in SkookumScript will be worth it for our team. It seems one of the biggest advantages is compile times and live interaction with BluePrints. However, Live++ seems to be addressing this major drawback of C++ very quickly.

With Live++, the compile times are subsecond to a few seconds long depending on the size of a module, all while the game is running (i.e. similar to the demos of SkookumScript). So now, I have the following hurdles with SkookumScript:

  • Language syntax. Learning curve, even if it’s a small one, is a negative. Trying to convince other members to adopt it vs. using Live++ and getting the main benefits of SkookumScript.
  • Cannot use an external editor such as vscode (well, I can, but I get no autocomplete and of course, debugging requires usage of the integrated IDE)
  • Considering 4.2/4.21 is still not supported, it seems that over time the team may not be able to maintain development of the language/IDE (reinventing too many things including language syntax, IDE, debugging)

One of the advantages of SkookumScript seems to be the way the logic is written with the help of co-routines. But that in and of itself is a not a convincing argument. Price is another, but again, not that convincing.

I am hoping for some more convincing arguments from the community/devs for a team to invest time (and money) learning a new way of doing things in UE4.

We all know C++ and can work with it easily. Live++ removes the biggest shortcoming of C++ while providing something better than hot-reload. No learning curve.

What does SkookumScript provide for me to invest my time?

P.S: Contrary to what it may seem, I am trying to find reasons to adopt SkookumScript. When I first read about it I was excited to see a scripting language that can be turned into a BP node and called with the BPs. But then, I saw the clunky IDE and the strange syntax and was turned off.


#2

I disagree, coroutines are the main and most convincing argument. As far as interaction goes, with Skookum, you have a repl where you can test code on the fly. These two features alone are very powerful, they allow for rapid iteration and testing. I prefer the closure/higher order approach of Skookum over C++, I prefer the simpler syntax and semantics of Skookum, I prefer the pure approach over the ad hoc history of C++. Basically, Skookum is a better language, designed specifically for real-time interactive simulations, a razor sharp tool for the domain of game development and other interactive applications.

I am inferring from what you said, “seems to be”, that you have not really built much with Skookum. Try building some things with Skookum then you can ascertain whether it is a good investment or not.


#3

It is difficult to respond to your statement without knowing why it is not a convincing argument. If you need a simple way to declare in code “stop, but come back later”, then co-routines are the compelling argument.

I have enjoyed my limited time with :sk:, and co-routines played a large role in that. To accomplish something similar in C/C++, you either have to monkey puzzle the maze of threads, or build a caricature of co-routines yourself by designing re-entrant functions. Alternatively, you could just call _wait in :sk: =)


#4

While typing out the replies (which I have put below if you’re interested) I discussed with my team as well and it just seems too big of a risk to take (the bugs I encountered (separate posts) lower the confidence level). Of course, that’s our opinion and obviously there are people and teams who are happy with :sk:'s direction.

I do wish that :sk: had done a few things differently:

  • Not made your own IDE inside UE4 (perhaps Epic forced your hand). That’s programmer time wasted on reinventing the wheel - and considering :sk: is behind in delivery and has quite a few bugs, this was not a good decision. VSCode could have been used instead.
  • Used syntax of an existing language. The argument that programmers would be somehow confused because the code looks too much like C++ is shortsighted.

It would have been quite amazing to have BP nodes that are scripts using tools and syntax game programmers are already familiar with. Minimal learning curve, easy to integrate with a team.

Regardless, I wish the devs good luck. Perhaps we’ll revisit this option in the future.

… … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … …

@JacobGood1

I am inferring from what you said, “seems to be”, that you have not really built much with Skookum.

I tried, you can see my 2 posts on the issues I came across by following official tutorials. Encountering bugs (1 show stopper, where I simply cannot continue due to a compile error) this early doesn’t increase my confidence.

I prefer the simpler syntax and semantics of Skookum, I prefer the pure approach over the ad hoc history of C++

Syntax I have to learn and convince my team to learn.

@JesseRMeyer

It is difficult to respond to your statement without knowing why it is not a convincing argument.

As I said in my original post, the reason is always time (and by extension, money). For any decent sized team to learn and trust something new (which doesn’t use existing, mature, tools) some very convincing arguments need to be made.


#5

That’s why I motivated the usage case of a co-routine. They save a ton of time and money when you need code to “stop and come back later”, which is a common pattern in higher level game logic. As to whether you find that compelling, I don’t know. I don’t know anything about your project and its requirements. :sk: is an expressive textual scripting language with first class support for co-routines, and a great tool for that usage case.


#6

That’s fair. It could work and co-routines are (were) compelling enough for me to try it out and go through the tutorials. I wish they had stuck to mature tools rather than make their own.


#7

Hi, guys, I guess samaursa and his team shares the same views that I made earlier when I first encountered SKS. I’m happy that I’m not alone.
Here are my posts.



If SK wants to make SK very popular, I still think my comments are relevant.
We can at least change the syntax a little to make it little more conventional.

I still think that SKS has very good chance to become popular in UE world because Epic doesn’t want to support scripting language.

Yeah, Co-routine is probably the best feature that can overcome all shortcomings, however, I’m really not sure if SKS can survive. There has been very little update since the April and I’m not sure what’s going on.

I’m still waiting for the big announcement that are pending. ^^

Cheers!


#8

For me it’s about loving co-routines more than hating the IDE, not a huge fan of reinventing the wheel as well. Being able to develop in VSCode would be really great.

One more way to look at SK is strongly typing the game data, using sk scripts instead of xml or json.

In terms of syntax I think it was a good decision. When you develop simultaneously in two or more different languages, that have some similarities, it’s quite hard to switch quickly between mindsets.
Having distinctly different syntax makes it easier to switch and not get confused.

I would recommend to give SK a serious try and reconsider if the creators manage to get a 4.21 compatible version.
Co-routines are just amazing.


#9

You did a much better job of articulating it than I did! :slight_smile:

@pew I will do just that! Hopefully it’ll grow on me.


#10

There are some issues with SK:
One issue is actually a UE4 flaw which is unrelated to SK: being that label names in Unreal don’t necessarily correlate with the exact UE4 ID. This seems to be a UE4 issue which won’t resolve with any other scripting method.

Unreal Engine already supports Live reloading afaik, so I don’t see that as I primary issue.

I do agree that having first class support for an external editor such as sublime would be optimal. However, having its own built in editor is awesome, so I disagree that it is a downside. Occasionally some mouseover info has been misleading but other than that its a pretty decent IDE.

I do agree that sometimes SK names things oddly. I sometimes see names appended with some partial hash, so I hope that changes for the better.

Overall the support by the Agog team for SK has been excellent whenever we mention something, especially recently.

My recommendation is to re-evaluate SK upon their next release, and see how many issues that you had resolve.