How do i make a select screen for a fighting game?

[Paul_Boland]

Ok, I think I see where you're going with this. I have one Active Object on screen twice, the same object, and I'm using Alterable Value X to dictate which copy is controlled by which player.

So...

Player 1 pressed Fire
+AV_X of Character = 1
>Character play animation Punch.

Player 2 presses Fire
+AV_X of Character = 2
>Character play animation Punch.

I now have two events, not one. Now, agreed, this is for reading in which which player control is pressed, so let's look at another example.

How do I distinquish the characters? If both are the same, they will both look the same on screen, that's not good. So to take from something you said, let's say the two character models are inside the one Active Object. Based on the Global Value you then display the required animation. But that would lead to even more coding then you need the way I indicated above because you'll always have to test for who is who and display the required animation based on that. You'd need another Alterable Value (Y) to keep track of which character the player is playing as.

Example:

Player 1 pressed Fire
+AV_X of Character = 1 //Player 1's character
+AV_Y of Character = 1 //Player 1 is human
>Character play animation HumanPunch.

Player 1 pressed Fire
+AV_X of Character = 1 //Player 1's character
+AV_Y of Character = 2 //Player 1 is beast
>Character play animation BeastPunch.

Player 2 pressed Fire
+AV_X of Character = 2 //Player 2's character
+AV_Y of Character = 1 //Player 2 is human
>Character play animation HumanPunch.

Player 2 pressed Fire
+AV_X of Character = 2 //Player 2's character
+AV_Y of Character = 2 //Player 2 is beast
>Character play animation BeastPunch.

You're leading yourself into even more complex coding then using individual objects for each character.

[LB]

Can't you just make a list of animation numbers that correspond to events and play animation by number (the corresponding value from the list)? It seems like a much easier way to do it.

[Paul_Boland]

There is no way to test for collision controls properly between players when they are the same Active Object.

Character collids with Character
+AV_X of Character = 1
+AV_X of Character = 2
...
>...

This always retuns false and does not execute. This is a problem when wanting to test for impacts between characters when they are fighting. It's much easier to keep the two as two individual Active Objects. It's a good idea to use Alterable Values to distinguish characters but it doesn't work when you're dealing with multiple player interactions.

[Paul_Boland]

Can't you just make a list of animation numbers that correspond to events and play animation by number (the corresponding value from the list)? It seems like a much easier way to do it.

Good idea, LB, I didn't know you could pick an animation based on a number.

[Ryan]

I was trying to simplify things with pseudocode, the correct MMF2 way of programming it for network play (notes: key 'space bar' initiates punches, players AV_X values are 0 and 1 instead of 1 and 2 for compatibility with fast loops, I've commented the code with /* my comment */ ):

/* Local player punch (can be duplicated and edited for shared keyboard play)*/

The key 'space bar' is pressed
+ AV_X of Player = AV_X
> Set AV_PunchPressed of Player to 1

/* Multiplayer opponent punch */

Packet Received tells us to punch
+ AV_X of Player = (AV_X + 1) mod 2 [this is math to get opposite player. ie. if current player is 0, return 1, if current player is 1 return 0]
> Set AV_PunchPressed of Player to 1

/* Processing the input for both players */

Always
> Start loop "getinput" 2 times

On loop "getinput"
+ AV_X of Player = loopindex("getinput")
+ AV_PunchPressed of Player = 1
+ AV_X of Character = loopindex("getinput")
>Character play animation Punch.
>Set AV_PunchPressed of Player to 0

[Ryan]

Regarding collision testing, straight up animation active vs active collision tests is oversimplifying the problem. It can work if you choose to duplicate all events for both players, but once again, it's asking for a world of hurt later down the track. Not to mention, you could potentially kick somebody with your back as long as your animations are overlapping.

Advanced fighting games use hitboxes that are bound to animation frame states. These would be active object rectangles that change size and width depending on which frame of animation is playing.

A collision for both players can be tested via hitboxes vs hurtboxes with unique ids for both players. You could then determine whos hitbox overlapped whos hurtbox for damage. A hitbox will never need to be tested in collision with another hitbox therefore the problem you demonstrated is not relevant. See gkinfinity's post about hitboxes on page 2.



From Street Fighter 4: See the hitbox in red vs the hurtbox in green.

[Paul_Boland]

I think this conversation has run its course for me so I'm going to bow out here. You've shown me an interesting idea on approaching multiple-player characters, but it's not one I think I'll ever enbrace. For me, it seems it could be problematic at times. I'd much rather have unique Active Objects for each player character. But it's an interesting approach...

Regarding the fighting hit points, yes, you are right about having to designate parts of the body as hitpoints. Who wants to be kicking with their back .

[Ryan]

I get where you're coming from. There is nothing wrong with sticking to what you know, or as the saying goes 'better the devil you know'.

To clarify any reservations people have, I can assure that the method is sound. It's been tested, proven and is utilised by MMF2 programmers in all matter of games. I wouldn't want it to be disregarded as creating more problems than it solves, as the result is precisely the opposite in larger projects. In small projects the difference is negligible, but the larger the project grows, the more effective the method becomes.

[Paul_Boland]

I get where you're coming from. There is nothing wrong with sticking to what you know, or as the saying goes 'better the devil you know'.

To clarify any reservations people have, I can assure that the method is sound. It's been tested, proven and is utilised by MMF2 programmers in all matter of games. I wouldn't want it to be disregarded as creating more problems than it solves, as the result is precisely the opposite in larger projects. In small projects the difference is negligible, but the larger the project grows, the more effective the method becomes.

And just to clarify, while it's not a method I can see me taking up, I am in no way putting this method down.

[lastlightstudios]

thanks everyone for the info all very helpful and cuz of this info

i'm almost done with my fighting games thanks everyone for being so helpful the methods above do work just need miner tweaking

thanks again later