Hmmm I only Just wrote a lengthy email about this topic
I got an email which asked:
"Hello,
I have been scouring the net recently for various information related to game development. My most recent ventures have been related to fighting games, more specifically the input systems contained therein. During this search I came across a post made by you on a DarkBASIC Pro forum, in which you state you had experience in creating a number of game types, including fighting games. I was wondering how far along these projects were and if there was any information you could share regarding the pitfalls, considerations, techniques, etc. you used in their creation. I guess for now I’ll stick to fighting game control systems. One of the more challenging aspects I’ve found when creating a fighting game is creating an efficient and flexible control system for input combos where the moves are not just hard coded checks inside if statements. What have been your experiences with this sort of thing? What are some things to consider when designing input and animation state integration (FSM, Pattern-matching, etc.)? What are good ways of representing states and patterns for efficient traversal and comparison? I have been studying the Mugen and SFR-IBM fighting engines, using the info they provide as reference. I would like to eventually design a somewhat general purpose input/animation/state control system for use in my projects. Any information, advice, or enlightenment you could provide would be greatly appreciated. Thanks in advance."
and I replied thus:
"I am presuming you are asking in reference to producing fighting games in Dark Basic or Dark Basic Pro, rather than just generally. I have produced complete fighting engines in both packages, with remakes of some old 2d games, Street Fighter II, Mortal Kombat and Final Fight. I have also made a prototype 3d fighting game, along the lines of Virtua Fighter and Tekken, but as yet my modelling and skinning techniques are not up to the task of making a complete project myself.
Firstly to basics: If you are considering making a 2D Sprite based fighting game in DBPro, you're going to find one stumbling block very quickly, pro does not natively support pixel perfect collision of sprites, it simply draws a box around the outermost pixels of the sprite and detects collision with that, which is of course utterly useless for fighting game sprites, unless you draw the hands and feet of each sprite separately, which can cause massive animation problems without very complex routines and techniques.
One "solution" which some people stick to is a colour based collision detection system, using the "point" command. Alternatively you could make the whole screen tile based and work it that way. These have limits but are lightning fast in Pro.
Another solution is one offered originally by IanM on the forums which uses mem-blocks and the screen backbuffer to check for perfect collision between sprites, this is highly accurate but can considerably slow an engine.
If you are using Dark Basic classic or enhanced rather than pro, you will experience no problems with the 2d collision detection, but will have seriously crippled 3d performance and future compatibility and expandability.
If you are planning on building 3d *.x model based 3d fighting games, pro is the definite way to go. Unfortunately we can not get polygonal perfect collision between two objects, simply polygonal perfection against a sphere. This actually has advantages in fighting engines though, as you can attatch invisible spheres to each limb of the fighter and use these as the spheres to detect perfect collision with another fighter, thus returning exactly which limb you hit them with, and you can recoil appropriatly. This is very accurate, and surprisingly quick within Pro, you just need to be considerably skilled in the modelling, skinning and animation areas.
For amateur and semi professional modelling, skinning and animation I would recommend MilkShape ($20) and Lithunwrap (FREE) which for any game with low-poly (5000 or less, which is more than reasonable for a fighting game in most cases) will do the job just as well, and quicker than 3dsmax or Maya!
The control systems are relatively easy to set up in DarkBASIC, simply because on detecting collisions or changes of movement within animations, be they 2d or 3d you can detect the frame of animation playing and react accordingly.
Being a BASIC language, DarkBASIC and Pro will consist mainly of 'if-then' statements, and unfortunately cannot run conncurrent comparisons or use a true object orientated approach. However, if you contain all your if statements within one loop and only refresh once at the end of each loop (sync on, sync rate 0 before your loop, sync at the end of the loop) the speed at which dbpro runs and refreshes almost makes this irrelevant. If you imagine a scrolling image rather than sprite for background, and maybe 10 sprites for characters, projectiles and HUD, you could easily expect frame rates of 500fps per second on a 1.4Ghz GF2 machine in 320x240 res (still standard equivalent for most 2d games, and rightly so, games like Marvel vs Capcom 2 look stunning!)
An AI system for the computer should start off simple, Ie
1. If computer is more than so many pixels away from the player, randomly jump towards, walk towards or throw a projectile.
2. If computer is close to player and player is not attacking randomly perform a move.
3. If computer is close to player and player is attacking then block.
Then you can add in more and more lines as your program grows more complex, incorporating different responses towards different moves. I would also reccommend that the computer remembers the last 20 attacks the player has performed and can start to predict what the player will do.
An obvious and simple way of incorperating a combo style system is to be constantly writing to a stored file in ram or on hdd depending on speed requirements, and before doing one move, check what was done before. For "special" moves requiring multiple keypresses or sequencial keypresses a similar method can be used, maybe storing the last 10 keypresses. A simple approach, but one that works well, and is easy to read back, edit and debug.
For example, the first three times a player throws a projectile, the computer could block it. After three, the computer could perform a flying kick towards the player, as the jump would get it over a projectile, but also hit the player whilst they are in the vulnerable throwing animation frames.
The key in my opinion to a good fighting game is the smoothness of play and control, and the intelligence of the opponents. These can only be implemented with careful planning and skillfull programming. Obviously I can't give you a clamshel program or wizard to fill in, but I guess you wouldn't want that. My best advice is to start with two fighters with only walking, punching and blocking moves. Then you can add to the main program, with more a more complex moves, combo and animation processes, whilst still having it playable from the off, so that you may try out each new feature as you make it, and feel a much stronger sense of achievment."

Read all that if you can b bothered
Bunnies aren't just cute like everybody supposes, They got them hoppy legs & twitchy little noses,
And what's with all the carrots? What do they need such good eyesight for anyway?