The Sinclair QL Forum

And for my next trick the full 14 disks of Monkey Island 2 compressed into one exe.....

Only kidding, I didn't even realise how big that Colossal Cave was until I tried to write it to disk image and it would not fit.
Is the main reason for the size. Its just one binary array which is pretty much all the game data.

But really I was just perusing the ifarchive to see what would be fairly easy to "port" and give me some practice of qdos-gcc/xtc68

XorA wrote:And for my next trick the full 14 disks of Monkey Island 2 compressed into one exe.....

Only kidding, I didn't even realise how big that Colossal Cave was until I tried to write it to disk image and it would not fit.

Code: Select all

-rw-r--r-- 1 graeme graeme 2.1M Dec 29 20:17 adv6.h

Is the main reason for the size. Its just one binary array which is pretty much all the game data.

But really I was just perusing the ifarchive to see what would be fairly easy to "port" and give me some practice of qdos-gcc/xtc68

Ahhhh! Monkey Island 2 :sigh:

Okay, I've printed off a copy of the Apple II source code for Akalabeth

Hi George,

I have seen your work on ZX version at WoS forum, may I just ask how it went on
QL, also is there a ZX most recent or final version available?

Tom

Hi Tom,

Sorry, I only just saw this post.

I didn't write the ZX Spectrum port, just did some testing. Someone called Battelbunny gets the credit for that. However, I am making good progress with the QL port. After a few months distraction over the summer writing articles for The Spectrum Show Magazine, I'm now back on the case with Akalabeth and hope to have a first complete version ready for testing by Christmas.
Sorry again for missing your question,
George.

Looks good!

Well, Christmas came and went, with little time to work on the game. However, January has been much more fruitful and I have now produced an alpha-quality version of the game, which you can download from the QL GitHub repository:

https://github.com/SinclairQL/akalabeth

--and run a BBQL system or in an emulator.

There are a few known issues (see accompanying notes) and probably a few more unknown issues, though this is a playable version of the game with all main features included.

It's also worth noting that I've tried to recreate the original game accurately, and this includes some elements that people may find odd or think are bugs. For example, when you revisit a dungeon level, all of the monsters/ enemies reappear in their original place, even if you've previously killed them. This is as is the case in the original game. I've also left some of the debugging code in, which might help you find your way around .

While I've tried to keep to the original game, I haven't used the original BASIC. Instead I've tried to rewrite the game using the power of SuperBASIC. The spaghetti code of GOTO statements that were necessary in Apple II BASIC have been mostly replaced by procedures and functions. However, I'm new to QL BASIC (part of the aim has been to learn QL BASIC), so expect I've not yet fully exploited the power and style of the language.

Hopefully this is a good game, which people will enjoy playing. I only encountered Akalabeth a couple of of years ago, but was fascinated by such a deep BASIC program, written in 1979 by an at-the-time amateur programmer on an Apple II. The author, Richard Garriott, wrote the game for fun and because he wanted to recreate the enjoyment of playing Dungeons & Dragons in computer form. I'm not that big a fan of science fiction and fantasy. However I really enjoy this game and particularly like the fact that the instructions leave so much unsaid--so you have to build up your experience and employ patience to get to grips with the game.

I'll keep working on the game--starting with the known issues--so keep an eye on GitHub for more.

Have fun,
George.
George.

Hi Georgeo and thank you for bringing Akalabeth to the QL!

I haven't tried the game yet, but have been perusing the code.

There are a couple of things that you might want to add to your 'issues list' for the beta version

a) Try replacing all those RETurns intended to terminate PROCedures with END DEFine's instead.

SuperBasic/SBASIC can get a little upset if DEFine's are not matched with corresponding END DEFine's - RETurn is not considered a replacement for END DEFine in SBasic.
You can actually leave the RETurns in place if you prefer and add the END DEFine and the logic/behaviour wouldn't change as long as they are added immediately following the terminating RETurns. Otherwise, keep explicit RETurns for conditional clauses, or of course to return values from FuNctions.

b) You can drop all those LET's - throughout. SBasic never requires LET, although some people like them...

c) Perhaps cosmetic but to improve the readability, its typically recommended to keep the main, non procedurised routine altogether in a contiguous block, usually at the start and before any procedures/functions appear.

I look forward to trying the game this weekend

Hi Martyn,

Thanks for the advice. When you talk about not using RETURN to exit a procedure, do you also mean exiting early, e.g. from a condition test:

100 DEFine PROCedure doSomething(dng)
110 some calculations
120 IF done THEN
130 END DEFine doSomething
140 END IF
150 do some more
160 END DEFine doSomething

—or just the final delimiter. I have gonewith END DEFine at the end of the block of code and RETURN in the middle (though I see I missed one at least).

The LET statements are a personal preference, assuming that they don't have any impact other than increasing the size of the source file a bit.

Thanks again,
George.

Georgeo,

END DEFine is intended to mark the end of a definition. As definitions only have one beginning and one end, there shouldn't be more than one END DEFine in a FuNction or PROCedure. Premature exit from a PROCedure or FuNction should always be done using RETurn.

You can easily check this by trying to compile the code with Turbo - It will spot such errors and complain.

So your example should look like this: Tobias

100 DEFine PROCedure doSomething(dng)
110 some calculations
120 IF done THEN EXIT doSomething
130 do some more
140 END DEFine doSomething

You should utilize EXIT and place the END DEFine at the very end of the procedure.
And thanks for your nice game!