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 hasa) 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.

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.