Great Exploitations

I have a suggestion...

 

To me, it's a little frustrating wandering blindly through a maze, only having to backtrack from a dead-end. The appeal of the original game was being able to see where you were going, and planning a route. While that won't work in this version, there might be an alternative.

 

If the player is going in approximately the right direction (say, within one or two branches of the correct path), the computer would let them know with a "warm" indicator (maybe the player's color). If they were close to the end, and on the correct path, it'd be "hot", and if they were way off the mark, it'd be "cold".

 

Just some food for thought.

No room for optimization of the game logic? How much room do you think you'll need for a selection screen?

 

EDIT: Only allowing block placement on every other position kinda drives me crazy. I'd prefer that blocks in all positions be allowed but, if that won't work, some kind of indicator (like changing the color of the player) that shows when you can place a block would be nice.

 

The way to remove blocks is nifty, though.

Now here's the problem - I think I should also put in a selection screen in the upper 2k as well, but this will need to run again, but will be wiped out by the maze. But this is a Supercharger, so in theory I could reload the upper 2k? Can this be done automatically, or with minimal annoyance to users of a real SC/CC/CC2?

 

Yes, technically possible, but except on a CC2 it would require the user to play the right track.

I have a suggestion...

 

To me, it's a little frustrating wandering blindly through a maze, only having to backtrack from a dead-end. The appeal of the original game was being able to see where you were going, and planning a route. While that won't work in this version, there might be an alternative.

 

If the player is going in approximately the right direction (say, within one or two branches of the correct path), the computer would let them know with a "warm" indicator (maybe the player's color). If they were close to the end, and on the correct path, it'd be "hot", and if they were way off the mark, it'd be "cold".

The problem is that the 2600 doesn't actually "know" where the correct path is. There are algorithms to determine this, but they would require too much RAM/cycles.

 

I have actually found that you get better at solving mazes while playing this game. My record now is 3:47. A good strategy is to move to the upper right whenever possible.

 

If it helps, a program will be included that will create any maze on your PC, which can then be printed out. (The old program doesn't work, as the maze generator was improved on the 2600 but not the PC... yet.)

 

No room for optimization of the game logic? How much room do you think you'll need for a selection screen?

 

EDIT: Only allowing block placement on every other position kinda drives me crazy. I'd prefer that blocks in all positions be allowed but, if that won't work, some kind of indicator (like changing the color of the player) that shows when you can place a block would be nice.

200 bytes is pushing it for a selection screen alone, much less additional game features on top of that.

 

There is one digit free in the score - I could place an icon there.

 

Now here's the problem - I think I should also put in a selection screen in the upper 2k as well, but this will need to run again, but will be wiped out by the maze. But this is a Supercharger, so in theory I could reload the upper 2k? Can this be done automatically, or with minimal annoyance to users of a real SC/CC/CC2?

 

Yes, technically possible, but except on a CC2 it would require the user to play the right track.

So does this mean that I'd also need to create a multiload binary, or could it all be done within the 8448 byte single load image?

 

For that matter, does a regular multiload game (such as Leprechaun) require selecting the track as well... so although inconvenient, it is expected?

No room for optimization of the game logic? How much room do you think you'll need for a selection screen?

 

EDIT: Only allowing block placement on every other position kinda drives me crazy. I'd prefer that blocks in all positions be allowed but, if that won't work, some kind of indicator (like changing the color of the player) that shows when you can place a block would be nice.

200 bytes is pushing it for a selection screen alone, much less additional game features on top of that.

If you have 4K of game logic, written in the last couple of weeks, unless you are the worlds greatest off-the-cuff coder - and I'm not ruling that out - then there *must* be tons of room for optimization in there. Go Fish! 1K started out at about 1.5 K. Granted, it was one of my first projects. Nonetheless, I was able to not only optimize 0.5K out of it, but also add tons of additional features (like the sun, the different shades of water, and the fish being darker the lower in the water they are).

 

If you could free up another couple of pages, 500+ bytes should be enough to get a simple selection screen in.

There is one digit free in the score - I could place an icon there.

No room for optimization of the game logic? How much room do you think you'll need for a selection screen?

 

EDIT: Only allowing block placement on every other position kinda drives me crazy. I'd prefer that blocks in all positions be allowed but, if that won't work, some kind of indicator (like changing the color of the player) that shows when you can place a block would be nice.

200 bytes is pushing it for a selection screen alone, much less additional game features on top of that.

If you have 4K of game logic, written in the last couple of weeks, unless you are the worlds greatest off-the-cuff coder - and I'm not ruling that out - then there *must* be tons of room for optimization in there. Go Fish! 1K started out at about 1.5 K. Granted, it was one of my first projects. Nonetheless, I was able to not only optimize 0.5K out of it, but also add tons of additional features (like the sun, the different shades of water, and the fish being darker the lower in the water they are).

 

If you could free up another couple of pages, 500+ bytes should be enough to get a simple selection screen in.

There is one digit free in the score - I could place an icon there.

The 200 bytes is after doing optimizations. It wasn't hard to fill up 4k given that the code contains a non-trivial maze generator, maze solver, pixel plotter and reader, as well as a scrolling engine and progress bar. The actual "gameplay code" is not too big - it's all of this other stuff that takes up all the space.

 

The apparent "coding speed" is merely due to the relative ease of programming in a high-level language compared to asm, rather than exceptional programming skill.

 

In order to free up 500 bytes, I'd probably need to convert all of the bB code to asm. But I'm not too thrilled about that idea. If multiloads are not a good idea, I'd rather just keep the game selection simple - like the old Atari games that just showed the game number on the screen.

Holy smokes! I didn't realize that big chunks of this (all of this?) were in bB! Pretty impressive.

 

But - no wonder you ran out of room.

 

 

 

Holy smokes! I didn't realize that big chunks of this (all of this?) were in bB! Pretty impressive.

 

But - no wonder you ran out of room.

 

 

 

I'd say 20% of the bB code is inline asm. It's the most asm I've added to any bB game so far.

 

I decided that instead of adding native SC support to the bB compiler, I would write a bunch of supporting asm libraries for things like bankswitching and RAM access and glue them together in an includes file. The result was easier (for me) and more versatile.

Now here's the problem - I think I should also put in a selection screen in the upper 2k as well, but this will need to run again, but will be wiped out by the maze. But this is a Supercharger, so in theory I could reload the upper 2k? Can this be done automatically, or with minimal annoyance to users of a real SC/CC/CC2?

Yes, technically possible, but except on a CC2 it would require the user to play the right track.

So does this mean that I'd also need to create a multiload binary, or could it all be done within the 8448 byte single load image?

 

For that matter, does a regular multiload game (such as Leprechaun) require selecting the track as well... so although inconvenient, it is expected?

Each load (which may replace 1 to 24 pages (256 bytes)) is a separate 8448 byte file. (Although each SC format file is 8448 bytes it represents a variable length sound recording.) Each SC format file contains a load number which is provided to the BIOS load routine. (Unfortunately, the original SC doesn't indicate which load is required, something I will need to address in the documentation for Leprechaun.)

 

Anyway, for Leprechaun, my idea is to have load #0 contain both the game code and the data for level #1. Other loads will only contain the 1280 bytes of level data. (With load #1 to quick-load level #1 to restart.) On a SC or CC1 the player would then play the right track, while on a CC2 it would auto-load the right level right off the MMC.

You could modularize blocks of code depending on what game mode you are in (menu, maze generation, main gameplay). You don't need all these features taking up space at the same time.

 

There is a way to do autoloading on any Supercharger-compatible device. CC2 does this automatically. Cuttle Cart 1 or Superchargers should be able to accomplish this by requesting the load ID by shooting a byte of serial data down the 2nd controller port. A PC would be running a terminal program that allows for scripting (I'm planning to use Tera Term with the Chimera project, at least initially). The scripting engine waits for input and uses the byte value to construct a filepath to the appropriate BIN file and shells out to Makewav. It sounds more complicated than it is. It sounds like a good solution unless you wanted to use the 2nd controller port, but it may be possible to have a multiplexer type device to share the port like what Supercat has been talking about on and off.

 

I was hoping that Leprechaun could use this scheme because you could then easily scan forwards and back through the levels as the XEGS Lode Runner cartridge does.

 

BTW, I will accept hybrid bBasic/Supercharger games in the contest as Supercharger games. I could use more entries.

You could modularize blocks of code depending on what game mode you are in (menu, maze generation, main gameplay). You don't need all these features taking up space at the same time.

I've been thinking about this, but it looks like I may not need to use multiloads for this. My game takes up the full 6k, but doesn't need the upper 2k until a maze is generated. So upon startup, this 2k could contain a selection screen and code that "builds" parts of the lower 4k differently depending on what the game options are. The disadvantage is that you will need to power cycle to change options, but you can play multiple mazes with the same options. I think it will be slightly less annoying this way.

There is a way to do autoloading on any Supercharger-compatible device. CC2 does this automatically. Cuttle Cart 1 or Superchargers should be able to accomplish this by requesting the load ID by shooting a byte of serial data down the 2nd controller port. A PC would be running a terminal program that allows for scripting (I'm planning to use Tera Term with the Chimera project, at least initially). The scripting engine waits for input and uses the byte value to construct a filepath to the appropriate BIN file and shells out to Makewav. It sounds more complicated than it is. It sounds like a good solution unless you wanted to use the 2nd controller port, but it may be possible to have a multiplexer type device to share the port like what Supercat has been talking about on and off.

 

I was hoping that Leprechaun could use this scheme because you could then easily scan forwards and back through the levels as the XEGS Lode Runner cartridge does.

If you get the details worked out, I'd consider it, as it would solve the issue with non-sequential loads. But there's still the issue that the last page of bank 1 gets wiped out after every load.

 

Also, I may end up using the right joystick in some of the options.

BTW, I will accept hybrid bBasic/Supercharger games in the contest as Supercharger games. I could use more entries.

Sounds good... I don't expect to win though. (BTW, I will not be entering the bB coding contest... You know, personal ethics... | )