No, and there won't be. The dark version returns the look of the game back towards the original Psion version. There was no "running jump" in the original, so there won't be in the dark version.
Bob's Stuff
Creator of
Recent community posts
The engine as a whole has become very bespoke to this game, although elements of it could be re-used for other titles. However, I'm not much of a game creator these days, and admit I have no idea even what an SRPG is, and so somebody else would need to design the whole thing for me for it to become a possibility.
Unfortunately, although it was initially my dream for this, it will never run in 48k even if each character was a different load - the graphics for all the rooms take more than the available space on their own. I really want to have everything loaded at once, and be able to swap characters literally at the press of a key. I think multi-loads are awful!
Lovely to see this getting attention after nearly 10 years!
There was no real inspiration behind it - I don’t like shoot-em ups, especially R-Type (controversial I know) - it was purely that I hadn’t written one so thought I’d have a go. There’s no ‘bomb as well as laser’ because I simply didn’t know that was a thing - I just wrote what I wanted to play, not a copy of any existing game or style.
Likewise with the ASCII art - I thought it would be an interesting look to try, although that turned out to be the most difficult thing as there’s lots of pixel-based editors, but few few ASCII ones, and none I could find which handled the low ‘resolution’ I was working at.
You’ve hit the nail on the head when you say that ‘modern machines do not suffer with memory shortage...’ - this is being written for the ZX Spectrum, a machine that’s 39 years old, and has only 128K of usable memory. It also has next to no hardware support, so that memory is for all the code, graphics, sprite routines, music, SFX, etc. In order to get the most out of the machine and this memory the game is written entirely using Z80 machine code, and compression is the only way it will fit in memory.
Thanks!
The code is written using Microsoft’s VS.Code editor, along with a couple of plug-ins for syntax colouring and counting the t-states of a selected block of code. Everything is then compiled using the Pasmo assembler, which has been updated to support compiling to the memory bank pages required for a 128K game such as this.
The graphics are done in an old version of Photoshop elements (from when it was still pretty close to Photoshop instead of the photo-retouching service it is now). These are output as required for the game code using some basic scripts in Unity. That gives me the flexibility to write whatever I need the output format to be, and use just about any input image format.
Everything is then tested in the Spin emulator.
Only one quarter of the surrounding frame is stored, as it’s then mirrored and flipped to fill the other three quarters. Because of that it only uses 52 characters, so is technically stored in 52 x 8 = 416 bytes, there’s the supporting code for that as well, and also the table used to mirror that data. The current frame might not be the final design though...
Thanks for the support and encouragement, it’s much appreciated! I’m slowly glueing the game back together, re-writing each section of the rendering engine as I go. It’ll likely take a week or two, but will hopefully free a lot of memory and mean that I can continue writing the game as a true conversion of the original