Excellent new puzzle game. I also included it in my new "Gameplay of New Amstrad CPC games, April-December 2024" video along with other new Amstrad CPC games. I hope you enjoy the video.
Actually, it all depends on the porting of ugBASIC. The Apple II and PC-8801 targets are in the roadmap, so as soon as they are available I will try to recompile the source "as is", to check if the performance is satisfactory.
As for the VIC-20, I think that some optimization is still needed in the amount of assembly code generated, but I do not despair that it is possible. Moreover, the "tile" technique marries very well with the implementation on the VIC-20.
Hi The File-Hunter, first of all thank you so much for the feedback! Actually, I removed the disk image because it is not working. I'm delving into why. In the meantime, you can use the ROM image since it works fine. Thank you again for the report, and I apologize for the issue.
Game is good, but i recognized one strange thing. When it comes to the C64 version of the game, the reaction-time of the player-sprite, when the user controls it with a joystick/joypad, is much better in the older C64 version of "Soko64" from Emanuele Feronato. I compared both versions in two emu-windows side by side and controlled the sprite in both emulators at the same time by using the same controller. Then this can be seen easily. Can something be done, regarding this point in "Soko64+"? I ask, because it feels much better in direct comparison, when the player-sprite reacts immediately to inputs and not only after a short delay.
Hi Sparky-D, first of all thank you so much for the comment and compliments. There is actually a difference in the control mechanism between the original version and the plus version.
In the original version, by leaving the joystick in the same direction, the character moves in the indicated direction as if joystick were moved repeatedly. On the contrary, in the plus version the system waits for the finger to lift from the button from the keyboard or the the joystick come back to the original position.
The ugBASIC language, being isomorphic, does not present an abstraction for the input and therefore gives direct access to the I/O subsystem. Wanting to write a single source, I therefore opted for this different approach by virtue of the numerous, and differentiated, input methods present on the various computers.
Fixing the problem shouldn't be difficult, and it will definitely be one of the improvements in the next version. Since I would like to stay on the single source valid for all computers, a certain period of testing will certainly be necessary. As soon as the new version is ready, I will update it on this page.
Hello. Thanks for your fast answer. Yes, i already had recognized, that there is also a difference in the control-mechanism and that in the new version, you must make single steps, while in the older version, you can hold the stick in a direction and the character moves constantly in this direction then. Also this point, i find better in the older version, because this is, what players are used to, from the vast majority of other games. This single-step thing takes a little getting used to, if you ask me.
But this point was not the main-reason, why i mentioned this thing. The main-reason for me was, that the first movement of the player-sprite, when you steer on the joystick in one direction, happens much faster in the older "SOKO64" version, compared to the new version. In "SOKO64+" it feels a bit, like if the game would have a lag in the input-reaction-time and this feels not really good. In games, you normally want to have a very direct and quick control of your own sprite, for best playability. But very good, that you think about changing this, in the next release. Always nice, when programmers react to the input of users and don't stubbornly do their own thing. Looking forward to this next version. Best regards.
Not actually because ugBASIC does not support this model of computer, yet: however, it is possible that it may do so in the future.
The source code was written without dependencies on any specific hardware, and so it should be easy to port it to Enterprise 128, when it will be supported.
I will be waiting for support for this platform in your software.
As a child, I loved programming in Enterprise's built-in BASIC.
But now it’s more difficult to force yourself to do it using the classical method. There are several ideas that I would like to implement in own small games.
← Return to game
Comments
Log in with itch.io to leave a comment.
Excellent new puzzle game. I also included it in my new "Gameplay of New Amstrad CPC games, April-December 2024" video along with other new Amstrad CPC games. I hope you enjoy the video.
Any plans to port it to PC-8801, Apple II and VIC-20?
Hello Aklim95, and thank you for the comment. :)
Actually, it all depends on the porting of ugBASIC. The Apple II and PC-8801 targets are in the roadmap, so as soon as they are available I will try to recompile the source "as is", to check if the performance is satisfactory.
As for the VIC-20, I think that some optimization is still needed in the amount of assembly code generated, but I do not despair that it is possible. Moreover, the "tile" technique marries very well with the implementation on the VIC-20.
The targets foreseen in the roadmap can be found here:
https://ugbasic.iwashere.eu/targets
Thank you again, and have fun!
The MSX .DSK doesn't seem to work. It should be 360Kbyte (Single Sided) or 720Kbyte (double sided) file.
Hi The File-Hunter, first of all thank you so much for the feedback! Actually, I removed the disk image because it is not working. I'm delving into why. In the meantime, you can use the ROM image since it works fine. Thank you again for the report, and I apologize for the issue.
No need to apologize at all!
People like you are keeping our old computer systems alive, so we can only be thankfull for that :)
Game is good, but i recognized one strange thing. When it comes to the C64 version of the game, the reaction-time of the player-sprite, when the user controls it with a joystick/joypad, is much better in the older C64 version of "Soko64" from Emanuele Feronato. I compared both versions in two emu-windows side by side and controlled the sprite in both emulators at the same time by using the same controller. Then this can be seen easily. Can something be done, regarding this point in "Soko64+"? I ask, because it feels much better in direct comparison, when the player-sprite reacts immediately to inputs and not only after a short delay.
Hi Sparky-D, first of all thank you so much for the comment and compliments. There is actually a difference in the control mechanism between the original version and the plus version.
In the original version, by leaving the joystick in the same direction, the character moves in the indicated direction as if joystick were moved repeatedly. On the contrary, in the plus version the system waits for the finger to lift from the button from the keyboard or the the joystick come back to the original position.
The ugBASIC language, being isomorphic, does not present an abstraction for the input and therefore gives direct access to the I/O subsystem. Wanting to write a single source, I therefore opted for this different approach by virtue of the numerous, and differentiated, input methods present on the various computers.
Fixing the problem shouldn't be difficult, and it will definitely be one of the improvements in the next version. Since I would like to stay on the single source valid for all computers, a certain period of testing will certainly be necessary. As soon as the new version is ready, I will update it on this page.
Thank you again for the suggestion, and have fun!
Hello. Thanks for your fast answer. Yes, i already had recognized, that there is also a difference in the control-mechanism and that in the new version, you must make single steps, while in the older version, you can hold the stick in a direction and the character moves constantly in this direction then. Also this point, i find better in the older version, because this is, what players are used to, from the vast majority of other games. This single-step thing takes a little getting used to, if you ask me.
But this point was not the main-reason, why i mentioned this thing. The main-reason for me was, that the first movement of the player-sprite, when you steer on the joystick in one direction, happens much faster in the older "SOKO64" version, compared to the new version. In "SOKO64+" it feels a bit, like if the game would have a lag in the input-reaction-time and this feels not really good. In games, you normally want to have a very direct and quick control of your own sprite, for best playability. But very good, that you think about changing this, in the next release. Always nice, when programmers react to the input of users and don't stubbornly do their own thing. Looking forward to this next version. Best regards.
Cool!
Enterprise 128k version is possible?
Hi SlashNet, and thank you for the comment!
Not actually because ugBASIC does not support this model of computer, yet: however, it is possible that it may do so in the future.
The source code was written without dependencies on any specific hardware, and so it should be easy to port it to Enterprise 128, when it will be supported.
Click here to see what hardware is supported by ugBASIC, and there is also a roadmap of future developments.
I will be waiting for support for this platform in your software.
As a child, I loved programming in Enterprise's built-in BASIC.
But now it’s more difficult to force yourself to do it using the classical method. There are several ideas that I would like to implement in own small games.
I would be interested in a version for Commodore vic-20 🙂