Green Beret for Amiga

[zzbylu]

Gameplay - Green Beret: UPDATED_FEBRUARY03
[ Show youtube player ]

[saimon69]

The project might be over however, as a former speccy user, i like to remind how darn good the port was on the Spectrum, done by the sorely missed Joffa Smith
Note the incredible particulars for a 1984/85 port like using communist symbol for indicating lives left...

[ Show youtube player ]

[Radertified]

The latest jump mechanism is pretty bad.

Why am I suddenly allowed to jump from one level to another? Defeats the whole point of ladders and makes the game significantly easier.

I say go back to the previous jump method.

[VincentGR]

Nice port!
I made an HDD version, unfortunately no quit key, but it's fine for me.

[vulture]

Yup, I think being able to jump from one level to the next defeats any purpose the ladders have, I believe the previous jump method was better.
Still, quite an awesome conversion

[jotd]

Originally Posted by VincentGR

Nice port!
I made an HDD version, unfortunately no quit key, but it's fine for me.

a whdload version will come out at some point. Let's wait for the final version.

[Aarbron]

Originally Posted by Radertified

The latest jump mechanism is pretty bad.

Why am I suddenly allowed to jump from one level to another? Defeats the whole point of ladders and makes the game significantly easier.

I say go back to the previous jump method.

Yes, now it became obvious why the original jump was so short. People complained it was too short so I make it about the same height as NES. Which opened the clear possibility of skipping ladders.

Anyway, the previous jump method is still there in the original ADF from January 31 GreenBeretAMIGA.adf

[Aarbron]

Originally Posted by vulture

Yup, I think being able to jump from one level to the next defeats any purpose the ladders have, I believe the previous jump method was better.
Still, quite an awesome conversion

Thanks, I believe that it wasn't bad too and making it short was a decent solution for a problem (that now you guys are all seeing clearly!)

Anyway, the old jump is still there in the GreenBeretAMIGA.adf from January 31.

[Aarbron]

Originally Posted by jotd

a whdload version will come out at some point. Let's wait for the final version.

Great, status is about at version 0.8 now. Let's clear the high jump issue and it could move to version 0.9. To be version 1.0 will need all missing music delivered by musician and also some boss position issues fixed from later levels.

[malko]

Originally Posted by Aarbron

Thanks, I believe that it wasn't bad too and making it short was a decent solution for a problem (that now you guys are all seeing clearly!)

Anyway, the old jump is still there in the GreenBeretAMIGA.adf from January 31.

Sorry if I do not understand correctly but is the original "old" jump kept or is it only available in the version from January 31 ?

[Tsak]

Well done @Aarbron, nice work (more so since this is your first game)!

Regarding jumping I think the issue in the previous version wasn't height but the fact it was just too fast. My advice would be to check a video of the original arcade and compare carefully how high the character jumps and the time the jump takes.

Timestamp for player jumping in the arcade
[ Show youtube player ]

And in RC1
[ Show youtube player ]

[Aarbron]

**UPDATED FEBRUARY 05, 2022**

JUMP: the higher jump added in February 03 update ruins the game for many people: it defeats the purpose of ladders, since you can simply jump to reach another floor.

So, in this February 05 update I rolled back to the original jump height with some adjusts but also added a subtle horizontal "push" if the player jumps while moving forward.

This still enables the player to jump from truck to truck in level one or jump over landmines, but is not enough to reach a higher floor. It's very experimental, though.

Tsak : thank you. I've recorded the height and compared. Now it's the height of one man and it's the height of the arcade.
About speed, everything is a lot faster... as an analogy I'd say, remember how shmups on the 1980s (Toaplan etc) had such faster bullets? Now shmups (called "bullet hell" today) have very slow bullets enabling the screen to be filled with them? It's because 1980s Toaplan shmups can only put a limited number of bullets on screen at once, so they made bullets faster. Today it's unlimited CPU power almost, so bullets can be slow or ultra slow...
What this has to do with Green Beret? Well, in Scorpion Engine on target spec (A500) I can have about 4 enemies on screen, plus the occasional bullet. This is way less than the arcade machine (8+ enemies, plus bullets) so the idea is that they're faster to avoid filling the screen with them. The NES version (Rush'N Attack) typically has 3 guys on screen and that's exactly what they did. If you have 3 guys on screen at the same pace of the arcade it'll be a super boring, easy game. Boost their speed, add unpredictable moves and you get a superb challenge. The NES version is brilliant in how they managed their limitations and Amiga Green Beret has more to do with NES, than with the arcade. I think this also applies to Neeso's JACKAL, which is more NES than arcade too.

