Duck! Me? - An old-fashioned 1980's style text adventure

[EdwardianDuck]

I had a go at writing a text adventure using Inform6/PunyInform (http://duckology.co.uk/code/06/index.html) and have packaged it up for the Atari. Originally I wrote this in 6502 assembly for the BBC Master 128 before deciding to port to PunyInform and extend it a bit.

 

Technically still a beta, but it is playable. See the link on the page to StarDot for some history/discussion.

 

It's not a huge game, my non-optimal walkthrough is ~330 moves.

 

And, yes, the premise is a bit silly.

 

Jeremy

[_The Doctor__]

Grabbed the .ATR at the bottom of the screen... Time for a quacking good time of saying 'duck me' as I will have to try multiple time to solve it.

[EdwardianDuck]

For convenience, I've attached the ATR here.

 

If anyone wants hints, I'd suggest posting here and encoding the question using ROT13 to trivially hide spoilers (for example, https://rot13.com/) and I'll reply in the same manner. Or send me a PM, but I might not see that as quickly.

 

Any constructive feedback would be welcome.

 

Jeremy

 

DuckMe-Beta-16.atr

[Mark2008]

Thanks, I tried it.  I guess I went 75 moves and scored 0 points.

 

Back in the day, I only played one text adventure, it was called Xenos, that I played on a TRS-80 Model III.  I solved that one - it took quite a long time, of course I had lots of time to try back then, lol.

 

Given that is my only experience of any kind with a text adventure - and it wasn't infocom, I don't really know if this game is a bit harder than others?   I wanted to stumble into something to indicate I was doing something right, but alas, it wasn't to be today.

 

 

 

 

[EdwardianDuck]

Thank you for trying it. The game isn't super easy, but not (IMHO) super hard either. Most of the puzzles are a bit more involved that "you find a key in room 1 which unlocks a locked door in room 2". It also tries to be reasonably fair to the player.

 

Score isn't that helpful as the game isn't of the "treasure hunt" style and I didn't think it needed a score at all. It was added after a player completed the game, but wasn't 100% sure he'd "won". If you use the SCORE command you'll see what I mean.

 

To set the scene, make sure you

 

<rot13>

RKNZVAR ZR

YBBX VA ZVEEBE

ERNQ YRGGRE

</rot13>

 

The first one hints at the major puzzles to solve, the other two hint at the premise.

 

Jeremy

[Mark2008]

9 hours ago, EdwardianDuck said:

Thank you for trying it. The game isn't super easy, but not (IMHO) super hard either. Most of the puzzles are a bit more involved that "you find a key in room 1 which unlocks a locked door in room 2". It also tries to be reasonably fair to the player.

 

Score isn't that helpful as the game isn't of the "treasure hunt" style and I didn't think it needed a score at all. It was added after a player completed the game, but wasn't 100% sure he'd "won". If you use the SCORE command you'll see what I mean.

 

To set the scene, make sure you

 

<rot13>

RKNZVAR ZR

YBBX VA ZVEEBE

ERNQ YRGGRE

</rot13>

 

The first one hints at the major puzzles to solve, the other two hint at the premise.

 

Jeremy

 

Thanks, I'll give it another go.

 

Interestingly enough, I think I did ERNQ YRGGRE...

 

But again, it just goes back to that single game I played before.  In that game /* SPOILER ALERT */, if you turn on the radio in the saloon, that may not be any great puzzle, but it increases your score by 10%, and it had the impact of signaling being on the right direction.  However, many people never finsih that game, it was a lot of endless guessing - I think because my entire family was investing hours upon hours, we had occasional break throughs.

[EdwardianDuck]

Just a quick update. The link in the top post no longer works. After a number of years prevarication I decided to let the domain & hosting go and didn't renew it. The game is of course still available from this thread.

 

As before, please post here for hints. I'm also interested to learn if anyone completes the game and any comments / issues found. If someone actually completes it, I could move if from beta status and call it a formal release.

 

Jeremy

[EdwardianDuck]

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

[EdwardianDuck]

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

 

[EdwardianDuck]

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

[drpeter]

On 6/13/2023 at 8:12 PM, EdwardianDuck said:

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

I can confirm that this seems to be a bug in the Atari interpreter: I get the same issue in a test compilation for the Atari, but the same Z3 file run in Winfrotz behaves as expected (i.e. 'self' correctly refers to the relevant object both in the before routine inherited from its class and the one declared in the object definition)

[EdwardianDuck]

7 hours ago, drpeter said:

I can confirm that this seems to be a bug in the Atari interpreter: I get the same issue in a test compilation for the Atari, but the same Z3 file run in Winfrotz behaves as expected (i.e. 'self' correctly refers to the relevant object both in the before routine inherited from its class and the one declared in the object definition)

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.

[drpeter]

4 hours ago, EdwardianDuck said:

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.

I guess you could in most cases use something along the lines of:

 

if (noun ofclass RelevantClass) ...

else if (second ofclass RelevantClass)....

etc.

[EdwardianDuck]

18 minutes ago, drpeter said:

I guess you could in most cases use something along the lines of:

 

if (noun ofclass RelevantClass) ...

else if (second ofclass RelevantClass)....

etc.

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.

 

Edited June 15, 2023 by EdwardianDuck

[drpeter]

As an aside, I notice that the Inform superclass operator doesn't work in Ver 3 stories- although this seems to be a Ver 3 issue rather than an interpreter issue as it fails in the same way with Winfrotz: i.e. you can't write

 

myObject.RelevantClass::before()

 

in Ver 3.

 

Well, you can write it, and it compiles, but the story then throws a run-time error when this expression is evaluated, so you can't emulate inheritance in that way

Edited June 15, 2023 by drpeter

[drpeter]

2 hours ago, EdwardianDuck said:

Interesting idea, although I think (untested) that it'll break down in cases like ...

 

PUT BUCKET IN CRATE

I don't think this is necessarily the problem you think it is (in the case of before [; ... ], properties in any case) since the action will be ##Insert in the case of self==noun and ##Receive in the case of self==second

[Rafael1138]

Hi There. I'm a big Text Adventures fan in C64 and I was looking for some Atari Text Adventures but still need to dig in in that topic.

 

I will try yours, that way I can satisfy my Atari 8-Bit Text Adventure curiosity lol.

[EdwardianDuck]

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

[EdwardianDuck]

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

[+DjayBee]

@jindroush you might have a try with your interpreter. 

[jindroush]

@EdwardianDuck Is this working for you?
What specific bugs you mean?

test.atr

[EdwardianDuck]

@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.

[EdwardianDuck]

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.

Edited September 1, 2023 by EdwardianDuck

[jindroush]

Stupid me, I know exactly why this is a problem. The attached version should not produce internal error 12 (tested with the walkthrough).

test.atr

[EdwardianDuck]

@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