Re: Penguin Software's The Quest/RingQuest maps/walk-thru wanted...

[Holger Picker <pickerh@uni-muenster.de>]

On Mon, 31 May 2004, Yan Termit wrote:

> Date: Mon, 31 May 2004 03:53:51 GMT
> From: Yan Termit <yt@no.spam>
> Newsgroups: comp.sys.apple2
> Subject: Re: Penguin Software's The Quest/RingQuest maps/walk-thru
>     wanted...
>
> In message <bQxuc.6409$aM1.2895@fed1read02>
>  Yan Termit <yt@no.spam> wrote:
>
> Anyways, now that I have "The Quest" maps, does anyone have any input to
> offer as far as ideas or suggestions for improving the game?  Anyone
> interested in helping in audio/graphics/programming?

Hi,

well, I'd have a few questions:
1) What platform are you targetting? AppleII, Apple// GS, other?
2) What programming language would you like to use? AFAIK, the main program
of "The Quest" (MQ) was written in Applesoft Basic with subroutines in assembly
language (6502), but you don't have to stick to that.
3) What platform do you use for programming? In case you'd like the final
program to run on an AppleII, do you also program on a real AppleII or do
you use some cross-compiler platform with an emulator?
4) Do you also plan to improve the parser? Are you in need of one?
5) Have you already extracted the graphic data from the picture files? Do you
know what the format looks like?

Suggestions (if you program for the AppleII):
1) If possible, use 2 (double)hires screens, i.e. a buffered output. Hide
drawing of the pictures from the player.
2) Split the action data into several little files depending on the location.
Don't load everything into memory, only on demand. Loading a few sectors for
action data isn't that time consuming, but helps you to avoid running out of
memory.
3) Split between logical and physical rooms. Physical room = the action file on
disk. Logical room = the room number that is used with the objects.
Sometimes you may want to have several different action files for one
logical room (e.g. before an earthquake, after an earthquake).
4) Avoid numbers or indexes like O%(4) = location of object 'sword',
O%(23) = location of object 'chest' etc. Code like this is hard to read and
maintain. This also applies to room locations. Better call a room
location 'in_desert' than '43'.
5) If possible, use a special adventure programming language that supports
all this. This also has the advantage that the final code is very small in
size. The code itself also becomes portable then, or you can (pre-)compile
it e.g. for compressing message strings.
6) If possible, use an emulator for development. I personally use Emu][ (aka
Dapple) for writing programs for the AppleII. It has a built-in assembler as
well as a debugger. Developing programs is rather simple this way as you can
use all the memory. Assembling is done really fast and directly into the
'AppleII' ram. Finally, finding bugs is not as annoying as it used to be.
Purist possibly won't like this programming approach, but IIRC, even old
programs for the AppleII by Lucasfilm Games ('Koronis Rift', 'Maniac Mansion'
etc) were written on a VAX and not directly on an AppleII.
7) If you are in need of 6502 code etc, just ask, please.

Holger