Skip to main content

Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines

Richard Hallas

108
Posts
1
Topics
15
Followers
158
Following
A member registered Feb 02, 2018

Recent community posts

Any chance you could supply this as a proper .tap file, please? Z80 snapshots are great for emulators but are very inconvenient for real machines, and they're the worst archival format because they only preserve the memory contents, not the loading screen etc.

Terrific! Dracula was fantastic, and A Christmas Carol is a book I've loved nearly all my life, so I'm really keen to see your interpretation of it on the Spectrum Next in particular!

A quick observation: please try not to advertise this so prominently as being only for Windows! Because…

(a) As a Mac user, I tend to ignore anything 'modern' that's for Windows rather than Mac. I can run any Windows software on my Mac through Parallels, CrossOver etc., but I don't unless I have a reason to.

(b) More importantly (in a sense), I've only just discovered (through finding this game as a link in a retro collection) that you’ve also issued Spectrum and C64 versions! NOW we're talking! As a retro lover (particularly of the Spectrum), this is now of MUCH greater interest to me!

So, I've bought it for the retro versions.

I never expect to play the Windows edition, though, and had it not been for someone else including this game in a retro collection, the 'for Windows' label would have caused me to miss it forever, which would have been a shame! (In reality, it's just the sort of puzzle game that I like, so I'm doubly glad I checked.)

Hi, Many thanks. I completely agree that just having the dot-command version in future makes far better sense. It's just that your documentation explicitly said that both existed in parallel, so it seem worth making these points.

Anyway, thanks for the clarification – and for all the remarkable work you've been doing recently, with so many great things!

Since the release of the dot-command update, things seem have become incredibly confused with regard to installation.

From what your documentation says, it appears as though you  should now be supplying CalmCommander in two separate versions: its original stand-alone form and the new dot-command alternative. Certainly your most recent development notes make it quite clear that the two versions now co-exist.

However, the downloadable zip archive now appears to contain only the new dot-command version. The files that your installation notes refer to (cc.bas, cc.bin etc.) are no longer present.  As for the files that ARE provided in the archive, the only installation notes relating to those are tucked away in the dev-notes about the new dot command, so are hard to find. The installation notes provided in the same place as the download now refer to files that aren't present! I assume this is an oversight…?

I've personally kept my old copy of version 1.6 for the time being, but it'd be nice to be able to update it to match version 1.7 of the dot-command edition.

In addition to that, it appears as though there are now two separate copies of the plug-ins folder, with everything duplicated in two places – i.e. the contents of C:/CalmCommander/plugin and C:/sys/cc/ should be identical.

That's what your installation notes (themselves provided in two separate places!) clearly say, but it seems very inefficient to maintain two separate folders of 18+ plug-in files.  (My old /plugin folder also contains a 'copy' file that isn't in the new /sys/cc folder.) Couldn't the stand-alone version of the tool be updated so as to use the same C:/sys/cc/ folder as the dot-command version, rather than having a separate /plugin folder?`

Or am I misunderstanding something?

Thanks!

Despite the fact that someone has already written "very good"… it seems that the .tap file provided here contains only a loader program, and not the nine 1-liners that are supposed to follow it…!

Unless I'm missing something blindingly obvious…

Great, thanks a lot! I've got it now.

A couple of observations, though…

First of all, POKE 23658,8 turns on Caps Lock, if you wanted to insert this into the program (or into a short initial loader) so that players don't need to turn it on manually.

Also, I see no reason why this should be specified as being for Spectrum 128 BASIC. Given what it is, there's little chance that it needs any features that are exclusive to Spectrum 128 BASIC (i.e. use of a RAM disk or playing back music through the AY chip).

Moreover, by saying that this is for Spectrum 128s, it's likely that people will put the machine in 128 mode and use the inbuilt Tape Loader option to load the .tap file (you even advise them to do so in your loading instructions) – but if they do that, they'll find that they initially get a corrupted display that's quite distracting. That's because the 'Tape Loader' banner at the bottom of the screen doesn't get cleared (as there's no CLS command when the game starts) – so colourful artefacts from the banner remain on-screen until enough text has been printed to cause them to scroll off the top of the screen. But if you load the game in 48K mode, that doesn't happen because there's no 'Tape Loader' banner to get in the way.

