This is definitely a goal of SkookumScript - user created mods.
Right now you could allow mods if you shipped with all your script source and the SkookumIDE to generate a binary. There might need to be a little modification to the C++ source to indicate a different script binary should be loaded if it is present, but it would be fairly easy.
It would also be possible with Demand Script Loading as @VolkerEinsfeld mentioned. This might even allow you to create mods without the full script source given to the end users. Though as mentioned, we are planning to make Demand Script Loading a paid feature - currently $5000 a project.
All the SkookumScript C++ API is available and with a little C++ tinkering you could definitely write code that could allow more sophisticated user created mods.
Regardless, the plan is to have an easy mechanism to support SkookumScript mods.
You can either ask for help to work with the building blocks available to make SkookumScript mods work yourself or the more teams ask for it the more we can prioritize building a turn-key mod mechanism.
That’s great! We’re nowhere near ready for mods yet, but knowing that it’s possible with a bit of work definitely has me sold. I’m very much looking forward to working with SkookumScript. If/when I have questions I’ll post them.
Do you mind if the full script source is available to the modders? This would make enabling mods for your project really simple.
Alternatively, do you require that some of the original game scripts be hidden from the modders? This is possible though it would require some additional work and some new C++ code written. Even if this is what you want in your final shipped product, you could start with 1 above and work towards 2.
What platforms are you planning to have your project run on? If it is all Windows PC then it might work right now with no C++ code changes. Consoles and mobile can be modded too, though they may require more hoops to jump through.
I’ll first answer with a mechanism that uses the currently existing features of the SkookumIDE and the SkookumScript UE4 Plugin. New features could be added that could make end user modding even more flexible in the future.
The main idea is to have mods compiled on a server and have the compiled binaries with mods sent over to clients that want to use a particular mod.
You could theoretically have several different mods and their respective overlays applied in whatever combination that you like.
The trick and the unwritten part that you would need to write depending on the needs of your moddable project would be to transfer the script files for a mod to the server and to create some sort of a management system for the mods - which ones to apply for a given game etc.
On a modder’s system
A modder would need all the script files and a version of the game that still allows the SkookumIDE to connect to it to build up a mod. Modders could use the freely available Standard SkookumIDE or the future Pro SkookumIDE to build their mod. The game that allows SkookumIDE connections, the SkookumIDE and the scripts could be included with every version of the game or be a separate download for people that have decided to make a mod.
Each mod would use its own “overlay” to contain all the script files in their own directory that can easily be toggled on and off. Mods should probably be located between the “Engine” overlay and the “Project-Generated” overlay. Project overlays can be seen and modified in the SkookumIDE “Settings”->“Project Settings…” menu option.
Here is a related post on overlays:
Once a mod was working on a modders system, the overlay and all its script files would need to be uploaded to the game server. You might also want the server to ensure the name for a mod was unique, add a description or icon to represent the mod or any other custom details that make sense for your game.
It would probably be a good idea to be able to download mods and all their script files from the server so that modders could look at existing mods for ideas.
On the game server
The most efficient mechanism of getting mods to client systems would be for the game server to generate compiled binaries for various permutations of mods. Each compiled binary would have all the logic needed for the particular mods applied and all the rest of the game logic. Once a particular set of mods was chosen for a game the server would build the binary if it didn’t already exist and then each player would download the binary to play.
There are many features that could be added to the existing tech to help with this process, though you should be able to work with the current SkookumIDE without too much extra work.
A project file for the SkookumIDE stores the names and locations of all the overlays in a simplistic .ini file usually called Skookum-project.ini. We can supply the format of the project .ini file in a follow post if needed. Your server could edit this file and add or remove mod overlays as needed and then run the SkookumIDE on the command line to generate the compiled binary.
It might be nice to add a couple of extra command line options to make this process easier. New options that come to mind include reload project, load new project and quit SkookumIDE. We can work that out as needed.
The generated SkookumScript binaries should be a simple single file to transfer to the client. In the future we could add tech to compile just the code for a mod rather than the entire game + any mods. Even without that future tech making the SkookumScript binaries more modular the full binaries with the entire game + mods would still be pretty small. For example, the compiled binaries for the open world game Sleeping Dogs is about 6MB.
On modded client
The SkookumScript UE4 Plugin is currently written to look for the compiled binary in a particular content location and to load it once when a game starts. You could keep it that way if you could swap in the appropriate SkookumScript binary downloaded from the server. Alternatively you could modify the freely available SkookumScript UE4 Plugin C++ source so that it looks for the SkookumScript binary in different directories or file names for different mod combinations and it could reload the binary at different points rather than just at the game start.
Future modding tech and more info
It may be possible to get modding working mostly with the existing tech as described above, however we will be adding additional modding features to SkookumScript so don’t be shy to ask for features in this area if you think it will save you a bunch of work.
Likewise the descriptions above may need additional details or info to get you on the right track before you have a modding system 100% implemented and shippable.
There were 3 Main Goals to what we want to achieve and 1 thing that would be cool but is not really required:
Initial state: The game is not running. The player who purchases the game edits the scripts (modding) without really having any serious IDE / except maybe in game error log if their is an error. When the game is launched the game loads the scripts and the game can be played. I suppose since the free version will be available the basic IDE would be ok. That would be dependent on SK for permissions. This would typically be “single player”
The game is running. The Server sends modified scripts to the client. And the client runs those scripts and destroys them when appropriate. (Server controls the scripts available to the client)
Depending on the “game type”, all scripts may be required to be “the same” for the server / server client so that no one can cheat by modifying their client side scripts to be different from the others.
The last thing on our list was sort of dynamic loading of modified scripts, but I take it that would be close to impossible.
Question: It sounds like the first three can be achieved, but then I read about possibly removing the text parser.
So I am a bit confused about that. Let’s say we want to allow people to run their own servers for certain game types, How will they be able to run their own modified servers if they can’t parse scripts?
Modding and parsing scripts is awesome and we want to encourage that - not take it away. What we are suggesting is that we encourage the parsing to take place in the tools that are specifically designed for parsing: the SkookumIDE and the SkookumCompiler. And since this has many more benefits we are also planning to take parsing out of the runtime. This would also make it easier to optimize the runtime for what it needs to do best - run the scripts.
The runtime can still load up different script binaries that are created by the SkookumIDE and the SkookumCompiler. In the runtime you could replace the old binaries with new ones or even leave in the capability for the SkookumIDE to connect to a game remotely.
You could do everything on your list including #4 with the SkookumIDE or the SkookumCompiler. The only difference would be that the main files loaded by the runtime would always be little compiled binary files rather than text files. Such files could be generated when they are originally written, when the game starts, when a particular level loads or at some particular game progression point or event. Some of the mechanisms would be different for each though it is all possible right now. Some would work right out of the box and some would require a bit of C++ calls into the SkookumScript API to load/reset things as appropriate.
Nope. Demand script loading solves the problem of fitting a large game into a smaller memory footprint. If you already were using demand script loading you could bend it a bit to create a form of end-user modding. It isn’t necessary - just one possible way of doing it.
As it stands right now, we don’t have a specific recommended mechanism for doing end-user modding all packaged up with a bow on it. All the pieces are there and it shouldn’t take too much work though we will be adding more end-user modding tech and recommended mechanisms to achieve it.
Here are some end-user modding features that we have planned for the future:
skin the SkookumIDE to the theme of your product as a end-user version
sandboxing so you can ensure that end-users can only mod a subset of all the game features (some of this is possible right now)
allow the SkookumIDE to be extended and modified using SkookumScript code.
making it easier to author a mod with either only a portion of all the game scripts or only with the compiled binaries
Re: Script Availability: This has some complexities.
I wish I could simplify this answer more but here goes:
The first game that we will release will have 2 parts:
The single Player Campaign, and a Multiplayer Arena type. I think the “Official” Single Player Campaign absolutely needs secure scripts. The official version of the game will need to be protected from any outside script execution. The sandboxed versions can do whatever.
Initially we want the single player to work out of the box after download with no additional internet connection required to play.
Options will be provided so that the player can store their progress on a server OR locally (or both) and to get updates.
So, yes, It would be critical to ensure that the Single Player Campaign has “secure” scripts and data.
For example: Hidden Mission Scripts / general logic etc…/ Weapon and player stat values etc
We would probably want “Add-on” Missions to the “Official” Single Player Campaign to be Server Provided, and Secure (And stored only in Memory / transient)
That would allow us to have an initial go anywhere campaign, with server side only add-on missions.
We will need to some way to block user script modification / unofficial script updates for the “Official” Single Player Campaign.
If the player were to modify any scripts for the Single Player Campaign that were not “official” then his progress would be invalidated for our game sequels. So that also means Official Changes, should be allowed, and we will need some secure way to make sure that we can allow official scripts to run, but block anything else.
Sandboxed Modes: This is great too. We would not “track” player progress for this. And it would be outside of our single player campaign. I suppose we would need a “Sandbox Mode” that would allow for custom local or hosted server scripts. Most likely we would provide the end-user a “set of sandbox scripts” to get started that did not include critical solo player campaign logic / data.
As far as sandboxing a portion of the entire available command set of SK for Unreal Engine (If I am understanding this?)… In some way this makes sense, but I don’t think this would be an easy task.
It seems easier to just allow them to do whatever they want with the sandbox “version”… similar to how other games get modded… ie gut the entire game, leaving just the environment, and a small subset of initial scripts to get started and let them play.,
Re: Platforms: Windows for sure. I would consider Linux / Mac at some far future point. Our game can’t be played on mobile with today’s tech.
I am not sure if I answered properly, so feel free to ask any follow up.
Obviously, much of the mechanics of these requirements for tracking unofficial modding may fall into our own for creating the methodology. We just need some way to secure any game modding for the official game so that they cannot execute scripts for the Official version of the game.