Skip to main content

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

Richard Hallas

40
Posts
4
Followers
45
Following
A member registered Feb 02, 2018

Recent community posts

How very kind — thank you!

Thanks very much indeed for correcting these problems so quickly!

Good luck with this game. It looks as promising as usual. I've just had a brief play at the first part of the English version, and here's a little bit of feedback based on that initial try. Mostly I've just found some trivial typos, but the last point is about an important apparent bug:

1. "Physical" should be spelt with a "y" in it, not an "i" (title screen).
2. "Teclado" should be "Keyboard" in the initial control choice. (And since you say "Sinclair Joystick" in this choice, I think you should also say "Kempston Joystick", not just "Kempston".)
3. If I examine the workbook and the comic, and work my way through the motorcycle race, then whenever I make a bad choice, there's a faulty character in the failure message. Where it says "I don't remember having drawn it like that", there's an unwanted character after "that", before the full-stop. It looks like it's probably an "í" (acute-accented i).
4. *** BUG1 *** After working through the motorcycle race in the comic, if I then choose the "I order a cup of coffee" option, and follow it with the "Inventory" option, I just end up with a completely blank black screen, and nothing else happens.

I'm sure there will be other little problems to find, but that's as far as I've got. Overall, the quality of the English translation seems very good so far.

I've just downloaded the new version 1.1, and it doesn't seem to work. I've tried both English and Spanish versions in four emulators (Fuse, Retro Virtual Machine, ZXSP, Clock Signal on the Mac) and in all cases it just produces a colourful crash during loading. The existing version 1.0 – which, thankfully, I kept – works fine. I can't believe I'm the only person to have experienced this problem in the month since the version 1.1 update was released, but nevertheless, that's what I find…

Thanks for supporting this great new platform

Thanks very much!

Very playable game. NB there's an important typo in both the game and the documentation: it's "Kempston" joystick (wth an "m"), not "Kepston".

Excellent! Thanks very much

The ReadMe refers to an Acorn 8-bit version (BBC, Electron etc.), but it appears not to be present in the retro archive. Could it be added, please? Thanks.

Oh, great – thanks, that’s really useful to know.

Hehe! Thanks very much indeed for your efforts with this!

Hi,

I admit that I haven't yet had chance to try this out – and I certainly will. But my initial reaction to the news about the absence of keyboard controls is… Y'WHAT???! :-)

Other than a handful of games that were specifically designed for use with a light gun (and how many people had those…?), I have NEVER encountered ANY Spectrum game that lacks keyboard controls. Making a game joystick-only is an extremely Commodore thing to do, and thus a heinous crime and wholly unacceptable.

In all seriousness, though, I personally simply do not like joysticks and game pads. I never even owned a joystick in the 80s when I had my original Spectrums. On the Next, I do now have a joystick and a game pad, but I only really got them for testing purposes, and I rarely use either. I'd MUCH rather use the keyboard, every single time.

Objectively and dispassionately, it's a straightforward FACT that the keyboard is inherently more responsive than any joystick. The only instance I can think of where I can imagine that a joystick might be desirable is when you have a keyboard-destroying 'waggler' game of the Hypersports/Daley Thompson ilk, where using the keyboard can kill both your keyboard and your hands. And even that's arguable.

The point with a joystick is that the stick has to travel in the direction indicated. By contrast, on a keyboard, the only travel is in the depression of the key. Thus, on a joystick it takes time to move in a particular direction, and it's impossible to indicate more than two directions (i.e. diagonals) at once, whereas on a keyboard you could potentially press all the directions at the same time. (Not generally terribly useful, but nevertheless…) Ergo, the keyboard IS simply faster and more responsive in use than any joystick; it's a simple physical fact. With a game pad, maybe you can use it like a keyboard, maybe you can't; it depends on the pad. Either way, it's either equivalent to a keyboard or less good than a keyboard. It can only be said to be better inasmuch as you can pick it up more easily, and there are no other distracting and unnecessary keys. On the other hand, you're probably stuck with the four-key diamond layout for the direction buttons, whereas on a keyboard (if the keys are redefinable) you can choose the option of having horizontal controls under one hand and vertical controls under the other, which I for one generally much prefer. Moreover, assuming the keyboard is indeed redefinable, you can choose the layout that you find most comfortable and responsive.

