[Tool] Chronicler - ChoiceScript Visual Code Editor

[BenSeawalker]

@Ephemeral
Hey, sorry I missed your messages.
I literally graduate next week and become a free man.
As such, I’ve been focused on my education and all the homework and tests that entails. Which essentially means I haven’t checked my email or done much of anything on the interwebs for the past couple weeks or so.

Regarding your issue, I suppose I really should add a note in the main topic.
Essentially the Mac issues boil down to the fact that I do not own one and had to rely on a generous forumite to help me build it.
Turns out that Mac is extremely picky about it’s programs, and Chronicler only seemed to run on their specific system. I posted the download anyway, and some people can run it without issue, but many have reported a similar error message.

Unfortunately, as I pointed out, I have no way of testing or debugging it myself and thus can’t offer much in the way of support.

However, it may be possible for you to run the Linux version. There should be several tutorials on the internet for running Linux apps on Mac.

Your other option is to simply remain patient for a few more months while I finish the new web version of Chronicler. It should be a much more stable program and run in any web browser, and hence any system.

I apologize that there is not much more I can do at the moment…

I hope to resume posting regular updates regarding the new program in the relatively near future.
Rest assured all that work is not abandoned and I fully intend to finish what I started!

• BenSeawalker

[enrique.arcilla]

Does Chronicler for Apple only work on a certain kind of OSX?

[BenSeawalker]

@enrique.arcilla, see my previous post.

[Ephemeral]

I’m glad you replied! I’m sorry for taking time from your busy schedule, I hope your graduation goes well!

As for the issue, no need to apologize, It’s reassuring that you replied and it’s someone who genuinely cares, so I think I’ll just wait, I’m impatient but for something like Chronicler, I would say it would be worth the time, it’s truly an amazing app and I thank you for making something like this! It’s more than enough that you tried to make it available for Mac and got some people to access it.

Nonetheless, continue the hard-work, I’ll be cheering you on in the sidelines lol, but don’t go overboard, and once again, good luck on your graduation!

[Tevin]

Sounds like a really great tool

[Boodini]

Oof, somehow the Mac version does not work for me.

It just tells me “Chronicler-Next cannot be opened because of a problem.” whenever I try to open it.

*edit

Sorry, didn’t realized that Ephemeral posted the same thing earlier.

[BenSeawalker]

@Ephemeral
Graduation turned out just fine, thanks to your cheering no doubt

@Boodini no problem, it’s mainly my fault for the lack of communication.

@everyone
I’ve resumed work on Chronicler Online, but right now I’m helping several family members move to a different State, I’ve also got jobs to apply for, so I can’t guarantee regular updates just yet. It does feel good to be working on a project that personally interests me again, and hey, I guess I won’t have to spend time on homework assignments again unless I decide to go for my masters at some point, but I don’t plan on that anytime in the near future.

Again, thanks for your patience while I make Chronicler Online the absolute best product possible
-BenSeawalker

[BenSeawalker]

Hey all, I’ve started working on the new flowchart.

Originally I intended it to automatically layout the nodes for you. In other words, there wouldn’t be any interactivity other than moving the screen around and clicking on nodes to edit them. I intended this to save time on the part of the author.

Unfortunately, problems arise due to the fact that Choicescript allows for branching across scenes and looping paths back to previous nodes.
There doesn’t currently seem to exist an algorithm for laying out such a complex tree.
Undaunted, I came up with my own algorithm that simply sorts the nodes into rows below their “lowest” parent. It also ignores looping paths so it doesn’t get stuck infinitely moving nodes below each other.
It actually works fairly well and may actually look good when I figure out how to horizontally space the nodes.
It also doesn’t currently know how to handle nodes that don’t have any connections.
However, it just looks plain ugly with lines being drawn all over the screen and crossing each other and generally creating a confusing mass of information. There does exist algorithms to reroute lines so that they don’t cross each other, but it will take time to implement that and I can’t be sure the result will actually look any better.

Considering it more, I’m leaning towards making the flowchart interactive like it is in the desktop version. I plan on making it much more intuitive though.

• Double clicking an empty spot will create a new node at that location
• Nodes can be dragged to the desired location
  Simply clicking on them will take you to the node editor
• Nodes can be themed with a color, although to simplify things there will probably only be 5 or 6 colors to choose from rather than a full color picker palette.
• Nodes will be circular in shape with labeled connection handles around the edges.
• Connection handles are draggable to connect them to other nodes.
• Double clicking a handle will remove the connection.

I’m considering combining all scenes into the same flowchart view. They will be areas surrounding the nodes with a darker background and border. Scene names will be listed at the top where the scene currently in view will have it’s name highlighted. Clicking a scene name will jump to its starter node.
Zooming further out will hide the nodes and scenes themselves will be draggable. They will also have “default connection” handles that can be attached to another scene. This will be what happens to nodes without a connection leading out of them (unless the node specifies that it is an *ending). I’m not sure this will be more intuitive or not, but it eliminates the problem of visually representing connections between nodes in different scenes.

