Adventure Game, or: Initial Memory Concerns

[Yosikuma]

So I have been tinkering with IntyBASIC for a bit, and I have decided to go ahead and try to make an adventure game (a la a point and click game, though I feel a pointer may be a waist of my precious MOBs and figuring paths may be a pain!). However, in my mind, the controller would seem to be far more at home in something where you advance a story and solve puzzles than something more action oriented.  Before I bite far far far more than I can chew, I had concerns about game size. Since the game would certainly be more dialogue heavy, this is a concern. Would I need to contemplate text compression? 

 

Hoping I can show some progress here in due time!

[+DZ-Jay]

8 hours ago, Yosikuma said:

So I have been tinkering with IntyBASIC for a bit, and I have decided to go ahead and try to make an adventure game (a la a point and click game, though I feel a pointer may be a waist of my precious MOBs and figuring paths may be a pain!). However, in my mind, the controller would seem to be far more at home in something where you advance a story and solve puzzles than something more action oriented.  Before I bite far far far more than I can chew, I had concerns about game size. Since the game would certainly be more dialogue heavy, this is a concern. Would I need to contemplate text compression? 

 

Hoping I can show some progress here in due time!

There are many ways to compress text.  I've been toying with a similar idea, and the approach I was planning to take is based on a technique employed by Infocom in their Z-Machine.  It's rather clever and should be easy to implement.

 

It works like this:

• They store each character in 5 bits, which allows them to store three characters in two 16-bit words.
• 5 bits allows up to 32 characters, which is not nearly enough for the full set, but is enough for complete groups of characters like say, all upper-case, or all lower-case.  They call these contexts.
• They use special character codes to switch contexts and treat the text as a stream of characters in different contexts.
• If you use one context for all English lower-case characters and one for all lower-case characters, that'll take 26 special codes each.  There are surely less punctuation characters than 26, and only 10 digits; which means that you can reserve about 6 special characters for contexts.
• We've already mentioned upper- and lower-case, punctuation and digits, so you have two more special codes to use for additional contexts, like paragraph justification, indentation, emphasis, etc.
• You could even reserve a special context code for commonly used words, like articles or pronouns, etc., so that you do not have to re-encode "the" and "their," all over the place.

 

Anyway, this gives you a the ability to compact three characters into two DECLEs, which is no small thing.  This approach may work better for a text adventure than typical compression because text compression gains typically come with larger texts; and, although your total amount of text may be large, in practice you will only be using a little at a time.  You will have to compress the text is smaller chunks, which reduces its efficacy.

Anyway, it worked for the Z-Machine, which was ported to some rather tiny platforms, so it may work for the Intellivision.

 

     dZ.

[+DZ-Jay]

For further ideas on how to fit a large program into a small machine, check out the article entitled, er, How To Fit A Large Program Into A Small Machine, by Marc Blank and Stu Galley, veterans from Infocom.

 

https://web.archive.org/web/20130113052554/http://www.csd.uwo.ca/Infocom/Articles/small.html

 

They go through simple explanations on how they implemented other crucial components like linked lists, which is the cornerstone that holds their adventure world together.

I think all of these techniques and implementation details can be very useful, as practical lessons from the past, even if you do not intend to build something as sophisticated as a Z-Machine.

 

   dZ.

[+nanochess]

It depends on how much dialogue you expect to have.

 

My suggestion would be to code the first few screens, and then having a semi-playable game you can estimate/calculate the size of your dialogs.

 

For a first game it is entirely possible everything can fit without compression.

[+DZ-Jay]

One other point on this:  encoding strings into some compact format should be fine, and actually preferable.  However, compression may make text string searches when parsing input, etc. more expensive or impractical.

 

    -dZ.

[carlsson]

If it is point and click, there should not be any need for a lexical parser. Only text output to accompany the graphics.

[+DZ-Jay]

40 minutes ago, carlsson said:

If it is point and click, there should not be any need for a lexical parser. Only text output to accompany the graphics.

DOH! You are right.  Still, unpacking one string at a time may be more practical than extracting a single string from a compressed block.

 

    dZ.