next »

[the_dannobot]

I read earlier that Terry was planning on doing the coding with Allegro. I also code with allegro and would like to contribute. I don't know what Terry's over all engine will be like but I volunteer to work on some of the game modes if I can figure out how to work with him.

I'm not sure who's doing the coding for this game.  I've got some smash-style fighting game engines laying around that are already complete, but I'm not sure if everyone especially likes the style of animation I use.  Like if it's decided that you guys want this game to be sprite-based, I don't really want to do a top-to-bottom overhaul of the engine to support it. 

I'll post a big explanation later of how my stuff works and what it would mean for the artists, and then you guys can decide what to do.

[Wilson Saunders]

I'm not sure who's doing the coding for this game.  I've got some smash-style fighting game engines laying around that are already complete, but I'm not sure if everyone especially likes the style of animation I use.  Like if it's decided that you guys want this game to be sprite-based, I don't really want to do a top-to-bottom overhaul of the engine to support it. 

I can't imagine it would be to hard to replace what ever graphics with those from the community. I was also going to offer my smash style engine but I wrote that for a speedhack and the code is ugly.

[Xion]

Yeah, it says in there about left and right being relative to a character facing right, so left=backwards and right=forwards.

Another problem I forgot about is that in a Smash style game, when the player presses the 'back' direction, the character turns around.  So if you have a move like "attack+back" and the player's timing is a little off, the character will turn around and do the attack in the wrong direction.  Just might be something to think about.

SSB handles this by having a slight delay when turning around. Also you can increase the window of opportunity to be slightly longer when back is being pressed to make sure the system flags back and attack.

It...it does? Not that I know of. If the character is facing right, and does a smash attack left, he'll turn around and perform the forward attack. The only backwards attack is while in midair, where the character cannot reverse facing.


I am opposed to backwards-attacks nonetheless. I'm still in favor of the moveset I proposed:

button 1 = attack
button 2 = jump
button 3 = block

block + attack = grab
block + jump   = evade
attack + jump  = powerful/special/ranged attack

attack = weak hit (3 types; crouched, standing, midair)
direction + attack (simultaneously) = strong hit (3 types: up, fwd, down)
direction + attack (while moving)   = dashing hit (3 types: up, fwd, down)

then there could also be character-specific fighter-type combos, such as
dwn->dwn+fwd->fwd + attack = missile
or
dwn->up + jump = high jump

So that's like a total of 10 attacks + grapple, evasion, and maybe 3 - 4 character-specific combos?
also,
by default characters have a bit of acceleration before reaching peak speed. This acceleration time could vary from character to character. This time could be circumvented by double-tapping the direction in which motion is desired, resulting in a quick dash beyond top speed followed by a deceleration to full run.
If a controller is being used this could all be analog, I suppose.

whited out 'cause it's probably not relevant so early.

[Shoot-em-upper]

Perhaps it is not a good idea to combin Z,X, or C in a single button combo. While this is easy on the keyboard, I expect this game to include game pad support for multiplayer. In this case We should not expect the user to be able to hit two or more buttons with their thumb. I favor the_dannobot sugestion of having the diection modify the attack.

Have you heard of shoulder buttons?  Besides, I like directional attacks.

[skaldicpoet9]

im telling you man, gomez should always be batshit chainsaw crazy.
always.

Yes, I definitely agree with this.

[Soulliard]

I think Dannobot's suggestion for the controls is best. It gives a lot of options, while staying fairly simple.

However, for the type of game this will be, it should be even simpler. I'd get rid of the super-special attacks (those that require z+c), since pressing multiple buttons to use a single attack is difficult, and I see no need to have more than a single grab. Also, differentiating between forward and backward attacks is unnecessary, in my opinion. That type of control scheme just gets frustrating, since you often end up accidentally turning around and attacking thin air.

As long as the game doesn't have an archaic combo system, though, I'll be happy.

[Stij]

I don't really care what kind of fighting system we have, as long as we you don't have to memorize huge A+B+B+C+left+right+up+down+R+A+C+R+do a jig combos like in the Street Fighter series.

[Wilson Saunders]

Does anyone know how to make an AI for a fighting game? I did it once by hooking up the rand() function to the input buttons. It simulated a button mashing player quite well. It also liked jumping off cliffs. However if you want to simulate something a little more intelligent, I would like to hear suggestions.

[the_dannobot]

Does anyone know how to make an AI for a fighting game? I did it once by hooking up the rand() function to the input buttons. It simulated a button mashing player quite well. It also liked jumping off cliffs. However if you want to simulate something a little more intelligent, I would like to hear suggestions.

Yeah, here's a really goos system for doing AI for a smash-clone fighting game.