In other words, I'm REALLY struggling to imagine any justification whatsoever for NOT including keyboard controls – especially on a Spectrum, where keyboard control is universal and joystick has always been an optional extra.

So I will give your game a go in its current form when time permits, but if it always requires a joystick, that will be a very substantial deterring factor against it for me. I very much hope you'll get around to implementing keyboard control before it's considered 'finished'.

PS It's similarly hard to imagine why keyboard controls "work poorly" for this game when the equivalent joystick controls presumably work fine. How can that be? How is it that up, down, left, right and fire are so hard to pull off on a keyboard, considering the evidence of 40+ years of Spectrum gaming, and hundreds upon thousands of previous Spectrum games, all of which use the keyboard and have managed to pull it off successfully over all that time? I think the end user needs to see evidence of the poor performance of the keyboard controls in this game, and be given the option of which control method to choose.

The above is of course intended in good humour, but I think my basic points are valid.

This is a great game – an excellent follow-up to Tut-Tut.

I've spotted a couple of typos, though!

1. "BARCELET" on the list of scores
2. "KNOSSOS" on the list of objectives – inconsistent with KNOSSOSS elsewhere.

To be honest, I'm not sure about the title itself, as I thought there was only one S at the end of both Minos and Knossos (so point 2 technically isn't an error), but maybe there's some cunning reason for the extra Ss in the title. Anyway, point 2 is still an inconsistency.

Trivialities, I know, but I thought I'd point them out. 'Barcelet' is definitely a typo worth correcting.

What's in the zip file if you pay more? A .tap or .tzx file? I really don't like bare snapshots; a .tap is a far better alternative with a much wider range of potential uses.

Fantastic! Thanks very much indeed – and yes, it seems fine.

Hi, thanks for doing this. However, could you please supply the updated game as a .tap file (like the original)? Unfortunately, a snapshot is the least desirable distribution format in many ways. People can easily make their own snapshot from a .tap file if they want to, but they can't do the reverse at all easily. A .tap would be best for both widespread compatibility and archival purposes. Thanks.

(1 edit)

Great – thanks!

Hi,

Thanks for doing the ZX Touch versions. However, you seem to have uploaded the wrong one for Mike The Guiter. The ZXT version here is for MTG The Shooter.

Thanks – it's certainly very much less frustrating now!

Thanks for the detailed and positive response!

Hm. There's a lot to like about this, and it's almost very good… but the whole business of the ship getting destroyed (and ending the game) really is INTENSELY irritating and unfair. The shield is often depleted and then the ship destroyed and there's just nothing you can do about it. Also, the need to position the ship sections together pretty precisely is also frustrating. The beauty of the original Jetpac is that it was so very easy to play. It could be annoying, but it didn't have these aspects of sheer frustration. Take away the possibility of the ship being destroyed and make the assembly less frustrating (i.e. make it more like the original) and this could become really fun

Sorry, but I've just noticed a bug in v1.2. Just playing the first level, the cherries appeared for the second time (I think) – I'd missed them first time round – and they seemed to stay on-screen an unexpectedly long time. But I managed to reach them, and rather than collecting them, Pac-Man passed right over them and they stayed there on the screen.

Your archive contains separate downloads for the ZX Spectrum and the ZX Spectrum 128. These are clearly not the same because the code is different between the two, yet I can find no functional difference between them. There isn't any AY-3-8912 sound in the 128K version, which would be one reason to have two versions. Also, both versions work equally well on 48K Spectrums (even the supposed 128K version – which is actually smaller than the 48K version).