malko February 05 update (today) has a jump that should't reach upper floors, so ladders are back in fashion.

[jotd]

Yes people often overestimate the blitter capabilities. It's not that good, specially if you have to copy/restore the background / cookie cut blit, etc.

you could have more than 4 enemies on screen but you'd have to use sprites sometimes. Not exactly easy with an engine.

you could also limit the background blitting/restoring using dual playfield. One playfield for enemies, one playfield for the scenery.

There are a lot of things you can do but if you go single playfield 16/32 colors full blitter no tricks it's pretty frustrating.

Good job!

[Aarbron]

Originally Posted by jotd

Yes people often overestimate the blitter capabilities. It's not that good, specially if you have to copy/restore the background / cookie cut blit, etc.

you could have more than 4 enemies on screen but you'd have to use sprites sometimes. Not exactly easy with an engine.

you could also limit the background blitting/restoring using dual playfield. One playfield for enemies, one playfield for the scenery.

There are a lot of things you can do but if you go single playfield 16/32 colors full blitter no tricks it's pretty frustrating.

Good job!

Thanks and well said.

Could maybe attempt to replicate arcade's number of enemies on screen using crazy sprite multiplex routines like shown recently by the [ Show youtube player ]. But that's 68K ASM.

To be fair, Scorpion engine has a sprite multiplexing, but has very strict limits and cannot fit enemy soldiers, only small bullets. Has also Auto Sprite features which I think is great: whenever a bob can switch to a sprite, it does automatically, speeding things up a bit. Seems to have a steep chipmem cost, though.

I was writing my little Blitz engine before Scorpion Engine dropped in the scene and I did the old trick of having dual playfield and moving bobs on foreground playfield so didn't had to "clear", restore background and all that... seemed to work so well.

So I'm occasionally bothering Earok here and there to add something like that in Scorpion at some point. It may help with shmups (which was the point of my game engine). As is, Scorpion is single playfield and I've tried doing shmup (prototype) but was about 5-6 enemies on screen, which is a bit sparse. Seems to be able to manage a good deal of bullets by multiplexing, though.

