Forums » Advanced Editor Forum » Read Thread

First of all, the CYS editor is great! Seriously. It allows anyone to create great games easily.
But it is far from perfect.

This thread might be interesting to those authors who:
1. Use a lot of complex scripting in the advanced editor. In particular, generate pages by scripts.
2. Find the editor limiting or inconvenient.

After I tried and failed to create a game using the editor, I made a small JavaScript storygame engine that allows you to use JS instead of the editor scripting language and run an entire game inside a single page.
If at least one good author wants to use it, I'll write a reference and release its source.

The key differences with the stories created in the editor (what are pros and cons - decide for yourself)
1. There is no editor graphical interface. You write everything in text files.
2. All related texts, links, variables, conditions, etc. are visible in one place - no need to open and close many windows.
3. With JS you can do anything!
4. You can run it on this site, other website or on a computer without internet.
5. You use a browser console and debugger to find and fix problems. The good thing is that you have a debugger (the CYS editor has none). The bad thing is that you will probably have to use it often.
6. Saved games are stored on your computer instead of this site. You can have multiple saves for one game and even transfer data to the next part of a series.
7. A user can access your entire game code and cheat.
8. There is no standard inventory system and I don't want to implement it anytime soon because stories that I like don't need it. Maybe someone else implement it as a plugin.
9. It seems the site might auto-ban a user for a few minutes after pasting many KB to the editor.
10. The game length is calculated incorrectly.

How hard is it to use?
Not very hard. Here is an example of a non-scripted page:
addScene("town square",
"You are standing on the main square. It is crowded. <ln> There are shops nearby.",
"go to the armory", "> armory",
"go to the apothecary", "> apothecary");

Here is an example of a simple scripted scene:
addScene("town square", function() {
  ln("You are standing on the main square. <ln> There are shops nearby.");
  if ( time == "day" ) {
    ln("The square is crowded.");
    if (naked) ln("Everyone is looking at you.");
    link("go to the armory", "> armory");
    link("go to the apothecary", "> apothecary");
  } else ln("The square is empty and the shops are closed.");
  if (has_friend) ln(friend_name + " is standing near looking at the sky.");
  if (naked) link("put on your clothes", {naked: false} );
  else link("put off your clothes", {naked: true} );
} );

No knowledge of HTML, CSS, DOM, or anything more complex than conditional statements is required. If you have no problems with the editor scripts, you will likely have little problems with these scripts too. The hardest thing to learn is probably how to use a browser console and debugger to find syntax errors and bugs.

The source code of a bigger example showing advanced features and more JS syntax is here: http://pastebin.com/zSUsjpXe
you can test it here (it is not published): http://chooseyourstory.com/story/javascript-cys-game-engine-demo
The story is stupid, it's just a technical demo. And the engine is unfinished, of course.

The results don't look all that different from what the editor can do. 

Yes, it looks the same from the outside. The editor can do many good things. If you didn't hit the limits of the editor yet, then you don't need this engine :)

I was forced to create this program because I couldn't reasonably implement what I needed in the editor.

Can you provide a specific example of what your game engine can do that the CYS editor CAN'T do?

what made me stop using the editor:

- 2 serious problems and 1 bug that I posted in the Wishing Well and bugs section. The JS itself is bug-free. I can fix bugs and implement necessary features in this engine without praying to the "storygame god".

- you can't see conditions, scripts, etc. - only icons. You need hundreds of mouse clicks to open and close windows. You can't even rearrange links without re-entering them all. It's much faster to type everything, you can see the whole picture and edit everything.

- there is much more freedom. For example in the "town square" a single condition is used for both links and lines of text. In the editor you have to enter it with mouse for each link. And more complex conditions you just can't enter.

- there are some problems with global and page scripts and evaluating conditions that make certain things impossible, but it will take pages to explain...

Again: the editor is fine for most tasks. I don't want to convince anyone to not use it. This is only for those who have problems with it.

Ah, yes. The "AND OR" bug. It could be bypassed though. 

The only problem I have with the editor is that it doesn't have a global image script. Otherwise, the other things you've talked about- such as rearranging the links and such, I don't find too troublesome. Usually, I leave the links alone after entering them, and rarely do I have to rearrange them. 

Ah. You mean if you have 5 links on one page, you can have 1 condition linking to all 5 links without copying and pasting in all 5 links? That is rather useful, and much less time-consuming. I agree that it should've been implemented a long time ago.  

The worst thing for me was not AND, but the inability to replace %%variables%% in a scripted text. In some scenes it cannot be bypassed without making everything unreadable.

I'm happy that you are happy with the editor :)

Okay. I'm curious. You seem to be pretty good at coding. Do you happen to have any knowledge on Java? 

I know Java a little.

