Metro Siege: new arcade quality a500 brawler!

[Photon]

Not into this genre, but it looks really great already!

[Master484]

Great to see so many different moves for the characters.

Does the game store both left and right facing versions of the characters in Chip RAM ? Or does it use some advanced tricks like real time horizontal flipping or real time decompression from Slow RAM to Chip RAM ?

[DanScott]

Originally Posted by Master484

Great to see so many different moves for the characters.

Does the game store both left and right facing versions of the characters in Chip RAM ? Or does it use some advanced tricks like real time horizontal flipping or real time decompression from Slow RAM to Chip RAM ?

It appears that the characters are made up of many individual small parts that are reused between different animation frames, so I suspect that they have the chip ram available to store the flipped versions

[ExiE]

I expect to be nominated to Capital Punishment after this but i can't help myself :-)
Alex's legs looks weird in stand-by position. Left leg from knee to ankle looks more "blurry". When Alex move in stand-by posture, the knee splits are too visible on both legs.

[Tsak]

@Saimon69: Nice ideas, however it's way too early to start thinking about easter eggs and alternative modes right now. I guess everything is possible but we have to wait and see.

@Shatterhand: the key word here for me is responsiveness, how easy/natural it feels to perform the wanted action and how this affects the game's flow. I have a friend who tried the game and only just 5 mins into it he started doing crazy stuff, comboing various moves, flying around and smashing heads like a maniac. And his feedback was that everything felt precise, spot on and easy to perform. Obviously this is something that the rest of our team has also verified.

I agree 100% with the game examples you brought up, like Lionheart and Body Blows (I would add Barbarian and a lot other Amiga brawlers into this list). The main issue with all these games is that the responsiveness is kinda garbadge (imho) and it often feels you are moving a tank around, rather than an agile warrior. Which drags down the whole experience and makes performing moves a chore. Metro siege is hopefully nothing like that.

Now, when it comes to using directions and buttons, it's not like you need to keep the button pressed and THEN press a direction (like it's done in some of the aforementioned games). Just pressing them at the same time works equally as well. And it's exactly as you'd expect from various similar moves in arcades. For example check the Punisher moves list which uses a lot of similar direction and button combinations.

Originally Posted by Shatterhand

All other moves could be done by just holding direction and then pressing button (which is faster, more dynamic and more instinctive).

I disagree. If we did it that way, then everytime you tried to move down or up the lane (or forwards or backwards for that matter) you'd do a different attack or move by mistake. What you want to do instead is to facilitate that the player will be able to use his basic jab and combo attacks freely while moving around and not f.e. low kick unintentionally everytime you try to reach an enemy that is below you. Forcing the player to stop in order to jab and do his basic combo is super unintuitive imho and hurts the game's flow.

Anyhow, besides the above, I just want to add here that nothing is set to stone yet and we'll continue refining and streamlining the controls as the game's development progresses. Also keep in mind that we're considering a 3 or more buttons option, so the player will have more variety in regards to his preffered control options.

Originally Posted by DanScott

It appears that the characters are made up of many individual small parts that are reused between different animation frames, so I suspect that they have the chip ram available to store the flipped versions

That's correct
Basically this is another interesting topic I might get into later on. Thanks to this method we were able to create a crazy amount of moves and anims with the minimum possible RAM overhead. F.e. the Alex character has currently more than 230 frames of animation he is just 42k!

Personally I consider this to be one of the greatest technical achievements the team has managed to pull off so far and without it the project would not be viable without sacrificing gameplay and variety in the process.

[Shatterhand]

I agree 100% with the game examples you brought up, like Lionheart and Body Blows (I would add Barbarian and a lot other Amiga brawlers into this list). The main issue with all these games is that the responsiveness is kinda garbadge (imho) and it often feels you are moving a tank around, rather than an agile warrior. Which drags down the whole experience and makes performing moves a chore. Metro siege is hopefully nothing like that.

Now, when it comes to using directions and buttons, it's not like you need to keep the button pressed and THEN press a direction (like it's done in some of the aforementioned games). Just pressing them at the same time works equally as well. And it's exactly as you'd expect from various similar moves in arcades. For example check the Punisher moves list which uses a lot of similar direction and button combinations.

...

Forcing the player to stop in order to jab and do his basic combo is super unintuitive imho and hurts the game's flow.

I actually feel that hold a button and pushing a direction is more unintuitive and hurts the game flow more than puttting the joystick in neutral *just vertically* to start comboing.

But well, I'll just have to wait and test the game myself then when it's ready

[Tsak]

You don't need to hold the button and push a direction to start comboing (If that's what you're thinking). Regardless of what direction you are holding (or not) pushing fire will initiate a jab. Exactly as you would do in any other arcade brawler.

[Shatterhand]

