itch.io

Hy, thanks for answering. Okay, when a 2-player-mode, also against another human player, is technically a problem on 8bit systems and when the game should be the same, on all systems, then sadly nothing can be done. It was just a suggestion, because in my experience (and i play Dr. Mario very often on different systems, e.g. on the SNES), playing against a human friend or against a good CPU-player, always is the most fun in these games. Because in the levels, the gameplay is always very similar, but directly against another player, the game has more dynamism, because it can become more interesting, thanks to the pieces, you receive from your opponent, when he make combinations.

I hope, that the rotation thing (possibility to turn in both directions) could be integrated, because this is an important feature, especially in higher levels of the game. Often it takes too long, to turn three times to the right, instead of one time to the left. Best regards.

Sounds very good.

Looking forward to it. It's already a good game now and if it can be improved with a few tweaks, it will of course be even better.

Hy Lunoka. This is a great game and really nice, that it is available for alot different retro-systems. Good work! One question. Are there any plans, to add a two-player feature, since the game is obviously most fun, against each other? Selectable CPU-opponents would also be great, since you don't always have a second human player on hand.

And a second thing, that would be great. Users should definitely be able, to rotate the falling pieces in both directions (the systems for which the game is available at the moment, all support more than one button). This would be a very important feature, because in higher levels and especially, when the pieces are falling at a high speed, it's a huge advantage for the player, if he only have to rotate a falling piece one time to the left, for example, instead of three times to the right, because that obviously saves the player a lot of time. Therefore it would be great, if this feature were included in possible future versions of your nice game.

This suggested "random color-order" could be realized only as  a selectable function in the game-menue and the "normal color-order", which is already in the game, could stay like it is. Then users could choose, what they want and both sides (advanced players and normal players) could be satisfied. But okay, all theses things are only suggestions, of course.

Nice that you like my idea. I would just be interested to know, what exactly you mean by "Machiavellion"? When I google it, this word isn't exactly described in a positive way.

Sounds very good! Looking forward to this.

I took a look at this longplay and what would also make the game a bit more difficult, would be, if the color-order weren't always the same, but were randomly generated by the C64, before each level. Then the player wouldn't be able, to plan entire moves in advance, which would always play out the same way, if you played the game repeatedly. Because then you'd have to adapt your gameplay to the color-order randomly selected by the C64 each time. This could be realised by a click-function in the game-menu, that would offer a choice between "fixed color-order" and "random color-order".

Hy. Thanks for answering and the interesting technical infos. Yes, i know about this sprite-limit problem and the idea of software-sprites or the thing with the 8x8 matrix, sounds very interesting. I can't really comment much on the programming of the C64, because you will certainly know better, but these suggestions sounds good. Better than the idea with the porting to modern platform, because if you ask me, then that would take away a lot of the game's charm, because what's special is, that it runs on retro-hardware. But maybe some of your other ideas could be realised, sometime in the future?

On the C64 alot of programming-tricks where used, in the last years by different people, to realise unbelievable things in demos or games. I am always surprised, what is possible in the meantime, on a C64. Do you know the little demo "Field Sort" from Lft, this is also very interesting, when it comes to sprites etc (can be found on the CSDB, by the way). But, back to the topic. A 2-player mode would be really nice to have in your Randoom games, because games that can be played together at the same time, are often the ones, that are most fun. Perhaps a way could be found to include a second human player in the future?

And just a fast idea, but it could also be fun, if, for example in a 4-player mode, the other players were the objects to be hunted (the guards), or rather the one player, who had the right color. One player could always be the adventurer and the others the guards etc. Or the second human player could also be one of the guards, besides the other, cpu-controlled ones. Could also be interesting to play. Of course, you would have to think this through further, but then less cpu-controlled sprites would be needed and the second player would have a meaningful task in the game. But, just an idea.

Great game. I already liked the first Randoom game, and this one here, is just as good. It's fun to play. Good work. By the way, a two-player simultaneous function could be a lot of fun in both Randoom games. And I could also very well imagine a four-player simultaneous mode (using a 4-player-adapter). I am sure, it would be a great party-game, when you have friends visiting. There would be a lot going on then, on the screen, but it would definitely be a lot of fun. If multiple human players could play simultaneously, there could be different game-modes. For example, you could set it up, so that you could either play together as a team, to complete the respective levels together, as quickly as possible, or it could be set up, that the human players must play against each other, based on the principle, of who can defeat so many cpu-powered opponents the fastest. Just a few suggestions, that are currently popping into my head, as the gameplay would be really great for a multiplayer-game.

