gar0u Posted September 26, 2020 Share Posted September 26, 2020 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? Quote Link to comment Share on other sites More sharing options...
gar0u Posted September 26, 2020 Author Share Posted September 26, 2020 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. Quote Link to comment Share on other sites More sharing options...
artrag Posted September 26, 2020 Share Posted September 26, 2020 (edited) 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 September 26, 2020 by artrag Quote Link to comment Share on other sites More sharing options...
+nanochess Posted September 27, 2020 Share Posted September 27, 2020 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. 1 Quote Link to comment Share on other sites More sharing options...
TR4SHD4T4 Posted September 27, 2020 Share Posted September 27, 2020 I'm into it. I like the ideas of Unique games/randomly produced story lines. I think at the end of the day we're making games for each other. Quote Link to comment Share on other sites More sharing options...
Zendocon Posted September 28, 2020 Share Posted September 28, 2020 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. 1 Quote Link to comment Share on other sites More sharing options...
+cmadruga Posted September 28, 2020 Share Posted September 28, 2020 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. 1 Quote Link to comment Share on other sites More sharing options...
carlsson Posted September 29, 2020 Share Posted September 29, 2020 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. 1 Quote Link to comment Share on other sites More sharing options...
gar0u Posted October 3, 2020 Author Share Posted October 3, 2020 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. 1 Quote Link to comment Share on other sites More sharing options...
Zendocon Posted October 5, 2020 Share Posted October 5, 2020 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. Quote Link to comment Share on other sites More sharing options...
gar0u Posted October 7, 2020 Author Share Posted October 7, 2020 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. Quote Link to comment Share on other sites More sharing options...
+DZ-Jay Posted October 7, 2020 Share Posted October 7, 2020 (edited) 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 October 7, 2020 by DZ-Jay Quote Link to comment Share on other sites More sharing options...
Zendocon Posted October 9, 2020 Share Posted October 9, 2020 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. 1 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.