I've written a quick blog post about Quest 4.1, which I'm working on at the moment:

http://www.axeuk.com/blog/2009/02/13/qu ... ming-soon/

MUDDAFLUXING AWHSUM!

Will it auto-convert old games with the messy |bcodes|xb to pretty stuff or do we have to do it manually?

Also, I see this as a chance to get some input into the new version.

Corrections and Bug Fixes

* In the Quest Documentation, under QuestNet Server User's Guide the QuestNet Editions lists Quest Pro as $99.95
Yes, there are more, but I am no coder. I'm just reporting what I see.

Improvements and Future Requests

* Importing.
A way to import Images, Music and other files and implement them into your game *without* the ugly listing of the files in your game directory - or to at least be able to use them from sub-folders. Yes, you could say that you can just throw them into the directory of your game and then specify the path, but that is way too annoying for anyone to use. Very few games have ever used it before. An import system would be lovely.
* Combat System.
An easily modifiable Combat System. As I mentioned on the ElexEngine thread, you should be able to change the following.
- Combat Type: Turn Based or Realtime
- Combat Variables.
- Stats
- Strength, Agility, Intelligence etc., and the game creator has the ability to modify the names of these variables and the effects they have on gameplay. (eg, a rock is in the middle of the road. If the Strength Variable is equal to or greater than 5, the player can move it // If the player has a sword that hits 10 damage, and has a strength level of 5 then the sword hits 15 damage, but if the player has a skill level of 1 with swords he can only hit 12.)
- Weapons
- Tools used by the player to defeat his enemies. The game creator can change their damage, name, description, and the skill level required to use them effectivly, as well as implementing stats (5 Strength increases damage by 5,etc.).
- Levels
- The experience a player gains by achieving certain things specified by the game creator. These levels can unlock other things (eg, New Abilities, Items and Areas). The GC can change how much exp is required for a level up, or just turn the whole thing off.
- Abilities
- These can vary from throwing fireballs to farting jellybeans, and can be changed to be either bought with another numeric variable (eg, Gold), awarded freely for achieving a high level, etc.
* Weather.
Rain, Shine or Snow, players want to play. And the weather is never the same. The GC can change how often certain Weather Effects occur, and what their effects are.
* Time.
What's the Time, Mr. Wolf? Time can change heaps of stuff, (eg, meeting deadlines, making enemies come out after 8 o'clock, etc.)

---

Comments and the such are welcome!

Thana

Quest is for text adventures, not just muds. We'll see how my engine does when it is done.

I have absolutely no idea what a mud is. And adventures usually have some form of violence in them

MUD= multi-user dungeon, the forerunner of the mmorpg genre. Multiplayer text based rpgs basically. See Wikipedia for more

Last I checked a game doesn't have to be multiplayer to have a combat system

Single player combat systems are rare since there is usually little attraction to them.

Usually, the people who play text adventures are more after the description and story of a game, rather then any battle-based game (which is sort of what battle-system games are based around: raising stats).

Thanatos wrote:
Will it auto-convert old games with the messy |bcodes|xb to pretty stuff or do we have to do it manually?

It's still the old formatting codes in the background, so it will convert to/from automatically. There's a "show formatting codes" button you can toggle so you can see the underlying formatting codes.

* Importing.
A way to import Images, Music and other files and implement them into your game *without* the ugly listing of the files in your game directory - or to at least be able to use them from sub-folders. Yes, you could say that you can just throw them into the directory of your game and then specify the path, but that is way too annoying for anyone to use. Very few games have ever used it before. An import system would be lovely.

You can put stuff in subfolders already, just use the relative path in your script command.

In QDK 4.1 you will be able to click a "Browse" button to find files more easily. They will be automatically copied to the same folder as your game.

* Combat System.

I have no plans to implement a combat system in Quest, ever - that's what scripting is for. I can't think how I could make a generic combat system that would be easier to use than just scripting it yourself, unless you have any better ideas?

* Weather.
* Time.

Again, easily scriptable yourself?

Alex wrote:easily scriptable yourself

But we shouldn't *have* to. Quest is about being able to make a game "Without any prior coding knowledge."

You mean you can't learn from scratch?!

Thanatos wrote:But we shouldn't *have* to.

I Think It is looking awesome Alex, That's what Quest needed was more Text options and easier
since it is a Text game engine.

Good work.

*shrug* Agreed

Alex I Still say if you can add some kind of room refresh option, so that we can easily refresh the room
so that vars can be updated but nothing else gets changed.

