itch.io

Hello. Good to hear, that there's a SG-1000 port of the game too. Will try out this version on my real Master-System in the next days, by using my Everdrive X7.

I already had a look on this SG-1000 port with the Kega Fusion emulator today. Your MSX port looks a bit better, I would say. But gameplay-wise, this SG version is also not bad. Thanks.

Guzzler is a game, I really like and it's a bit sad, that there is no port of this game for other well-known systems like for example NES, Atari-7800, C-64, Atari-800, Master-System, Mega-Drive, PC-Engine or Super-NES. Nearly all of the old Arcade classic-games have their ports on these systems, but this game was forgotten, it seems.

Very nice. I love Guzzler, because when I was a kid, in the mid-80s, there was an arcade machine for this game at our outdoor cummunal swimming pool. There was a small room in this swimming pool, where you could buy food and drinks and there were always two arcade machines in the back corner of this room. For several years, these were the games "Guzzler" and "Xevious", and I played both there quite often, with some friends.

I have a question, since I have a Master-System but no MSX computer. The two systems are technically related, I read in the internet, wouldn't it be possible, to port your MSX version of "Guzzler" to the Master-System, or would you be able to do that? As far as I know, only certain things need to be adjusted, that a MSX game also works on the SMS and there can be found several MSX-to-SMS game-ports on the internet therefore. I just don't know how it works.

Hy Shoriontea, i had a look at your new project and it makes a good impression. I always like good shooters, no matter if horizontal or vertikal scrolling, therefore i am looking forward to see Scartarix finalized. At the same time, i have hope, that maybe someday in the future, also a Redux version of "Star Hero" can be published with enhanced additions. 

Already makes a good impression. Looking forward to see this game finalized.

Good game with beautiful graphics, but made only with the normal SEUCK. Taking that into account, it turned out really well. "Star Hero" definitely is a candidate for the enhanced SEUCK engine, that offers more possibilities and for a subsequent Redux version with some improvements. Would be cool, to see a "Star Hero Redux" version some day.

Hello Shoriontea. I saw, that you finished your game, some days ago, as a normal SEUCK game. Good one, with really nice graphics. I bought it some minutes ago and it would definately be interesting, to see your game with the enhancements, that the SEUCK Redux engine can offer. Hope that a Redux version of "Star Hero" will come out some day. Maybe with the help of some of these mentioned people, which already have experience with the enhanced engine?

True, what Richard wrote, also the thing with the VICE snapshots and one thing more about this whole freezing thing. The mentioned Action-Replay freezer is probably even a bit better, than the FC3 freezer, but especially when it comes to the SD2IEC hardware, freezing with the FC3 has the advantage, that the FC3 fastloader is already included in the SD2IEC firmware and fully compatible, when it comes to loading this freeze on the SD2IEC in the end. When using an AR cartridge, then it depends on the size of the freezed file. When the file is small enough, that the AR can create a onefiler, out of the freeze, then it's no problem on a SD2IEC and even better, than having two freezed files (that the FC3 always creates), but when the AR must also create two files, out of the freeze (for example when it's to big for one file), then SD2IEC users have the problem here, that the AR fastloader is not compatible and the second file then can not be loaded, on a SD2IEC.

Great game with beautiful graphics and an interesting story. And I also like the presentation (box, manual, etc.). Good work.

For C64 beginners, there is an alternative way, that the game can be loaded with a SD2IEC. Simply load the game in a C64 emulator and freeze it with the FC3 modul, when it's completely loaded. The FC3 fastloader, which is present, when the freezed file is later loaded, is compatible with the SD2IEC firmware.

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.