Hello,
I'd just like to announce my new game Cap'n Rescue: Reprisal for the ZX Spectrum is almost complete. This is the third game in the series and is again authored with AGD.
The test version for 128k is available on my Dropbox
HERE. A 48k version will follow later.
Comments
picture share
Games List 2016 - Games List 2015 - Games List 2014
Thanks. Glad you like it :)
1- At start or whenever you re-spawn, the sprite is facing right, but if you fire, it fires left.
This only happens if you don't press any other key, after you are dead, but before pressing fire.
Once we press any other direction keys, it fixes it self (except jump key).
Please fix, the re-spawn routine sprite status initialization.
2- That item that looks like electric rays, when disabled, still leaves the BRIGHT color setting behind, which can be seen when player passes over it.
My suggestion, clear the settings
3- If we enter a room from the right, but then we die, we are re-spawn, but now on the left side.
An unintended teleport I believe.
TIP: You can save position player enters a screen, so that you know where to re-spawn.
I haven't played many screens, but it seems you require some more variety on the challenges and enemies to make it more interesting. Some review of level graphics would help too.
Something that I also noticed in terms of game play, is that we can jump quite high, but we are killed at almost the exact same height that we can jump, which feels awkward. It seems that a pixel more, and we are killed.
A "splash/splot" animation when dying, would be nice. :P
Some help page explaining all the "power ups", would be nice.
I also sometimes loose the ability to fire, but I haven't figure out why yet.
Do we have limited ammo ?
How do I gain more ammo then ?
How can I know how many I have ?
What are the coins for ? ammo ?
Keep it up.
P.S.
I also found out, that rolling belts transport you, even when you are in the air. It should only transport you, when you actually stand on them. It makes some parts, harder then it should. At least, according to what a user expects.
This is something I had noticed but hadn't a clue how to fix. I could try testing for which sprite is displayed and alter laser direction or force a particular direction that is the same no matter which room you restart in.
I'll do that.
Thanks, that would be quite simple to implement - sometimes I just need a nudge. :)
Hmm, I have 3k to play with, adding sprites is causing memory corruption though.
Hmm, I did tweak the jump table - probably best I tweak/untweak it some more.
I have an unused sprite already in memory that could do that.
There will be a manual in the finished download.
There is a limited amount of ammo - trouble with leading zeroes is causing me problems when the variable is printed. Some sort of IF <10 THEN `print one along` instruction may solve it.
Points and rank (there are two prior Cap'n Rescue games on my blog www.play-tape.wix.com/loadingscreech using the same system
Thanks, and thanks for the feedback!
Sometimes I get killed by nothing, or something that isn't there.
It happened on second screen, and also on this next one (see picture)
As you can see, I just died my last life, but there is nothing near me that could have killed me, no enemies, no spikes, nothing.
This appears to happen, in places where there was an enemy before, which I killed before hand.
Somehow, in some situations (I can't replicate it consistently), it must think the enemy is still there or something like that.
Just guessing, but maybe it's related with enemy initial position, when screen loads.
Hope this helps to find the issue/bug.
P.S.
Or maybe it's that extra pixel besides jump height, and we dye when landing.
This makes the walking look more realistic, since our legs have a fixed length, when walking we extend the legs to the front and back in a diagonal line, which according to Pythagoras theorem means the hypotenuse is the longer part, hence the height between floor and "crotch" diminishes. Which makes us humans (and other animals) go up and down while walking.
Something as subtle as a single pixel difference, makes a great effect in the walking animation.
You could also move the edges of the hat, so that they appear to move with the flow:
- when body goes up, the edges of the hat bend down,
- when body goes down, the edges of the hat bend up.
By "bend" you can also move just a single pixel, but it will make a difference in fluidity of the animation.
Similar observations can be done to his arms/shoulders, for example.
If you have more than one frame for the torso already, use those.
Hope it helps.
Seems unreasonable, to me at least. Such a small ledge, just jump and you are dead.
Here is another situation, where I died without knowing why ?
Collision detection error (matching 8x8 block ) ?
NOTE: I was jumping over the spike, going from right to left.
Found a graphical bug: When we jump the hat blinks, in the sense that a few pixels aren't there to give it that yellow volume inside the main area on top of hat.
Yes, thanks - I caught that one myself and had it fixed already. As I recall it was the player respawn point being right on top of the enemy so you were right about that.
The code was there but, I forgot I changed the sprite to Bright Yellow (it's darker in the other two games), requiring the COLOUR 6 command to be changed to COLOUR 70 in AGD. Little bit sloppy of me that one.
I designed the game with the intention of the player 'dropping' to the next step if going down - does that remove the problem? If not I'll study it again.
My first thought is something to do with the way the ZX Spectrum seperates the screen into 8x8 pixel blocks, as the spike is pointy at the end. Maybe my paper is the mythical 'bright black'?
Could that be the famed 'colour clash' that affected these vintage computers? I hope I'm not coming across as patronising, I'm just troubleshooting - you can have one paper and one ink colour in each 8x8 square, so if you pass under a platform that is any colour other than bright yellow and black, the Cap'n Goode sprite will change to that colour - I avoided this to some extent in the previous two Cap'n Resscue games by having less colourful blocks. The fact the Cap'n moves pixel by pixel rather than in 8 pixel jumps as in BASIC programs would provide the explanation, as does the fact the platforms are more shallow than 8 pixels.
If that is the problem - I've done it deliberately in order to have a more colourful game.
Again, I hope none of that was patronising to you.
TO ANYONE READING THIS THREAD
I have a newer version with various fixes but, for now - I'm removing the test download until I have an even better version sometime next week.
I know that, and that's fine.
What I'm trying to pass to you, is that falling from (jump height + step down height) should not trigger a death.
Also, falling two small steps, shouldn't kill you either, because it seems unreasonable.
Basically what I'm saying, is that height used to trigger a falling death is too short.
There is a level, where a step is not in line for straight walking, and if you press right to just walk down, the player actually falls two steps and dies, although it seems it's walking.
Player doesn't understand why he died, at least at first.
I'm noting this so that you can avoid frustrating players.
Player is standing on plataform position that will show a problematic death, if you just walk right.
No, it's perfectly fine, you are just explaining your reasoning.
I'm note entirely sure, but it could be a quirk of the emulator, because I can't replicate it on the first screen.
But when I saw it, I didn't have anything above the player.
If I see it again, I'll be sure to grab a screen shot.
Some notes:
When walking right, there is a pixel near shoulder that seems to blink (on and off), but when you reverse direction going left, it doesn't happen. What this tells me is that you are using different sprites depending on direction.
I never used AGD, so I don't know if it's hard to reverse sprites, but it would probably better for you to reverse and reuse the same sprites, instead of using a different set.
NOTE: it doesn't have legs or arms yet, just feet, waist and head.
Walk cycle is composed of just 4 frames, while allowing to progress to next char (advances 8 pixels for each 4 frames).
To make it really cool, 8 frames would be ideal, so that each leg can be correctly identified when walking.
NOTE: One can simplify normal walk cycle from 4 to to just 2 frames, but it will not be as fluid. To correctly identify each leg, we need to double it too.
Obviously, with your character is somewhat harder to implement, because it has a larger head, in proportion to his body, which makes available pixels scarcer to implement something like this.
https://www.facebook.com/groups/1694367894143130/
What happens, is that some lines, are thicker than others, in some particular zoom settings.
It seems the emulator implements non integer zoom levels, like (1.0, 1.5, 2.0, 2.5, 3.0, 3.5, etc...), which then results in these artifacts, when we are in a non integer (*.5) setting.
Zoom WITHOUT Artifacts
ZOOM WITH Artifacts
So that one is found.
I returned the jump table to default - Mr Cauldwell probably has a poke for that (suggestion for the instruction manual?) but, I used a 30cm Ruler instead! :)
Cap'n Rescue 3 V1.0b (Dropbox)
Oh, great - so, it's not all me being sloppy! :)
I also added a rucksack so the player better fills the 16x16 square, hopefully improving overlap detection with enemies.
The code is there for remembering Y,X co-ords for respawn but, AGD seems to override it. Deleting the restart sprite just leads to no player respawning on screen.
Old download link can still be used for new version at this stage.
Sometimes, animation features are hard to implement, because they depend a lot on the original graphic, and sometimes, it's not possible to make it work, that's life. :)
I upgraded my previous example, with a loop of 8 frames, although they are just 7 distinct frames (4+3), one is reused, and the extra three are for the left leg animation.
I gave him a hat, a torso and some trousers, but still no arms yet :)
NOTE: Animation speed 100ms per frame (5 PAL frames) (except first frame 500ms)
@LoadingScreech, check your messages.
The difficulty is near the games like Jet Set Willy, so it's probably what you wanted.
I don't like counting the number of shots left, and that's all.
Games List 2016 - Games List 2015 - Games List 2014
Link is 6 posts above this post.
Games List 2016 - Games List 2015 - Games List 2014
Thanks. Glad you like it. :)
There's the link Timmy mentioned or my downloads page on my website play-tape.wix.com/loadingscreech#!downloads/ehc5j
I know from another thread that you will know the answer to this - I am calling it 128k because it has AY sound but, do these AGD games work okay on 48k machines with AY interfaces?
hmmmm, strange - I can't hear any music. Only FX.
If they're for AY, then OK.
But if the game takes only first 48K, one screen and AY music/sound, so it will work normally on ZX48, playing through AY, I'm sure.
Thanks,
Y
There's no music, just AY FX so, that's good news.
Okay. Originally I wanted to add music but, I think I added too many sprites and other things. My game has grown down to (without looking) around 30206 in RAM so, I think that makes AY music a bit difficult.
I think I'm right in saying I have only 200 bytes outside contended memory. Correct me if I'm wrong.
Thankyou for your reply :)
(Reason for edit - changed 30200 to 30206).
If anyone is linking to my downloads, for example from a database, please link to the DOWNLOADs section of my site, as the Dropbox link changes more than my very cheesy-smelling socks.
Just to reiterate, I make no claims to be anything more than a high-level language programmer, and this game was written in AGD. I've been reading up on Z80 assembly but mainly doing so makes a good sedative!