Misconceptions
Here I list some misconceptions one might have about QML. Read on if you're unsure whether or not this tool is the right for you, or you just want to get a clearer concept of possible uses.
It has to be played online, using an Internet Explorer browser
Actually, QML;
- can be played offline
- can be played in any browser
- doesn't even need a browser in some cases
QML itself is platform and media independent.
Playing it online using a browser is likely to be the most common use,
and using the client-side version instead of the server-side version
a possibility (then one needs the Internet Explorer),
but it's not restricted to that.
All that QML does is let you lay out the
stations and their connections and states
and this way can be interpreted
in a lot of ways and exported to other media.
E.g. QML-Edit has
a special Print View functionality that is optimized
for putting the quest on paper. Or you can export it to static HTML.
You can also put up the server-side interpreters (PHP, VBScript or Pyhthon)
that will run on the exact same data files provided. Or you can
provide a download to the players to have them run the quest offline.
It's for multi-user adventures
There are no plans to bring this to QML in the near future, even though I think it's an interesting topic to think about. Even before thinking about implementation issues I have to ask; how could multi-player add to a game, and by which syntax could it easily managed by the author? Just imagine the author creates a world in which there's a certain special item needed to do something. How can the game be finished by others once this item is taken by a player?
Another possible scenario that should be easier to solve is group decisions for what choice to take, by voting. As a matter of fact an author wouldn't even have to rewrite any of the QML, it could be implemented with existing data by writing an interpreter to handle this.
... and it's multi-user created
There are many websites that let users read a story, and when they arrive at a dead end, they can contribute new options and thus make the story grow. I think it's a good idea (it has its pros and cons compared to single-author creation), but QML/ QML-Edit itself don't natively support this. However, you could still use QML as the underlying data format for such a structure (in fact, I encourage you to give it a try).
A completely different issue is teamwork creation. Since QML supports clean state resetting and chapters, a team of authors are enabled to create seperate individual chapters or closed settings of a bigger world, that are then connected to a linear, or network structure.
It's another way of doing text-parsed adventures
I like text-adventures. But QML cannot -- isn't intended to -- parse complex user input and retrieve information. If you want to write a text-adventure in the spirit of the Infocom games like Zork Zero or The Hitchhiker's Guide to the Galaxy, there's already several good tools out there. (See the links section.)
What QML can do is to have user input in certain situations where it's needed to e.g.:
- Get a password
- Ask a character about a certain topic
The point here is that a multiple-choice display would give away a password, or make a choice that's needed for a puzzle too obvious.
Using text-input you
can also create bottleneck situations in which you make sure the player understood
what's happening: e.g. have somebody ask "What do you want to buy?" and so make
sure the player already has
a) a need for this item and
-- what might be more important, since you can't check that by setting states --
b) actually paid attention to
the story.
QML is for doing adventure games
That's one use, and probably the most common one. But QML is not restricted to that. On purpose did I not include words such as "room", "item", "path" and so on in the syntax, because even when those might be more common in text-adventures, that would have put QML into a certain restricted category. Thus you can think of a QML "station" as a room, an event, a function, a time of the day, a single page, and so on.
... and it has ready-to-run battle algorithms, bag items, auto-mapping
By design I try to keep QML as unspecific to any genre as possible to not push
authors into any direction.
In QML, it should be as easy writing a trivia game, an intranet questionnaire, and a surrealist,
out of this world dream sequence, as it is to write a cave with a treasure chest.
Therefore, you won't find any ready-to-run battle algorithms and monsters, there's no player inventory like a bag, and there's no automapping of movement in directions like north. Nevertheless, most of these things can be fairly straightforward to script in QML using states, number, and strings, as well as the dynamic CSS positioning and so on. In fact, implementing things like a battle-system should be a challenging and fun task to do, and I'd be thrilled to see working examples.
In any case, you might want to check out the battle sample on the examples page.
Data oriented vs. behavior oriented
QML will always make it easy to create data-oriented quests, with added scripting support. If your quest requires a lot of functionality (maybe even file system specific one), but has practically no data, you should ask yourself if this is the right tool -- you won't find it easy to have database connections, user data validation, file access, and so on. As a matter of fact QML2 in the VBScript-interpreted versions has no XML-triggered mechanisms to write to anything in any way. This is also a security issue since everybody should be able to exchange and run QML files without risking to have anything bad done to the operating system.
QML creates good quests
Does QML make it very easy to create good quests? No.
When you've got a toolset solving many technical problems,
you won't be able to tap yourself on the shoulder just
for making it work, and the tasks ahead might actually appear bigger than before.
There's nothing left but to focus on the actual
content and game dynamics. A good adventure still needs
to be designed and fleshed out in professional
writing. Text lengths and choice quantity have to be balanced to not make
a quest become boring. Game play needs to be fair, ideas need to be original.
QML does not and never will automatically generate meaningful content,
and there's absolutely no intent or possibility for this language to replace good author
skills.
QML doesn't create good quests; you do.