Set the screen to center on the position halfway between the players? But make sure you force the player to stop when they reach a fixed distance from the other player.
Set the screen to center on the position halfway between the players? But make sure you force the player to stop when they reach a fixed distance from the other player.





Always
>Centre screen at (X of Player 1 + X of Player 2)/2
That will keep the screen centred on the midway point between both players.
To make the players always face eachother, just set one players direction to look left and the other to look right.
KnightTrek Productions
http://www.knighttrek.com
if i do this will they always face each otherOriginally Posted by Paul_Boland
example (if player one jumps over player 2 will player 2 turn to face player1) this is to prevent each other from ever facing back to back
I disagree with your methodology Paul regarding the handling of multiple characters. You'll end up with loads of copy-pasted events.
I'd only have 1 event per action for all characters.
For example, the arrow keys will control an invisible 'active'. This is your placeholder which will have a visible character active bound to it. The binded 'character' is then created at the start depending on which character they chose (the overlayed actives will be positioned with: always set position of character to 0,0 from placeholder). Thereby, 1 event will control all characters, and different overlays are used depending on character choice.
Hitting punch can change the animation on all overlayed characters, but because we're only creating 1 character per player, it will only have an effect on the 1 active in the game with the character chosen.
That way you only have 1 event per action for all characters, and you wont get lost in a sea of copy-pasted events. You'll also beable to add new characters with very little coding, allowing for you to focus on the animations.





You are right in that that will work if only one character is on screen at any give time. But what if there are two? What if a second player comes into play? You now have two characters of the possible "lot" from the selection screen in game. By all means, if there is ever only going to be one of the playable characters on screen at a given time, then yes, this works great. But if the game will allow two or more characters on screen at once, this does not work. In that case you do have to program multiple events for every character possible and the coding becomes a nightmare to handle. Given that the question was for a Street Fighter type game, this was the assumption underwhich I based my reply.Originally Posted by Ryan
KnightTrek Productions
http://www.knighttrek.com





To allow the players to keep facing each other after they have jumped over each other, you need to set up the following events:Originally Posted by lastlightstudios
Always
>Set Player 1 to always look at Player 2
>Set Player 2 to always look at Player 1
This will keep the characters facing eachother at all times.
KnightTrek Productions
http://www.knighttrek.com


Why can't you just have two invisible actives?!Originally Posted by Paul_Boland
That's my thinking exactly, Ricky.
There will be some duplication for player 2 but only for player 2's different set of input keys.
I wouldn't recommend this for someone without a good deal of MMF experience up their sleeve, but just to explain my overall philosophy Paul, here's how I'd address the problem.
I'd make player 1 and player 2 the same invisible active, created twice, and target them based on their unique ID. For example
Global value 'x' = 1 or 2 (player 1 or 2 decided at start up for multiplayer over a network, otherwise decided by the input keys they pressed on a shared keyboard)
Player 'x' presses punch
ID of active 'overlay' = 'x'
- Set animation for active 'overlay' to 'punch'
(repeat for all characters, or if all characters are contained in 1 active, then there's even less copy-pasting)
Player 'x' presses jump
ID of active 'placeholder' = 'x'
- Make player jump (do some sweet parabolic equations with the x,y values)
Then by fast looping it twice for player 1 and 2, you'll give each player a chance to input every frame. Over a network you'll need to translate received packets into input key presses. No nasty copy-pasting that would double the time it takes to make adjustments in the future.
Of course, this is bypassing the whole 'platform movement' setup, which I believe is necessary for a fighting game with tight controls... it all depends on how refined you want to take it.
Fighting games can be very hard to make. No offense or anything, but if you're not sure how to program a character select screen this project might be a little too much for you to tackle right now. I'm not trying to discourage you either because you'll probably learn a lot by just trying to make it. If you're planning on making something complex you probably won't be able to finish it though. I've started countless projects over the years and ended up scrapping almost all of them because they were too hard for me. Only now after about 5 years of messing around with MMF would I probably be able to make a 2D fighter (and it still wouldn't be that good). Of course, this all really depends on how complex you want your game to be.
Here are a few things you'll probably need when making a good fighting game-
-Character select screen. This could be done pretty simply if you wanted to. You could just have the player click on a portrait of the character they wanted to use. I would personally use a selection box controlled by the arrow keys however
-Health bars/special bars (should be easy enough to code)
-Many animations will be needed for each character for this project
-Different colors for characters (if both players select the same character) or some way to tell who's who at least. Maybe you can just have a floating P1 and P2 sign over their heads.
-Movement engine with knock-back
-Detectors. As Ryan mentioned you should have an invisible active that the players control and have the character sprite simply set to follow it. Fighting games also have invisible hitboxes/hurtboxes. Hurtboxes are pretty much just invisible detectors that overlap your character and determine when your character is hit. Hurtboxes usually just overlap the characters main body. Hitboxes are invisible detectors too but they determine when your character hits the opponent. These commonly just overlap your characters hands/feet/weapons. When a hitbox of one character overlaps the hurtbox of the other, the 'hit' character is knocked back. The thing that makes hit/hurtboxes annoying is that they are usually different for every character so you've gotta spend some time figuring out how long each one stays out, how large each one is, where each one is positioned, etc. If you're unfamiliar with them, here's a random example-
http://www.youtube.com/watch?v=kziM3c_91TM
-And finally, you'd need a victory screen of some sort
As far as the whole 'choosing from multiple characters' thing goes, Ryan is right. It wouldn't actually require extra coding for different characters EXCEPT for special abilities/attack effects. For example, pressing attack for one character might do a straight punch while for another it does a jumping uppercut /shoryuken





Ryan, you've completely lost me!?! LOL!! If I have four characters on screen at the same time, Player 1, Player 2, Player 3 and Player 4, how can one event control an aspect each individual character individually? For example, how can one event tell one of the four characters to Punch?Originally Posted by Ryan
KnightTrek Productions
http://www.knighttrek.com