Design of 2D Fighting Game Engines


#1

Hello everyone, I’m new to SRK and I just wanted to greet everyone and ask a small question…

I’m curious to know generally how most 2D games are designed in terms of management and methods of accomplishing common problems. For instance, how are all moves handled by a 2D fighter? Are the moves scripted for maximum flexibility? For something like MvC2 I would think it would have to be, because while a lot of moves have very similar cause and effects, others are completely unique. Having uniqueness means pretty much that having a generic structure of “moves” so to speak is near impossible (example like the green bubble trapping you from the last boss).

So essentially I’m wondering if most of the games all have complete seperate code done for every move, down to even moving the opponent away. Say Ryo when he does his level 3 super in CvS2, it hits him and the person flies across the screen and gets dizzy, the “flying” isn’t something that most moves do, so I would think that it would have to be customly scripted to get the right effect.

I’m asking because I’ve been a game developer for quite some time, and I’ve also been a really avid fan of 2D fighters for a long time; and I wanted my next project to be a 2D Fighter.

So what does everyone think? Any feedback would be greatly appreciated, thank you!

  • Consty :tup:

#2

Since you’re new, I’ll let you know that this probably belongs in Fighting Game Discussion.

-9


#3

Consty, I think the majority is done in C or C++, but that is an assumption. I’m interested in doing the same, I’ll send you a PM.


#4

(wanders in like a shameful puppy with its tail between its legs)

Hi!

I think what you’re trying to ask is whether or not you can derive moves from others. In C++ terms, the question would be, “are there parent classes and child classes of moves?” or “do move-classes use inheritence?”

As far as I can tell, the answer is no. I don’t think this is an impossible thing to do, but rather it just hasn’t been done. Each move can be classified as having some basic properties: damage, startup time, recovery time, knockback. However, the difficulty is in the collision detection. For each unique move, the collision data is completely different. Since you’re going to end up making seperate code for each individual move, it seems unnecessary to give them a parent class to inherit properties from.

To me, a move is a script of actions and/or events. It’s these actions and events that can be made into common functions that can be used by a wide variety of moves. Still, most moves are going to come down to an animation sequence and collision changes.

I tried to put game development behind me, because I suck at coding, but I can’t resist the temptation to get involved in a project. :shake:


#5

You’ve been a game developer for “quite some time” and you don’t know these basic things?

Are you actually a professional or an amateur? There’s no shame in being an amateur game developer, but your lack of experience leads me to believe you haven’t actually been paid for your work.

In any case, here’s how it usually boils down to.

There’s a generic engine for character blits. There’s also a generic collision detection engine, with hitboxes. There’s usually 2 kinds of hitboxes: what I like to call “Offensive” and “Defensive”. Quite often those 2 overlap, but sometimes they don’t (in the case of projectiles, they’re only offensive).

The game loop is basically this: read character input, and translate them into blits and collision detection. If an offensive box hits a defensive box, perform a blocking check. If it’s blocked, the blocking character receives no damage (this can vary from game to game); if it hits, the hit character performs the offensive hitbox action.

Usually, there’s also a generic script engine that gives moves effects. When a hit is performed, it just plays back the script. For your knockback and dizzy effect, there is almost surely a “knockback” variable that can be adjusted to the whims of the game designer. A lot of moves do knockback, just not to the effect of that specific move, but since the script system is flexible in itself, it’s easily possible.

If you want to make a flexible scripting system for events in games, just make it so you add in new effects you want when you need them, and make them with PARAMETERS. Those parameters will determine what you can and cannot do. Any good game designer will fool around with those parameters to gain the wanted effect, and as a game designer myself I love to fiddle around with scripting to achieve the effect I want even if it wasn’t initially included.

For example, my latest title is a skateboarding game for cell phones. Initially, we hadn’t planned to include obstacles in the maps, because they would be too costly and the devices we needed to support wouldn’t be able to run it. Near the end of the project, we shifted platforms a bit and we realized it was possible to add new objects without too much of a performance hit. The problem was adding new collisions in the scripting engine was proving to be too long and difficult, and the scripting system was already flexible to a certain point. Since our system already had variables for height and “crash” zones, all I did was script in the display of a trashcan in the middle of a track and faked an obstacle: I put the height of the image as the height of the track, and put a crash zone on top of it so that you couldn’t skate on it (it’s not really possible to ride on top of a trashcan, now is it?).

See, a nice and flexible scripting system can work wonders in this type of situation. It’s the same with fighting games; just let your designer(s) run wild with possible effects, and you’ll end up with a good result.


#6

As timekillr mentioned, moves are easily scriptable. There’s nowhere near that many variables in moves that you couldn’t do them as a script. Writing each move as it’s own code is just retarded and a great way to ensure your project never goes anywhere.

