itch.io

Hy. It has proven worthwhile for me, to take a closer look at this again, as it led me to update the SD2IEC firmware to the very latest version now, which is "SD2IEC V1.0.0atentdead0-57-ge2dd332". My previous version wasn't actually that old and I never had problems loading a game with it. Therefore I had assumed, that any subsequent updates, were relatively minor. An impression I also gathered from the texts on the SD2IEC website, to every of these updates. As it turns out, that wasn't the case, because now, with the latest firmware version, the situation looks a bit different, when it comes to your "Nuts & Dolts" game.

(A) when I now turn off my FC3 cartridge with the "kill" command in the BASIC screen and then load your game with the LOAD"boot",8,1 command, everything seems to work correctly at this time, because suddenly, I have music in the intro-picture now (which I didn't have before) and I see no more graphic-bugs in the sprites of the game, when I start the first level.

(B) when I load the game with the FC3 active, it loads alot faster, but sadly, there are the same problems, I had described earlier. Here the firmware update didn't change the situation. When loaded with the FC3, there's no music, when the intro-picture of the game is visible and the red LED blinks in that moment. When I press SPACE next, the game-menu appears and the red LED blinking is over. No more red LED and the menue is there (but also no music in the menu), but when I start the first level next, in the most cases (but not in all, as I already mentioned), I have some graphic-bugs on the walking sprites and they are partly destroyed. In rare cases (about one or two attempts out of ten), no graphic-bugs appear and it seems to work correctly, but there must still be a problem, because the loader seems to be unstable and already the missing music in the intro-pic and the game-menu, together with the blinking red LED, makes it clear, that something's wrong, when the game is loaded with an active FC3.

That’s how things stand in the moment. Fortunately, everything seems to run bug-free now, if I disable the FC3 cartridge. The downside is, that the loading of the game takes about six times as long then. Perhaps there’s still something that can be done here, given that I generally have no issues with 99% of C64 games, when loading them via the FC3 fastloader. I am sure, other FC3 users can confirm this, as the module's fastloader is highly compatible. Of course, it’s not strictly necessary, to make the game’s loader compatible to it, but it would be a nice touch, since the FC3 is quite widely used in the C64 scene (especially when SD2IEC's are involved, because its fastloader also works on SD2IEC) and the cartridge makes loading, as well as reloading in the gameplay, alot faster. You can consider, whether you want to do anything further, to make this work, or not? At the very least, the game does run correctly on SD2IEC's, when the latest firmware is used and when it's loaded without a FC3 and its fastloader (and probably also without any other fastloader cartridge). Downside is, that the loading-time is quite long now, but it’s still manageable, though.

To answer your other questions. Nothing else is connected to the serial-bus of my C64 and I run the game from the d64. Have not tried it, when all single files of the game are copied directly to the SD-card in an own "Nuts & Dolts" game-folder. By the way, in addition to the official SD2IEC firmware, there's also another firmware by the user "Thierer." It works with a wider range of C64 fastloaders, allowing also many demos, that load additional data (reloading), to work on SD2IEC. But sadly this firmware can only be used on specific SD2IEC models, as it requires a 128KB microcontroller. Both of my SD2IEC units, for example, use an ATmega644, which only has 64KB of memory and it seems, there simply isn't enough free space left, for the modifications included in Thierer's SD2IEC firmware. When it comes to games, however, it doesn't make that much of a difference, since for about 90% of all C64 games, you can also find versions that work with the official SD2IEC firmware. For demos, though, it makes a big difference.

Nice game in the Gauntlet style.

I’ve tested the v1.1, by using my SD2IEC device, on which the latest official firmware from this website: https://www.sd2iec.de/ is installed. Unfortunately, I’m encountering some issues. It seems to work correctly in the VICE emulator, when true-drive emulation is turned off and virtual-device-traps are turned on. But on a real SD2IEC, there are problems.

While the game does load on my SD2IEC, it’s clear that something isn’t quite right during the loading-process, because the red LED on my SD2IEC lights up from time to time, which indicates a problem. When the game’s intro-screen finally appears, the music is missing, which is another sign, that something's wrong. Nevertheless, the game proceeds to the game-menu and I can even start the first level, but there are graphical glitches visible, because some sprites are corrupted. When I tried this, I tried it without using any of my cartridges, on the C64.

