EdwardianDuck

In related news, Infocom's source code for some of their interpreters has surfaced here https://github.com/erkyrath/infocom-zcode-terps, including an Atari 8 bit one (not sure which version this is). Off topic, I was able to build the Acorn (BBC Model B) version by converting the source code to CA65 syntax. See https://stardot.org.uk/forums/viewtopic.php?p=408915#p408915. Jeremy

@jindroush Yes, that's better, thank you. Uploaded again with a different name to make it clear that this is a released version. Hopefully this is the last release for a while and I can get back to the sequel. If anyone needs hints or wants to provide feedback, please post here. Jeremy DuckMe-Z3-20230903-Release2.atr

I played through the game again using the latest test.atr without issue. One thing I did notice is that SAVE/RESTORE seems to want a double density disk (also cosmetic display issue). If the aim of this build is to target stock hardware, isn't that going to be an issue for most setups? I don't think this is a real issue, it's fine on emulators which is what I imagine most players would use, I'm just trying to figure out how to describe this to avoid confusion. I don't have real hardware myself. Jeremy

I noticed the odd disk size and did think that it would be a problem on real hardware. @jindroush, is it possible to build this in a standard disk size/format? Unfortunately, I've no idea how you're building the image or whether just padding it out would work. In the short term, the two disk build uses a standard disk size. Jeremy

So that this game has a permanent home, I've uploaded it to the Internet Archive here. This page also has a link to an online interpreter so that you can play the bare .Z3 in a browser. Jeremy

@jindroush Yes, that works, thank you. I've played through the whole game again using the same walkthrough without issue. I've attached the .ATR again with a more descriptive name as this is now the release version. @ZeroPage Homebrew I'm calling this (in conjunction with the "20230828" files attached earlier on in this thread) a finalised release (it's currently shown as a WIP binary in your thread). Atari 8bit users have the choice of 1 or 2 disk builds, but for ease of use I'd suggest using the "jindroush" build here. If anyone finds other issues or wants a hint, please post here. Jeremy DuckMe-Z3-20230902-Release2.atr

Even if you just wander around the game, it crashes after a relatively small number of moves with internal error 12, using the test.atr attached above.