So basically, I think you should drop all references to the Spectrum 128 and just state that it's for the Spectrum. There are still loads of 48K-only models in use, and as far as I can tell, this game will work just as well on them as on a 128K machine.

Overall, I'm pleased to see this game because it's interesting: you've taken a truly ancient computer game and ported it to a system that's merely extremely old! :-) – but one that's readily available to pretty much everybody, and still in widespread use, both natively and through emulation. So you've preserved this game in a practical way that makes it very accessible, and that's all to the good.

I'm not suggesting that you should have modernised the game for the Spectrum; that could certainly be done as a separate exercise, but the best initial step was to keep it as close to the original as possible, I think, and that's what you've done.

However, for the sake of convenience, you could potentially make it very slightly more accessible by turning on Caps Lock for the user with the POKE (even in a separate loader program, if you want to keep the main listing as authentic and unsullied as possible), and I really see no reason not to advertise it as being for all Spectrum models. NB The game is too large for a 16K Spectrum, but that's the only model it won't run on. And I very much doubt that anyone made any real use of a 16K Spectrum after about 1983 in any case!

Fantastic! I'd love to see this… but… where's the download? How do I obtain this, please?

Chris, your Settings table on this page appears to be missing the following entry, which I found elsewhere:

default_line_ending=<mode>  # Default line ending for new files: crlf, lf, cr (default crlf)

Basically quite nice, but with a few problems. Here's some feedback…

1. To me, the keys are the wrong way round in terms of the way they move the character on-screen. That is, if the functions of Q/A and O/P were swapped, it would feel much more natural in terms of how the movement of the character relates to the positioning of the keys on the keyboard. As it stands, I often press the wrong direction because it's the opposite of what I expect.

2. The alignment of the character and the pushable blocks is MUCH too fiddly. Unless you're perfectly aligned, pressing Space to push has no effect – and it's far from obvious when you ARE aligned properly. Initially, I simply couldn't understand why I couldn't find the 'fire' button; I expected Space to work, but nothing happened when I pressed it. It emerged after much frustration that I had to be positioned exactly correctly, to the pixel, before the block would move. It'd be far better if the game could reposition the player's character by itself, if it's slightly off-centre, when Space is pressed; e.g. if you're positioned one or two pixels away from where you should be. Think of how Knight Lore works, when you try to go through a door but you aren't aligned properly: the character first slides sideways until it's properly centred. If the same thing happened here, it'd solve a very annoying problem. Alternatively, and perhaps even better, you could allow blocks to be pushed without being exactly central to them, which is how other games work – even though that makes it more likely that the player's character will collide with a nearby enemy. NB This alignment problem also applies to going through narrow gaps: it's quite hard to find exactly where you should be positioned before you're allowed through the gap. Copy Knight Lore and other similar games, by getting the game engine to help the player with the positioning of the character and the movement of blocks!

3. It can be too easy to get into an impossible situation by moving a block up to a wall accidentally. If that happens, what are you supposed to do? With some games, pushing a block that's adjacent to a wall into that wall causes the block to bounce back by a space, leaving room to get behind it again. That'd be really helpful here. Otherwise, there needs to be a way to reset a level or quit the game back to the menu. I couldn't find any such Abort/Restart key(s), not even Break (Caps Shift and Space), so when I pushed a block into a wall and made a level impossible to complete, the only way out was to reload the game.

4. The Campaign mode is quite enjoyable (though the room layouts are rather dull and too repetitive), but very, VERY short. I completed it on the first attempt without losing any lives, and the only challenge at all was getting aligned properly to be able to push the blocks and move through gaps (see point 2).

5. The Random mode is fine for just playing a quick level, but there don't seem to be many levels to choose from, and the same ones keep coming back. Surely it'd be far better to have a series of individual levels of increasing difficulty for the player to work their way through. The Random feature could then pick one of those levels… but it should also be possible to address the whole level set directly, and for there to be a clear progression through the levels. At present, choosing Random just gives you one very easy level out of a tiny selection, and you end up seeing the same one time after time, so there's not much to keep you coming back.

