QuestKit will consist of the following components:

- compiler (questkit.js)
- Core libraries (core.yaml, core.js)
- player UI (index.template.html, style.template.css, ui.js)
- language templates (en.yaml, etc.)
- editor
- documentation

To develop these, work is split into the following projects:

- Migration of Quest 5 Core libraries
- Migration of Quest 5 language templates
- Implement player UI
- Implement editor
- player UI state saving and undo
- unit testing (this is new - Quest 5 has some unit tests, but we can unit test all of the Core libraries when they are in JavaScript)
- end-to-end testing (some way of generating example/test games and running walkthroughs)
- write documentation, tutorial

There are some features of Quest 5 that we shouldn't need to migrate. I'm planning to add the ability to show Squiffy-like sections and passages ("pages", I suppose), which will make it easy to have gamebook-style parts of a game (like conversations). This means we shouldn't need the following:

- "wait" should be unnecessary, just go to a page with a "Continue" link
- "get input" also is unnecessary, if we can create pages that have an input prompt
- "show menu" - just show a page with a list of links instead

We want to deliver something as soon as possible - some kind of MVP - so we can iterate on that. But quite a lot needs to be in place before we can create a minimally useful release.

I propose the first release of QuestKit will be a command-line only program, much like Squiffy 2 currently is. It will implement much of Quest 5's core library - some usable subset of it anyway. It will generate games that will save and load to local storage, with a fairly basic player UI.

Later releases will, in turn:
- finish migration of the core library
- migrate the other language templates
- implement a simple text editor for web and desktop
- flesh out the rest of the editor
- add an API to save game state to a player's textadventures.co.uk account, so they can resume on another device

Then we will finally have something that replaces Quest 5, while hopefully shipping often enough to gather useful feedback.

So, for the next step, I'm going to be migrating the Core libraries and implementing a basic responsive player UI. We can split these projects up if anybody wants to volunteer their time and skills - let me know. Otherwise, I'm not planning to look myself into any of the testing stuff just yet - I know Jay is interested in this, so perhaps he can share some thoughts here about how this side of things might work?

When saving will the complete game be saved like now or do you think of something new?

No, it will just save the changed attributes.

I'll be happy to contribute what I can toward the testing. I think we should ultimately ideally strive for
- total code coverage. So if any line of code changes that breaks a feature, we'll know right away.
- fully automated, to the extent possible. If we make the tests easy and quick to run, then we'll run them!

Of course, those are the ideals. But it's good to have something to shoot towards. I want to avoid the case where we add a new feature and unwittingly end up breaking something else, and then users end up finding it in their code. Also, as the code becomes larger and more full featured, it will be more and more difficult to manually test the entire system. Finally, the tests provide not only sample code for the APIs but provide a form of living documentation. If you want to know how an API works, go look at the tests for it.

I'll look into mocha, to make sure it's able to be automated (and how easy). I'm figure it must be, but it would be good to be sure.

I do think some kind of "show menu" will be useful, even if it's just a convenient way to output HTML links. A menu might not be able to be statically defined in text. Also, assuming there is a parser, you'd want a menu to be somewhat modal, the coding of which is probably beyond most novice authors. Of course, once we have the framework, then this stuff can be added as libraries/modules.

Oh yeah - a library/module mechanism seems to be a must (even beyond the core libraries). That opens things up to users growing the code base. I know people can always insert <script> lines in their Javascript, but the more user-facing interface should make it as easy as possible.

You may be right about "show menu"... the parser will need to be able to generate a list of links for disambiguation anyway. Although this doesn't need to be modal (it hasn't been modal in Quest since maybe v5.3? You can sort of ignore the in-output disambiguation list and type some other command instead).

Yes, it would be great to provide a way of making it easy for people to share code via some kind of library/module system. I'm open to all suggestions!

Hello guys,