@jindroush Actually, no, but I get a different error much earlier in the game (I'm using the exact same walkthrough each time). This version gives "Internal Error 12" and the problem can be creating using the following moves. wear badge get torch get pillow s s e open packet eat crumpet Previously I was getting internal error #5957 when in game was listing the contents of various containers and supporters, some of which are nested (the jack is on the bucket which is on the crate which is under the desk in the study). OK, that isn't going to mean much unless one has nearly completed the game, but perhaps I'm hitting some sort of complexity limit in the interpreter. Using your build I'm not getting far enough through the game to trigger that issue. Another internal error was triggered when I tried to redirect to <<transfer noun second>> within a <<insert noun second>> action just to avoid a particular message being printed. I've since customised one of the response messages instead, which is a much better approach. I wasn't able to figure out precisely what the bugs were. In practice, I'm not particularly bothered by this, the two disk build works and I think that's good enough.

The game has now been independently testing, although not specifically the Atari build. I'm now going to call this release 2 (release 1 was a disaster) and the files are attached. Please note that I have dropped the single disk build which used the early interpreter version as I have not been able to work around the bugs I appear to have triggered in the more complicated bits of my game. While there are apparently bug fixed versions of the interpreters, they don't seem to be publicly available, so I'm just going to release this as a two disk set. Also attached is the .Z3 file in a .ZIP archive. Just for information, none of the issues I've seen with the Atari interpreters appear when using the Acorn build of Ozmoo or when using a modern interpreter, so I'm reasonably sure the problems are interpreter related. Jeremy DuckMe-Z3-20230828-Release2-Disk1.atr DuckMe-Z3-20230828-Release2-Disk2.atr DuckMe-Z3-20230828-Release2.zip

Is anyone willing to fully test this for me? By that I mean play the game through to the end and try anything that comes to mind while playing it. I'll provide a map and minimal walkthrough so you don't get stuck. I'd like to get a proper release out so I can move on to the sequel. Please PM me if you're interested. Jeremy

Interesting idea, although I think (untested) that it'll break down in cases like ... PUT BUCKET IN CRATE ... in my game because both objects are ofclass ConstrainContent. One would probably have to check second first to cover more cases. I guess that in practice I'd try to design the game to avoid this sort of confusion.

The work round is to replace self with either noun or second as appropriate in the class before routine. That works in my game because for the impacted classes self == second in all cases. If a game has a class where self could be either noun or second, that's more of a problem.

To clarify slightly, "before" is additive. You typically use it to constrain some action. In my case I have a class which uses "before" to constrain what containers can hold, based on some properties. For a particular container you might have a "before" routine to check some other condition which is not expressed by the class properties. What's supposed to happen is the class "before" routine is called first, then the object "before" routine. Without coding round the problem, it appears that self = 0 in the class "before" routing when object also has a "before" routine. Self should be the object number in each case. Probably. Unless I'm not understanding how it all works, which is quite likely. Jeremy

At long last, yet another beta (see top post), .ATR + .Z3 in the Zip as usual. For no particular reason I've included both 1 & 2 disk versions. The only difference is the version of the interpreter used.Fingers crossed it's less buggy now and most of the terrible omissions have been dealt with, but as testing is really just me "marking my own homework", who knows? I have had to make Atari specific code changes to deal with what looks like an interpreter issue. In Inform, if you have a class with a "before" routine and an object which is an instance of this class which also has a "before" routing, things get confused and the interpreter tries to reference object 0 ("nothing") instead of the actual object when referenced as "self". If one removes the "before" routine from either the class or the object, the error goes away (but so does the associated functionality). This doesn't happen using Ozmoo on the BBC Micro or in whatever Spatterlight uses on my Mac, where "self" references the correct object. Same issue with "after" routines as well. It's easy enough to code round in specific cases, but it's not very generic.Jeremy DuckMe-Z3-20230613-Beta19.zipDuckMe-Z3-20230613-Beta19.atrDuckMe-Z3-20230613-Beta19-Disk2.atrDuckMe-Z3-20230613-Beta19-Disk1.atr

Effectively yes. I fiddled about with the A8 script from the Puddle Build tools because they don't seem to work on macOS out of the box (or possibly they do and I don't know how to run them on macOS), but the actual process is the same.

I know I said I would stop posting here, but here's a worked example (still a beta) https://forums.atariage.com/topic/332183-duck-me-an-old-fashioned-1980s-style-text-adventure/#comment-5176022 which is ~90K on a single bootable disk. Warning, it's a terrible game.

I guess my understanding of how this works is wrong. Sorry about that, I wasn't intending to spread confusion and misinformation. I won't post on this subject again.

To the best of my knowledge, no, because the interpreter being used (whether this is a period correct Infocom interpreter, a modern replacement of a hybrid of both is unclear to me) is effectively the start of a bootable disk to which the game file is appended to form the image. My guess based on no actual knowledge is that this is done to save memory. I imagine it uses the same area of memory as DOS. In theory I imagine someone who is so inclined could port the OZMOO interpreter from the C64 world to the A8 (as has been done for the BBC Micro) and make that a transient program loadable from DOS. I vaguely remember the only Infocom game I had for the A8 in the 1980's (HHGTTG) was a bootable disk like this. Doubtless an actual expert will be along shortly to correct me and explain this correctly. Jeremy

I found the .Z3 on your FTP site and built a .ATR using the process I described earlier. This boots straight into the game as expected. The files differ starting from byte 7189, which is after the interpreter (length 7184) so perhaps the build process is modifying the appended .Z3 in some way. I'm happy to post my build of the .ATR here if you're OK with that. Jeremy

