Trying to build a 2D fighting game engine for my thesis


#1

Hello SRK,

I’d like to introduce myself but there’s not that much about me worth knowing other that i’m just an avarage peruvian college student and a somewhat recent (~4 years) fan of fighting games and the FGC in general. Though i’ll admit that i’ve been more of a lurker than actually participating (hence the first post on the brand new account). In terms of my programming background i’ve messed around in pretty much every cs subject at a shallow level and when it comes to game development i’ve coded a very shitty 2D platforming game engine using XNA and messed a bit with Unity.

Since i’d like to get into game development i’ve chosen to develop a 2D fighting game engine as my thesis project (technically speaking it’s more of an end of carreer project than an actual thesis).

Though the scope of the project is fairly limited (one man project, 3 months of documentation and revisions and 4 months of actually developing it) i’m far from an expert when it comes to engine programming and what are the needs for this genre in terms of engine architecture and where to find realiable sources (books, gdc talks, papers, wtc.) and i’m struggling a bit to find any sort of standars and documentation to follow given that a lot of things in fighting games were born from happy accidents that resulted in unintended mechanics.

Now, the knowledge and expertise of this community is massive and full of unfiltered passion that helped people accomplish amazing stuff that i can’t even begin to list. Which is why I’m coming to you for help.

I’m having trouble finding reliable sources for the follow keypoints:

-2D Game Engine Archquitecture (So far i’ve basing my most of my reasearch in this aspect on “Game Engine Architecture” by jason gregory)
-Speciffic fighting game engine documentation
-Mechanics and features (both needed and optional) for fighting games. Since i’ve failed to find any sort of documented standards. In this part i would just like to know what would be the “perfect” fighting game and try to
-NetCode stuff since this is the part in which i’m most inexperienced. I’m trying to find to find a compehensive way in which Quake 3 implemented their netcode and why is it still used in a bunch of modern games. Also trying to understand GGPO.

Now i’m aware that most things delving into speciffic genres of videogames aren’t that well documented or even documented at all. But since correct citation and finding relevant and reliable sources es key for this part of the thesis this is highly needed and is causing me a lot of struggle.

I would also like to get in contact with indie/smallish fighting game developers (labzero games, one true game studios, mane 6) to see if they can shed some light in this subject.

In terms of what i could offer the community in return, i’d be more than happy to share with the results of my research (drafts, final versions, etc most likely in spanish but i’ll see what i can do) and if it doesn’t get shutdown in these stages of the process (WHICH OH GOD I HOPE IT DOESNT) and actually procceeds to implementaion i’d be more than willing to open source it since i’m not really looking forward to monetizing it.

Thanks for your time, hopefully this is fighting game enough to warrant a post here. Also english is not my native language so i apologize in advance if something is not clear enough.

TL;DR: I’m trying to make a thesis out of developing a 2D fighting game engine. HELP!


#2

For netcode. You should read this.

http://mauve.mizuumi.net/2012/07/05/understanding-fighting-game-networking/
http://skullgirls.com/2011/09/skullgirls-ggpo-and-you/


#3

Thanks a lot! that’s the kind of things i was looking for.


#4

I’m not up to snuff on the current events of this forum, But I know Keits at least used to mod here. I imagine he might be a good person to ask to even just point you to some people.


#5

Does this belong in Tech Talk? It doesn’t particularly belong in fighting game discussion, as it’s not about an actual extant fighting game.


#6

As a preamble, do note you can find all the stuff I’m gonna talk about by googling “game networking” or “GGPO” then seriously looking at several pages of links, and looking at this site’s own wiki. I’m just gonna roll my eyes right now because I work with lots of students who don’t realize how easy it is to do research on the net. A lot of what I’m gonna talk about took the humongous amount of maybe one week to assemble 8though I guess it may help to be a seasoned programmer with some good google-fu). So, Google is one of your best friends in this matter. But I won’t be reproachful beyond this sentence. It’s actually great you’re interested in all that and a central reference will surely interest other people here. For clarification, I’m not a game developer but I am a software developer by trade nonetheless, with taking apart games as a hobby.

