Davidw, just out of interest, I decided to go to your website. It seems that you have created about 40 games for ADRIFT and more are on the way (this was after a quick 3-4 page view). If you are so heavily interested in ADRIFT, why come to Quest?

I prefer Adrift, but there's been a definite feeling on the Adrift forum for the past year that the creator is kind of losing interest (or maybe that's just my personal feeling). There was a period last year when the latest release had a few pretty dire bugs in it that went unfixed for months. In fact, the latest release at this time has bugs in it that have been there for at least a month. A few years back, such bugs would be fixed in a matter of days. Now they linger for weeks and sometimes months and often the next release introduces more bugs than it fixes.

Added to that there's the fact that I've had several pretty heated arguments with a couple of the moderators on the Adrift forum and I'm really beginning to wonder if I might not be better off elsewhere. I thought about learning Tads 3 because that seems to be the new craze right now, but I don't have the patience for it. Alan is a possibility which I'm looking into.

And then there's Quest. I wrote a Quest game last year but I don't find the system as easy or straightforward to use as Adrift and nor is it as quick. I could write a game in Adrift in half the time it took in Quest and it would probably be better as well because I know Adrift a lot better. Added to that there's the Quest interface which is, sorry to say, about the worst one I've ever seen. I might write future games in Quest if it goes through several improvements but right now I'm still using Adrift.


Do I think Adrift and Quest should merge? There are parts of each has which the other lacks - Adrift is incredibly easy to use but doing complicated things is, well, complicated; Quest is potentially more powerful but also more time consuming. Editing the source code of an Adrift game isn't really an option at the moment (it's possible, just far easier to use the GUI); Quest allows you access to the game's source code which is a handy feature. Taking the best aspects from each and merging them into one system would make a far more powerful system than either on their own.


007Bond, there's no reason why someone couldn't use several different systems at one go. Adrift and Quest both use a GUI so making the switch from one to the other is fairly straightforward (or it was for me anyway).

merge? wtf?

I looked at adrift a while ago, but was disappointed to discover there is no source code for it, it's all binary. It's probably not possible to implement libraries with this system, is it ?
The system for editing games seems to be good, as good as the one in Quest, but since I enjoy to use both kind of edition (ASL and QDK) I don't think it would be to the benefit of Quest if the two projects merge.
And the authors probably wouldn't like the idea.

You can have libraries in Adrift via modules in V4. You write them in one game then export them as a module and import them into another game. Nice idea but it doesn't work as well as it should and there's also a size limit on them which means if you export a game to edit the source code (which is the only way to get at the source code), you might not be able to import it into a game file again. Hopefully this will get fixed in the next version.

As for the two merging... I doubt very much that is likely to happen. Adrift's creator has said several times that he won't let anyone else have access to the Adrift source code and when someone suggested on the forum the possibility of creating a version of Adrift for use on non-Windows systems, he turned down the idea.

But there are several things in Quest that Adrift could benefit from and vice versa. Maybe a merged effort would never work because each system is copyright to the person who created it, but perhaps a few of the better aspects of each system could one day be incorporated into the other.

Merging would certainly be a mission - more effort than starting from scratch, I should think!

What do people like about Adrift? I confess I quite like the map editor. I'm not too keen on the rest of the interface really - what is it that people like about it compared to QDK? Is it that it doesn't pop up so many windows? Is it that it offers more default behaviour for eating things etc.? Those are the only things I can think of - is there anything else?

Actually, when I talking about the interface I meant the one you use to play the games. Quest's default is bad - miniscule black text on a glaring white background. According to the options part of the menu it should be possible to set the size of the font to what you like but it never seems to work in the games I've played. I'm also not keen on the items and directions being displayed down the right hand side but that's probably just me. And the part where you enter your commands is so small that half the time you're squinting at the screen to see it.

As for the game writing interface, Adrift's just looks more organised. Each of the five main categories - rooms, objects, tasks, events, characters - is separate and this makes it easy to keep track of things. Quest lumps them into two - rooms and objects - with characters being counted under objects. Shouldn't they be separate? They are, after all, completely different things. Tasks (or commands) seem to be built into the individual rooms which makes editing each one a pain as you have to select the room in question then navigate your way through half a dozen pop up windows to edit the bit you want. With Adrift you just click on the task in question and edit away. Far quicker and easier. There's also the added problem in Quest that if you want a task to be possible in several different rooms, you have to write the task for each room as there doesn't seem to be an option to do it for several rooms at the same time. Adrift has this option.