Then I also tried it, using my Final Cartridge 3, because the FC3’s intern fastloader is compatible with the SD2IEC and the overall loading-process is much faster then. But the same problems persist. Again the red LED on the SD2IEC lights up occasionally and graphical glitches almost always occur. I write "almost" because on one occasion, out of about ten loading-attempts, there were no graphical glitches, even though, I followed the exact same loading-procedure as always. It seems, the loader is somewhat unstable, causing issues most of the time, with only rare exceptions.

Something's clearly amiss. If the loader were entirely kernal based, there shouldn’t be any errors at all, when I load the game with a SD2IEC, but here we have some. There must be an incompatibility somewhere. Maybe it has to do with all these small files in the beginning of the load-process? Therefore I also tried to load the game in an C64 emulator, to let it load behind this critical point, where the red LED flashes and then freeze it, at the intro-screen (when the music is playing in this screen). But it didn't work, when I load this freeze on my SD2IEC then, because on the SD2IEC, the game don't go on loading, from this freeze (while it works on a real 1541 floppy and on my 1541-Ultimate). Therefore also this is not a solution. 

Nice work, thanks.

"Deathchase" plays well and reminds me a bit of "Encounter" by Novagen, from 1984. Not sure, if A.I. was used or not, but good game regardless.

Here in this game, I’m hoping for an option in a v1.1, that’s similar to the one in its successor, specifically, an option that lets you turn off the long aiming-line, so that the gameplay is a real competition and not every shot hits 100% exactly, which makes the levels too easy, in the end. The ring can simply remain as it is, when the long aiming-line is selected, it doesn't look bad. For the short aiming-line, I would use this new aiming-point, that is used in the successor of the game now and a medium aiming-line isn't really necessary at all, if you ask me.

The game-menu would therefore only need a "Turn on helpline" function, nothing more. If it’s enabled, you get the long aiming-line, along with the ring and if it’s disabled, you just have the new aiming-point and no aiming-line. That’s all it would take.

Good game in the style of "Lemmings". Another solid one from you J5, nice work. I did notice one thing and wanted to give the info. Unlike your other games, this one isn't a onefiler and while "Nuts & Dolts" loads without any issues on my 1541-Ultimate and my standard 1541 and 1541-II floppies, it unfortunately won't start, when using a SD2IEC (stuck in the loading process). Since the SD2IEC is still widely used, it would be a bit sad, if its owners couldn't play "Nuts & Dolts". Would it be possible, to provide an additional version of the game, that uses a kernal based loader or a SD2IEC-compatible fastloader, such as Epyx Fastload or the "G.I. Joe" fastloader (which is used in the "G.I. Joe" game and which is also quite fast)?

The effort is hardly worth it. Here are two fairly inexpensive alternatives:

<(1)> Buy an SD2IEC. You can find them online as kits, starting at around 25,- EURO, or fully assembled, from about 35,- EURO. They allow you, to play many games directly from an SD card on your C64 and you can load the card with d64 and prg files beforehand, using your PC.

<(2)> If you still have an older PC with a parallel port, you could use an X1541 cable. There are several variations available, which allows you to connect a 1541 or 1541-II floppy directly to the parallelport of your PC. Using software like "Star Commander," you can then transfer files back and forth, between the PC and a disk, inserted in the 1541 fl.oppy.

Personally, I would recommend the SD2IEC.

Would be great, if you could do the same new features, that was added to this game here, regarding different aiming-lines and aiming-styles, also to your game "Bubble Pop - the sea" in the future. Because also this game is really great and would benefit from the changes.

Very nice, good work!

Sounds great, looking forward to the next versions. In any case, you’ve managed, to create a really good football game for the C64.

Everything good now in V1.23. Great!

Great football game! I did notice that sometimes, when a lot of players are bunched together, minor graphical glitches occur, like here for example in my screenshot, when the players were running off the pitch, at the end of the match.