Apart from Google, your new best research friends are http://stackoverflow.com/ and its game-specialized little brother http://gamedev.stackexchange.com/
They’re terrific programming resources and there’s hardly a workday that doesn’t see me using stackoverflow or one of the various more specialized stackexchange sites.


Regarding networking

Seconding Mauve’s articles on fighting game networking, he’s pretty much the best authority about this with the GGPO guy. Incidentally, GGPO was detailed in the september issue of Game Developer Magazine and, lucky for you, it’s available for free there: http://www.gdcvault.com/gdmag. Also that one’s not really gonna be useful for you, Mauve’s explanations are way more awesome, but I wrote a simplified muggle-friendly explanation of the general principle there: Something I do not understand: netcode

Quake networking is gonna be less relevant to fighting games specifically because though they share the general principle of delay and rollback that made internet networking possible, FPS games and fighting games (and RTS games for that matter) answer to different constraints (FPS have many players with an incomplete view of the battlefield and a server, fighting games are duels where both players have the same perfect view of the battlefield) and so ended up with different implementations. That being said, an excellent read is a series of articles called What every programmer needs to know about game networking which will tell you about the gut of the network protocols routinely used for this. There’s an article on Ages of Empire’s networking somewhere on Gamasutra which is THE article about RTS networking. One thing is all of those will concentrate on gameplay networking but not on player matchmaking/lobbies, which are half of what a good networked game experience is about. You’ll need to search for tutorials about how to create chat programs for that, it’s pretty much the same idea. If you’re really motivated you can also look up UDP hole punching, which is the method by which players that are hidden behind routers will be able to establish connection by means of a matchmaker, but it’s best left as a bonus because it’s very technical.

Quake networking (well, specifically, quakeworld networking) survived to this day in basically all FPS because it was made in an age where the net was terrible and slow and bred an excellent solution. And the net is still terrible and slow.


Regarding implementation

Engine-wise, look up docs about Mugen, which is a fighting game making engine. Not specifically to use it, but understanding what it demands from the people making games with it will make you understand what makes a fighting game tick. **Sprites **for graphics, **hitboxes **for collisions, finite state machines for both gameplay and AI, all the necessary notions are there, and also things like common states like being hit or grabbed.

I can’t really help you for general 2D game engine programming but stackexchange can. Personally I’m using the language C# and an API called SharpDX which is a DirectX wrapper, ie basically XNA but not specifically game-oriented and hiding a whole lot less boilerplate stuff from you. There’s a toolkit namespace that specifically mimics XNA with classes like spritebatch and all that, and it’s been specifically mentioned by Microsoft MVP’s as XNA’s de facto successor (since unlike XNA it runs in Win8). There may be other approaches that are more appropriate but I don’t know which. I like SharpDX because I loooove C# and it lets me easily access everything DirectX11 can do. It’s unusual for actual commercial game production but for prototyping it’s hella good.

You aren’t gonna need very complex collisions for example though, because you’re just dealing with hitboxes and a fighting area that’s also a big 2D box. If you can detect whether two boxes overlap you’re already got pretty much all the math and then it’s all about determining how different hitboxes ought to interact. Note a “2.5D” game like Street Fighter 4 uses 3D graphics but all the gameplay stuff is strictly 2D too.

Some rambling about input in another thread while I’m at it: Programing fighting game inputs
Somewhere on stackexchange there’s an answer about a reasonably simple learning fighting game AI - find it, it’s pretty cool. But also know that most fighting game AIs are finite state machines and thus as adaptive as big rocks. It’s all in the programmer’s or scripter’s knowledge of the game and ability to create a plausible script.

Oh yeah, scripts. Games tend to use those for the less intensive stuff, ie driving the AI and gameplay. A popular language is Lua, used in many games but specific to fighting games I’ve personally seen it in Skullgirls and KoF13.


Regarding gameplay

