Jump to content
Sign in to follow this  
gar0u

Polymorphic Entry?

Recommended Posts

I'm just getting started, but have a what I think is a pretty cool idea.  Wanted to run it by everyone to see what you think.

 

1. Variable space is going to be a challenge

2. The base graphics will always be the same

3. The base game mechanics will always be the same

4. The game itself will be "polymorphic"--meaning that each game will be unique

5. To play the game, you run a Python program that generates some random tables (see #1 above)

6. The random tables are populated into an IntyBASIC program

7. Python then compiles and links your game

8. You now have a unique 'quest' set in a familiar world with familiar game mechanics to play

9. When you beat your quest, or if you don't like it, you just rerun the Python program to get a new game

 

I don't want to spoil to much more of it at the moment.  Just curious what everyone things about my approach.

 

Thoughts?

Share this post


Link to post
Share on other sites

BTW, the Python program will take a seed as an optional argument for consistency to conform with the rules about compiling from source and matching the submitted binary.  :)

Share this post


Link to post
Share on other sites

Same of a rougelike but with offline game generation....

I prefer when level generation is done by the intellivision itself, use a ram expansion like LTO and you can go where you want 

Edited by artrag

Share this post


Link to post
Share on other sites

Interesting idea for the contest.

 

Just take in account that judges will only try one BAS variant (the one you send) because the entry validation will be performed and they will only play the resulting ROM file.

  • Like 1

Share this post


Link to post
Share on other sites

Reminds me of one of my crazy ideas from my early Inty development days.  Have a subscription where members would get a unique ROM image that would be different each month.  For that month, the character goes to different places like thrift shops and swap meets and enters into tournaments (a minigame), trying to build up a collection of something, maybe trading cards.  The game would generate a code that members would submit by e-mail, so I could keep track of their collection, which would be encoded into their ROM image for the following month.

 

With that said, I like the idea of a "generator" meta-game.  Definitely go for it.

  • Like 1

Share this post


Link to post
Share on other sites
On 9/26/2020 at 11:18 PM, nanochess said:

Interesting idea for the contest.

 

Just take in account that judges will only try one BAS variant (the one you send) because the entry validation will be performed and they will only play the resulting ROM file.

Sounds fair.

 

Which in general terms also means that the tools used to arrive at the submitted code do not matter. I like that principle.

 

 

 

  • Like 1

Share this post


Link to post
Share on other sites

I wonder how much variation you can obtain through maximizing your ROM to 42 kilodecles + using the 8000 words of JLP RAM. With algorithmic generation, you probably could get quite a number of variations even without requiring compile-time options.

  • Like 1

Share this post


Link to post
Share on other sites

I've been working off and on on a compression algorithm I call "Zork".

 

Given a set of words, what is the shortest single string (alpha) you can generate such that every word in the set is a substring of alpha?

 

You'd need a table of coordinates outside of the game to generate the words, but you could save a ton of space!

 

Creating alpha is its own algorithmic exercise.

  • Like 1

Share this post


Link to post
Share on other sites

There's an interesting idea.  I remember when I first conceptualized the Intellivision port of RobotFindsKitten that I wanted to write a helper function that would take all the nonkitten text and Huffman-encode it.  Shoehorning a large amount of text into a game that would put it all to use and eliminate the need for ROM bankswitching is definitely a topic of interest.  The other problem then becomes fitting all the text you need at a given time onto the screen when 20x12 characters is all you have to work with.

Share this post


Link to post
Share on other sites

There should be an efficiency point where the table required by adaptive Huffman and the algorithm to encode and decode the text pays off.  But not within the limitations of the original hardware (I am guessing!  Haven't done the math of course.)

 

Maybe I'll work on "Zork" so we can have more text in games?  I know we don't have the same restrictions with emulators and other tricks--even putting memory right on the cartridge was a good hack.  But I enjoy working within the constraints of the original system--so far.  I'm just dipping my toes in the water.

Share this post


Link to post
Share on other sites

Compression and decompression of text on the Intellivision should not be a big problem for most use cases, since it falls outside the critical path.
 

First, we can assume that compression occurs at compile time, outside the constrains of the machine, so time and algorithm complexity is not really a factor.  This leaves us with decompression and retrieval.

 

I would imagine that the use cases that require the storage and retrieval of huge amounts of text, are orthogonal to the ones that require immediate "twitch-reflex" response processing.

 

If it takes the program, say 10 frames to decompress and display a single sentence (a considerable number of CPU cycles), that is still 1/6th of a second, which is significantly faster than normal human reading speed. ;)

 

I further posit that a human would not mind terribly waiting even a couple of seconds for a "wall-o'-text" to render after input.


Now, if you need to decompress a large amount of text in a single frame while playing music, updating sprites, cycling the graphics RAM, and computing other miscellaneous state information; then you are in trouble.  But I do not see that as a practical or common requirement.  Humans really do not read that fast, and the focus of attention cannot be sustained at that speed.

 

    dZ.

Edited by DZ-Jay

Share this post


Link to post
Share on other sites
On 10/7/2020 at 1:27 AM, gar0u said:

Maybe I'll work on "Zork" so we can have more text in games?  I know we don't have the same restrictions with emulators and other tricks--even putting memory right on the cartridge was a good hack.  But I enjoy working within the constraints of the original system--so far.  I'm just dipping my toes in the water.

If you need more memory, bear in mind that using JLP gives you a little under 8K of additional 16-bit memory to work with.  It also provides for real-time multiplication and division, if that helps.

  • Like 1

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
Sign in to follow this  

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...