Wow, the game has received a lot of updates, since the last time, I was here (about a month ago). The addition of visible tire marks on the road and the sound of screeching tires, really enhances the atmosphere during gameplay. Also the other new features are good, for example that the highscore-list is now saved to the disk and so on. The sense of speed, which I’ve always really liked right from v1.0 of the game, comes across even better now, thanks to all the improvements. It's really a good game now!

Two quick things. It would also be great, to have a small soundeffect, when other cars ram the player’s vehicle, or vice versa, because it feels a bit unnatural, to hear absolutely nothing, in such a moment.

And another thing I noticed. When you ram other cars from the side, they move a bit to the side (as you’d expect), but when other cars hit the player's vehicle from the side, the player's car doesn’t budge to the side at all. This is something worth reconsidering, even though it might make the game a bit more challenging, if all other cars could push yours slightly sideways, but it would feel much more natural, especially since it already works the other way around. The player's car doesn't have to be moved as far, as the police car can move the player's car, when it hits you from the side, but at least a little bit, also when all other cars hit it.

After all, the player's car isn't glued to the road and it should be possible for it, to be nudged or moved a bit, by all other cars (more of course, when bigger cars hit you). The player often can make a quick corrective steering maneuver in such a moment, to avoid crashing somewhere, but if you happened to be right near the edge of the road, at such a moment, well, then you’re sometimes just out of luck. It’s no different in "Burnin’ Rubber" either and it's more realistic.

Wow, you online again. :-) You are acting as fast as a computer. *lol* Thanks for the constant ultrafast improvements.

Thanks for the ultrafast v1.2 update, very nice!!! Now the aiming definately works better, with this bigger dot and together with the setting "short" for the "aim line", the game plays perfect then. This is how a Puzzle Bobble game should work. Great.

If I were you, I would make the setting "aim line short" the default setting, because normally these kind of "Puzzle Bobble" style games, should be played without a long helpline, because the user should also make mistakes in aiming from time to time, it's the game principle to do so and this is nearly impossible, when a long aiming-line (I call it helpline) is visible. But such a longer helpline is okay for absolute beginners, therefore it's selectable in the game-menue then, but I would not make this the default setting, if you ask me.

And another thing I found out in v1.2. The settings "aim line short" + "aim style doted" end up in the same result as "aim line short" + "aim style line" (because there is no visible line in "short"). This is a bit confusing for the users, because you generally expect something to change, when you adjust something in the settings. But this could simply be solved in a way, that the function "aim style" is greyed out (unusable) in the moment, when the user selects "short" for the "aim line". And when greyed out, always the word "doted" should be visible, for "aim style". Then everything would be totally clear for the users and there can be no more confusion, regarding this point.

Thanks for the quick answer and for accepting and implementing user suggestions (that’s certainly not something everyone does). Therefore, thumbs up.

Good playing CPU-opponents really would be a fantastic feature, though it seems tricky to pull off, in "Puzzle Bobble" style games on a 8bit computer like the C64, I guess. Unfortunately, on the C64, none of the existing clones of this puzzle-game includes CPU-opponents so far. Perhaps because it's difficult to implement a really good playing CPU?

On the other hand, there's a great "Puyo Puyo" clone named "Oy Up" on the C64 and this game actually features well-playing CPU-opponents. And the "Puyo Puyo" game-mechanic isn't exactly simple either, if you really want to play well. So, it's possible obviously. Also in other C64 puzzle-games like for example "Dr. Maria", CPU-opponents would be a fantastic thing to have. 16bit puzzle-games (on Amiga, MegaDrive, Atari-ST, SNES, PC-Engine) often have something like this, while in 8bit puzzle-games, you mostly don't have CPU-opponents, sadly. But for example the Game-Boy "Puzzle Bobble" games are surprisingly good and they have CPU-players and these are also acting good in gameplay, when you choose "hard" mode in these games.

I bought the game a few minutes ago and I must say, it’s a good game (A.I. support or not) and I like it. It's also great, that some features are included, that are missing in the first Bubble Pop , like for example the various selectable aiming-lines or a 2-player mode. I also find the other stuff, with these planets etc interesting. Solid game. I do have some suggestions, maybe you are interested.