Start with the shoryuken wiki! Also other FG sites like eventhubs, dustloop or the mizuumi wiki (that one’s got some nice hitbox analyses, for example for Vampire Savior). Look up the glossaries and systems to learn the gameplay concepts and vocabulary. Learn about attacking vs blocking vs throwing, learn about hitstun and and the other hit-things, learn about combos/links/chains.

Do realize there’s no perfect fighting game all games are striving towards. Instead there’s one fighting game most games branch from (even if not directly, it hugely influenced them). I’m of course talking about Street Fighter 2, which basically defined the genre as we know it. From there you can see different “families” like SF, Marvel, KoF, MK, anime fighters… each going in their own direction. Others can probably better define those branches. But I think on the Shoryuken wiki you ought to read all the stuff that’s not character-specific for Super Street Fighter 2 Turbo, Kof13, MvC3 and Skullgirls, they all detail their mechanics very well (and some in great technical detail) and you can get part of the contrast between the families.

Some other nicely quotable and interesting sources are http://sonichurricane.com/ and http://www.sirlin.net/ (that one’s got a book about the competitive player mindset, though you may find it’s diversely appreciated).

Skullgirls dev Mike Z is a treasure trove of interesting tidbits about fighting game design but there’s no central reference, it’s all a mix of things he posted here and there and interviews and stuff he says on stream so it’s hard to quote from him apart from the interviews, which are a whole lot more generic than some of the other stuff he says. There probably are other developers who talk about fighting game design but I sure don’t know who they are and they’re probably less prone to inflict their opinion on the world on stream. Oh except for example there’s an ArcSys interview on Gamasutra which maybe has interesting stuff? Read it for yourself: http://www.gamasutra.com/view/feature/132295/dodging_striking_winning_the_.php


Regarding developers, well, send them mails and/or go pester them on the right chat (the skullgirls guys are on skullheart, specifically). Sometimes they’re a lot more approachable than you’d think! A few years ago I was researching Rise of the Robots (yup, that one) for an article which I seriously ought to finish one of these days and thanks to the help of another internet dude it was surprisingly easy to get nicely crunchy information from the devs.


That’s all i can think of for now.


#7

Thanks! As I continue my work i’ll try to get a list of speciffic questions regarding my research in case i get the opportunity to meet them.

You know, i wasn’t sure myself about the correct sub-forum for this subject and thought about posting most of the tech talk seemed to revolver around peripherals, consoles and stuff like that and not actual programming (which it would make sense since srk is not a programming forum). My main motivation for coming here is that my work being so fighting game centric, here it would be the best place to do the right research.

Heh, busted. I’ll admit that i haven’t done too much research on the net because first i’m trying to cover the very speciffic guidelines i have to meet in terms of bibliography (At least two of the following: published thesis, peer reviewd papers, magazine or journal articles, books from known publishers) and since pretty much anything that’s not in those falls into the category of “grey literature” according to their guidelines which they limit it to be no more than 30% of the total of sources cited as a refference. When i tried to point out the fact that the most valuable research i could do was in the grey area i told that they’d see what they could do about it but I end up having too many links as my sources it could end up getting shutdown.

So i’ve been mostly checking general guidelines in terms of game engine architectures and videogame design and trying to find a papaer or two about the effects that videogames in people, if they’re useful as education tools and stuff (not only to contextualize the thesis but also because i have to give a reasonable justification other than me really liking fighting games) but mostly filler stuff.

But thanks to your post i’ve noticed the incredible ammount of valuable information i was neglecting. You have no idea how much you’ve helped me just now. Thanks!


#8

Not really. Not unless he starts asking for help with the code. It’s more about what things/features are necessary in a 2DFG engine than anything.

This is mostly stuff that most of us know by heart, such as the RPS dynamic between attack, blocks and throws.

-Block beats Attack beats Throw beats Block.

Then there’s the 2 block states (standing and crouching) and the 3 attack levels/heights.

-Standing/mid attack - can be blocked both standing and crouching

-Low attack - must be blocked crouching

-High/overhead - must be blocked standing

Also, some games have air blocking/guarding which introduces a new wrinkle in that air block usually only works against jumping attacks and can still be beaten by grounded ones.