Originally Posted by Tsak

You don't need to hold the button and push a direction to start comboing (If that's what you're thinking). Regardless of what direction you are holding (or not) pushing fire will initiate a jab. Exactly as you would do in any other arcade brawler.

Yeah yeah, I had understood that

[dlfrsilver]

Originally Posted by Tsak

@Saimon69: Nice ideas, however it's way too early to start thinking about easter eggs and alternative modes right now. I guess everything is possible but we have to wait and see.

@Shatterhand: the key word here for me is responsiveness, how easy/natural it feels to perform the wanted action and how this affects the game's flow. I have a friend who tried the game and only just 5 mins into it he started doing crazy stuff, comboing various moves, flying around and smashing heads like a maniac. And his feedback was that everything felt precise, spot on and easy to perform. Obviously this is something that the rest of our team has also verified.

I agree 100% with the game examples you brought up, like Lionheart and Body Blows (I would add Barbarian and a lot other Amiga brawlers into this list). The main issue with all these games is that the responsiveness is kinda garbadge (imho) and it often feels you are moving a tank around, rather than an agile warrior. Which drags down the whole experience and makes performing moves a chore. Metro siege is hopefully nothing like that.

Now, when it comes to using directions and buttons, it's not like you need to keep the button pressed and THEN press a direction (like it's done in some of the aforementioned games). Just pressing them at the same time works equally as well. And it's exactly as you'd expect from various similar moves in arcades. For example check the Punisher moves list which uses a lot of similar direction and button combinations.



I disagree. If we did it that way, then everytime you tried to move down or up the lane (or forwards or backwards for that matter) you'd do a different attack or move by mistake. What you want to do instead is to facilitate that the player will be able to use his basic jab and combo attacks freely while moving around and not f.e. low kick unintentionally everytime you try to reach an enemy that is below you. Forcing the player to stop in order to jab and do his basic combo is super unintuitive imho and hurts the game's flow.

Anyhow, besides the above, I just want to add here that nothing is set to stone yet and we'll continue refining and streamlining the controls as the game's development progresses. Also keep in mind that we're considering a 3 or more buttons option, so the player will have more variety in regards to his preffered control options.



That's correct
Basically this is another interesting topic I might get into later on. Thanks to this method we were able to create a crazy amount of moves and anims with the minimum possible RAM overhead. F.e. the Alex character has currently more than 230 frames of animation he is just 42k!

Personally I consider this to be one of the greatest technical achievements the team has managed to pull off so far and without it the project would not be viable without sacrificing gameplay and variety in the process.

awesome. SOR sprites don't have the half amount of sprite frames you got.

[alpine9000]

Originally Posted by Master484

Great to see so many different moves for the characters.

Does the game store both left and right facing versions of the characters in Chip RAM ? Or does it use some advanced tricks like real time horizontal flipping or real time decompression from Slow RAM to Chip RAM ?

Originally Posted by DanScott

It appears that the characters are made up of many individual small parts that are reused between different animation frames, so I suspect that they have the chip ram available to store the flipped versions

As @Tsak mentioned above, the "modular animation" technique is the technique that allowed us to fit the huge number of animations frames into the target chip ram budget. The down side of this technique is that there are now a very large number of individual blits that must be done, for example if you have 6 characters on screen and they have on average between 6 to 10 (sometime more) body parts, that's the equivalent of 50 BOBs on screen, then add things like impact flashes, and world objects.

Something I have wanted to do is to make the characters "explode", so we can really see the number of individual objects being managed as they fly out towards the edge of the screen. Maybe this will be an easter egg

[trydowave]

Originally Posted by alpine9000

As @Tsak mentioned above, the "modular animation" technique is the technique that allowed us to fit the huge number of animations frames into the target chip ram budget. The down side of this technique is that there are now a very large number of individual blits that must be done, for example if you have 6 characters on screen and they have on average between 6 to 10 (sometime more) body parts, that's the equivalent of 50 BOBs on screen, then add things like impact flashes, and world objects.

Something I have wanted to do is to make the characters "explode", so we can really see the number of individual objects being managed as they fly out towards the edge of the screen. Maybe this will be an easter egg

has this modular approach been used before or is this a first?

Sort of unrelated but a awhile ago a very good port of Ghouls n Ghosts was being made for the Atari STE. It contains all sprite data from the arcade rom because an expanded STE can access 4mb of chip men. The guy porting it said this could never happen on the amiga because of its limited chip men, even on an A1200. Do you think this modular approach to sprites could be a way of overcoming this when porting a game such as ghouls n ghosts from the ground up?

cheers and thanks for the great work your doing.

[saimon69]

Originally Posted by alpine9000