An addition to "Can you provide a specific example of what your game engine can do that the CYS editor CAN'T do?"

I forgot to mention functions (pieces of code that you define once and call from different scenes). It's much better than copy&paste, because it's shorter, clearer and you can see and edit it in one place. There is one such function in the demo - addHunger().

In the first answer I didn't mention any JS features that seemed not necessary in storygames (for example, loops). But now I find another feature highly valuable:

- maps or hash tables. For example, I need to store a flag for each location, weather and time of day. In the editor it'll be dozens of variables with beautiful names like DDBPRA1 and dozens of nested IFs. In JS I use one line instead: "sceneDescFlag[place + weather + time]". They can also keep track of different things that the character encounter.

I'm making a card game using the editor and I can tell you, loops would in fact be quite useful, haha.

As would arrays, and strings.

String variables are definitely useful! (I even included friend_name in the example, but forgot to mention it)

And for minigames and puzzles all the language features can be useful.

As cool as this is, it feels like an extension of when you wanted to host a game off-site. You even list that as one of the benefits. Seems like this is just a way of circumventing the verdict when you were told no.

But assuming this is considered acceptable, I'd be interesting to see what you manage to do with it.

The only verdict was to not redirect users to other sites. This engine has nothing to do with off-site games. Everything is hosted and played here. (but if one day this site closes, your game can live somewhere else too)

Don't get high expectations for my game, though. Story and writing is what makes a storygame good, not scripts.

As long as you include an End Game Link that allows us to Finish and Rate the game when it's over through the CYS interface, I say go for it!

Yep, it can use an end game link just as any normal game (the author has to set it manually because the actual server link number may vary in different games and JS can't automatically deduce it).

The links in the editor can change the page and update variables. That’s all.

A link in the JS engine can do that and much more:
1. Replace or alter a text that will be generated by a scene after the click (it is the easiest way to show the result of the last action without leaving the scene).
2. Include an unnamed mini scene (it is the easiest way to make choices and confirmations inside a scene).

To implement that in the editor, one have to either create additional pages or remember last clicked link in a variable and generate a page using IFs. Both solutions are more complex and require more writing and clicking.

3. Function jumpLink() clicks a link from within a scene script. It allows instant scene change without displaying the canceled scene to a player. It is impossible to do in the editor.

An example:

addScene("interrogation", function() {
  ln("The suspect is afraid and trembling.");
  if (bill_health < 100) ln("He is injured.");
  if (bill_health <= 0) jumpLink("", "<", "The suspect died.");
 
  // the Bill's answer will replace the text generated above
  if (!know_bill) link("@What is your name?", {know_bill: true}, "@My name is Bill.");
 
  // the same, but the text is dynamically generated
  if (!know_bob) link("@Who hired you?", "", function() {
    if (bill_health > 50) ln("@I don't know.");
    else {
      ln("@It was Bob!");
      know_bob = true;
    }
  });
 
  // this link shows a mini-scene
  link("hit the suspect")(
    "How do you want to hit him?",
    "with a fist", "{ bill_health -= 5 }"
    "with a chair", "{ bill_health -= 30 }"
    "don't do it", "");
    
  link("stop the interrogation", "<");  
}

#2 is actually the only real point.

You can change the text that will appear on a page with $PAGETEXT and the inline IF statements. Yes, it's certainly EASIER with what you're doing, but it's not impossible, nor is it even overly difficult, with the editor.

Not even sure what your point with 3 really is. Given "scenes" don't exist in the editor, your comparison doesn't make sense. If you're saying you can skip pages without first revealing the page you skipped... you can do that with link scripts as well. In your example, you would just have a link script on the page before that dynamically changes the destination if bill's health is 0.

About #1: suppose I have 3 links and I want to change the page text and 1 variable after each link is clicked. This is a common thing in some types of scenes, especially in dialogs with NPCs (most of the demo in the first post is created that way too).
Here I write only 4 lines:
ln("default text");
link("a", {a:1}, "a is clicked");
link("b", {b:1}, "b is clicked");
link("c", {c:1}, "c is clicked");

In the editor I have to do:
1. Create a variable $LINKNUM
2. Go from "variables" site page to editing page.
3. Open a new window, create a page script
IF $LINKNUM = 1 THEN
  $PAGETEXT = "a is clicked"
ELSE IF $LINKNUM = 2 THEN
  $PAGETEXT = "b is clicked"
ELSE IF $LINKNUM = 3 THEN
  $PAGETEXT = "c is clicked"
ELSE
  $PAGETEXT = "default text"
4. Open a new window, enter a link script:
$A = 1
$LINKNUM = 1
5. Open a new window, enter a link script:
$B = 1
$LINKNUM = 2
6. Open a new window, enter a link script:
$C = 1
$LINKNUM = 3
Not much difference, really?

About # 3: suppose there are 100 links leading to a town square. Depending on whether a zombie apocalypses happened I want to go to scene/page either "square" or "square with zombies".
Here I can make every link simply to "square" and place at the beginning of "square" scene one line:
if(zombies) jumpLink("", "> square with zombies");
In the editor I have to add a script that changes $DEST if there are zombies for each of the 100 links.

"Not much difference, really?"

Is... that directed at me? I never said it there wasn't much difference, I said it was:
A) Possible, since your post implied it wasn't
B) Not hard, which it isn't.

