Printable View
Looking for help on this I have started building a game and i have no idea where to start. right now i just need to understand how to make a select screen i have made a few platf. games but this is my first attempt at a select screen
thanks for any help you give
What do you want the player to be able to select? "select screen" is very, very generic and could mean anything, I have little to no idea as to what kind of select screen you want - Menu, Level, Difficulty, etc?
more of a mortal kombat or street fighter select screen
Ah, then you'd probably want a selector for the characters, then?
My question to you would be, are you sure you're up for the job of creating this game? If you're new and trying to learn MMF, making a fighting game with character select is no easy job.Quote:
Originally Posted by lastlightstudios
Giving the player a character select screen opens up a whole hornets net of coding nightmares, believe me, I'm in the middle of one right now! The way it works is, you create a screen with your characters on it and allow the player to pick one to play as. You then note their selection, use a Global Value is easiest, but then, for every level that the player can play in, you need to code for every possible character that the player can select. Your coding has to take into account every possible encounter the character will have in the game, and then you have to program for that for every character in your character select screen. Movement, collisions, animations, data values, it can be a nightmare at times!
Giving the player a character select screen is great fun, but coding it throughout your game is not! Definitely not something to be undertaken lightly.
I'm not new to it i have mad a few games such as strange world 101 and so on..Quote:
Originally Posted by Paul_Boland
but just understanding what coding goes where is what i'm stck at i have mad all my char. and select board i'm trying
to understand this i just need like a layout i guess
I have an idea where you should start, and it's not the selection screen.
I believe you create the selection screen last. Just assign different characters a different global variable (ie. 1-10 for the different playable characters). Test the different characters by changing the global value before starting the game.
Once you have an engine that allows more than 1 different character to fight each other, then you can work on the interface.
I'm only saying it because while a character selection screen looks impressive and may appear like your fighting game is 50% complete, it's more like 1% complete.
A lot of people never finish the game engine, therefore time spent making interfaces is wasted time.
I agree with this i will get started on that thanks for your helpQuote:
Originally Posted by Ryan
Ryan has the right idea, you assign each character a unique number. So for example, if you have 2 (yes, let's just take 2 for now) characters in your game for the player to select from, you would have a Global Value store which character the player has picked. For this example lets say Character Red is 1 and Character Blue is 2. When the player picks red or blue, you store the corrisponding value in GV_PlayerCharacter.
Then in your levels, you need to code around that Global Value. So to move up,
Player presses Up Arrow
+GV_PlayerCharacter = 1
>Move Character Red up.
Player presses Up Arrow
+GV_PlayerCharacter = 2
>Move Character Blue up.
To punch:
Player presses Fire Button 1
+GV_PlayerCharacter = 1
>Character Red play animaiton Punch
Player presses Fire Button 1
+GV_PlayerCharacter = 2
>Character Blue play animaiton Punch
See, every individual character has to be programmed for so for two characters, every programmable event for each character is doubled. If your fighting game has ten characters, that's ten times all your programming for one character. Character selection is great in game but a nightmare to program for.
ok i have the basic layout made i'm on the stage part of my game how do i make both fighters face each other at all times?
and how do i set the cam to fallow both char.?
thanks for all the help guys
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.
if i do this will they always face each otherQuote:
Originally 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.Quote:
Originally Posted by Ryan
To allow the players to keep facing each other after they have jumped over each other, you need to set up the following events:Quote:
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.
Why can't you just have two invisible actives?!Quote:
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?Quote:
Originally Posted by Ryan
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.
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.
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.
Good idea, LB, I didn't know you could pick an animation based on a number.Quote:
Originally Posted by LB
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
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.
http://media.eventhubs.com/images/2011/02/15_blog06.jpg
From Street Fighter 4: See the hitbox in red vs the hurtbox in green.
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 ;).
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.Quote:
Originally Posted by Ryan
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