Okay, I understand and up to a point, it’s also understandable. Well, let’s wait and see. Assuming, it doesn’t fall through, due to technical problems (like for example the C64 version of "Prince of Persia" does, where a diskversion simply isn't technically feasible), then perhaps we’ll eventually see a cracked version of the game sometime, that runs from diskimages? It would certainly be useful, e.g. for users of SD2IEC hardware and the like. Cartridges are superfast in loading and you can fit a lot on it, but sadly they don’t work on every setup. We will see. Definitely a great game and good work.
Sparky-D
Recent community posts
Wow, really great new game. Very nice graphics, combined with good music and great playability (good jumping-mechanics for the playable character and great animations etc.). I read here, that it's 'only' a preview at the moment, therefore I hope, the game will be completely finished and perhaps it’s worth reconsidering, whether a diskversion of the full game might be released after all, because it would be a bit sad, if it only came out on cartridge.
Maybe it could be implemented in one of two ways:
(1) The specific section you are currently on, could blink back and forth between its normal color and black,, so that it should remains clear, where on the cube you are located. Black could be used here, because it's not one of the cube's standard colors.
Or (2) only the outline of the section you are currently on, could be displayed in black (instead of the normal blue). Even that alone, should actually be sufficient, to make it visible to the player, where on the cube he is currently located.
Perhaps one of these two approaches could be implemented somehow? Unfortunately, I am not a programmer myself, so I cannot say exactly what's technically feasible and what's not. But I do think, that at least one of the two, should technically be possible.
Not bad and interesting idea, but this game needs a joystick control additionally, for rotating the cube. Besides that, I like the idea, to bring the Rubiks-cube to the C64. One could, for example, combine the joysticks four directional keys with the firebutton and since the steering directions could then always be mapped to the cube's rotation directions, it would naturally be more intuitive, than keyboard controls and likely easier to remember.
One could have a controllable cursor e.g., directly on the cube (a small blinking sign), that the player can move back and forth, through all the single visible parts on the cube, by using the joystick's four directions. Then, depending on, where the player has positioned this cursor on the cube, the user could then rotate that specific section of the cube, by holding down the firebutton and moving in one of the four directions. Then, the player could release the firebutton again, place the cursor somewhere else on the cube and then rotate this part of the cube, and so on and so on. Of course, just a suggestion :-)
A good variant of Pong, nice work so far. There's just one thing, I don't really like and it's this - whenever the player or the CPU-player scores a point, a new ball suddenly shoots in, from the center-line immediately afterward and sometimes it's nearly impossible to catch this ball. It would be better if, after a point is scored, the ball always originated from the backline-side of that player, whose backline it had just crossed (i.e. the player who didn't just score).
That way, you would always have enough time to catch this first ball. At the moment, the ball comes flying in, from the center-line rather than the backline and sometimes the reaction window is too short, to respond quickly enough. Otherwise, I like the game. Support for real paddle-controllers would also be a cool addition, by the way. At the moment, it looks like only joysticks/gamepads are supported.
Great game with nice gameplay. One question. Does this DMA-safe version of the game, have any disadvantages, compared to the standard version? I assume it does, because if not, then there would be no need for the standard version anymore, if the DMA-safe version runs without issues on all Mega-Drive models while the standard version doesn't. Can you, therefore, say something about the differences?
Cool, nice game. By the way, your newly released games are working on alot of retro-systems, but they are only shown here as "for Windows and for Linux" (I understand, you mean because of the emulators that one has there), but I can also imagine, that some users of these retro-systems could get the impression, that these games are only for PC and because of this, then even don't look inside of the site of each of these single games here, on itch.io.
Maybe also all these retrosystems, on which your games work on, should directly be shown, besides the game-name, on the general website here, where all new games can be seen (if it's technically possible, to show more than two systems? I don't know, but it could make sense).
Very nice. I tried the new version in WinUAE and in Denise emulator and also on my Amiga600 (2MB Chipram + no Slowram) and also on my Minimig without Slowram. It worked everywhere without a problem now and so far, I haven't been able, to make it crash anymore, no matter what configuration I set in the Minimig menue. Good work, thanks for the update.
That sounds good, thanks. By the way, I have a Minimig in my parents house (sadly have not used it around two years because of time-problems, but I will change this again soon) and I completely forgot, that the Minimig can be set to Turbo Mode (about 48MHz) in the Minimig-menu. I must try this out, in such of your ported games, that are a bit to slow on Amiga500 machines (like for example "Track & Field"), because I can imagine, that the slowdowns will then be gone, when they run in this Turbo Mode.
And this mode also doesn't mean, that everything runs to fast then (that happens only in a handful of games, mostly vector-based ones), the vast majority of gamesjust hold their normal game-speeds, when the Minimig runs in Turbo Mode, just things like slowdowns in some games (like for example in the Amiga game "R-Type 2", when alot enemies are on the screen at the same time) are completely gone then and such games hold their normal fullspeed to 100% then, in such moments. This thing could especially be very interesting for your ported games, such as Galaga500, Phoenix500, Pooyan etc. I must try this out.
@jotd666, I want to ask one thing more. First of all, I want to say, that I really like your "Donkey Kong" version, otherwise I wouldn't spend so much time on it. Really a good game. The new question is this - currently the game's highscore is only saved, when the player exits the game by pressing the ESC key before. If the player forget to do this, as recently happened to me, right after I had set a new highscore, then this new highscore is not saved in the scorelist, sadly.
Most other Amiga games save directly to their highscore list, immediately after a match and it's not necessary, to leave these game with ESC key before, because it's also easy, to forget this and then the score is always gone. Maybe it would be good, if the player didn't has to do this ESC thing at all. Would it actually be possible, to change the score-saving behaviour to someting like direct saving, here in "Donkey Kong 500"?
Nice, that you've hidden the loading commands now, it looks more professional than before now. I thought about, what you had written about the fastloader-thing and it's understandable. By the way, I tried the game with a speeder-kernel, to see, if the reloading-process in this case, is also accelerated then and it luckily is. This also works with fastloader-cartridges like the FC3 or the AR6 etc. That's good. If a AR6 is used, the load-commands are visible again, I found out, because the AR6 changes the BASIC color for text into white, which is probably the reason for that.But that's tolerable.
By the way, I've also noticed, that unpacking the reloaded parts takes quite a while. Are they packed with "Exomizer"? This packer has a very good compression-rate, so it makes the programs very small, but it takes a relatively long time, to unpack them. If you pack with "NuCrunch", for example, unpacking only takes about half the time and the files aren't much larger. But it must be tried out, to see, if the whole loading and unpacking process is shorter with "NuCrunch" or with "Exomizer" here in these cases. It could be worth a try. But it's always difficult to predict exactly, without testing it. If you always load the game with a speeder-kernel or a fastloader-cartridge, the unpacking-time naturally plays a much bigger role, since the reloading-process itself, is relatively fast, regardless of the filesize. Without a fastloader, the situation is quite different, as the filesize then becomes a much more significant factor, because loading a larger file then naturally takes noticeably longer and the unpacking-process is then only a small part, in terms of time.
@jotd666, after playing version 1.2 for a while now, I've noticed something else, besides this described floppy-led (floppy-motor) thing? At the moment, the japanese level-order is only correct on the first cycle. On the second cycle of the levels, after level2, it suddenly goes back to level1 instead of level3. So something doesn't seem quite right here, because it should always be the order lv1, 2, 3, 4, which then repeats.
emmonks, yesterday a friend and I tried out your United DX version of the game. It's good, that everything is together now, in this version. In our opinion, there are only two things that could potentially be improved in a possible upcoming v1.1 of the game and I wanted to make these suggestions. Whether you implement this, is of course entirely up to you. (1) A fastloader could be used for reloading, that would make the loading-process significantly faster. For hardware like for example the SD2IEC, a version without fastloader can remain, because only kernel loaders run there, but for normal drives or for hardware like 1541Ultimate, Turbo Chameleon, etc, a fastloader would definitely make sense. (2) These loading-commands in the C64 BASIC, which appears during reloading, are looking a bit odd, inside a game. Here, all the colors in BASIC could simply be made black (text and background) so that players wouldn't see these commands. Then it would seem to the player more as if the individual reloaded versions, were directly connected to each other and no longer separate programs. That would be my last suggestions. It's a good game.
Very nice! This is the ultimate version of the "4goal" series, because it combines all the features. Thanks, for implementing my suggestion. Good game! I can recommend it to everyone, especially when friends are around, because it's a great party game, especially when played with a multiplayer adapter on the C64.
Hy. Okay, I understand. Maybe you find a good solution in the future, it would be nice. Or maybe someday, also one of the numerous C64 crackergroups will release a cartridge version (Easyflash maybe?) or a d64-version of the "4Goal" games in which all functions/versions are united? (Aaah, also a nice name would be "4Goal United" yeah). We will see.
I definitely like your 4goal games, because they are especially well suited as party games, played with friends and since my childhood, I always liked simultan games, in which more than one player is involved at the same time, because in my opinion, these games give the most fun. :-)
Also this "4Goal" version is nice and adds some new features again. One question I have here. There are alot different versions of your game now and every version has some good features. What do you think, about releasing a "4Goal Deluxe" or "4Goal DX" version, that has all these selectable features in one version of the game, choosable from a game-menue? And, if this would need too much memory, such a DX-version don't need to be a onefiler, it could also reload, some of these single modes, from a d64-file for example. Today there are alot of really good fastloaders on the C64, so also things like "loading time" is not a problem anymore, on this system. I think, having all features together in one version, could be a nice thing. And also a cartridge version of such a DX version would be great. What do you think?
Thanks for integrating the japanese level-order in the menue as a selectable option, that's very nice. And it also works now, when the user starts the game in the US-level-order, that the floppy-motor and the LED stopps, when the loading-process is finished. Sadly it seems, you forgot to do the same, when the user starts the game in the japanese-order now. Because I tried this out some minutes ago and when the game is started this way, then still the floppy-motor and the LED stays on, after the loading is finished. Best regards.
jotd666, thanks for the v1.2, I only saw this version today and immediately tried it. Thanks for integrating the japanese level-order in the menue as a selectable option, that's very nice. And it also works now, when the user starts the game in the US-level-order, that the floppy-motor and the LED stopps, when the loading-process is finished. Sadly it seems, you forgot to do the same, when the user starts the game in the japanese-order now. Because I tried this out some minutes ago and when the game is started this way, then still the floppy-motor and the LED stays on, after the loading is finished :-)
And I wanted to ask you one thing, because I have not seriously played the v1.2 so far. Could you combine the advantages of v1.0 and v1.1 in this v1.2, when it comes to the point with these slowdowns? In v1.0 there was big slowdowns in the second level, when the user is on these conveyor-belts. This then was fixed in v1.1, but sadly in this v1.1, in some cases, the first level could be a bit slower, compared to v1.0. I also realized that now, after the user rh70 mentioned this here. Therefore my question, if it was technically possible, to combine the advantages of both older versions, so that the first and also the second level runs good on Amiga500 machines now, in this new v1.2? Or is this not possible at all?
And thanks again for bringing all these cool Arcade classics to the Amiga, because they were always missing from this computer's game selection and I always asked myself why, since the 90's. Now many of them are here, even if not all of them have fullspeed on A500 machines, but at least they have it on A1200 machines. By the way, the first "Dig Dug" game would also be great for porting. And "Mr. Do's Castle" and "Guzzler" would be really great too. I always loved these three games, back in the Arcade.
A 4-player-mode really is a nice idea for this game, because in terms of gameplay, "4goal challenge" caters to this. It would also be great, to have even more play-modes, such as "player1 + cpu-player vs. player2 + cpu-player" or also "player1 + player2 vs. player3 + cpu-player" etc. A tournament-mode could also be fun, where the losing teams are always eliminated, until only one team remains. And the selectable cpu-players maybe could also have different play-styles. Just some suggestions. :-)
Nice level-set, good work. One thing I noticed, that i want to mention. In the second screen (the one, after the "Bubble Buddies" logo screen), it should perhaps be written somewhere, that you should press either button 1 or 2 (for 1 or 2 players) now, to go on.
Maybe not all users are so familiar with "Bubble Bobble" on the C64 and some could otherwise get the impression, that the game has frozen in this moment, since there's no music playing at that point and you also can't proceed with the firebutton on the controllers or with the function keys. In the original game, there's a note at the bottom in this moment, indicating the player, that he should press 1 or 2 now and that really would make sense here as well. Otherwise, great release.
I wonder a bit about that statement, because in my experience, when you use WinUAE for example and you configure everything in this emulator, exactly as it is on your real Amiga model (including Kickstart, Chipset, Memory, etc) then WinUAE will behave, exactly like your real Amiga computer. I've never experienced any discrepancies, to be honest and I've run really alot Amiga-games and -demos in WinUAE in the last years. It even works, to freeze software in WinUAE, for example with an emulated Action-Replay3 cartridge and this freeze then also works on the real Amiga, when you copy the files over to a SD-Card and use it on the real machine with a HxC or with a Gotek floppy-emulator for example. And when even freezing works, then it an be seen, how accurately WinUAE is emulating here. If you don't recreate it in an emulator, it's difficult to adapt "Tiny Pixel Adventure" to all common Amiga models, because the alternative would be, to buy all these Amiga models and I am not sure, if it's worth it? Using an emulator is a good alternative here, if you ask me.