January 2016 Retrochallenge 9: 10-Liner Puzzle Game "Dash" (Update)

Je me baise bien!

My fellow MC-10er from the Yahoo group, Robert Sieg, showed me how to access 256 character long lines on the MC-10 instead of just being stuck with the standard 128. He used the MCX version of Basic (a modified version made by Darren Atkinson from the group), which adds all kinds of commands and improvements, including longer lines. The downside is, one cannot use any of the special added commands, since regular MC-10s wouldn't be able to run the program. The upside is that the regular MC-10s can load programs with longer than 128 char lines just fine! So edit in MCX, CSAVE and then load and run on a regular MC-10!

With all the extra space I have added a few functions to Dash. Now the program displays the "code" for whatever puzzle is currently on-screen. This is really just the four peek addresses of the random number generator seed, which is a 32 bit number stored in 4 bytes (thanks to Darren for informing me where they were located). So if one discovers a very interesting puzzle, the code can now be written down. Also, during any game hitting "P" will call a routine that allows you to enter the four numbers and poke them back in to memory and then display that specific puzzle (after you also enter the difficulty Level #, which also must be recorded).

I know its unlikely that legions of people will be clamouring for such a feature, but its nice to have. I've run across a few puzzles that were quite challenging and regretted not being able to retrieve them in some way. My son told me that some games like Civilization and Minecraft, actually have features to "set the seed" so that specific "randomly" generated worlds can be recreated by other people. In fact, he told that alpha codes can used and some have been discovered to strangely correspond to the worlds created, like the word "hell" ends up creating a largely lava world in Minecraft, or something like that...sounds a bit mythical, but...

So now there is something like that, in miniature, for the MC-10.

Robert also did a modification where he replaced many commonly used multiple digit numeric constants with single character variables, which could now be added to a longer line 0. I reordered his variable declaration just a little to put some of the more critical main loop and commonly used variables earlier in the list.  It's my understanding that earlier is better as the variables get stored in a lookup table and the earlier they are in the list the faster they can get used by the interpreter.  I therefore put variables only used during initialization later in the first line. Don't know if any of these ideas are true, but Robert's use of single variables certainly produced a quantum leap in speed.

Here's some of what he wrote:

Hi Jim,
First I carefully added variables that were not used before by the program using a text editor.
Then once I was happy with all the changes I saved the text file and loaded that into the MCX with quicktype because the MCX has a longer 256 limit per line. Then I saved that loaded text file with a CASVE. Now the good old MC-10 can load it and run it.
I was surprised that the speed increased so much.  The way I checked the speed was to clear the top and have the hero ----> X walk across the entire screen timed. In both versions I got 16.13 seconds for the original and 12.92 seconds for the optimized.
12.92 / 16.93 = .8009 ----> a %20 difference. kind of shocking I was thinking it would be maybe half that.
Sure we could do a dual authorship but the prize is offered at the expo right? Are you going?
By the way it could be tweaked just a bit more but it can be quite time consuming to do the conversion.
Warm regards,
Robert

Since Robert had been so helpful, I put his name on a new title screen I added to line 0.

Robert also made some suggestions about scoring.  It became clear that since he was playing the game by himself that he needed some way to see whether he was improving in his play.  I, on the other hand, was primarily playing the game against my son and therefore repeating maps with him trying and then me, and so on.

It became clear that there were possibilities for whole bunch of alternative "play modes."  If it weren't for the 10-liner restriction these could be easily handled in one program with some menus.

What I added to try to satisfy some of these different ways of playing was a timer function and report of the number of tries for each puzzle. These were in keeping with what my son and I had been doing. We would take turns trying to complete a map, and the person who got the highest score and lowest time and # of tries was "the dude" for that puzzle. I guess you could call this "two-person" or "competitive mode."

I think what Robert wanted was something that could be called "tournament mode." A person tries to get the best total score for a fixed number of maps and also gets rewarded from trying maps of higher difficulty level. So I also added an aggregate score for all maps completed that takes into account the time factor in the scoring for each map and the number of tries needed for the total number of maps completed, etc.

I was also able to combine some lines from the old program and use more IFs instead of an ON-GOTOs (256 chars to play with certainly is very liberating), which freed up a line for the puzzle # entry routine that allows the player to select specific puzzles.  Robert also pointed out a number of places where he though program logic could be rationalized, which was very helpful.

The biggest change that his feedback prompted was from a suggestion to add a "bomb" if there was a wall that totally blocked passage to the exit it could be removed. So I added a bomb (wait the NSC will flag this)-- I mean to say I added a routine to the game source code so the player can now blast virtual obstacles once per puzzle in our computer puzzle game;) Just hit the SPACE key and a series of reverse boulders will appear in the 4 cardinal directions around you. The player is able to move through these boulders. Blue wall units around the edge will not be destroyed, nor will regular boulders. However, the exit and diamonds can be destroyed so one must be careful.

I also added an auto level select feature where if the player just hits ENTER between maps the game uses the level selected for the last map.

I also streamlined the key entry routine quite a bit so the game no longer uses any Ctrl keys, just regular keys:

ASWZ to move
R to restart a map
N for a new map
P to enter a code for a specific map/puzzle (4 numbers separated by zeroes)
SPACE to blast around you.

I also changed the exit character to a reverse "E"

Now, I should start thinking about porting it to the Dragon and Coco.

Addendum:

After another set of helpful suggestions by Robert I made some more changes.
Now you can choose skill level at start-up. If you choose 1 then the program uses the standard boulder fall routine where only being in positions like this can kill you:
  @
X █
███
But if you choose 2 then any boulder falling next to you (or even just flying past) can potentially kill you such as:

@ 

X █

███

This makes skill level 2 much harder.  Score is also affected. Now the higher the difficulty level of the puzzle and the higher the skill level makes each diamond worth more.

Also different difficulty levels provide different numbers of bombs: 1-29=1 bomb, 30-59=2 bombs, 60-89=3 bombs.