(1) Could the short aiming-line perhaps be designed a bit different. At the moment, it's only a very small dot and it would make the aiming easier, if this dot would be a bit bigger. I have two suggestions, how it could be designed:

In both examples, the point is bigger and this makes it easier to aim. Maybe the short aiming-line could be changed, or another selectable aiming-line (different dot) like this could be added?

(2) The idea for a two-player mode, where players take turns shooting, is an interesting feature. Even better, however, would be an additional two-player mode, where the play-areas of both players, are visible on the screen simultaneously, allowing players to compete directly against each other. I mean a classic "versus" mode, which continues, until one player’s bottom row is reached (much like in the official "Bust-a-Move (Puzzle Bobble)" games). Such a versus mode always is the most fun, in games like this, when you have friends at hand, playing against you.

(3) Absolutely perfect would be, to integrate CPU-players, against whom you can play in versus mode, as is the case in "Bust-a-Move 2" for example, because then you don’t need to have any friends on hand for playing. *lol* But I also know, that adding a strong CPU playing-mechanism is a hard thing, especially on a 8bit computer like the C64. But maybe, at least a 2-player versus mode for two human players, could be added?

And a final question. Would it be possible, to add this aiming-line selection-feature, also to your predecessor "Bubble Pop" game? That would be great, ideally including the new design for the short aiming line (one of these bigger dots). Cheers.

I’d like to add one small point here. Packing the game is, of course, a good idea, and Exomizer consistently produces very small files, because it has an excellent compression-ratio. However, this often comes at the cost of longer decompression-times and with Exomizer, this process is significantly slower than, for instance, with TS-Crunch. Files packed with TS-Crunch are usually only marginally larger in size, than those packed with Exomizer, yet they often decompress nearly twice as fast.

It’s therefore worth trying both, timing how long it takes for the game to start, and then choosing the faster packer (this is my own approach, whenever I need to pack something for the C64, as the results vary from case to case). Sometimes one packer is faster overall, sometimes the other. But especially if you load files on the C64 using a speeder-kernel or a fastloader-cartridge, the decompression-time becomes even more significant, since the loading-time itself, is already drastically reduced. For this reason, TS-Crunch often is the better choice.

Great! Really nice work. Another good C64 game from Arlasoft.

Sounds good.

Ah, you're planning a sequel, that sounds good, looking forward to it. And yes, saving to the disk is definitely better, than just saving to RAM.

Yes, of course I will enjoy it, because it's simply a great puzzle game and I also enjoyed the first levelpack, that came out and have it played through. Maybe, when you have the undo-function ready, this feature could be included in the already released versions of the game afterwards? It's very often the case, here on the website, that a v1.1, v1.2, v1.3 etc, of the same game is released. You might want to think about it.?

Nice!

Just saw, that you released a new levelpack. That's great. Does this levelpack now has this undo-function included?

Nice changes. I tried V1.0.5 today. Still a sound-effect is missing, when you bump into other cars, or when the other cars bump into the players car. Such an effect would be nice for the atmosphere, because total silence in such a moment feels a bit unfamiliar. The feeling of speed, when the car accelerates, is really good into your game, I like this. It's a stronger feeling of speed for me, than in the original "Burnin Rubber" game on the C64, therefore good work. I also like that other cars can now be pushed, when the player bumps into them. You see, that they are moving now. Also the players car can be pushed a bit, when the others bump into him, that's also good.

I have one suggestion here. A bit more different car-types could be integrated with different looking and different sizes, because at the moment alot of them have only different color and everything else is the same. And when the player bumps into certain cars then, the size of these cars could matter, when it comes to the point, how much they can be pushed/moved to the side. Cars that are bigger than the players car, could only be pushed a bit, while smaller cars could be pushed/moved stronger and the same vice versa, when these cars bump into the players car. A bigger car, can move the players car more, while a smaller one can't. Just a suggestion of course, but I think, something like this, could bring some interesting new aspects into the game and when I am right, in the C64 game "Burnin Rubber" it's a bit like that (car-size definately matters there and there are also alot more different looking car-types) and also in the game "Spy Hunter", the size of the opponents car matters. Maybe you like the idea, therefore I mention it?

