New realisations regarding KnyttWaDF levels

Now that I've starting to work out a system for the game to support any kind of dialogue tree and quest that can work in many different ways, I'm realising the inevitable; a game that can do complex things require a much more advanced level format.

It's working out well though, the Python scripting can be used to do all kind of cool various stuff that Knytt Stories could not without some seriously hacky solutions using those shift objects and flags. However, I need to try to figure out how I can make this easy to use people who want to create third party levels.

I guess what I'm saying is that my plan to make editing very easy may not work out. I suppose to create a quite linear levels without items and quests will be very easy. Dialogues that doesn't branch out in trees will require a little python scripting, but it won't be that hard. Creating a world with NPC's who give you quests... for that you'll need to know your way around a programming language.

I  would say: create an object reference guide, which holds all the objects in the game you can point at, and perhaps explain in simple words how to use phyton (like the indentations)

You would be focussing on those who can already program in another language and understand the basics of scripting, not those who're completely new to programming at all.

You will not be able to make the system less complicated, but you will be able to push people into the right direction.

Since I never touched python before, all I would need to make a level with a script, is knowing what objects there are, some basic functions maybe, but if they're the same as in normal python, then I would be able to google that myself and a small briefing on how the syntax works.

From there, we could make examples (snippets) that anyone can use, and we could dedicate a forum section for scripting questions.

Also, a question for nifflas, how will the python be implemented?
Could I theoretically import other libraries, such as math and pickle?
If so, you may want to limit things such as the pickle library, as it is possible to "unpickle" viruses and other code.

Or will there be some sort of "Knyttwadf" library?

For example, it would be much easier to create a virus, as it would be easy to make a never ending while statement, so it might be a good idea to bring in prevention measures, such as preventing a script from taking up too many processes.

Nifflas is playing with creating safe and unsafe scripts.

If a script uses certain functions that aren't in the safe list, the script is marked as unsafe. Players can still play the level, but at their own risk.

Actually, the main problem I'm having now is that RestrictedPython doesn't allow "yield". It's not something you implement a policy for like with many other things about RestrictedPython, it's just disabled. That must mean the developers consider the operation unsafe.

I must use "yield" for the scripting, and if I need to punch a security hole into the scripting part of the game, there's no point having any security. In that case, I'll just have a completely untrusted level format that are as dangerous as executables. I'll have to warn users to only run levels they trust. This will hurt level editing

However, I need to look into this. There's a chance "yield" is disabled only to prevent the possibility freeze a script or the game, rather to prevent damaging the computer it runs on. If this is the case, I can allow "yield" while still considering the level format safe. I really hope this is the case, because then level editing and scripting won't be a problem.

LP: If I run RestrictedPython I never planned to let players play untrusted levels. The thing is, room scripts are loaded and unloaded on the fly in the game, and it's inconvenient and possibly slow to iterate through them all when you start a level. What happens with RestrictedPython is that when the player enters a room and illegal code is found, it just stops the game and displays a warning.

However, your suggestion is still not bad. There's a lot that can be done with untrusted code; connecting to a server, changing dialogue depending on real life news or whatever. What I might do is instead to let the level designer decide if they want to have their code running with RestrictedPython or not. They just set a flag in the World.ini file like RestrictedPython=0 - if they do set it to 0, a warning is displayed for users who open their levels that the level is potentially unsafe and they can decide if they want to play it or not. If it's set to 1, the code runs with RestrictedPython and stops if the script tries to do things it's not allowed to.

However, I won't iterate through all the rooms figuring out there's any illegal code. It's way too much work that and it isn't any safer than just running RestrictedPython when the player reaches a room (the only gain is one less parameter in World.ini). The easiest and fastest solution is often the best.

But well, before all that, I need to figure out why Yields are disabled

Ah, I've misunderstood you then. Yeah, I agree with your point of view entirely.

On the topic of complexity versus simplicity, I think a real programming language would actually simplify things for level designers. The "hacky solutions" of Knytt Stories become enormously complex in comparison to the simple tasks they allow. They're hard to make, hard to explain, and very hard to understand by reading the World.ini. With a real language the programming will only be as complex as the tasks themselves.

Yeah, to a programmer it'll obviously be a lot easier to use scripting than KS' hacks.

For someone who's not a programmer I think it may still be far easier to think up hacky solutions using flags than learn a programming language. It's quite some work to learn to understand variables, data types, functions, and just the syntax.

In some ways, the scripting part of KnyttWaDF will be more limited than I want it to be. I mean, I can hook up pretty much anything in the game to the scripting, but if I do the game will never be finished. I constantly have to hold back to be efficient with creating the game too.