Sounds good.

Great little game with nice sprite-animations and I also like the controls. The cat is easy to control, once you get used to it, also when she's at higher speed. I recognized, that the highscore doesn't seem to save to the disk, if you get over 2500 points, but that might be a problem with the emulators, as I haven't played the game on a real C64 yet. I'll do that, though. Good work so far.

Nice idea, with this powerup in v1.3. Because of the porting - would be great, if you port the game to Amiga-500.

Only on the second floor in level 2, i have speed problems on my Amiga-500 machines (and when this level repeats itself, later in the gameplay, of course), when my sprite is on a conveyor-belt. The rest of the game really works very well, on 7MHz OCS/ECS Amigas. About this floppy-motor thing. I will look on the disk, if this file is there. If this is the case, you mean, that this problem is gone? I also asked this motor-thing, because in the last years, I've encountered more than one time, a problem with various new demos or games for the Amiga that were released on the Pouet.net, where the programers forgot, to reset the _MTR-Signal in the CIA or something similar to this and then the software sometimes goes on loading on real floppy-drives or the drive-LED always stays on, even when the Amiga game or demo, is already fully loaded and running. Maybe this also is a consequence of programming in emulators, not sure?

Works now, thanks. I really like the japanese level-order more. Had you recognized the other two mentioned things (floppy-motor and the problem in Lv2 on the second floor there, when running on the conveyor-belt)? The other three levels run well on A500, only in this second level there are some problems, but only on the second plane there, it seems. On a A1200, there's no problem in Lv2 (tested it today), so it has definately something to do, with missing speed on Amiga500 machines. Seems like Level2 needs more CPU-power, than the other three levels of the game. Can something be done here, then it would also run well overall, on A500 machines, or has everything already been maxed out?

Sounds very good, it's definitely worth a try. We'll just have to see, if it's too jerky then, or if it's still good playable with auto-frameskipping. Galaga is one of my favorite games, that's why I'm looking forward to this update. Same for Pooyan, i played it alot in different Arcades, back in the time. I guess, in Pooyan not much more can be done, to have it running in real fullspeed on A500 machines?

By the way. The Amiga is really lacking ports of some of the old Arcade-classics, for which there are good ports on other retrosystems (like for example C64, NES, A7800, etc). I was already wondering why, back then in the 90's, when i had my first Amiga500. So it's good, that you're bringing some of the classics over there now. Nice work.

Ah, it's autodetected. This is cool. I compared the speed in two emulator-windows at the same time, by emulating a Amiga500 in one window and a Amiga1200 in the other and the game is indeed playable on the A500, in this 25FPS mode. Sadly it does not run in real fullspeed, it seems, because it plays a bit faster on the A1200 (and of course more smoothly, because no frames need to be skipped, on the AGA machine). But nevertheless, like i already wrote, it's at least playable on the A500 now, so i think this 25FPS mode (every second frame skipped), was a good idea anyway.

One last question about this, because this frameskipping thing is interesting. I can remember, that you once wrote me on the webpage of your "Galaga 500" game, that this game also runs at a 25FPS-mode on A500 machines, but that it's still too slow on non-AGA-Amigas, because some of the code still has to run at 50fps (or something like that). But would it be possible, to give "Galaga500" an auto-frameskip mode for A500 machines, or would the frame jumps in the gameplay then be too large, making it run too choppy or jerky? Maybe it would be worth a try? Or perhaps, if that's not possible, an alternative mode, in which only every third frame is displayed and maybe the game could only then switch to this, when the A500 could not hold the fullspeed in the 25FPS mode anymore (e.g. too many opponents on the screen at the same time, etc) and otherwise run the game in 25FPS mode (as it is now)? Perhaps it could then maintain the full speed of the Arcade version on A500 machines then? What do you think?