I know this may seem a bit simple minded for you that really understand the coding going on behind the scenes. Yet, I wanted to ask if games made now would be fully operational on a new system such as the one you guys are planning on designing. I am planning my first game and I am having many roadblocks come up. All the time it takes a new game author to get used to the system is sizable. I wanted to know if it would be worth my time to jump in now or wait until the new platform is available. I have almost zero coding skills and guess that using the gui could be a good learn as you go thing.

I plan on making games for learning languages but want to make sure I won't have to simply redo the games once the system is updated.

Thanks for working on this system. It will be a great help in learning and teaching languages.

Given that QuestKit is in the beginning design phase, I can't imagine there being a fully usable system for quite a while still. And I can't imagine the current Quest going away either, at least not for a *very* long time. I think if you have the interest now, jump into Quest and get going with it! The concepts you learn will translate whenever the new system is in a releasable form. I don't know if games will be directly convertible, but I don't know how relevant that might be for you anyway - nothing is going to stop your Quest 5.x games from working in the future, and by the time you outgrow the current Quest, the new one should be ready for any future games you might want to create.

Thanks for the quick reply. I have been working on the ideas for a while now and quest in its current form seems like it will do the trick nicely (though some of the upgrades for the new one will be great later as well.) I will continue on and hopefully learn some coding along the way.

By the way, many of the pics in the help files are broken. I would looooove it if someone who could re-link them would give it a look.

Thanks again.

Does this new system mean that we will be able to translate the whole quest to others languages, interface included, 100%?

Yes, you'll be able to completely customise the interface by editing index.template.html: https://github.com/textadventures/quest ... plate.html

It will be translatable by default though, just like Quest's interface currently is.

I'm actually pretty excited about the proposed new system for Quest. I have a couple of questions in regards to what will be possible to do with it in terms of finished products, however as I have a couple of projects in mind that I'm writing out that have fairly specific requirements.

1. Will it be possible to have the Quest input/output and parser inside of a canvas element that simulates a terminal, i.e. like the Infocom games of old - similar to how a library like rogue.js creates a virtual terminal in a canvas element for the text-based graphics. If I'm not explaining myself correctly, Jay will know what I'm talking about and should be able to articulate what I mean better.

2. A persistent menu in lieu of a parser? Similarly to how text adventure games have been handled on gaming consoles, where there is a persistent menu on screen at all times with a list of context-sensitive actions based on your current situation (i.e. Phantay Star 2 text adventures for genesis/sega cd, phantasy star adventure for game gear, etc.) I know Jay has a library he's been working on that does something like this, but I'm thinking like where the parser would be replaced entirely and the list of commands would have some kind of a highlight bar that could be moved over the various choices by the arrow keys or even say by a gamepad, and then accessed by hitting enter or pressing a button.

Now that everything is going to be JS based I know it would be possible to hack this stuff in even if it wasn't specifically supported, but as a graphically-minded person I like the idea of having total flexibility in terms of presentation to the user because the UI usually factors heavily into my vision for a game.

Ugh. Just as feel like I'm getting good at Quest5, the rug's pulled out from under me and boom, new learning curve. I can just imagine, new rounds of bug reports about drop-downs on the UI not addressing the interface, features dropping out... Good luck on questkit. I think I'll just sit in a corner and quietly write quest5 games for myself. I was really hoping ... doesn't matter what I was hoping.
Good luck with QK.

Again, Quest 5 isn't going anywhere.

QuestKit is simply the next major version of Quest - there are always going to be big changes in a new major version, because that's what a major version is!

We've had a big transition like this before - Quest 5 was itself a complete rewrite, and didn't share very much with Quest 4. This time around, you should find more familiar in QuestKit, because it is based on the same core library as Quest 5.

It's going to be a long time before QuestKit is ready, and Quest 5 will continue to be supported, so you won't have to make the transition if you don't want to. But hopefully you will!

I'm excited about the new QuestKit! I'm just sad that it won't be ready before the next IfComp because I intend to enter this year with the sequel of Dream Pieces

I'm excited as it appears we'll be able to write for mobile devices more easily.