next »

[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.

[Ixis]

I think a traditional pixel approach is the way to go, and it's what most people are expecting based on some of the sample art that's been made and the reactions.

[Wilson Saunders]

Bump. I would hate to watch this thread die.

Any way from the past few pages it seems like both the_dannobot and I are thinking about coding this. Ixis still seems in charge of these shenanigans. All we need is a legion of sprite artists and level designers and we will be set.

On thing we could do is encourage people during the Art/Code Compo to make renditions of their favorite Indie game character. We may end up with 10 Indie Brawlers when the smoke clears.

Another thing we could try is making Brawler frame work that consists of a menu system, a character selection screen, A game type/level selection screen, a base class that each game type will inherit from, some helper classes that the base class can use, and some level/character design tools to create static files that can be loaded by the helper class.

I would prefer to discuss this in a more real time format with whom ever is interested. How about we meet on the IRC at a specific time?
I am free on the the Tuesday, Thursday and Friday after 5:00pm PST or 1:00AM GMT. Also I am free all weekend (because I have no life  ).

[skaldicpoet9]

Augh, damn my pathetic lack of coding or pixel art skills. I would sooo start busting out some pixel art right about now.

Maybe what we should do for the art is to have people start submitting some stuff to a new thread and we can all vote on what style suits the game the best?

[Ixis]

Ok, I think if we're actually going to do this (and no one's sick of it yet) we'll need some code and art down first (code more than art.) Who had some basic code out that could be used? (Just a character select, stage select, and multiplayer with two guys moving around, nothing more) or anything more/less similar?

Who's willing to be a core programmer and who's willing to be a core artist? I can do some basic art, GUI and such but I can't pixel art or animate worth crap.

[Wilson Saunders]

I would be willing to be Core programmer but I would prefer to do this after the Art/Code event. I am working on a very small project now that will probably be done before that event. While that event is running I want to participate in both the art and the code side of things. After the event I have no plans so making this sounds like fun.

I can have an engine with two guys jumping around a level fairly quickly. However there are some design specifics I want to hammer out before writing a single line of code. I would prefer to do this over IRC or some other real time media.

Here is a list of basic design things that need to be decided before coding:
What will the levels be made of structure wise (tiled squares, horizontal bars, abstract shapes, something else) ?
Will it be Horizontally/ Vertically scrollable or will the action take place on one screen?
Will there be Zooming? (the further apart the characters are the wider it zooms to keep every one in view)
What sort of rendering library will we be using? (I am most comfortable with allegro and magic pink, If you want an alpha layer you need to find some one else)

It is one thing to talk about boss battles and cinematics, but until we lay the foundation of screen rendering and level creation this will go nowhere.

[the_depraved]

bump for great justice.

[threesided]

I can lend my pixel skills here in terms of things such as character portraits, some minor stage elements such as platforms etc, potentially even roughing out stage backgrounds, but as for animation, I'm way too slow at that to get anything good. I'd be willing to do this as long as someone else wants to go halfzies on the core art with me.

[Xion]

I'll help with the art (definitely animations) when I can but that I might be timely-reliable is unlikely.

[Seth]

Same.

[the_depraved]

I also. once i figure out how to do stuff like that.