ADRIFT Forum


The place to discuss the ADRIFT Interactive Fiction toolkit

The real limits of ADRIFT.

This forum is the place to learn about and discuss ADRIFT 5. Feel free to mention any bugs you find here, but please also add these to the Bugs & Enhancements list.

Please also refer to the ADRIFT 5 Wiki for more information.

Re: The real limits of ADRIFT.

Postby BBBen » Mon Aug 01, 2016 11:39 am

Lazzah wrote:
David Whyld wrote:On Inform and TADS, the text seems to scroll much more smoothly. In ADRIFT, it jumps up the screen in stops and starts. Only a minor issue, but the Inform and TADS runners seem more professional.

I don't know what sort of computer you play your games on, David, but when I play ADRIFT games the text doesn't "jump up the screen in stops and starts"!

No, I haven't seen anything similar either.
BBBen
 
Posts: 287
Joined: Sat Jul 02, 2011 5:46 am
Points: 10

Re: The real limits of ADRIFT.

Postby David Whyld » Mon Aug 01, 2016 11:57 am

Try Inform or TADS then try ADRIFT and you'll notice the difference. It's not a major point though, just something I've noticed a time or two over the years.
David Whyld
 
Posts: 6748
Joined: Sat Dec 18, 2004 5:15 pm
Location: United Kingdom
Points: 25

Re: The real limits of ADRIFT.

Postby rotter » Mon Aug 01, 2016 9:19 pm

I think the only thing I would like to see improved is improved ability to run games online. For example with Inform you can create a web version of your game when you compile it. This web version is light, transferable and will run anywhere, so it is not dependant on anything else like the way Adrift does it.
Currently working on "The Blank Wall" in ADRIFT 5 and "Again and Again" in Inform 7.
Delron, the home of Otter Interactive Fiction.
User avatar
rotter
 
Posts: 1352
Joined: Sat May 08, 2004 12:12 am
Location: UK
Points: 10

Re: The real limits of ADRIFT.

Postby David Whyld » Tue Aug 02, 2016 9:37 am

RaveCoyote wrote:btw. gargoyle IS in fact still actively developed (last commits were Apr 24, 2016). And the map function is but a new aspect that could as well be integrated in their runtime as well.


Is there any interest from the folks at Gargoyle regarding adding ADRIFT? At the end of the day, Campbell could make ADRIFT open source but it doesn't mean it will be added to Gargoyle. Has anyone heard any interest in this respect from the Gargoyle crowd?
David Whyld
 
Posts: 6748
Joined: Sat Dec 18, 2004 5:15 pm
Location: United Kingdom
Points: 25

Re: The real limits of ADRIFT.

Postby RaveCoyote » Tue Aug 02, 2016 10:36 pm

There was quite a discussion regarding adrift 5 there. They had to give up though because of the missing support and source code. As far as I know the one took care of the former adrift 4 runtime for gargoyle was also contacted. But of course all that was a dead end at the time adrift 5 arrived on scene.

Regarding 'scrolling' and 'displaying': The gargoyle developers put lots of effort in smooth and visually extremely fine tuned font display. Being able to run all major IF systems in one small, visually compelling and compact cross platform tool was the goal of the project.

If campbell thinks that this is not of importance then it's of course his choice. But in case no one has noticed I created this thread to help and support adrift and not to annoy campbell. I still think adrift 5 has a good change to become as popular as inform because of its completely different approach to create stories.

And a simple message to the gargoyle developers saying "Hey guys, we want to have a gargoyle runtime, please help!" wouldn't hurt. Let's talk to them. :)
RaveCoyote
 
Posts: 6
Joined: Tue Jul 26, 2016 11:59 am
Points: 10

Re: The real limits of ADRIFT.

Postby David Whyld » Wed Aug 03, 2016 3:49 pm

That's quite interesting. I didn't realise there was any real interest from the Gargoyle crowd about ADRIFT
David Whyld
 
Posts: 6748
Joined: Sat Dec 18, 2004 5:15 pm
Location: United Kingdom
Points: 25

Re: The real limits of ADRIFT.

Postby RaveCoyote » Sat Aug 20, 2016 2:44 pm

I think we should simply contact the guy who created the scare runtime. He IS interested.
RaveCoyote
 
Posts: 6
Joined: Tue Jul 26, 2016 11:59 am
Points: 10