You set up your AI to update every time a specific time delta expires.  First, the bot has to pick a target.  This can be as complicated as you want it to be, it can select the last guy to hit it, the guy with the least/most amount of energy, the guy who's currently winning, or just the closest enemy. 

Then, the bot needs to select an action to take.  If it's really far away from its target, it can dash or walk towards it.  If its above/below, it can jump or drop down.  The goal is to get it close enough to be in melee range of the target.

Once it's close enough to the target to fight, it needs to take into consideration its current state and the target's current state.  If the target is attacking, it should block/parry/counter.  Otherwise it should select an attack that is valid from the bot's current state.  Selecting the attack can be as complicated or as easy as you want it to be.  If it has hit box data stored for each attack, it should select the attack most likely to hit.  Otherwise, selecting a random attack works okay too.

So now whenever the AI updates, it will always pick the best action to take given the current situation.  The best part about setting up a system like this is that to make the game easier/harder, all you have to do is change the time delta between AI updates.  An AI that updates like every 0.1 seconds will be really hard, but an AI that only updates every 2 seconds will be really easy.

[Wilson Saunders]

@ the_dannobot
That sounds a lot smarter than my random button masher, but if we are going to make a multi level game with bottom less pits of doom, how do we tell the AI to jump over them?

[the_dannobot]

One thing you could do, is when the AI is doing its update, have it check if it's been airborne for more than like 0.5 seconds.  If it has, cast a line straight down from its current position.  If that lines doesn't intersect a peice of level geometry, it means it's floating above dead space.  If that is the case, have the bot target the nearest piece of geometry and force it to do a "movement" action.

Honestly, I cheated on my last game so I wouldn't have to worry about this problem.   

Like in Smash Bros, the character have a low terminal velocity after which they stop accelerating due to gravity, and the boards have a lot of dead space between the level geometry and the "edges of death".  As a result, even if the player gets hit really hard, they can still often slowly float back to safety.  The AI in a game like that would have to be smart enough not to chase an enemy off the edge of the board to their own death.

In Super Pillow Fighter, the characters accelerate downward very quickly, and there's little dead space between the edges and the level.  The result is faster gameplay with no slow floating, so if you are knocked off the board you die really quick.  Enemies that get knocked off the board die too fast for the AI to have a chance to follow them.  After an enemy dies they spawn back in the middle of the board, and the AI will turns around and targets them.  My AI never even checks if it's in danger, I didn't do any fancy logic because the situation almost never comes up where it could recover back to safety anyways.

[skaldicpoet9]

I think Dannobot's suggestion for the controls is best. It gives a lot of options, while staying fairly simple.

I totally agree. I think a two-button layout would maintain enough variety but also make it simple enough to be fun and not a long and drawn out string of buttons presses for specific combos.

One thing that was never mentioned in the design doc was level design. Are we going with multiple levels and inclines like Smash brothers? Or will this be flat and simple like Street Fighter?

I think a multiple platform design would be the best option for this game since a lot of the characters that are going to be featured in this game are native to the platform genre, plus it adds an extra element of depth to the gameplay in that there are also physical obstacles to overcome and not just your opponent.

All in all this is sounding pretty damn good. I am almost as excited about this game as I am about Brawl lol...

[the_dannobot]

I'm not sure who's doing the coding for this game.  I've got some smash-style fighting game engines laying around that are already complete, but I'm not sure if everyone especially likes the style of animation I use.  Like if it's decided that you guys want this game to be sprite-based, I don't really want to do a top-to-bottom overhaul of the engine to support it. 

I'll post a big explanation later of how my stuff works and what it would mean for the artists, and then you guys can decide what to do.

So here's how the art and animation works in my engine:
For the characters in the game, it does something a little bit different than traditional sprite-based animation. The engine uses a skeletal "paper-doll" style of animation, because it makes the artist's work a lot easier and allows for higher-def artwork. All teh character artits would have to do is draw each body part separately from like the front, side, and back.

As an example, here's a programmer-art girl I've been using to test stuff:



When it's all put together, it looks like:



The tool for putting the art into a skeleton is sort of complicated, so once the artists are donw on their end I would volunteer to do that part.  But once the skeleton is all set up, cranking out animations is really easy, so anybody could do it.  It can also do ragdoll physics on parts of the skeleton during runtime, so stuff like the little tassle on Chainsaw Gomez' head would look really cool

Like I said, a downside is that a lot of people don't like the look of this type of animation.  The upside is that the whole engine is pretty much done already, and it would cut the art requirements into a fraction of what would be required in a sprite-based engine. 

Let me know what you guys think of all that.  If you like it, I can start doing a first pass at the gameplay with "Batman Beyond Girl" up there as a placeholder character.

[shinygerbil]

artits

[skaldicpoet9]

I don't know...

Personally I would prefer a more traditional pixel art approach but that's just me.