Also timekillr, a cool technique I use is to give a ‘move’ a List that can contain ‘MoveEffect’ classes. The MoveEffect class is abstract and does nothing itself other than containing a reference back to the move. However, the idea is to expand the class and make additional changes on how the host move updates. The move class calls these MoveEffects when it updates, so you can essentially use these small MoveEffect classes to create non-standard effects on moves that a regular move could not do. For example, you could have a projectile with a CircularMoveEffect, which causes the projectile to move in a circular pattern around it’s host. You can also use them for effects onHit, or whatever else.

It tends to help more with Projectiles and bullets in 2D shooters, but it can still be useful for other things.

(You can also do it with function pointers, but that tends to be a little more ugly)

As for what to write an engine in… use C# under Visual Studio.NET. The language is far easier to use than C/C++, and the only real limitation is memory management and garbage collection (which is a non-issue in fighting games). DirectX is a little weird to do 2D with, but it can be done. Plus then you get to use Pixel Shaders and happy things like that.


#7

True. In any case, I wanted to show that it’s really not that complicated :slight_smile:

I’m more of a designer than a programmer, although I need to work with an in-house script engine all the time, so I learned to get around it’s limitations.


#8

This is somewhat off topic but I’m asking it here because someone might know. Is there any way to change the window’s style shortcuts in visual studio.net to emacs style shortcuts? I’ve been programming games in my free time and I’m seriously considering switching from C++/VS.net to java/eclipse just because I hate the shortcuts in VS.net so much (also java has some new and interesting graphics related classes, but they probably still aren’t as powerful as directX and platform independence is nice). I would switch to g++/emacs, but then windows people wouldn’t be able to play games I’ve written.


#9

I guess I should have been more speciifc. I was just curious as to how most fighting engines did movement from attacks, the rest I think I understand well. Collisions and such wont be a problem; pixel perfect collision detection is easy. I have an understanding of how I think I want to do it, but I’m doing research before putting fourth the time and effort.

