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.