Don't they auto-update when they are changed?

The vars do auto update but not the rooms, therefor the player
cannot see any changes unless the room is refreshed.

How about the problems with .asl / .qsg? Are they fixed?

Just a few:
- .qsg files grow without limit because they store obsolete data.
- Conditions with mixed AND / OR don't always work correctly.
- It's impossible to exactly compare two strings for equality.


How much of Quest's features are written in .asl and how much is done in VB?

I'll fix the QSG problems in version 4.1.

Mixed and/or is a bit of a tricky one because of the way this is handled in Quest at the moment. You can't nest expressions within brackets, and there's no point in overhauling the "if" statement if it can't do brackets as well. So, this will have to wait until a bigger overhaul of ASL.

Not sure what you mean by the string comparison - if it's just whitespace that's the problem then you can always do "if ( .#blah#. = .#something#. ) ...". Not pleasant but it should work.

Basically none of Quest's features are written in ASL, except if you're using net.lib or stdverbs.lib.

Everything else is VB6, of varying degrees of whackiness. (Yes, I was 16 years old when I started Quest, and some of that code lingers and makes me want to cry)

So, the code

enter <var>
if ( .#var#. = .#var#. ) msg <This always occurs.> else msg <This never occurs.>

will always prompt the player for a single string, then print out "This always occurs.", and have no other effects?

As far as I know...

What if the player enters one of:
- ";lt;"
- "$rand(1;100)$"
- "$getobjectname(book;game)$"
(where there are multiple books defined in the game)?

Interesting... There are two separate things happening here:

- ";lt;" messes with the "is" function as internally "if (#var#=#var#)" becomes "if is <#var#;#var#>"
- When a string variable contains a function call, the function is executed because Quest evaluates string variables first, then functions - this is so you can use string variables in function parameters. But a side-effect is that if the string variable contents itself looks like a function call, that function will be executed.

I introduced an expression handler in Quest 4.0 which currently is only used for simple addition, multiplication etc., but which handles nested brackets. I could extend this to handling "if (...)" and also for evaluating functions and variables - this would be more robust than the current approach, and allow for more advanced (and nested) "if" expressions.

This would be beyond the scope of Quest 4.1 though - I'm trying to keep the changes to Quest itself fairly minimal for this version, as the bulk of changes are behind the scenes in QDK. I'll add it to the list for the version after.

What exactly is *on* this massive list you have

Have you tried studying context free grammars and rewriting your expression handler (or better still, the entire .asl handler) using one?

I wondered how long it would be before you brought that up again

I don't think I get what a context-free grammar is. Wikipedia is certainly unhelpful. From what I can tell from other pages, the existing expression handler is context-free? Albeit limited in that it only supports + - / * operators at the moment.

("if" doesn't use the expression handler "properly" at the moment - it calls it separately for both sides of "is <a; b>", whereas if it were clever then it would just have additional operators "=", "and", "or", "not")

Form a context-free grammar, and it's possible to give that to a program like yacc, which will create a parser for your format.

Read a good book on compiler design and that will explain everything.

One of the most irritating of all time is the fact that, to work around the simplicity (or lacking features) of Quest, you NEED to use references... BUT YOU CAN'T!!

Ie, to get a viable, text-based menu system up yourself you can either have a very large function/procedure with hard-coded menu options, have a game FILLED with objects which are meaningless apart from 2 or 3 properties, and adding a WHOLE degree of over-complexity into the mix, or have a load of number-based fugly arrays which are even harder to decode (but nicer to try to decode IMO).

This is because, if you want to use variables to hold you options would would need to do something like:
##var#[i]#

Of course, #(var)[i]# doesn't work since it's not an object.
#%var%# doesn't work either as %'s aren't evaluated inside #'s anymore (when did THAT happen?) - debug shows "no string variable '%var%' ".

This is also helpful if you have a string, or SOME strings, which your want to come out based on TEXT rather then NUMERICAL data (again, you can do this using arrays and number references but this is SO ugly it's MORE likely to do damage then you would allowing text references).

Oh, and how about combining procedures and functions since they do basically the same thing, and I only remember VB having a difference between the two (which wasn't actually different).
It get's rather annoying having to choose one or the other purely based on how I'm going to call it (using do <> or $$).
I should be able to use either, except do <> throws away the answer (perhaps into the DEBUG log).

See, this is why I never bothered to learn code!

There will be any support in QUEST 4.1 for spanish language ???

It will support languages in the same way as Quest 4.0, so if you have a "spanish.ldf" file that will continue to work.