To answer your question timekillr, I’ve only developed simplistic final fantasy ala snes style games. The most popular of which is Mirage Online (you may or may not have heard of it http://www.miragesource.com/ ). It was basically just final fantasy 4 for the snes, but online multiplayer where hundreds of people could play at the same time.

What I want to do now is a fighter which is entirely different and requires a whole new level of design and understanding, I just want to make the right design choices prior to programming.

Thank you for all the replies, it answered my question.

  • Consty :tup:

#10

I really don’t like Java’s graphics classes, but you might have better luck. There have been a few projects done with the Java2D that looked real nice, so I’m assuming they have a lot of power in the right places… I just don’t know about speed or Pixel Shaders and other things.

For that matter, I’d suggest you use C# over C++, but I guess that’s me.

Don’t know about changing shortcuts, I thought they were fine in VS. Just look around the options, it’s probably in there somewhere.


#11

This is an interesting thread for us games programmer types. I am an amateur games programmer, who has recently graduated from University with a 1st, but I lack experience of how to solve some key problems when creating a fighting game, coding in C++ and using DirectX. I have actually started creating my own game, using the 3S sprites. What I am finding to be the most difficult thing at the moment is creating a good Input Manager for the game. Detecting QCF motions, Dragon Punch motions and so forth. Looking back through SF games in general, one can see that in the early days it was much harder to perform a dragon punch motion in World Warrior than say in 3S. Could anyone shed some light on how this has been done? I have actually come up with a method of doing it, but it’s very early days and I am not too sure how things will work out. Right now I am trying to convert my custom input manager’s inputs into rendering the correct move onto screen.

If anyone is interested in explaining any of this to me, please add me to MSN and contact me because there are so many questions to ask, I just cannot post them all here. I’d be more than happy to show anyone interested my code as this is purely a pet project for me to do, and more than anything I jsut want to learn how a fighting game is put together.


#12

Honestly, with a good flexible animation engine that whole Ryo fist thing shouldn’t be hard to implement. In terms of inputting the moves, you would have to create an event queue wrapper considering all the event handlers I know of aren’t flexible enough.

In terms collision detection, I recommend activating the Akuma glitch in SSF2TR for the GBA and learn of collision boxes are implemented in the real world.

Of course I’m assuming you’re coding in C++ and you’re using a low level API like SDL or DirectX.

and on a side note, C# is an excellent language but it hasn’t made a significant dent in C/C++ chokehold on the game industry. Don’t even get me started on Java.


#13

Any games studio worth their salt has a proprietary sprite/animation editor that allows them to import and string together still frames, with animation offsets flipping flags and bounding boxes. This is necessary for almost every 2D game.

The editor Capcom uses will most likely be an extended version of this generic tool, that will allow them to assign damage and vulnerability regions (spheres, boxes, bitmap images) onto individual animation frames. This basic functionality will allow them to create moves with invulnerability frames, or large areas of damage inflicting pixels (ie projectiles.). Each animation frame would posess attributes like delay (how long this animation is shown in frames), damage*, stun* etc. As well as flags (that can probably be redefined per game) to indicate whether an attack ‘knocks down’, launches, juggles, cancels to specials, is an overhead etc.

Throws would probably include a single anchor point to indicate where the oppoents character should be positioned. As for solving the sprite overlaps, you’re on your own there mate :slight_smile:

  • Damage and stun probably work slightly differently, to allow a move’s ‘active frames’ to span several animation poses.

#14

Would it be possilbe to elaborate a little more on the Event Queue Wrapper please? A further problem with detecting special move motions is that one can do a dragon punch by pressing forwards, then QCF and still get a dragon, not a hadoken if pressed quickly enough. Or you can get a Sonic Boom by charging down-back, and in 3S you can fire a sonic boom by moving the stick back, forwards, then pressing the button at the same time as you move the stick backwards again.

I have a system for dealing with some of this, but to me the most important part of a fighting game is the Input Manager as well as the collision detection because many games have been killed because they are no fun to play. It’s for this reason that I am putting so much emphasis on creating a good Input Manager.


#15

I developed my own framework for a fighting game over last summer. One of the most difficult tasks for me was accurately detecting command motions from input.
I solved this problem by having an array with each element representing all the states for input for eaching input device (for example every button on a gamepad). Each element matched up with a frame of game time, which was updated a set amount of time. The buffer is checked in order to see if any motion matches a particular patter for a special or super. I also developed my own scripting system in order to easily control the patterns for these motitions. The most challenging thing about this method is developing the algorithms to match motions.
Good Luck!


#16

Somebody needs to make good use of the Capcom (and some SNK) sprites from SvC: Chaos, as well as the music, backgrounds and such.


#17

I’ve never actually implemented it, but I know a common method is to take events from the general queue and put them in specialized queue. So there would be a queue for player 1 and another for player 2. and I would imagine that the players would have a queue for joystick input and one for button input.

What becomes an issue is when to clear the queue so that the user can’t hold back for 2 seconds, let go then press forward to sonic boom. Again, I know the general idea, but since I haven’t implemented my own version I can really say all the details.


#18

Interestingly enough, my soultion is very similar to this. I use a “Move Buffer,” an integer array 50 in size. When the buffer reaches the end, it loops back to the begining. My manager can detect all eight positions the stick could be in, e.g Up, Up-Right, etc, as well as neutral. It can also detect if one of these directions has been held down rather than tapped. Every update, the move buffer is checked for a series of pre-arranged move sequences, such as QCF. The simplest way I can explain my method is that if a player taps the “Down” key, the first part of an object called QCF is filled, along with the first part of a “360” object and “charge down” object. If the player then over a given time taps or hold the down-right key, then the second part of the “QCF” object would be filled. When the player presses the Right Key after tapping the first wo parts of the QCF, the QCF is completed and added to the move buffer, where it will stay for a pre-determined amount of time. If a player then taps a punch button, the move buffer is inspected and if a QCF has been found within a certain time frame of the punch button being pressed, then a Fireball would be activated. So far I have been able to succesfully determine between walking, dashing, jumping, super-jumping and many other basic motions using this method.

However, my main problem I experienced is that this method is still quite “strict”. I can get any move I want, but often you must be far too accurate in key presses to get the move, akin to Street Fghter 1. How did you acheive flexibility in entering inputs to make the game easier to play for players? Could you expand on your scripting system as well? I appreciate that it must have taken quite some time to develop this, as I myself have spent a long time on my project also. However, anything you can suggest or elaborate on would really be useful to me.


#19

I wrote one of these for a tech demo years ago. It had the caorse input problems you mentioned. If I were to write another, I’d do it something like this. It allows for overlapping charge times, partitioning and so on.

With some tweaking it should allow players plenty of leeway. If you aren’t getting the desired results from specific moves, you could add checks in for unwanted pressed. Sort of a negative state, to help the move checker along. This might be helpful to aid the move checker in identifying the difference betweek Hadoken and Shoryuken for example? I hope it’s of some use.


#20

That’s prettyy useful stuff, thanks. Actually you have coded in way that may have solved one of my other problems. The way I coded my manager, when a player made a motion for a half circle, say for exampel Ryu’s Red Hadoken from ST, my manager would actually read that motion as Back, Down-back, Down-forward, Foward, skipping the stick in down, even though the stick had to be moved in this way to perform the motion. Thanks and check your PM.