And last question. When I tried the game, the highscores were not saved to the disk, I saw (when I loaded the game again). Is this normal, or do you have to press a specific button for that, before closing the game? Normally the scores should save to the disk and be there, when the player loads the game next time. But I tried by using a SD2IEC on a real C64, maybe this was the problem, because SD2IEC's are not 100% compatible. I must try again in a C64 emulator.

Maybe a similar track, to the original one? Or perhaps the original track could be made accessible, via a hidden feature or easter-egg? (something like that, often happens in games).

Great  "Burnin' Rubber/Bump`n`Jump" clone with good control and I also like the look of the cars. A selectable-function between music+sfx, only music and only sfx in the game-menue would be nice, together with a new sound-effect, when the player bumps into other cars, or other cars into him, because at the moment, this happens in silence. Really nice work and the feeling of acceleration comes across well here, by the way.

 I do have one small criticism. Forcing opponents off the road, causing them to lose a life in this way, is significantly harder, than in the other two mentioned games on the C64. Of course, you can kill them all quite easily, by jumping on them, but pushing them off the road isn't easy to pull off. But maybe that's how it's meant to be? Good game, in any case. And by the way, a simultaneous 2-player mode would be awesome here.

I will and I do give the matter some thought and consider it carefully, before making any suggestions. I wouldn't even bother proposing anything pointless. Since I’m not a programmer, though, I can’t always say, whether it’s technically feasible to implement, exactly as proposed. :-)

You're welcome. I'm always happy, when someone actually takes up suggestions (and I always have alot of suggestions to many games *lol*).

Nice. The game might seem relatively simple, in graphics and gameplay, but it offers a satisfying feel, at least for me, partly due to the inertia in the control of the butterfly, which is something you can easily get used to. And I also like the game's overall look. Simple but gives good feeling, sums it up for me.

Your plans with that stars-system sounds interesting. But, just wanted to mention, you don't necessarily need other players around, to want to know your best score, because after all, you don't want to have to write it down every time. Plus, there are times when you might want to show your highscore to a buddy, to compare it with his best score, and so on. So, a highscore-list definitely serves a purpose, even if you're playing solo, just wanted to mention that.

That said, the star system you described, sounds pretty good, too, as I already mentioned. Fewer moves, to complete a level, could/should also mean earning more stars, that could also rise the motivation. However, if a list for the score isn't planned, the game should at least display the highest reached score so far, somewhere on the screen and save it to disk, when a player makes a new highscore. Maybe a player wants to know later on, how many stars he already had achieved, after all. So, these are all just suggestions, of course, it’s up to you, how you actually do it.

255 positions is really alot. I think, that should be more than enough, for any rewinding (or undo) function. Good work. What you mentioned about the falling, also makes sense, of course.

And also this idea with the stars is good, because the game needs something like a reward-system, that increases the motivation of the players. When the game give stars, the game also needs something like a highscore display, showing the highest star-value, achieved so far, somewhere on the screen, or in a list, at the end of the game.

Another idea to that reward-system point, could be the following. It could also be made in a way, that two separate highscore-lists would be created (that also save the scores to disk by the way), depending on the user's settings for the rewind (undo) function, in the game-menu, i.e., whether they use this function or not. If they use it, their score goes in one list, if not, it goes in the other list. The game could have a point named "highscores" in the game-menue, where the user can see the saved highscores and where the game shows both lists. At the top of each list, could be written, if the rewind function was used or not, that it's clear for the players. That way, by having more than one scorelist, the point-results remain separate, they don't get mixed up and everything stays fair (because the game is easier with rewinding).

At the top position in each highscore-list would be the player, who used the fewest moves, to complete the levels (the game already tracks move counts). But the scorelist should not show moves, but it could show points. For this, the number of moves could be converted into points, but inversely of course, so that fewer moves result in more points and the player with the most points, stays on top. Each scorelist could, for example, show the best 10 scores so far. If a player uses the "select level" function in the game-menue and doesn't start from the first level, his score shouldn't be included in the scorelists at all. That would naturally skew the results, because the same conditions must apply to all scores in the list, of course. Alot of games use highscore-lists on the C64 and some games also use different scorelists, often depending on the difficulty-level, you've set in the game-menu, or sometimes it also depends on other factors, like the game-speed or something else, it always depends on the specific game, what settings are available. And that multiple scorelist thing works very well, if you ask me, because it guarantees fairness.