But for Green Beret it suits well if following NES game design adjusts. The criticism received was that of "bit rough in the edges" and need to tweak controls further etc (which is fine and I'm doing). The game's performance received only compliments so far. Which is a cool goal achieved given the difficult circumstances. It helped push the Scorpion engine as I was constantly toying with the idea of having mixed 50/25Hz (enemies updating at 25Hz, like Battle Squadron) so Earok nicely added that. May had that in mind before, but I remember bothering a lot about that feature. In the end, the Green Beret you guys are seeing runs at full 50Hz whenever possible but the interpolation and mixed Hz feature in the engine is there anyway.

[Tsak]

Originally Posted by Aarbron

About speed, everything is a lot faster... If you have 3 guys on screen at the same pace of the arcade it'll be a super boring, easy game. Boost their speed, add unpredictable moves and you get a superb challenge.

Your idea to make the enemies faster to compensate their numbers on screen is legit. I just don't know how this relates to your jumping speed though. As it is, it doesn't look natural (game-feel wise) and smooth enough imho. And reason is it's way too fast. In that regard I think people correctly identified there's an issue with jumping in the first place. They just gave you the wrong feedback in regards to what's wrong with it (yup, happens some times) by assuming it's the jump's height.

Having said that I know Scorpion currenlty does't allow for much flexibility and accuracy in regards to setting up jump controls. This is one of the reasons Erik recently added the "jump height" field to actors (after we talked about it). I'd be interested to know if this helps (should you happen to use it).

*Sidenote, from what I saw from AmigaBill's stream, your Castlevania port also suffers from this issue btw. One of the reasons Bill found it so difficult to correctly and easilly hit high candles.

[Aarbron]

Originally Posted by Tsak

Your idea to make the enemies faster to compensate their numbers on screen is legit. I just don't know how this relates to your jumping speed though. As it is, it doesn't look natural (game-feel wise) and smooth enough imho. And reason is it's way too fast. In that regard I think people correctly identified there's an issue with jumping in the first place. They just gave you the wrong feedback in regards to what's wrong with it (yup, happens some times) by assuming it's the jump's height.

Having said that I know Scorpion currenlty does't allow for much flexibility and accuracy in regards to setting up jump controls. This is one of the reasons Erik recently added the "jump height" field to actors (after we talked about it). I'd be interested to know if this helps (should you happen to use it).

*Sidenote, from what I saw from AmigaBill's stream, your Castlevania port also suffers from this issue btw. One of the reasons Bill found it so difficult to correctly and easilly hit high candles.

Jump is slower since February05 update. I'm getting there.
But yeah, the whole problem is that people expect NES type jump (which in case of NES Green Beret/Rush'N Attack has a fixed height/distance providing great accuracy) and Scorpion Engine by default has a Turrican type jump which is the more you push up, the more you go... to explain in easy terms. It doesn't helps with accuracy and feels like a legacy from pushing the joystick lever to jump instead of having a dedicated jump button. It took a while for AmigaBill to find out that Castlevania AGA had such variable jump. Rest assured that I'll look closely at the "jump height" to help provide better accuracy to Castlevania's jump.

Earok also has done a cool Atari's Pitfall demo a while ago that HAS a precise jump, which is the main requirement for a Pitfall game. It's very interesting as it ZEROES the jump values and does the thing in a script. Also, it's always on button for jump. So, yeah, it feels very Pitfall and precise and shows that it is possible in the engine to have different styles of jump.

Edit: I just find out that AmigaBill's issue hitting high candles in Castlevania has more to do with the *Prevent Move* box being ticked for jumping whip attack, rather than entirely to blame on engine jump mechanics! I mean, with that option ticked, each time the button is pressed to hit the candle, character motion is prevented, no matter if upwards (jump), walking or anything else. Making it fall short. I'm fixing that. Jump height is set at 64. It's running nicely in the latest experimental branch of the engine that Earok checked about 4 hours ago.

[RWE]

Jumping in to say thank you very much for making this. Incredible work, especially for a first game. I find it interesting to follow the discussion around the details. Eagerly looking forward to v1.0 and beyond!

[Aarbron]

Originally Posted by RWE

Jumping in to say thank you very much for making this. Incredible work, especially for a first game. I find it interesting to follow the discussion around the details. Eagerly looking forward to v1.0 and beyond!

Thank you very much for your support!
So far the new jump (February 05 update) has been well received.

Then, for 1.0 I got in the list:

1. adjust position and speed of bosses (specially last boss which was deemed impossible)

2. add the following missing music tracks: stage clear, game over, end game (just added BGM 2 on February 06 update, which is in-game music that plays on stages 2 and 4)

3. add Original Controls, which is as follows: button 1: knife, button 2: special weapon, Up: jump. It was like that on NES as well.

Beyond 1.0:

1. I've planned to add all the stages of NES Rush'N Attack, which have 2 extra ones, for a total of 6.

2. It has also a Star item which gives invincibility

3. Option to have either Green Beret title screen or the alternative title Rush'N Attack (like in Gradius Enhanced on MSX which you can have GRADIUS or NEMESIS).

And finally, I probably need to record a full longplay of the game, on A500 OCS (which is the one I test all the time, because there's nothing more frustrating than to reach the final boss and ran out of chipmem).

[zambot3]

Why do enemies advance with bayonets if they are bare-handed in the original game?

[vulture]

@Aarbron

seems like a good list, looking forward!