Overall, I think there's a lot of potential here for a really good 3D Sokoban game, and actually it all works reasonably well in terms of mechanics, given the points I've made above. But it needs a bit of polish in terms of implementation, and the game itself needs a LOT more content and logical challenge.

The Campaign mode is actually a really nice idea, solving levels to open doors and allow progress etc., but it's FAR too short and easy, and the settings aren't very interesting. As for the Random mode, see my comments above: the randomly picked level should be from a much larger selection of levels that can be accessed directly, or unlocked in sequence.

Why not simply take all the levels from the basic game of Sokoban and include them in this game? Then you'd have a series of ready-made, excellent levels of increasing difficulty, rather than just a tiny handful of excessively easy ones. You could even potentially allow for the loading of level sets, which might easily be user-definable outside the game. In fact, there's a standard text-based Sokoban level-design format, XSB, with a run-length encoding option to make it more space-efficient, and also an XML-based SLC format for level collections. You could devise some way of converting levels in these formats for use in your game, whether or not you provide an actual 'load' option.

So actually I think this game is pretty good as far as it goes, and is a great start for something better… but it does currently need quite a lot of work to turn it into something that's really worth playing. But I hope you'll keep working at it and make it live up to its potential!

Weird. Maybe I was served a cached version or something. Anyway, I can confirm that your latest version does indeed work fine now. Thanks!

I'm afraid that your replacement file is just the same! Oddly enough, zxsp on the Mac can load it (despite issuing a warning), but other emulators can't (e.g. Fuse), and it's simply not a standard .tap file

You've made a mistake with the .tap file, I'm afraid. It isn't a .tap file; I think it's just a dump of the BASIC listing. Anyway, it can't currently be loaded as a .tap. The .z80's fine, though.

Very funny/entertaining write-up of the update!

Many thanks! BCNU

Hello,

There's an error on this page. Under the 'Links of interest' heading, the first link is missing. There's no href in the source, so the "HERE" text is styled as a link but doesn't respond to clicks.

Aw, boo! Now that I know about it (thanks!), it was rather a fun hidden extra to have… But sadly I’ve updated and not kept the original version.

Here's something weird. The very first time I tried playing this game, and once again since, on starting the game I could see every mine on every screen (so there was no challenge and I could just walk past them). Every one of them appeared as a solid red character square, rather than being invisible.

Yet when I start the game again now, all the mines are invisible as expected. I presume I must have pressed something accidentally on those two occasions when I saw the visible mines, and activated some sort of cheat mode or debugging code. The question is… how did I do it? What did I press to turn this mode on? Certainly, it ruins the game in terms of the challenge, but it's also interesting in terms of letting you see a lot further ahead!

This was all on the original release, not the recent bug-fix… but I'm guessing it's a deliberate hidden feature rather than a bug, so hopefully it's still there to be rediscovered.

I’d like there to be a Spectrum Next version too, with Amiga-quality graphics.

Well done for getting there in the end! How did you do it, out of interest? I did try myself with your previous file in the EightyOne emulator, but it wouldn’t work in that either. Mind you, perhaps the file was faulty...

Hi,

There's a weird problem with the new version B .tap download, but only in the Fuse emulator. I've tested this on a Mac, and it applies to both versions of Fuse, i.e. Fuse and FuseX (which is an alternative build of Fuse with slightly different features).

Basically, the emulator won't load the game from the .tap file; it loops round through the tape and ends up crashing. Very weird; version A was fine.

NB This appears to be an emulator problem, because the game DOES load OK in other emulators. I tried it in both ZXSP and Clock Signal, and it loaded fine in both of those. Indeed, I saved a .z80 snapshot out of ZXSP and that then worked fine when loaded into Fuse (as expected). So it's something about the .tap file rather than the game, as you'd expect.

Nevertheless, Fuse is one of the most popular emulators out there, and lots of people will use it as their primary emulator (I do), so it'd be nice if a fix were possible. I've never seen another .tap file behave this way on Fuse, so it's pretty strange.