As for 3, that's not true. You could create a simple global link script to override the destination.

IF $DEST = @P43 THEN
IF %ZOMBIES = 1 THEN
$DEST := @P76

Is all you'd have to do. Where @P43 is the normal town square page, and @P76 is the one with zombies. So there's no difference in difficulty there.

"A) Possible, since your post implied it wasn't"
It's not true. I specifically stated that it is possible, but require more work. A quote from my post above (it was about both #1 and #2, but maybe it looked like it was only about #2):
"To implement that in the editor, one have to either create additional pages or remember last clicked link in a variable and generate a page using IFs. Both solutions are more complex and require more writing and clicking."
Because you stated that only #2 is a real point, I took it as if you found the difference between JS and the editor in #1 insignificant. So I tried to show that it is big enough to be a real point (of course, if it is used often). And I'm sorry if it looked offensive to you, it's only a technical discussion :)

Unfortunately, IF $DEST = @P43 THEN (or IF $DEST = "@P43" THEN) doesn't work because it can compare only numbers. I tried it before I got an idea to use JS.

Unfortunately, IF $DEST = @P43 THEN (or IF $DEST = "@P43" THEN) doesn't work because it can compare only numbers. I tried it before I got an idea to use JS.

That's just plain wrong, lol. I literally made a script to double check if it worked before saying that it worked. The @ syntax works fine (without quotes), it's just the only thing you can use it with is the $DEST variable.

You actually didn't state that at all, because saying "To implement that in the editor" in context only refers to the previous stated point. You should have said "those" (or "all of that") if you wanted to include both points. I can give you the benefit of the doubt there though, because it seems like that was really your intention.

Yes, I will comment on your grammar. This is a writing site after all, haha.

You're right! IF $DEST = @P43 THEN does work! :)
I checked your solution (without quotes) before the previous reply, but probably screwed something last time and it didn't work. And it is even explained in the "Intermediate scripting", LOL. I tried to compare $DEST as a string with quotes because of $DEST := "@P" + %LASTPAGEID in the "Advanced scripting".

So it can be easily done in the editor. jumpLink() still provides more freedom (it can be placed in a global or local script and can contain a mini-scene). But it's not very important.

Yep, I didn't formulate it right. And I'm grateful for comments on my grammar, I need to improve it!

While I do like the idea of the increased functionality,  the way it stands, it looks like this would put even more strain on beta readers and play testers (especially those that don't have prior programming experience).

Compared to non-scripted editor pages, it's definitely harder.

Compared to the editor pages generated by scripts with $PAGETEXT, it is actually easier, because proposed scripts are much shorter, cleaner and you don't need hundreds of mouse click to open/close windows.

Understanding scripts logic is not necessary to proofread texts in them.

If one just plays and proofread while playing, there is no difference.

I looked at the source and saw the 'Go Back' reference, but while playing your example it doesn't show.  So I can't return to check other links without restarting the game from the beginning.  Is this a bug or intentional?

Going back like in the editor games (i.e. cancelling last actions using udno history) is not implemented yet. I'll probably implement it later.

In the current version you can use multiple saved games to try different paths without restarting.

I also plan to allow scripts to create autosaves before dangerous situations. If you die, there will be a quick link to load the last saved game.

Autosave sounds like cheating nice.  I can't wait to see what you can do with this.

(I only use "Go Back" for proofreading/play testing or when I come across a broken link, dead end, etc.)

The engine is pretty much finished.

"Go back" is implemented as well as many useful features absent in CYS editor: customizable menus, scene stack, more flags for hiding links or pieces of text, custom random generators. A powerful advanced feature is selecting data (texts, stats, etc.) from database-like structures with tags, which allows using a single scene script for all locations, all combats, etc.

The engine was originally made for "The Story of a Unicorn" game. Here is its short demo with the latest engine version. Because the game itself caused zero community interest, its development was stopped. And after that I won't try to make another game.

Today the engine is probably the most powerful scripting tool for storygames, yet it is still easy to use for simple things. It's a shame that most likely it will never be used. Still, coding it was fun and I don't regret it.

If someone decides to use it, I'll send a source code of the engine with both demos and provide a limited technical support (because it would be cool to see it in action).

It is pretty damn slick though.  :)