As @Tsak mentioned above, the "modular animation" technique is the technique that allowed us to fit the huge number of animations frames into the target chip ram budget. The down side of this technique is that there are now a very large number of individual blits that must be done, for example if you have 6 characters on screen and they have on average between 6 to 10 (sometime more) body parts, that's the equivalent of 50 BOBs on screen, then add things like impact flashes, and world objects.

Something I have wanted to do is to make the characters "explode", so we can really see the number of individual objects being managed as they fly out towards the edge of the screen. Maybe this will be an easter egg

Are you also using subpalettes of less colors in a similar way to Powder to save RAM and bandwidth?

[kamelito]

Vroom also used many bobs to be able to draw the cars in différents angles. Sword of Sodan also used this technique at least for the legs and the upper body part.
They probably didn’t have more parts than MS but it is the same trick.

[aros-sg]

Originally Posted by alpine9000

The down side of this technique is that there are now a very large number of individual blits that must be done, for example if you have 6 characters on screen and they have on average between 6 to 10 (sometime more) body parts, that's the equivalent of 50 BOBs on screen, then add things like impact flashes, and world objects.

Quick test: how far away from 50 fps are you if running on A1200 and temporarily replace the BOB restore routine with a blitter clear routine? (For a quick AGA improvement with basically unchanged game code/game gfx one would use dual playfield and have BOBs in second playfield so restoring bobs is just clearing).

[Samurai_Crow]

Originally Posted by aros-sg

Quick test: how far away from 50 fps are you if running on A1200 and temporarily replace the BOB restore routine with a blitter clear routine? (For a quick AGA improvement with basically unchanged game code/game gfx one would use dual playfield and have BOBs in second playfield so restoring bobs is just clearing).

Having 6 bitplanes active hogs a lot of blitter time so forget that idea. It would probably be a net loss of speed especially since they've already optimized the restore routine to opaque blit, I think.

[alpine9000]

Originally Posted by aros-sg

Quick test: how far away from 50 fps are you if running on A1200 and temporarily replace the BOB restore routine with a blitter clear routine? (For a quick AGA improvement with basically unchanged game code/game gfx one would use dual playfield and have BOBs in second playfield so restoring bobs is just clearing).

Our focus at the moment is 100% on getting the OCS game finished, which as you can imagine is a huge task by itself, so I really apologise in advance if I don't engage on AGA questions yet.

I can understand that it might sound like a bit of a contradiction to say that we are laser focused on the OCS version and at the same time announcing support for modern platforms, but the thing with that is, that running the game on modern platforms actually increases the speed of development for the OCS version.

When running on a modern platform, I can take advantage of any development/debugging tool available, as well being able to easily add real-time diagnostic stuff to the game which would not be feasible on an A500. This stuff saves heaps of time.

[aros-sg]

Originally Posted by Samurai_Crow

Having 6 bitplanes active hogs a lot of blitter time so forget that idea. It would probably be a net loss of speed especially since they've already optimized the restore routine to opaque blit, I think.

I'm talking about quick&easy changes to game engine when game detects that it is runing on AGA machine (ie. not real enhanced (more colors) AGA port). So that would mean running in 8 bitplanes dual playfield mode. Only makes sense if that would make 50 fps possible, otherwise is would look and run the same way as non AGA anyway.

If the game is also coming to modern machines (PC) I was guessing code to run the game logic at 50/60 fps should already be there as it would be a bit strange to run the game at only 25/30 fps on modern machines. 25/30 fps on LCD is not as bad as 25/30 fps on CRT. And 50/60 fps on LCD is not as good as 50/60 fps on CRT. But it's still better/smoother (try 2x increased playback speed of trailer video on YouTube).

[Galahad/FLT]

Originally Posted by trydowave

has this modular approach been used before or is this a first?

Sort of unrelated but a awhile ago a very good port of Ghouls n Ghosts was being made for the Atari STE. It contains all sprite data from the arcade rom because an expanded STE can access 4mb of chip men. The guy porting it said this could never happen on the amiga because of its limited chip men, even on an A1200. Do you think this modular approach to sprites could be a way of overcoming this when porting a game such as ghouls n ghosts from the ground up?

cheers and thanks for the great work your doing.

The guy is talking out of his hat!

There is no need to store graphics in memory that are not even going to be used until later levels, so i'm pretty damned sure that the Amiga could do it on a 1meg machine.

The Megadrive got a pretty damned close version and the ROM for that is less than 660K!!!

[trydowave]

Originally Posted by Galahad/FLT

The guy is talking out of his hat!

There is no need to store graphics in memory that are not even going to be used until later levels, so i'm pretty damned sure that the Amiga could do it on a 1meg machine.

The Megadrive got a pretty damned close version and the ROM for that is less than 660K!!!

thanks for clearing that up Galahad

[donnie]

looking to good to be true.

looks amazing.