As I mentioned before, nodes themselves are merely containers for story text and choicescript actions that end in a link of some kind (*goto/*pagebreak, *if, *choice, etc.)
They will have a searchable “toolbox” on the side containing choicescript text and actions. Each one will have a link to the relevant wiki page for ease of learning and reference.
Components in the toolbox can be dragged into the node’s list or double clicked to immediately append them to the end.

Anyway, that’s it for the progress update. Let me know what you think about these ideas for the new interface. A simple like will be a vote otherwise post alternative suggestions

-BenSeawalker

[Chris_Conley]

I’d suggest allowing the user to add consolidation points onto the graph, kind of game-flow teleports. They wouldn’t have any code effect, like gotos or choices (although many goto/label pairs could correspond to them); their only purpose would be to simplify the graph visually.

Here’s the graph I made while I was writing the first chapter of Machinations, trying to keep it all straight. The boxes represented choices; the green circles are the consolidation points. Using them reduced the number of lines running all over the place, and also helped keep the gameplay flowing (mostly) from top to bottom.

[BenSeawalker]

@Chris_Conley

That’s actually a fantastic idea. I may reconsider the automated layout again and use those “consolidation points” to represent loops and links to other scenes.
I thinking that I’ll just add it as a button the user can push to auto-sort their layout if they so desire, but still give them the opportunity to manually edit it.

[Chris_Conley]

Interface idea: click (or double-click) on a consolidation point input to jump to and select the corresponding output point.

[BenSeawalker]

Just tossing ideas around in my head, I’m wondering if I’m going about nodes in the wrong way.
Really, what truly makes IF what it is is the choices that are made.
So what if the new program was entirely based around branches? By that I mean rather than choices being a component in a node, the choice itself is the major component.

For example: you click on a node in the graph, a radial menu pops up with “plus”, “edit”, and “delete” options.
Press “plus” and a larger radial menu pops up with the type of branch (goto, choice, if).
Select choice and a new choice node is automatically aligned below it with the textbox highlighted for immediate editing.
Type in the text of the choice then hit the “plus” button again. This time it doesn’t ask you for the type of branch, it simply appends another choice for you to fill out (which you do).
Select the first choice and hit the “edit” button. You are taken to the editing screen where you can change the text of the choice and add story text and choicescript actions as components.
Hit the save or cancel buttons and you are returned to the flowchart view.
From there you can add sub-choices to those choices and so forth.

Eventually you want to return to the main path so you select the final choice and add a goto branch. You can either choose an existing node to link to or add a new one.
If you add a new one then a label branch is added, you can then select the other choices and give them goto branches to the new label branch.

It may look something like this:

Inside each of those choices would be unique story text and actions such as setting variables.

I think this kind of hierarchical structure makes more sense and puts the focus on the branches of the story where it belongs. It also makes the flowchart more useful.

[Eiwynn]

That type of flowchart would help non-programmers visualize the CS bedrock code involved and allow them to relate mechanics to their story better.

[Chris_Conley]

Makes a lot of sense to me.

Maybe add a little button to press on each *choice to expand/collapse all of its #options together:

[BenSeawalker]

Dev Update 7/20/18

Progress is swift since I switched to the Meteor framework. (Yes, that’s right, I started Chronicler from scratch again haha). But fear not, since the decision to change the entire design of the flowchart view meant changing the entire data structure as well, this essentially needed to be done anyway.

I spent some serious time deliberating the usage of Meteor over plain old React/Redux and came to the conclusion that it was the superior environment. I’m still using React for the frontend UI design, but I’m doing all the backend data storage in Meteor.

Meteor takes care of user accounts and authentication including Google/Facebook login if one so desired.

On top of that, it uses a local database which automatically syncs up with the server, so if you lose internet connection temporarily you can continue working.
Note that if you close the browser/tab while offline, all changes made during that time will be lost. There is a workaround for this, but it takes quite a bit of time to implement and I’d rather spend my time on more important features.

Furthermore, this solves the issue of collaboration as any changes that are pushed to the server are immediately reflected in all related clients. I’m not totally convinced that collaboration is a particularly necessary feature though. It seems like most authors work alone and there’s nothing to stop multiple people from logging in with the same account so if you want to collaborate on a project simply create a new account and share the login info with each other.

Regarding further changes to the design. I’ve decided that I can abstract away a lot of Choicescript specific stuff such as requiring a scene named “startup”. A novice user shouldn’t have to know that, instead I allow creation of scenes of any name where the first one created will be linked to from the automatically generated “startup” scene.
I’ll also work on an intuitive stats screen editor separate from scenes.

I created Chronicler with the intent of saving user’s time, but the current version seems to actually make things more difficult and time consuming. The redesign of the flowchart mentioned in my last post solves this problem quite handily! It also solves a lot of the programming design challenges such as how to handle disconnected nodes and connection loops. Since it is now impossible to have disconnected nodes, and loops are handled by special links.

For the future, I don’t plan on releasing the new version until I’m satisfied with it’s aesthetic quality and I have it thoroughly bug tested. The initial release of Chronicler desktop was plagued with bugs and lacked many important features which drove a lot of potential users away. I don’t want that to happen again. I’d rather release a finished product like they did back in the good ol’ days of CD-ROM technology
That said, I may offer a limited beta-test for the aforementioned bug testing when I’ve implemented all necessary features.

I’ve said it before, but please remain patient while I make Chronicler Online the best product possible.
Thanks!
-BenSeawalker

[BenSeawalker]

Screenshot from the new flowchart:

Regarding concerns about how wide apart some of the upper nodes are, I currently haven’t implemented labels that would allow the flowchart to merge back together. I should have that done by tomorrow hopefully.

I’m actually surprised by how fast progress is being made. I don’t want to get your hopes up yet, but the release date may be much earlier than I anticipated

-BenSeawalker

[BenSeawalker]

It turns out that it’s easy to make a tree that always expands (like in my last screenshot), but significantly more difficult to get it to converge back together again (like in the mockup a couple posts back).

I’ve been considering various ways to handle labels. Each one can be considered a separate tree. So I’ve thought about making a tab view where each tab is the label. But that might become hard to follow when there are a lot of labels…
Another option is to have each label tree appear beside each other like so:

Then at the ends of each route would be a special “goto” node that points to one of the labels.
Of course this means a lot of sideways scrolling. I could also make the labels draggable so users could move them wherever they wanted them to be. (I think that would be a good compromise)

---

Consider: the following is roughly the shape of the first few choices in Choice of Dragon.

(converging lines added in via Paint…)

Here’s what it looks like with side-by-side labels:

And vertically aligned labels:

And this would be the most ideal and aesthetically pleasing layout:

---

Thinking about it, I might implement it like thus: every choice will have a “goto” or “finish” node below it. When you make the “goto” and set the label it links to, you have the option of choosing an existing label or adding a new one. The new label will be placed below the current tree.
If the label that is linked to is close enough in height then the goto node will draw the converging line to it.
The interesting thing about this is that one can have multiple labels side-by-side if multiple new labels are created from the same tree.
I think I’ll go ahead and see what I can do with this idea.

Glad we had this discussion
-BenSeawalker

[Chris_Conley]

As long as you can double-click on a goto node to jump to its label, I don’t think much scrolling will be a problem. (People do tend to hate horizontal scrolling, though.) Especially if there’s a minimap, say in a separate small window that can be repositioned.

[BenSeawalker]

Well, I managed to adjust my algorithm to produce this:

Note the overlapping lines near the end there…

---

I also found a library called “dagre.js” for laying out graphs and it produces this:

I can’t figure out why it lays out those two on the bottom so far to the left, but whatever haha
I can also adjust the lines to be smooth, but I kind of like the square ones.

Anyway, I think I’ll stick with dagre for the time being so I can focus on making the rest of Chronicler work as intended.

[BenSeawalker]

So, one of the things that I want to accomplish with Chronicler Online is to build a community where you can share your games, and learn along with others.

I’d have to check into the legal implications, but I’d also like to turn it into a marketplace where you can sell your games as well without having to go through the full CoG process. In the event that this is not possible, I may break away from Choicescript entirely. Don’t get me wrong, Choicescript is amazing and has a wonderful community behind it. One such that I wouldn’t have been able to summon the motivation to keep working on Chronicler without all of you.
That said, it really would not be too hard to generate my own rendering of CYOA games from the Chronicler dataset. And I could even allow for much more customization such as fonts and colors that CS does not currently support and even a builtin saving system. Another thing about CS is that it’s actually kind of hard-core. If you make a mistake you are basically forced to restart the game entirely. I could offer a feature where you could set waypoints where adventurers could return to if they didn’t like the outcomes of their choices.
I’m actually kind of interested in going this route (if I did, I’d still offer CS import as a feature).

Furthermore, I’d like to host a blog where users could write tutorials on CYOA novels, sharing hints and tips with each other to bring up the overall quality of work that is produced. We could even have a gig-job board where people could offer editing or art skills specifically for CYOA projects.

These things will not be available right away, but I don’t feel they necessarily need to be. Once Chronicler is fully released, users will need time to build projects before they can think about hosting them.

---

In other news I’m still putting a little bit of time into working on the Choicescript master-class that I plan on hosting on Udemy. I’ve got the first lesson planned out and partially written. This will be a comprehensive course that covers more than what you could just teach yourself from the wiki. Besides useful resources such as a CS cheat-sheet, it will include lessons on good practice coding guidelines/patterns and even walk you through implementing common things such as an inventory system in CS. On top of that it will be a general writing course with worksheets for characters, scenes, and overarching narrative structure. Ideas and guidelines for good character development, how to write dialogue that sounds natural, and more!. This is obviously a massive undertaking, perhaps even more daunting than Chronicler itself, hence it may have to wait until Chronicler is done.

---

Finally, most of the UI work on the Projects, Scenes, and Flowchart page is complete.
As for editing nodes, I envision a searchable panel on the side with all the components that can be dragged and dropped into the list (or double-clicked to quick add). They should also have links to the relevant wiki pages so you can learn what they do.

-BenSeawalker