This suggestion with the two scorelists, could maybe also be used for your idea with the stars (instead of points). Then the scorelists would show the players with the most stars. In this case, because we have two seperate lists, it would not be necessary, that players, who use the rewind function, receive fewer stars than the others, since the results would be separated in two scorelists anyway.

Ah okay. I didn't knew, that there's not enough memory, to display every single step of the snake, while rewinding. In that case, your undo-method obviously has to work in discrete steps, I understand. Makes sense, of course. Nevertheless, it might be worth considering, how the firebutton handles the function and whether the squares, when the undo-routine runs, go back automatically, while the firebutton is held down, rather than requiring the user, to press the button repeatedly, for every single square. But go ahead and do everything the way you think is best. You know more about programming than I do, I am sure. The finer details of the function can always be tweaked later on, once the structure of the function is in place.

In fact, such an undo (or rewind) function like this, is interesting for C64 games in general, since, as far as I know, no C64 game features anything like that so far. This makes it a point of general interest for C64 games as a whole.

Looking forward to this new version, thanks for integrating my suggested feature. Each press one square, you wrote, this can sometimes mean alot of presses. Therefore I thought, the game could rewind automatically, as long as the player holds down the firebutton. That would be an alternative, that could be tested, in comparison. The automatic rewinding could begin, after the firebutton is pressed for 2 seconds. A shorter press, would restart the level.

Right. When I suggested the idea with the fire2 button, I had completely forgotten, that "Gravity Snake", unlike 99% of all other C64 games, doesn't actually need the standard firebutton in the gameplay (okay, for restarting the level, but not for controlling the snake itself). This means, fire1 is not really needed so far.

Then, logically, you wouldn't need a fire2 button support at all and of course, fire1 can be used for the rewinding process. In this case, I would set it similar, to what "Vivid Warthog" also had suggested, that the game rewinds, as long as the player holds down the fire1 button. If the player release this button, he can start playing again, from this point on. That would be a pretty intuitive approach, if you ask me. The rewinding could begin, after the player had hold the fire1 button for 2 seconds.

And the "level restart" function could be mapped to a short single button-press. A short press on the firebutton, normally is alot shorter than 2 seconds and as a side-effect, this would have another advantage. Alot joysticks have a autofire-button and then also this autofire-button could be used for level-restart, because autofire is alot of short button presses in a row.

Additionally I would also use the Space-Bar key for level-restart, because in alot emulators today, the user can remap a keyboard-key to a controller-button and then these users can do this with the Space-Bar and they would have the level-restart on another button on their controller, than the rewinding-function, which would also be nice. Then you don't need to take care, how long you press this button.

And some controller-adapters for the real C64 machine, like for example the GenAssister, plug into both joystick-ports simultaneously and with such an adapter, the player has the fire-function of the first joyport directly on a controller button too, and this fire action corresponds to the Space-Bar in most games. Therefore this adapter is great for Shooters on the C64, because in these games, often the Space-Bar is used for "calling a drone" and "send away a drone" and then you have this feature directly on a button of your controller too, besides the normal fire function on another button. And when "Gravity Snake" uses the Space-Bar too, then this also applies to your game.

Sounds very good, looking forward to this feature! It could for example be included in a way, that the player had to stay on a keyboard-key, to rewind the gameplay and as long, as he holds down this key, everything runs in reverse. If the player releases the key, he can continue playing the game from this point on.

A nice side-effect here, would be the following. There are some C64 emulators, like for example Hoxs, Denise or CCS64, that allows the user, to remap keyboard-keys to buttons on the controller. Then the player could rewind in the game, directly on his controller, offering excellent handling. And I also have another idea, regarding this point, that would make it possible, on a real C64 as well.