Re: The real limits of ADRIFT.

Postby ralphmerridew » Sun Nov 20, 2016 11:42 pm

Speaking as the developer of jAsea, there's a significant design decision that makes the ADRIFT interpreter very difficult to support.

Inform, TADS, and Hugo have separate "development" (.inf for Inform, .t for TADS) and "distribution" (.z? or .glulx for Inform, .gam for TADS) formats for games. ADRIFT essentially uses a single format which has to perform both duties. (An ADRIFT blorb contains an obfuscated version of the .TAF.)

The development format refers to the files that the author edits to create the game. The distribution format refers to the compiled game run in the interpreter.

Development formats can change greatly between releases; only the author of the game needs to work with it; if something has changed that is important to that game, then the author can go back to an older build, or just retest with the new format.

On the other hand, distribution formats should change very little. Once a game is released, it needs to run the same on all future interpreters.
(There were only 8 different versions of the zcode format and 9 of the Glulx format: http://eblong.com/zarf/glulx/changes.txt )

Notice how short the Glulx changelog is. Notice that it hasn't changed at all in over six years. Changes between 2.0 and 3.x are small enough that 3.x interpreters should also run 2.x games.

Date comparisons: Glulx has not been changed since before the public release of ADRIFT 5. Glulx games written since April 2000 (back when I6 was the current release, and before ADRIFT 3.90) are still playable on current interpreters.

Because ADRIFT uses a single format for both development and distribution, almost every feature added to developer must have a corresponding feature added to the interpreter. (Exceptions would be things like searching the game file.) Trying to keep the interpreter up to date can be an arms race.
Bloodhounds can make you laugh and cuss in the same breath. They are endearing, faithful, and can sling drool ten feet in any direction. -- Virginia Lanier
User avatar
ralphmerridew
 
Posts: 2547
Joined: Fri Dec 13, 2002 11:56 pm
Location: Missouri
Points: 10

Re: The real limits of ADRIFT.

Postby saabie » Mon Nov 21, 2016 1:08 am

If support for the maps (and anything else ADRIFT does that the other formats don't support) were added to zcode or Glulx, then it should be reasonably simple to write a compiler that takes the XML from an exported .AMF file of the entire game and converts it into zcode/Glulx that will run in gargoyle.
The players can then run the game anywhere without having to worry about version changes, and the author only needs to update the cross-compiler if he wants to use a new feature added to the developer.
saabie
 
Posts: 922
Joined: Fri Aug 12, 2011 2:07 am
Location: Adelaide, South Australia
Points: 25

Re: The real limits of ADRIFT.

Postby ralphmerridew » Mon Nov 21, 2016 3:32 am

Possible, yes, simple, no. It's almost as much work as writing Runner itself. The only way it's realistically likely to happen is if Campbell changes Developer to output the format of whatever VM, and redesigns Runner as an emulator for same VM.

I wrote a program to convert ADRIFT 4 games to TADS 2 .gam format a number of years ago.

Compiling ADRIFT to zcode has one significant obstacle; zcode, being developed to run on early 80s computers, has limited amounts of writable memory, while ADRIFT tends to use large amounts of writable memory. That would not apply to targeting Glulx or TADS VM.
Bloodhounds can make you laugh and cuss in the same breath. They are endearing, faithful, and can sling drool ten feet in any direction. -- Virginia Lanier
User avatar
ralphmerridew
 
Posts: 2547
Joined: Fri Dec 13, 2002 11:56 pm
Location: Missouri
Points: 10

Re: The real limits of ADRIFT.

Postby saabie » Mon Nov 21, 2016 4:54 am

It's not an insignificant amount of work, but probably not as much as you might think, as most of ADRIFT-5's smarts are in the standard library and the entire runner GUI is being replaced by gargoyle's.
When I said simple I didn't mean quick, I just meant that a team of average programmers could do it without too much difficulty.
You could start with a standard XML parsing library and string-handling libraries and then re-use code for parsing expressions from TADS or a similar system.
The core of ADRIFT runner mainly just scans text for substring matches and replaces one bit of text with another bit of text.
All of the necisary code should already exist in the other game compilers, so all you need to write is the bit in the middle that tells the XML library which element it needs to read and pass to the Glulx/TADS compiler code.
saabie
 
Posts: 922
Joined: Fri Aug 12, 2011 2:07 am
Location: Adelaide, South Australia
Points: 25

Re: The real limits of ADRIFT.

Postby ralphmerridew » Wed Nov 23, 2016 3:50 am

saabie wrote:It's not an insignificant amount of work, but probably not as much as you might think, as most of ADRIFT-5's smarts are in the standard library and the entire runner GUI is being replaced by gargoyle's.
When I said simple I didn't mean quick, I just meant that a team of average programmers could do it without too much difficulty.
You could start with a standard XML parsing library and string-handling libraries and then re-use code for parsing expressions from TADS or a similar system.
The core of ADRIFT runner mainly just scans text for substring matches and replaces one bit of text with another bit of text.
All of the necisary code should already exist in the other game compilers, so all you need to write is the bit in the middle that tells the XML library which element it needs to read and pass to the Glulx/TADS compiler code.


1) It would be pretty easy to get a Runner with sort-of-compatibility or even mostly-compatibility. The result will generally be like playing an ADRIFT 4 game with the ADRIFT 5 runner; games seem to play fine, and then suddenly you hit some slight difference which turns out to be crucial to the game. For this project to work, the new runner has to do everything exactly the same as the official runner.

2) "as most of ADRIFT-5's smarts are in the standard library". -- Having most of the smarts in the standard library is a good thing, but ADRIFT falls short of that. StandardLibrary.amf appears to contain primarily verb definitions. I couldn't find things like:
- how exactly are lists stringified (in what order are objects listed?)
- sequencing of task / event interactions (if an event triggers a task, and completing that task starts another event, does the second event start on the same turn or the next one?)
- sequencing of text substitutions (if more than one overlapping text substitution can be performed, which one will it use? If performing one text substitution makes a second possible, will the second be performed?)
- when is "seen by player" updated? (If a task moves an object into the room with the player, then immediately moves it away, will the object be marked as having been seen?)
- rules for object disambiguation