I did manage to complete the game (in nine moves!) and noticed some other cosmetic issues. Mostly descriptions which reference objects which have earlier been taken, adjectives which describe objects not being understood (for example "wooden door", but "wooden" is not understood by the game). Also OPEN PIANO gives a message about the window. I was unable to crash the game this time, so perhaps I did something strange first time round. All in all it's a fun little game, but I do think it would benefit from a bit more testing and it feels a bit underimplemented, there's too many things which are referenced but not implemented for my personal taste. Hopefully this helps. Jeremy

When I say "my game runs with BASIC enabled" I mean it starts up, I didn't play through the whole thing again.

It's written in Inform6+PunyInform (same as my WIP game) so it doesn't need BASIC. If it runs with BASIC* present fair enough, but I think it will run more smoothly if RAM is present instead. It really should just boot into the game if the image creation process is equivalent to what is outlined in the Puddle Build tools. For an Atari, this is basically append the .Z3 file to the interpreter file, pad it with zeros to the exact size of an ATR then call the file nameofgame.atr. There's no DOS or file structure as such. I played a few moves before the game crashed and I was returned to the READY prompt. This reinforces my thought that there is something amiss with the ATR. Great minds think alike, two of the three aims are the same ones I came up with. While I don't want to be critical of anyone's efforts, I did notice a few issues before it crashed. I'm pointing these out in the spirit of trying to help. Firstly, the introduction mentions a stream, which is not implemented / understood, possibly this could be cheap scenery? Secondly, if you try to open the locked door, you get a custom message followed by the library default (without an intervening space). My guess is that you're printing the first message in a BEFORE routine, but not returning RTRUE to prevent the default action running. Thirdly, the EXAMINE text for the key should change once you've taken it. Once the door is unlocked the key disappears, but is still part of the piano description. After unlocking the door I was unable to open it. Not sure if this is a bug or I need to do something else first, but as I was trying a few things, the game crashed and I gave up. The default library message suggests that the door no longer has the openable attribute, but of course I can't be sure. * I just checked, my game will run with BASIC present, but it's not needed or recommended. Jeremy

If you're looking to have your game run on multiple vintage platforms, have you considered Inform6 + PunyInform + Puddle Build Tools? OK, that's going to give you an Infocom style of game rather than a Scott Adams style of game but at least once you've compiled the .Z3 (game files) using Inform6 + PunyInform, that's a game which can be run on many platforms, including the Atari 8 bits using the Puddle Build Tools to package the .Z3 file up with the relevant interpreter and disk format for each platform. This does mean you'd be writing your game on modern hardware, which might not be what you want to do, but at least the tools are still being maintained / developed.

If you search extensions for MADS, there are a couple of options. One is (I think) just a syntax highlighter, the other is Atasm Altirra Bridge (also supports MADS) which seems to integrate building as well. I haven't tried either myself as I switched to CA65 a couple of years back for cross platform reasons.

I've attached the latest beta to this post. If anyone is playing beta 16, you probably want to stop and use beta 18 instead. There are some serious bugs in beta 16 which may prevent you completing the game. There was also a bug which would have enabled you to skip a couple of major sections and still complete the game. I didn't post an Atari build of beta 17 or the complete mess that the first formal release turned into. Nothing sinister, I just forgot to do it. The release turned into a disaster, you really didn't miss out. A couple of things to mention. The Atari interpreter requires a .Z3 build, so that means only the first 6 characters of words are significant. There is at least one (avoidable) case in the game where you might need to provide additional disambiguation. The Atari interpreter doesn't seem to handle a £ sign. I guess that's a character set thing. There is one place where "£1.99" is mentioned. For the Atari build I have substituted "$1.99" although this is not canon in the Duck universe. However, this is just scenery, it is not relevant to the game play. As before, please post here if you require a hint or want to provide feedback. Jeremy 01-DuckMe-20221222-Beta18-Z3.atr