Intermediate Skookum Tutorial

Greetings Skookumites!

This tutorial is a bit more advanced and assumes that you have completed the Basic Tutorials so far. It takes Unreal’s TwinStick Shooter template, adds in a 2nd player, and modifies the controls to match Atari’s classic, Combat!

You can download the project here to take a look. Please keep in mind that the implementation is quite bare-bones: basic controls, spawning projectiles, and handling collision. There’s no UI, scoring system, or any visual fluff.

The main feature of this demo is that PlayerOne is scripted using :sk: while PlayerTwo is scripted using :ue4: Blueprint graphs so you can easily compare scripts and nodes. Both players have exact mirror implementations.


First thing you’ll notice when you open the project is that PlayerOnePawn is a Pawn while PlayerTwo is an Actor. This is just an :ue4: workaround to allow two “players” to use one method of input; in this case, a keyboard. You can review the control mappings under Edit > Project Settings... > Engine > Input:


PlayerOnePawn's BP class looks like this:

Hit the :sk: button in the toolbar to navigate to this BP’s Skookum class and take a look at the methods and data members in there. At this point, you could also open PlayerTwo's BP in :ue4: and see how the graphical implementation in there compares to the :sk: scripts.

It’s worth mentioning that we don’t yet have auto-generation of all engine events (in this case, input events) and that is why we’re still detecting input in PlayerOnePawn‘s BP graph and then passing on the processing to :sk:. This is something that we’ll be working on in the near future so you can do all logic and processing in :sk: alone and rely on BPs solely to edit your objects’ spatial and graphical properties etc.

Make sure to check out the projectile classes in both :sk: and :ue4: as well. Note that only ProjectileOne's collision processing was moved into :sk: while leaving its MovementComponent in :ue4:. One can certainly write a coroutine to handle a projectile’s movement frame-by-frame, but in this case, it was easier and quicker to just use a native :ue4: component.


Questions? Comments? Have at it!

And as always, Stay Skookum! :madsci:


Can this example be updated for 4.15? I get a bunch of errors in the IDE when trying to open it.

Thanks for pointing this out. We’ll take a look.

I get some errors with the butterfly example too, just not sure what to change to make it work again.

You’re using the pre-built UE4.15.1 downoalded with the Epic launcher?

Could you please post the errors you are receiving?

Many times the errors are really just warnings that you can skip past and then even resave the level and it will be fine the next time you run.

Regardless, we will update the examples to load without errors or warnings.

Sure, the errors were:
Class GameMode found twice with different super classes!

  1. In overlay Project-Generated with super class Info
  2. In overlay Engine-Generated with super class GameModeBase.

A text chunk has been created from the file (user path)\Unreal Projects\Blueprints_Sk 4.15 - 3\Scripts\Project-Generated\Object\Info.GameMode\!
but is now being updated with a different file (user path)\Unreal Projects\Blueprints_Sk 4.15 - 3\Scripts\Project-Generated\Object\GameModeBase.GameMode\! which is not allowed.
This could be caused by a corrupt file structure, containing two copies of the same class.

But anyway, like you said, just pressing cancel and restarting the editor made it work again. However at first I didn’t know that you needed to restart (well close) the SkookumScript IDE as well. Is there a reason the IDE doesn’t close when the UE4 editor does? Sometimes I forget to close the IDE when I’m done editing the project and when I realize the IDE is not responding in the task manager and using 15% CPU doing something mysterious. :fearful:

That file structure bug is already fixed, we just haven’t rolled out the fixed IDE yet. Expect an update early the coming week!

We’ll look into that 15% CPU issue and see if we can repro it.

We fixed the 15% CPU issue, and it will be rolled out with this week’s update.

It doesn’t close since you can still edit scripts when the UE4 editor isn’t up.

If the UE4 editor crashes the SkookumIDE will stay up and you can still save any work and just restart your UE4 session.

Sometimes the UE4 editor makes a new instance of itself, so there is no need for the SkookumIDE to shutdown and restart. On some projects people bring up the SkookumIDE at the start of the day and have the runtime and world editor go up and down many times but the SkookumIDE can just stay up.

When you are working on platforms that don’t share the same system such as mobile or console then the SkookumIDE needs to run independently.