Could you therefore please explain what the difference is between these two versions? Thanks!

I emailed it to you. If you haven’t received it, please check your spam.

Hi! I haven't heard from you yet. Did you miss my previous message? I've got a nice .TAP file to send to you, when you tell me how to send it…

Thanks a lot. I'm pleased to say that I've been able to convert it to a plain .tap file successfully. Where should I send it to get it to you? NB If you'd like to email me directly, my email address is my name (as shown here) with the @ instead of the space (surname is domain name) and .net on the end.

I'm not familiar with how raw audio data is encoded is .tap and .tzx files – and I don't know how you're creating them to produce this result. I suspect it's probably just a .wav file in a .tap/.tzx wrapper, but I'd have to look into the file format specs to be sure. Anyway, there are various tools that do convert .wav files into 'proper' .tap and .tzx files. I haven't a lot of experience of creating such files personally, but I've managed it successfully from time to time. audio2tape (one of the Fuse utilities) is one such tool, and there are certainly others. If you can't manage it successfully yourself, if you post a straight .wav version of your tape file(s) here, I'm sure that someone would manage to do it without much trouble. I'd be happy to try myself, or someone else might beat me to it!

(1 edit)

The .TAP and .TZX files currently supplied are unfortunately some sort of raw audio rather than proper tape files. This means that (a) they're much less useful than they should be and (b) they're approaching 40 times larger than they need to be (1.8MB rather than around 50K). Could they please be converted into 'proper' tape files? NB Since only a standard loader is used, a .TAP file is all that's required and a .TZX isn't really necessary. Why not instead supply (a) a proper, regular .tap file for users of emulators and modern hardware with SD cards, and (b) a .wav audio version for people to play in if they want to use original hardware?

NB The same comments also apply to your other release, Ziona Quest X.

Wonderful! Thanks very much indeed! This makes all the difference! :-)

If you're wondering why I care… when using an emulator on a modern keyboard, the right-hand Shift key is perfect for 'jump'. I typically choose either Q, W, Shift (JSW-style) or Z, X, Shift. I don't like using the space bar for 'jump' as it's too big and clumsy, but a regular key like M is too small for a one-handed function. The right-hand Shift key is just perfect.

8-D

There's one downgrade in the full version compared with the demo: it's no longer possible to define Caps Shift as the jump key (which I want to do…). Could this be fixed, please? Thanks.

Excellent! Thanks.

It's a shame that this is only provided as a snapshot, not as a .tap file. This greatly reduces its potential audience.

Thanks a lot!

Is it intentional that there's an infinite lives poke active from the outset? It's a fun game, but given that the lives counter never goes down when you die, there's really no challenge.

Thanks a lot! 😊

The docs say that there's a 48K Spectrum version, but you only seem to have provided 128K Spectrum downloads. Just thought I should point it out.

…and… thanks for the tape file! :-)

Excellent. I love 'perfect' snapshots like these, which show the loading screen until you press a key. So, that's great. All we really need now is a tape file. Many thanks for all your efforts!

Interesting game. However, I agree with the other comment here – a tape file is badly needed. ESPECIALLY given that this is a paid-for game, it really MUST be supplied in a better form than just a snapshot. That's so half-hearted. (And .SNA isn't even the best snapshot format: it's wasteful. .Z80 format does the same thing but uses a smaller file size and also supports 128K snaps.) This game NEEDS to be supplied as a .TAP file, and ideally as a .TZX file as well. The .TAP file format is best – especially for regular loaders (i.e. non-turbo loaders) – because it works with EVERYTHING, including loading into real machines. If you want to use a fancy loader, supply a .TZX file as well. (But please note that the new ZX Spectrum Next currently can't handle .TZX files, which is one reason why a .TAP is so important: it's absolutely the best option on the Next.) If you need to have a loading screen designed, I recommend approaching Andy Green, who does superb work (search for Andy Green Pixel Art on Facebook).