None of these are particularly difficult to produce an implementation, but, without explicit documentation by Campbell, very difficult to get exactly right. Even if they're correct in one version, Campbell might change how Runner works in the next version.

But the equivalent tasks for Inform are explicitly defined in its standard libraries. There is no need for an interpreter author to care how those are handled, because the code to do them will be within the game file.
Bloodhounds can make you laugh and cuss in the same breath. They are endearing, faithful, and can sling drool ten feet in any direction. -- Virginia Lanier
User avatar
ralphmerridew
 
Posts: 2547
Joined: Fri Dec 13, 2002 11:56 pm
Location: Missouri
Points: 10

Re: The real limits of ADRIFT.

Postby David Whyld » Fri Nov 25, 2016 10:25 pm

Is there any real chance something like this will come about one day? I've never been a fan of the v5 Runner but I'd love to be able to play v5 games in either TADS or Inform interpreters.
David Whyld
 
Posts: 6748
Joined: Sat Dec 18, 2004 5:15 pm
Location: United Kingdom
Points: 25

Re: The real limits of ADRIFT.

Postby ralphmerridew » Sat Nov 26, 2016 12:35 am

I did it for ADRIFT 4 (tAsea).

As for ADRIFT 5, I don't consider it very likely. Doing so would require strong technical skills with Glulx or TADS VM, as well as a solid understanding of ADRIFT 5 (which, as I mentioned in the previous post, is probably "read the Runner 5 source code"). I'm not sure if there's anyone who has the skills to do it who'd be willing to do so. Personally, even if it weren't for my recent lack of free time, I wouldn't be willing to do so unless Campbell made some sort of commitment to deal with the "moving target" problem.
Bloodhounds can make you laugh and cuss in the same breath. They are endearing, faithful, and can sling drool ten feet in any direction. -- Virginia Lanier
User avatar
ralphmerridew
 
Posts: 2547
Joined: Fri Dec 13, 2002 11:56 pm
Location: Missouri
Points: 10

Re: The real limits of ADRIFT.

Postby RaveCoyote » Mon Jan 02, 2017 8:52 am

Come on guys, I'm pretty sure if you're working together this would turn out to be a real good thing in the end.
Any word from Campbell regarding supporting you with this?
RaveCoyote
 
Posts: 6
Joined: Tue Jul 26, 2016 11:59 am
Points: 10

Previous

Return to ADRIFT 5.0

Who is online

Users browsing this forum: No registered users and 4 guests