And yes, way too many pop up windows. There's no reason to have more than one on screen. A dozen or more (and I've had a lot more before) is just too many and takes an age to open and an age to close. There's also an annoying thing I've found with the pop ups in that the cursor doesn't jump to the entry part so you need to either tab there or click on it with the mouse. Not a major hassle, but a pain nevertheless.

I like the MDI interface. It means that at most, yes, you will only have about 2 other windows open. But the fact that you can't get at the source-code of the games is a real downer. On the other hand, it has a whole heap of easy-to-use, ready-made commands, like open, close, lock, read, climbing, and stuff, without having to use libraries. I know TypeLib supports reading, but what if you want a system where you want the user to choose whether or not they turn the page? I think Alex, if there's one command you need to implement that hasn't already been implemented in Quest 3x, it's reading. Some people might not use it, but it saves us having to write custom commands, it'll save us from using look at or examine instead of read if we are bored, and it will give MaDbRiT more time to write other commands

Alex wrote:

What do people like about Adrift? I confess I quite like the map editor. I'm not too keen on the rest of the interface really - what is it that people like about it compared to QDK? Is it that it doesn't pop up so many windows? Is it that it offers more default behaviour for eating things etc.? Those are the only things I can think of - is there anything else?

I am not a big fan of Adrift, I've tried it but couldn't get my head around its way of doing things. I also really dislike the look of the player.

FWIW I think the biggest bugbear with QDK is how deeply nested some of the screens needed to build conditions and actions etc are. It is often easier to save the script out and do it by hand than delve down the seemingly endless succession of dialogs needed to use QDK!

I'm not sure that there's an easy alternative to the way QDK is done, but perhaps making QDK take up more screen real-estate and thus showing 'more options at once' (possibly greying out some areas) might be better? I know it is tricky to decide just when to have something open in a new form rather than becoming 'enabled' on the current form, but I feel QDK leans too much towards "opening a new form for everything".

As far as the 'inbuilt features' of Quest go, I'm with MaDbRiT - using libraries to add features is the way to go... "it is the chosen approach of TADS, INFORM, HUGO & Alan and I think it is as well to respect that considerable body of wisdom." (I think that's how he put it).

Things like MaDbRiT's typelib (and new 'typelib3.qlb' which I am beta testing) are the best way to give Quest more 'out of the box' features, hard coding too much is almost invariably restrictive.

All I have to do is persuade him to write a 'combat' library - and then do one for Quest.net...



SnakeCharmer

I would defenitley go for a combat lib. I tried making a combat "engine" for one of my single player games, and gave up, because it was too repetitive and too broing to keep going. I've also seen a demo of a game (can't remember the name) on the Games Archive, that used a fighting engine with timers and a health property, and didn't work to well. I think a lot of us would welcome a combat lib.

I'm with 007Bond on the custom commands side of things. I remember being surprised when I wrote my first (and only) Quest game that lots of basic commands I had taken for granted with Adrift weren't implemented. I couldn't read things unless I wrote a specific command for them; I couldn't wear items; I couldn't eat anything; there were so many others that I felt if I tried to cover everything that I thought should be covered, my game would have been three or four times the size by the time I finished it.

I found it pretty disheartening that incredibly basic commands weren't covered and I should imagine quite a few people have reached that stage and given up.

A series of libraries covering all these options would be a major move forward but I can't help wondering just why they weren't included to begin with.

This is a little late down the track of posts in this thread, but anyway:
What will happen when the guy who created ADRIFT becomes to old (passes away) to maintain the sourcecode and make updates?

He's only mid-20's so hopefully he's got a couple of years in him yet.

But hopefully when he gets bored of Adrift, he'll release the source code so others can continue with it. The idea that he release it freely has been suggested already a few times but he's said no.

I wonder if him being the age he is is a good thing or a bad thing. I think it's a good thing, because only he would fully understand the code, because he wrote it, and a program like ADRIFT would take an awful lot of coding. (Of course, if he's commented it, that's a totally different thing