I’ll keep it in the features list as a bonus feature.
Old enough to have Windows Vista on it 
It does have a quad-core processor in it and I might get an SSD for it if necessary. I’ll also upgrade the OS to either Windows or Ubuntu server. I don’t really anticipate millions of requests per second, so this should be sufficient to handle all the traffic.
As an aside, I’ve had lots of trouble with Windows 7 & 10, the two OS’s that people liked, but none whatsoever with Vista and 8 haha.
And will you be registering a domain names or will you rely on IP addresses?
The amazon server will of course have a name. But either way, I don’t believe this should affect the users since the address will be coded into the program.
I will probably use NoIP, it’s a service that allows you to register a domain name appended by .ddns.net for free, and by installing an app on your PC it keeps track of dynamic IP addresses. I’ve used it in the past and it works quite well.
I see, best of luck!
I’m kind of torn right now. Based on the toolset I’m using it almost seems best to just make the new version of Chronicler a website rather than a desktop app. HTML 5 appears to have features for allowing websites to work while not connected to the internet. This is very important as I know many writers that like to work while travelling.
Other benefits of a website are that it is immediately cross-platform even for mobile devices.
I wouldn’t have to worry about complicated software updates since all the user would have to do is reload the page.
It would be immediately accessible for everybody without them having to download and install an app.
Users wouldn’t have to switch back and forth between a browser to test their games.
So, assuming I can get an offline mode working, would a website be the best way to go?
For me, offline as in not having to go to a website, is important - unless I can take this HTML 5 website, put it on a stick and take it to a computer without a net connection? I have no idea how all that works.
But, I am but one irregular user, with a no doubt ever more outdated preference for stand alone programmes (one reason I dislike single-player games requiring online connection).
Agreed, I don’t intend to sacrifice usability for ease-of-access. I can easily provide the releases on GitHub which from the user’s point of view should be as simple as opening index.html. Of course, users who take this route will have to manually update.
From what I’ve been reading about “Progressive Web Apps” they are designed to cache everything they load for significantly faster response times and only update the cache when changes are detected on the server. The only issue with this is that a user would first have to visit every Chronicler page at least once before they could run it offline.
I think I’m going to go for it and let it be a website to begin with. It is relatively easy to then take that website and embed it inside Electron for a desktop version. This will allow me to take advantage of better development tools to produce a more polished project.
Sounds ideal then - offline downloadable HTML5 for dinosaurs like me and easier on you. 
But if Chronicler is a website, could it edit local files? Why not do it like cside and have both versions?
Earlier you asked about collaboration features. I’m all for this too. How about if it were wikipedia-like where anybody can make changes (instantly or requiring acceptance), but the owner(s) can accept or reject these changes. This would make it so there are not only co-authors, but betatesters could fix typos and provide comments and suggestions themselves.
I just read your post about Chronicler 2.0, and you mentioned pegjs. Wow, that sounds neat! Have you made the grammar yet?
Remember my attempts to make a graphical tree view of a game’s choices tree? That’s something I still look into from time to time, and it seems I’ve waited long enough that now there are the tools to do it, like d3. Of course, you might beat me to it with Chronicler. LOL. I read that you will be tracking stats. My old php code had the beginnings of this, and I got to the point that I was trying to detect times when the game might loop, updating a stat indefinitely. Have you solved this yet?
@Flurrywinde11 I really like your ideas on the collaboration features where they get put into changesets and the author decides what is and isn’t accepted similar to Git. This is brilliant, because I can’t tell you how many times a minor typo spoils the experience of a really great game, and being able to immediately go in and fix it would be fantastic.
I really am torn between desktop and website. The differences in development will be no more than some boilerplate JS code for launching and working with Electron.
However, making it a website opens up all the collaboration tools for everybody to use.
I don’t believe this is something that needs to be decided immediately.
As regards local files, my plan is to run everything from the server (unless the user is in offline mode). In other words, there will be export options to download your CS code as .txt files and your Chronicler project file. Since @dashingdon just added an API for the free CS web hosting, I will add “Publish” options for pushing your game out to his server. Most of the time you will be working online and it is best if all changes are simply stored there.
To import existing CS projects you can upload cs .txt files that will be translated into the new format.
As for toolsets and things such as pegjs, I have decided to switch from React.js to Elm. Elm is a reactive functional language that compiles to JavaScript. The really neat thing about it is that developers end up writing much better and maintainable code because they are forced to by the language. For example, you send out an HTTP request and it sends out a bunch of commands that are later parsed into receiver messages that handle cases for when the data is loading, successful, error, etc. Elm forces you to handle each of these cases, meaning nobody can forget to put a loading spinner when it is retrieving data, or get null reference exceptions when an error occurs that isn’t handled.
I’ve been playing with it for about a week now, and am ready to branch out on my own and start implementing some of the components for Chronicler.
Elm also looks like it makes it super easy to write a context sensitive parser for other languages. I’ll let you know when I’ve got a decent looking CS parser made.
As regards algorithms, I’ve structured my data model in such a way that it is really easy to traverse the game flow with recursive algorithms that never have to go more than 2 or 3 levels deep. I’ve already written and tested most of these in JS. I only have to convert them to Elm code now.
If you are curious, I made this Visio drawing showing how a project might be structured. It is not complete, but is a good overview of it.
One of the algorithms checks for loops in the game flow. The code is available on GitHub. The relevant file to look at is src/core.js. To get it going you need Node and NPM installed then simply open the folder in your cmd prompt and enter “npm install” then “npm run test” to see the results of the unit tests. There is no UI as I simply began working from a tutorial template and decided to flesh out the backend before worrying about the frontend.
Aw, but then I cannot run it offline, can I? Or how does it work? Can I ‘download’ the page and transfer a working copy of Chronicler 2+ to another, internet-deprived computer? 
I have no clue about these things. 
As regards local files, my plan is to run everything from the server (unless the user is in offline mode)
The nice thing about Elm is that it forces me to account for cases where network requests fail. In those instances Chronicler will adapt and store things locally. Assuming I decide to go the Electron route for the desktop version, I can also detect if it is currently running in an instance of Electron and if so use file dialogs rather than server storage.
I’m seriously considering going with Electron, and allowing users to login with an account. When logged in it will attempt to backup the project to the server, and allow them to edit other public projects assuming they have an active internet connection.
Online backup can be disabled in the settings, and it won’t even attempt to do so if the user is not logged in.
New projects will have the option of being public or private, and will default to private when the user is not logged in.
Private projects stored on the server will be encrypted whereas Public projects will not.
I might also add a Protected state where the project is still encrypted and the author has to invite users before they can see or edit the project.
As I said, I am well aware of how important an offline mode is. 
So, er, that’s a ‘yes’ to it can be downloaded and saved onto a stick? 
Awesome. It is a win-win then!
Can the local version be made to have the same collaboration tools?
Will there be automatic restructuring if a node has more than one parent?
I’m excited about all these developments!
(P.S. I filed an issue on git. Potential bug with Chronicler on Ubuntu 16.04 · Issue #79 · GarrettFleischer/ChroniclerQT · GitHub I’m trying to get v.1 to run on Ubuntu.)
@Flurrywinde11 I saw the issue you posted this morning. I apologize, but I’m not sure what to do about it right this moment 
I suggest you give Linux Mint a try though. It’s my favorite Unix flavor so far. (:
I’ve decided to go desktop with electron, and yes it can have the collaboration tools builtin. I was trying to think from a reader’s standpoint rather than a developer’s. If I saw a typo and wanted to fix it, I would be less likely to take the time to download a program, than to simply submit a quick fix on a website. I don’t know, as I said it actually makes little difference from a development standpoint. If I ended up also making it a website, it would have the bonus of being accessible by mobile devices as well. I’d have to think about the interface some more to come up with a good solution for small screens however.
Regarding your second question, that Visio drawing is how the underlying data model is structured rather than how the node graph will look. There’s an algorithm in src/core.js that calculates the order and moves nodes below their lowest parent. It also takes into account circular loops so it doesn’t get stuck constantly moving the nodes below each other.
Hey all, the mockup image in this post worked under the idea of users drag’n’dropping pieces from the toolbar on the side to the middle. Having recently worked on another app that had DnD for the interface I can safely say it was not fun to work with. Lots of extra movement that quickly became extremely tedious.
Instead, there should be cells containing “+” buttons in all the areas where new pieces can be added. When clicked on they bring up a sortable and searchable dialog of components that can be placed there. When the dialog is brought up, the search box is automatically highlighted so you can immediately begin typing the piece name you want. It will also have a short list of recently/most used pieces.
I think there will still be drag’n’drop for reordering components in the list. The distances will be less, and the mechanics familiar from other apps. Also, reordering happens less often than adding new pieces.
UI Changes
I plan on getting rid of all the tab views in favor of a single view that can easily be navigated.
It will have a small preview in the top left that brings the node view back up to the represented item. By preview I am thinking something similar to a minimap as seen in most games. It will be small until hovered over whereupon it will expand slightly for a clearer image.
When in the node view it will show a mini version of the flowchart with the current node highlighted.
When in the scene view it will show the list of scenes with the current scene highlighted.
When in the list of scenes it will show the title image and be a link back to the dashboard.
I’d like to make a really cool animation for it so that when it’s clicked on it expands to fill the screen, or slides up to the other view, or zooms out of the current view to see the bigger one. I’ll decide on that later when I’ve got a better grasp of how animations work in HTML.
Variables
Variables will still be in the toolbar to either the left or right. It will slide in and out as needed. Variables will be much better laid out and divided into sections for scenes and global. Again the + buttons in relevant locations will be the way to add variables.
When selected they will have a trash icon on the left. Clicking it will delete the variable immediately if it has no usages, else the sidebar will change to become a list of links to all the locations it is used in the game and you must fix each of these before you can confirm the delete.
Dashboards
There will be two layers of dashboards. One containing an overview of all the projects you are working on or are a member of. They will be in private, public, and protected sections. This is related to the collaboration tools I will get into in a minute. There will also be access to the Community view where you can search public projects.
Then there will be the dashboard for each specific project.
This will contain options to change your project from private to public and vice-versa. There will also be an “invite collaborators” button.
All projects will have the settings for title text and image, as well as the summary. New projects will be filled in with some boilerplate text that seems to be common to all the CS games I’ve played. From there will be a link to the scenes view.
If it is a public project, there will also be a list of submitted changesets from other users. They will be roughly grouped by which parts of the project they modify.* (see “Regarding collaboration tools”)
Protected projects will only have collaborators and changesets will work slightly differently for them.
Online/Offline
Hopefully this section will address all nagging concerns about Chronicler’s online features.
All project data will be stored offline locally on your individual computers. This data will then be synced with the server.
This means Chronicler is not bound to the internet in order to run, but when it is connected you can rest assured that your project will be backed up, and can be used across multiple devices.
To facilitate this functionality there will be an icon to the left of the user profile in the header bar. This icon will show a green check-mark when pending changes are synced to the server, a loading spinner when changes are being sent or received, and a “no connection” symbol when no connection can be established.
Clicking on the “no connection” icon will show the options: “retry now (5s)” and "switch to offline mode.
The “(5s)” shows how many seconds remain until the next automatic attempt to reconnect occurs.
When in offline mode, Chronicler will not attempt to automatically connect.
I’m not certain how to handle user accounts in offline mode. The best way I can think of would simply be to encrypt user data with a password similar to what 7zip allows you to do with zip files. Note that local encryption will be optional in the settings.
Regarding collaboration tools
This is probably the most complex part of the entire project. As such, it will be put on hold until the core features are complete.
(nodes are the new name for bubbles, and components are the pieces that go in them like text, actions, and choices.)
Public projects will be featured on the homepage and searchable by anyone including anonymous users without an account. Collaborators can be invited to public projects.
Private projects are exactly what you would expect. Only you can see and modify them.
Protected projects are simply private projects that have collaborators associated with them.
I will use the term “user” to refer to non-collaborators.
Users
When a user wishes to modify a public project they will have full access to change whatever they wish with the project. This includes adding new nodes/scenes, and modifying text. Any changes they make will be put into a “changeset” and submitted to the server. When submitting a changeset the user will be able to include a message explaining why they felt the change was necessary.
Collaborators
When a collaborator modifies a project, their changes are immediately committed. If they make modifications to another’s work, then a changeset is added to the project. This changeset does not need to be confirmed by the owner, however a notification will appear. All collaborators can view the changesets, but only the owner of the project can revert to a previous changeset.
Regarding ownership, collaborators can own components and can own or co-own parts of components.
For example, a text component in a node was created and partially written by Sally. Bob comes in and completes the other half of the story in that box. He also fixes a couple of typos Sally made while she was in a hurry.
The question here is: who owns what?
Sally and Bob now co-own the whole component. Any changes to it by other users will result in a changeset.
Bob now owns the half of the component that he wrote and co-owns the typos he fixed. Even though Sally owns the whole component, any changes she makes to Bob’s text will result in a changeset.
If Bob makes further changes to the half he owns, there will be no changeset.
However, if either Bob or Sally modifies the typos that they co-own then a changeset will be committed.
Changesets will be grouped under the component they are in.
Owners
When the owner logs in they will notice the “messages” icon in the header bar shows that activity on their projects has occurred. Clicking on it will take them to the changesets view for the relevant project. From there they can view the changesets either grouped by user, or grouped by change.
When grouped by change they will be presented with lists of changesets that modify the same places, and ending in a list of changesets that are distinct from each other. This way they can quickly switch between changes to the same location and accept or reject them as they see fit. Of course the owner can modify the location manually and accept that as the final change.
When a changeset is accepted or rejected, a message informing the submitter will be sent so they can see what the final verdict on that section was.
Besides modifying the project directly, users and collaborators can leave comments on scenes, nodes, and components.
Closing thoughts
Personally, I’m super excited about the collaboration tools, as that could result in some truly epic community games. However, I needs must stave off my excitement for now. I’m working on this for my Senior Project at Uni, and we are only given a short amount of time to complete it. As such I have to focus on the core features that I specified in my proposal to the professor.
I plan on drawing up some new mockup designs for these features. Stay tuned for them in the coming weeks.
I have already started converting my project from JS to Elm and am quite pleased with how that is going. Not only does the Elm code take significantly less lines, but is safer and easier to maintain. Another benefit is that it is pure functional. This means that any functions when given the same input always return the same output with no side-effects. This allows for the Elm backend to cache function calls so that when they are given the same arguments a second time, it can simply map them to the result without performing the calculation again. In this way the program will get faster the longer it is run!
I could honestly sing Elm’s praises for another hour, but I better sign off here. 
Thanks!
-BenSeawalker
Hey all, just a status update to let you know work is progressing on the new version of Chronicler.
Somewhat tragically I was forced to stop using Elm. It is simply too new and lacks support in terms of both documentation and third party tools. Being in beta stage it is also likely that it will introduce further major breaking changes down the road, and that is something I’d rather not deal with trying to fix.
The good news is that the React/Redux community has grown exponentially since I last looked at it, and it shares many of the same concepts as Elm. Perhaps the only difference is that Elm has more type safety built in, but this is mitigated by WebStorm’s Lint integration.
Further good news is that since elm basically compiles to JS, anything that can be done in Elm can be done in JS, and JS has more features that Elm simply doesn’t.
Progress
So far I have implemented a unique id generator and undo/redo history. The great thing is that the undo/redo history is done. It will require no further modification, and will flawlessly handle any changes you make to the state!
I also have a basic node view implemented that allows for drag’n’drop re-ordering of components.
Glossary
Nodes are roughly equivalent to Bubbles in the current version. However instead of being specialized based on type, they are merely containers for Components.
Components are the actual CS pieces. Such as text boxes, choices, and actions. They are contained as a list in Nodes.
See the mockup image from previous posts.
Next up is to finish the Node view, once this is complete I can simply translate my CS parser into JS to get basic project importing.
After that I can hook it up to @dashingdon’s epic API.
Then I’ll make the Scene view that shows the graph of nodes. I will attempt to learn the D3 graphing library for this.
Once these features are complete, I will work on user accounts and online backup of projects.
After that it will simply remain to do the busy work of making everything look pretty with smooth animations.
Look forward to further updates!
-BenSeawalker