The C64 supports a second firebutton (Pot-X) and there are some joysticks available, that have such a "Fire2" button (e.g. the "ArcadeR" or the "Cheetah Annihilator" and also certain joystick-adapters). If the rewind function were possible not only on a keyboard-key, but additionally also with Fire2, then owners of the mentioned joysticks, could also rewind the game, directly on their controllers, even on a real C64.

An Undo system sounds interesting. Or maybe something like a Rewind function (similar to what you had written with "back a few spaces"), using a specific keyboard-key, that reverses everything on the screen, back to a point of the player's choosing, determined simply by holding that key down, for as long as you want to rewind. That would also work. But I can not say, whether it's technically possible on a C64, to rewind the entire gameplay, by more than just a few centimeters?

Really a nice game, also the new bonuspack is great, but also not easy. I spent the last hour, playing this new level pack, making it as far as level 7 and I noticed something, while playing, therefore I wanted to suggest a new function, in the menu of the game. 

It would be great, if the game-menu included an option, so that, when you die in the game, you aren't sent all the way back, to the start of the level, but instead, you’d restart from that point, where you collected the last fruit. Of course, there must be an exception in some cases, for example, if you had collected the last fruit in the wrong order and maneuvered yourself into a dead end, where the level is unsolvable in the end. Then, in such cases, the game should sent the player back, to the last fruit collected in the correct order (for solving the level) and allowing you, to continue from that point on.

Why am I suggesting such a function? Well, while solving the first three levels of the pack, I frequently had to replay the same opening-sections of some levels (after I’d already figured out the correct path), just to reach the point again, where I had lost the last life and try a different approach, at that point in the game. Having to replay the beginning of some levels over and over again, got a bit annoying, so I started, using emulator savestates (I played the game in Denise emulator today). That way eliminated the tedious repetition and letting me focus on the specific point, where I’d last lost the last life, until I found the solution at this point.

Sure, this makes the game a bit easier overall, that's clear, but it removes the frustration and keeps the experience consistently fun, when you can continue from the last (correctly) collected fruit. I thought, it could be a nice idea, if something like this, weren't limited to emulators (because mostly you play on the real C64 and there you don't have something like savestates) and if such a function would be a built-in game setting, offering a slightly easier gaming-mode to the user. Only slightly easier, because in the end, you also have to find the solution for every level, but without the need, to play the beginning of each level, over and over again.

What do you think? Of course, this should just be another game-mode and selectable, in the menu of the game and the standard gameplay, as it currently exists, should remain unchanged. Then the players can decide, how they want to play?

Cool project and really a very impressive 3D engine, that runs good on a stock C64. I wouldn't have thought, that was technically possible before, in this quality. Also nice, that it works on SD2IEC too.

Great work. And I have a suggestion for an improvement of the control in the game. The C64 can also support a second firebutton (Pot-X) and some joysticks, like for example the "Cheetah Annihilator" or the "ArcadeR" have such a Fire-2 button and also some joystick-adapters (GenAssister for example) have it and in well known C64 emulators, you have Fire-2 anyway. A very nice thing for the control in the game would be, when the strafing (left/right) of the player, could be enabled, by holding down this second firebutton, while moving the joystick in the left or right direction. And when the player let out this firebutton and move the controller left/right, then he should turn around, in the game. 

That way, the player would have almost everything, needed to navigate through the levels in a comfortable way, right on a joystick. He can run through the levels, turn around directly with the joystick and when he got involved in a fight, he can start strafing and shooting, by using the two firebuttons. And in C64 emulators, for instance, the user can map this Fire-2 firebutton, to any button on the PC joystick/gamepad (because all the best C64 emulators support this second firebutton), making it perfect for that as well.

And one more small suggestion. In the first level, the color of the soldiers' uniforms, often is the same color (light-brown/orange), as the walls, making it often difficult, to spot the soldiers, when they in front of a wall, or causing them, to be seen only very late, when they already very close. Perhaps another color, for example a different shade of gray, could be used here, for the uniforms, instead of this light-brown? That would make the soldiers much easier to distinguish from the walls and would guarantee a better playing quality in this first level.