Then there’s stun states depending on how you were hit.

Hitstun - Amount of time where the defending player is in the hit animation during which the attacking player may add more hits, resulting in combos. Generally cannot be canceled out of except by combo breaking moves (burst, combo breakers, etc.)

Blockstun - Amount of time where the defending player is in the blocking animation during which any attacks that hit deal reduced damage but add to the time the player is blocking. Generally cannot be cancelled out unless by certain moves designed to be used in blockstun (red parry, alpha counters, push block guard cancel).

Also, players in both hit and blockstun cannot be thrown. Some games however, include a special “stagger” state on hit where the defending player may be thrown out of.

There’s a plethora more of these small things and I expect people to post more about them.


#9

Maybe I can provide some insight. I’ll start by sharing some of my background for validation.

I have 7 years of experience working in the video game industry for a world-leading independent video game developer and publisher of online action-adventure games (i.e.: MMORPG’s). I have 10 AAA game credits under my belt thus far.

Engines

When it comes to game engines, you really only have three options. You can create your own (extremely time consuming and hard), license someone elses (ideal and recommended) or similar to the first option, but you find an open source project and do what you can with it either by contributing or adding minor modifications to fit your project (recommended over creating from scratch if you lack the skills).

Engines come in all different flavors. Some are developed in various programming languages where others offer benefits that fit your needs like 2D versus 3D or features that compliment a certain genre style like FPS versus RPG etc. They also port to various platforms like XBOX to PC to Mobile and ETC.

Developing Your Engine

Developing a game engine is a very extensive process if you want to do it right. For me, I worked in the studio that has been developing their own game engine for many years. Even today, it’s still in development in order to stay ahead of the game. It’s required a lot of brain power, man power and everything in between to work and support a massive range of requirements based on the platforms (i.e.: PC) and genre (i.e.: MMORPG). Engine development is no joke and the reason you cannot find as much documentation on the subject for specific genres is because of it’s extensiveness in development (IMHO). There is also few studios doing fighting games that are willing to share their secret sauce so to say.

That does not mean you cannot develop a basic engine that can render 2D or 3D graphics. But, you’re ideally going to have to recreate the wheel as they say. And that’s ideally why so many studios license third-party technologies like Unity, Torque, Bigworld and etc.

Game Mechanics

As with any game, great influence comes from playing other peoples games. I wouldn’t say go out there and copy Street Fighter’s wiki. I would say, experience life for itself and translate what you’ve learned upon your game. Most third-party engines such as Unity have powerful scripting engines that allow for mechanic development. Once you are able to utilize those technologies, you could hopefully translate what’s in your mind to paper to script. Thus, creating the core of your game as the end result.

Netcode

Multiplayer engines (or netcode) is also an extensive subject. Something that has riddled my co-workers in my career for multiplayer online games that support not just 2 players on a console, but hundreds to even thousands simultaneously in a persistent online world. Like your base game engine development, multiplayer technology is no joke. It’s a beast within itself. Almost an artform for most in my opinion.

Like the above, licensing third-party engines for netcode is ideal. There a few out there that come in various flavors depending on the requirements. For example, there is a different set of requirements for fighting games that support 2 players and the game mechanics versus a MMORPG that hundreds simultaneously.

Final Thoughts

I think you may be biting off more than you can chew for your paper. Creating a game engine and a game is an extensive process even at the basic levels if you have no programming experience, artist ability and so forth. Licensing a cheap third-party engine like Unity or Torque may be a better option as they come with ideally everything you need to get developing.

As for insight from other developers, I would not put too much work into bugging other studios. In my time in the industry, we received at least 3 requests a week from students requesting something from our studio for a project or paper. The game industry overall is still very new. Schools are now catching on to it’s appeal. There is a lot of people trying to break in and of course, there are a lot of students wanting to do research on top of school projects about the subject. Most studios (i.e.: developers) do not have the time nor the resources unfortunately to meet every request, especially when the topic is so extensive on things like, “How do I make a game engine for fighting games?”