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.
Here's an example of how undo works in the game. Currently, it happens one square at a time with each press of the fire button. Take a look at the following link: https://x.com/Naufr4g0/status/2096164494657380845?s=20
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.
Programming the game to rewind time seems simple, but it's more like programming a game that runs backwards like in the movie Tenet (there's not enough memory to store everything on the screen for every previous moment, so you have to reconstruct what happened from the limited data you have).
Anyway, I'm just testing the undo routine right now, which is why I used the easiest way to implement it in the game. I'll use a different approach later.
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.
The problem with the snake's lack of memory for its positions arises from the fact that it can fall at certain points. If it moved like a classic snake game, the problem wouldn't exist. When the snake falls, it changes not only the position of its head, but also that of the body behind it, positions that can't be used, as is, when going back in time. However, if I had programmed the game with the idea of taking steps backward, I would have chosen a different approach to developing the code, probably.
In any case, development is progressing, and I've solved most of the issues. There's no problem adjusting the rewind speed, so I think I'll do as advised. The only limitation: you can rewind a maximum of 255 positions, which is still a decent number, given that most levels take about 100 to 150 moves to complete.
I also thought about including achievements for each level: one star if you complete the level, two stars if you complete it without using rewind, three stars if you complete it without using rewind and in a certain limited number of moves.
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.
Your proposal is very interesting, but most players will play the game alone. Since there's no online leaderboard, the scoring system doesn't make much sense. However, the star system could provide satisfaction, encouraging players to complete the game 100%.
I could even add an additional star (perhaps a trophy) to those who complete the level in a very limited number of moves (a number I'd have to figure out myself).
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.