Thanks for the infos. I tried it in different ways (write this in an extra-line of the startup-sequence, write it in the line in which "Prompt "Selection:>" is written, etc, but it don't work in all the ways i tried. How exactly must it be written there, in an extra line or behind some other stuff?

Maybe it would make sense, to make the japanese level-order a selectable point in this menue, that comes, when the user load the game (this menue, in which different things can be chosen, like manual, infos, cheat-keys and so on). Wouldn't that make sense? The Japanese level-order is the better one anyway.

Two other things I noticed while playing. (1) The floppy motor doesn't shut off after the game has loaded, i think this should be changed (better for the hardware).

(2) In Level 2 (the one with the conveyor-belts), the game runs a bit jerkily, especially when you are on the second plane, at least on my A500. Sometimes entire animations for the Mario character are missing then and he seems to disappear shortly and then reappears. The other three levels run perfectly fine on the Amiga500. I have a suspicion, as to what the problem in Level 2 might be. If Mario is on the conveyor-belts and runs in the direction, the belt is also running in that moment, he speeds up considerably and then the player can notice things like frameskipping alot more, which could be the problem here, on A500 machines (if the game runs in a 25FPS mode there)? Mario then runs jerkily and seems to disappear for a short moment and then is suddenly two steps ahead, when he reappears. Perhaps this could be fixed, by not running the game with frameskipping, in such moment, when the Mario sprite is on the conveyor-belts in the second level? I don't know, how much slower the gameplay then will be on A500 machines, because if that's too much, then this suggestion obviously doesn't make sense. But if it's not much, maybe it could make an improvement in this "disappearing reappearing" problem? I haven't tried the game on an A1200 yet, but I assume, this problem doesn't exist there, when the Mario sprite is on the conveyor belts.

Same here. I guess, it must have something to do with his controller.

Nice port, it plays good. What exactly must be changed in the startup-sequence, to have the other level-order? I read the entries there, but it's not clear, what to change exactly. 

Hy, one question. You wrote, the game has a 25FPS mode now. Does this mean, that, with this mode, it will run in fullspeed on A500 machines too? And if yes, how can this 25FPS mode be activated?

Nice, thanks for implementing. One suggestion more, for future versions of the game. The shield is on the Commodore-Key, i saw. It could additionally also be on Fire-2 (Pot-x) and also on Space-bar. The reason, this might make sense, is, that there are some controllers for the C64, that have a Fire-2 button (ArcadeR joystick, Cheetah Annihilator joystick, etc). And there are also some adapters, that allow you, to have the Space-bar (respectively the Fire function on joyport-1, which has the same function as Space-bar in alot games) on a button on a connected MegaDrive controller for example, such as the GenAssister, which connects to both joyports of a C64 at once, etc. It's very good for many shooters, that have a function on the Space-bar. If the Shield function in Slither could be triggered by Space-bar and also by Fire-2 (Pot-x), this would cover all of these different adapters and controllers. Then those players, who owns one of these hardware, would no longer have to reach for the keyboard, to be able to use the shield function in the gameplay, but would have this function directly on another button on their controller. Just a suggestion of course, but i think, it would make sense. And the Shield can additionally still be on Commodore-key too. In some emulators it already works very well now, with the current version of the game. More precisely, in those C64-emulators, that allow the user, to remap keyboard-keys to a controller (like for example Denise, HOXS, CCS64). There you can remap either the Commodore-key or the Space-bar (if that happens) to another button on your controller. It's a clear improvement in the gameplay, when you don't have to let go of the controller, to reach for the keyboard, but can do everything at once with one joystick/joypad.

Where can this version be found? But actually, I don't think you need any other version, the FX should just be switched on by default and not deactivated. Not hearing FX and also no music by default, is a bit strange, because no other game on the C64 does this. One of the two, is always preset.

Not bad and i always liked Centipede and clones of it. But one thing is a bit strange. When starting the game, then the user initially hears neither FX nor music, during the gameplay. That's a bit confusing, you could even consider this a bug or something like that, because you don't always have the itch.io manual-text for the game, that describes what to do with F5. Months later, this can be forgotten and you then no longer have this text and then the user must find this out by himself. At some point, you might get the idea, to try out the F keys and then you realize, that you can use them to activate the music or FX. Or maybe you never find this out and you think that it's normal to have no FX and no music in this game.

Wouldn't it be better, if (1) at least the FX were active by default, instead of not hearing anything at all, and (2) wouldn't it actually be better, if you could also choose between FX and music, directly in the game-menu (where you can choose between joystick and keyboard controls)? A text there could explain the F-keys and their function on the audio-settings.

You're welcome. I hope this can help in any way and that you finalize your game as an enhanced SEUCK game. It looks to good to be left unfinished. :)

Hy. Unfortunately, I can only help to a limited extent in this case, as I've never created anything with SEUCK myself and therefore don't know exactly, where to find these enhanced version. It's apparently called the SEUCK Redux engine, but I can't say much more about it. But there are a few online pages that mention it, for example here https://itch.io/c/2039017/enhanced-seuck-games-c64-pal-only or here

https://tnd64.unikat.sk/Seuck_Compo_2025.html

SEUCK Redux is apparently by Martin Piper, as can be read on this second linked page. So you could try contacting either Martin Piper, Alf Yngve, or Richard Bayliss (i guess, the email-address of at least one of the three, should be found on the internet). They should be able to help, as these three have already been involved in several good SEUCK Redux games (e.g. Zap Fight 2, Flying Cobra RX, Dark Force Redux, Super Silverfish, etc). That would be my tip here, because if you take a look at the highest-rated SEUCK games to date (for example, on Lemon64, sorted by highest rating)

https://www.lemon64.com/games/list.php?list_genre=Shoot%27em+Up&list_sub_genre=S...

the games at the top, are almost all such SEUCK games, that use the Redux engine. There are a few exceptions, but generally speaking, SEUCK games like this play better, because more can be implemented technically and these SEUCK games don't seem so monotonous in terms of gameplay.

Looks really nice, especially for a SEUCK game. Nice graphics and good use of colors too, for example when it comes to the bullets. I could imagine, especially if the final version of this game will use the enhanced SEUCK engine (more enemies on screen at once, better collision detection, enemies directly targeting the player-ship, etc.), that we'd have another good shooter on the C64. I really like "Zap Fight 2" and some other enhanced SEUCK games, so it's definately possible, to get a good game, out of this construction-kit, especially with the extended engine. And "Star Hero" also makes a very good impression in its preview so far. Hope, it will be finalized.

Just wanted to ask, if a 32bit compatible version of your nice Turbo Out Run clone could be released?

Cool.

Ah okay, i understand. Little bit sad, would have been cool. Nevertheless, Dr. Maria is a good game already now.

Any plans for a 2-player splitscreen-mode in Dr. Maria? That would be a big improvement to the already good game, because playing this puzzle game against each other is more fun, than playing the levels. I see this in other Dr. Mario versions (e.g. Super-NES, N64, etc), therefore this would be superb. And choosable cpu-players would be the absolute highlight, then you wouldn't need another human player, which you don't always have at your disposal.

Nice. With this, it's definitely one step closer to the behaviour of a game.

The multi-level scrolling looks great, and I like the music too. I know, it's based on a demo, but for a game, there should be some kind of different levels, otherwise, when there's never a break, it feels like, it's always the same and nothing new happens.

If you ask me, i think "Donutsman" is worth it. The game itself is good, it only suffers from a bit of slow gameplay and if that could be fixed, by using a faster compiler, it should be done. But of course, that's your decision. It would be a fine thing, though. :)

Could the program "Oscar64" maybe help here, it can generate pretty fast code?

Hello. Good work, especially when considering, that this is your first game on the C64. I have two suggestions for a possible v1.1 version. There should also be a selectable mode in the game-menu, that speeds up the entire gameplay (both, the player-sprite's movements and those of the enemies), e.g. a choice of the difficulty-level (easy and hard), because the gameplay is a bit slow, in my eyes. If a player then selects hard mode, everything could run a bit faster. And it would also be nice, if the highscores were saved in the game. For the sake of fairness, two score-lists would be necessary then, one for the easy and one for the hard mode. Such things would improve the game and nice to have in a future version. 

Hy. It's indeed a bit better now and i also like the diagonal movement idea and the other improvements in v1.2. What generally doesn't work in the game, is, that after a 180° turn, the new line is directly next to the previous one. In "Light Cycle Duel", there's always a small gap between the old and the new line, after a turn, although this of course reduces the number of tracks, to be driven on the playing field considerably. But that seems to be the way, it was intended, because the cars are a bit bigger than the lines. If that would not be the case, all the lines to be driven in the game, could always be right next to each other and the playing-field would become considerably larger. But that would be a major change, one you might not like? I wanted to at least mention it once. At least, now it almost always work, to make such a tight 180° turn, as the game allows in the moment. So in any case, it's yet another improvement of the game.

A really nice shooter. By the way, a REU version of the game would be superb, for the future. There are some C64-emulators in the meantime, that can emulate the use of SCPU and REU at the same time (for example Denise or VICE) and a single large .reu file of the game, could be loaded much faster and more conveniently, than several individual d81 disk-images.

And the results of this compo? Can not find them on the internet so far.

Great. Copied it over to a real disk and now it runs on all Amiga-500 machines with A501 expansion, just like most of the old Amiga classic-games from the 90s do. The sound-restrictions, that were necessary for this, are more than bearable. Thanks, nice work.