use system
use scene
use dialogue
OnApplicationStart
scene "OutdoorScene"
jump QuestionLoop
QuestionLoop
dialogue.message "One way"
message "or another"
"I'm gonna get ya{pause=0.5}, get ya, get ya, get ya..."
CS string[] options = {"Yes", "No"};
choice "Right?", options -> chosenValue
CS if(chosenValue == "0")
message "Christine" "Well ok"
else
message "Christine" "No"
jump QuestionLoop
parallel NpcTalk
call ShowNotReallyDialogue
"I guess, I'm going home then"
# at this point execution ends unless QuestionLoop was called, not jumped to
ShowNotReallyDialogue
"Christine" "No not really, I said ok just because you were annoying"
"Ah...{pause=0.5} sorry"
NpcTalk
CS Find("NPC_Alice").GetComponent<TalkBubble>().Open("I wonder what's going on there");
wait 5
CS Find("NPC_Alice").GetComponent<TalkBubble>().Close();
I’ve heard a few people complaining that scripting in Unity is not a pleasant experience if you’re not a programmer. A few days back I had to create a game prototype that has a narrative and guess what, I couldn’t do it fast enough, there was just too much coding that I didn’t had time to do in Unity. So in the end I chose RenPy engine and used that for things it was not exactly meant for. Maybe I didn’t take the right approach in Unity, idk.
Anyway, this piece here is my attempt to invent a simple scripting language for Unity. I hope some of you already sense the power of it. I see it solving so many problems. This sample here is not just some text, but I already have tools to actually “compile” it onto C# and run it.
I’ve headed some people moving from Unity to Construct2 or other engines and I think I see why. It’s just either too programmer oriented or dumb user oriented (think about visual scripting tools, sorry) when it comes to putting together the storyline game flow.
Your thoughts about it? Am I overlooking something and inventing just another thing here, which already exists, but I just don’t know it?
to be honest there are thousands of programming/scripting languages… it don’t really see the need for a new one…
that said, someone who’s is willing to learn programming can learn it easily…
If for some reason logic is a total stranger to you then you should maybe just stick to making art or design (and even then you need logic…)
I think a lot of people give up because they make them self believe they can’t program. I see this with my students all the time, but then after i dump them into a project as programmer of the team every day for a week or two. they come out understanding a bit more and most of all loose the fear for programming… they still may prefer doing art and assets but al least they see its not rocket science.
I think it’s a fine idea, but with limited applicability.
What you have here is the beginning of a Domain-Specific Language (DSL) that seems to be focused on writing dialogue. That would probably be an excellent usecase for a little custom scripting language. But I think you’ll find that, as you try to expand its capabilities to cover more general programming scenarios, the language will start losing its usefulness as it becomes cluttered and complicated.
It also depends on the target audience. If you want to target non-developers, then it might be a good idea to remove the ability to inline C# and replace that with constructs native to the language, since having to know C# would defeat the purpose of learning your language as well.
But it the target audience was developers, then I as one would prefer to use a framework built in and usable from C# instead of having to use a scripting language that I’m unlikely to use anywhere else. I would personally find the following more palatable:
public class MyGame : GameBase
{
protected override void OnApplicationStart()
{
LoadScene("OutdoorScene");
QuestionLoop();
}
.
.
.
}
Yeah, learning programming is one thing, but that’s not the case here. This one here is comparable to “eventing” in RPG Maker, Construct2 or Unity Play Maker, BUT it’s written down in a format that doesn’t require you to use visual programming tools. It’s both declarative and procedural.
Consider this example. What are all the options for efficiently writing a nonlinear visual novel type of game (because that’s the simplest case for explaining).
A. Write a script that’s full of something like: yield return StartCorouting(Dialogue.Message(“Bla bla”));
Good: complete control of the game flow. Can use text editor to write text. Merging version control conflicts possible.
Bad: It’s just awful to write and read the script so only programmers may like it.
B. Write the text lines into some text file and then import it into Unity.
Good: Non-progammers don’t complain.
Bad: Works for simple cases, because there are no control flow directives in that text
C. Use some well known markup language like XML, JSON or other to write those texts.
Good: more control over the flow
Bad: Non-programmers slowly start to complain again.
D. Make tools for story writers to enter the text and flow
Good: Non-programmers won’t complain. It’s actually quite a good way.
Bad: It’s purpose designed, and often the tools are in some form of “visual programming”. Data is probably still stored in some markup language, which may be hard to merge if conflicts arise.
E. Have a storybook like narrative markup language with basic flow control that may contain bits of real code
Good: Story progression is more like using GOTOs in code than doing OOP, so it feels nice to writers. If needed, programmers can inject one line code snippets if a writer wants some complex behaviour. Otherwise programmers work on extending the storyline markup language. Maybe the game has weather and changing the weather is important to the story. So a coder can add “weather ” into that markup so a writer can use it. Since the markup is limited, it’s even possible to write importers/exporters that convert this particular story into a format that some other game engine can use. Due to the same reason, even visual tools for markup editing can be built on top of it.
Bad: If such higher level “eventing” language is not integrated with the Unity game engine, it may be hard to implement so that it’d work seamlessly. If the architecture isn’t designed right, then it might not provide the benefits. Right now this language alone doesn’t solve event triggering, because it’s too limited, but something can be surely done about it. These are the fears I have.
Uhh, that was a long one, but I guess this example summarizes it pretty well.
Yeah, it’s probably best for text heavy games, but I don’t really see it being DSL. I see it more like general purpose “eventing” language where keywords are not mapped directly to C#, because then it’d be quite pointless, but instead they’d map to something more meaningful. By default the scene “OutdoorScene” would maybe indeed call LoadScene, but instead you could easily set up the markup language so that it would do whatever is your custom scene setup and initialization for that particular scene.
I don’t see a point of it being Turing Complete (although it probably already is), because the story flow is more like GOTOs than OOP. Ideally I’d discourage writing inline C#, but I wouldn’t disallow it. It’d be a quick way to add some complex stuff quickly. Later on a programmer in the team should extend the markup language so that a writer doesn’t have any C# inside her file.