One other small suggestion… now that you have a nice loading screen, it'd be good if there were a pause at the end of loading so that people using emulators with 'instant load' behaviour could actually see it! You might consider waiting for a keypress, or for a few seconds at least, before clearing the screen and beginning the game. Then people could take a snapshot that includes this artwork on initial load.

There’s got to be more to it than that. I too have a Mac, and I’ve tried several ZX81 emulators in which this file doesn’t work. But a .p file is a .p file; it should work in everything, not just in some emulators and not others. I’ll look further into this if I get time later today.

Oh dear; I'm afraid your new .p file doesn't seem to load either. I've tried it in ZXSP, Clock Signal and SZ81, and in all cases it just locks them up. I'm afraid that none of the Mac-based emulators may be capable of actually saving software from an emulated ZX81. It may be necessary for you to use something like EightyOne for Windows, running it under a Windows virtual machine or WINE solution (such as CrossOver).

Ah, I see. I use ZXSP too, and it has lots of good features including ZX81 support (obviously), but I don't think it actually saves ZX81 snapshots. It wouldn't reload your .z80 file, anyway. I'm afraid I'm not sure what ZX81 emulators on the Mac do support outputting .p and .tzx files; most of them only seem to support loading, not saving. At a guess, ZEsarUX probably does; it supports just about everything… it's just rather complex to use.

What's the .z80 file from? This won't work with most emulators. It needs to be a .p file or .tzx tape image for most ZX81 emulators

Yes, please support the ZX Spectrum Next!

Fantastic! Very nicely done! And I love the Watership Down references.

Excellent! Thanks very much for your efforts; three separate alternatives, each with appropriate instructions, is very thorough! :-)

As for your point about detecting CS + Cursor keys in BASIC… I think it should be straightforward enough (and works fine in emulators). I've just looked at the listing, and I'm interested to see that in the Interface II version you're testing for G=IN 61438, whereas in the other two versions you're testing for INKEY$="5", "6", "7" and "8" (or q, a, o, p). I'm not sure why you have that distinction between IN and INKEY$ in the different versions.

Anyway, regardless of that, the shifted cursor keys (and the dedicated cursor keys on + keyboards) just produce the ASCII codes for cursor movement, i.e. Left = 8, Right = 9, Down = 10, Up = 11. So the amendments to the Cursor version of your listing – where you have LET G$=INKEY$ – in lines 2–5 would be:

• IF G$="5" OR CODE G$=8 THEN … REM left
• IF G$="6" OR CODE G$=10 THEN … REM down
• IF G$="7" OR CODE G$=11 THEN … REM up
• IF G$="8" OR CODE G$=9 THEN … REM right

I've made those changes to a snapshot of my copy here, for testing purposes, and I can confirm that it works fine (tested in an emulator). The game now responds properly to the cursor keys with and without shift, so it should also work properly with the arrow keys on a + keyboard if you added these four small changes.

Anyway, that's my last remaining suggestion. :-) Many thanks again for your work.

Thank you!

I have no doubt that this is due to the presence there of Paradise Cafe, unfortunately. Stupid censorship.

Great! I always really liked Mined-Out!, and a slightly optimised version is welcome.

A couple of things, though, which I've noticed after a brief initial look:

1. There's actually a couple of typos (or poor wording choices, at least) on the first page of instructions, which you could usefully take the opportunity to correct:

(a) "HE LAYS DORMANT" should be "HE LIES DORMANT". That's just atrocious grammar.

(b) "YOU BEGIN AT EACH LEVEL AT THE BOTTOM OF THE SCREEN" contains one "AT" too many! Please delete the first. ('You begin each level…')

2. You've changed the controls from the cursor keys (5, 6, 7, 8) to Interface II joystick keys (6, 7, 8, 9). I can see why you've done this (Interface II is a common joystick standard), but it has two unfortunate consequences:

(a) It makes page 2 of the instructions incorrect. In the first line, you've changed the "MOVE USING KEYS..." reference to say "6,7,8 & 9" instead of the previous numbers 5–8; fine. But on the second line it says "[ SEE ARROWS ABOVE THESE KEYS ]" – and that's now not only redundant, but wrong. Only three of the new keys (6, 7 and 8) have arrows above them (on the rubber-key models that show them), and they now show the wrong directions. It only makes sense to include this second line of text, obviously, if the original cursor keys are being used, so if you insist on this change, you need to delete this second line of text.

(b) Some people – and this includes me, I'm afraid! – will really, REALLY hate this change! Speaking for myself, I've never been a fan of joysticks and almost never use them on the Spectrum. I MUCH prefer the keyboard. And I taught myself to use the cursor keys as game direction keys decades ago, back in about 1982/3! Using 5–8 feels very natural to me – but using the Sinclair joystick controls instead is hopeless and sends me in the wrong direction all the time (as the order of the directions has changed as well as the keys). This literally completely ruins the game for me and will get me blown up regularly.

Also remember that the Cursor joystick interface (also Protek, which is the same) is a long-established standard – longer established than Sinclair Interface II. And remember too that from the Spectrum+ onwards, Spectrums have dedicated arrow keys on their keyboard that are equivalent to pressing those numeric cursor keys with Shift held down. It'd be very useful to be able to use those keys here, and your change renders that impossible.

If you really want to improve the keyboard controls in Mined-Out Faster, then I'd strongly suggest that you do the following:

• Revert to the original 5–8 cursor keys;
• Ensure that they also work as expected with and without Caps Shift held down, so that both the number keys (original rubber keyboards) and the dedicated arrow keys (+ keyboards) work as expected;
• Additionally support keys Q, A, O and P as directions, as this is the natural default choice for most Spectrum games.

If you really want to push the boat out you could add support for the Kempston joystick, which is the most widely established joystick standard of all. Or you could allow the user to redefine the keys, or let them choose between Cursor and Interface II joystick standards. But please leave the cursor keys default as it is; long-term players of this game are used to those keys, and that's as good a reason as any not to change them.

I hope that's useful feedback.

Thank you!

On the Options screen (press 3 from the main menu) you have some confused information: it says "KEY 0 DRAW LEFT" (that's zero) and "KEY O CLEAR SCREEN" (that's letter O). Those keys are the wrong way round!

Aha! Thanks for the explanation.

Regarding the music update… it looks as though you've updated the devlog but forgotten to update the .tap file itself…!

What a fab surprise for New Year’s Day! Thank you for your efforts with this fine game; this kind of enhancement is just the sort of thing I like to see on the Next.

By the way… 64 languages now. That's a good computing number! :-)

Hehe! Thanks!

Saluton!

Excellent work – many thanks!

Hi,

Thanks for that very positive response! You've done something pretty remarkable with all this language work, and I know you can't support all languages out there (62 is an incredible first start…) – but, as you acknowledge, Latin is a particularly important one. I'm glad to hear that it now has top priority!

One other suggestion is that you might include some instructions about how to play the basic game! Your docs are all about the language aspects – which is obviously what makes this release particularly interesting, but it's not immediately obvious what the objective of the game actually is, if you come to it without having seen it before! Some simple instructions would probably be helpful.

As for the various Star Trek languages… I don't think you can really be sure that the Klingons, Vulcans and Romulans never had Spectrum games. After all, Star Trek is set far in our future, when computers primarily talk to you rather than having simple bitmapped displays, but rumour has it that the operating systems of the computers installed on even the earliest Federation starships came bundled with at least one Spectrum emulator – and Memory Alpha has a complete archive of all known 8-bit software ever written, for all systems. Both the Romulans and the Klingons plundered that archive through espionage in its earliest days, whilst the Vulcans had legitimate access, and it's fair to assume that word of the Spectrum spread rapidly across the entire Alpha Quadrant as the other races rearched the origins of humanity's technology. Quite what they thought about our early computers isn't known; but how could they not be impressed?

In fact, if you watch the early part of Star Trek IV: The Voyage Home, when the Enterprise bridge is in chaos and the computers have crashed, you can clearly hear Spectrum loading sounds. It's clear proof that an errant ensign was trying to sneak a quick game of Jet-Set Willy just before the crisis began.