Tyrian, basically. Which is freeware, shoot-em-up, open-graphics, and had modem-based multiplayer (and therefore DOSBox-based Internet TCP/IP multiplayer).
I'm not sure what the leaderboards, etc. would add to such a game, and just about any game can have such "features" added. Personally, I don't class them as features - they are just a tiny little script / ten lines of code that uploads a score to a leaderboard and a server that receives them and stores them. Usually the problem with such systems is that they are easily subverted (because it's impossible to stop people reading the code and then just sending a packet that tells the server that their score was 9,999,999,999), generate an online vulnerability mess and require a hefty, always-on server somewhere to handle the connection.
Custom planes? Just a matter of different graphics files and/or XML datafiles for them. Don't even need to code a single line of program if you program it properly anyway, just replace the images / edit the datafiles.
Online multiplayer is, indeed, a feature. But again, you're looking at always-on matchmaking services or purely a P2P connection and all sorts of networking vulnerabilities, not to mention weeks of tweaking for things like latency-compensation and other problems. To do what? Have two or three people on the screen shooting at the same time. Much more and the screen would be too crowded, I think. Even Tyrian got too busy, and that was on a relatively high-res screen for the time.
Don't get me wrong, the models are good. If you can get anything working, then even a decent modern clone shoot-em-up would be worth it. But I think it's another case of it being easier to think up ideas and slap modes that you want onto existing games than to start a game from scratch with the idea of doing everything all at once.
Basically, I'd leave networking, sound, leaderboards and menus until you have even the basics of a game going. Menus are usually nothing more than an afternoon's work with a graphic artist at most. Sound is just a matter of finding sound triggers (explosions etc.) and passing off a sound chunk to an audio library. Rarely is there much code or many problems with those. Networking is a bigger job and will cause no-end of problems but requires a lot of testing and gameplay - that's hard without a game to play. It's not something you can knock up in an afternoon. And all of those things tend to naturally fold into the game at a later stage anyway, once it's playable and fun to play. Even such simple games can be fabulous fun (Take Altitude as an example - I've wasted hundreds of hours on that on my full Steam version) but also a huge project to code from scratch.
Personally, gameplay-mechanics and graphics are the 99% limiting factor in most game-programming projects. Programming a simple shooter game mechanic is relatively easy, even coding a display engine is relatively easy (not quick, but easy), but without half-way decent graphics to plug in it or a well-thought out mechanic, it rarely gets to the "fun game" stage. The other "features" (networking, etc.) are relatively easy to bolt on afterwards once the game has more than one person who wants to play it.
I'd continue with your graphics. Make mock-ups. Get full-screens of the action including backgrounds, borders, spritesheets etc. at least enough for a demo level.
Get coding - the game mechanic comes from the coding and you either end up with boring and common, or tricky to program correctly with a thousand caveats to take care of. If you can get a fun movement of some mock-up sprites going, you have an infinitely better chance of people jumping on the project. But as it is, everyone wants to write their own game, usually to counter the weaknesses or add features to their old favourites, and just saying "slap on multiplayer" is an AWFUL lot easier said than done. When you have a base game that can be networked, though, then someone who knows about socket programming can come along and start network-ifying it. It'll probably be the LAST "big" feature that you code for the game. At the moment, there's nothing *to* network.
Get to the stage where you have visual mock-ups of the game, and you'll generate a lot more interest. Get to the stage where you're able to move basic sprites about on the screen, realistically and smoothly enough for a 1940-style game, and you'll have a lot more interest. That's the point at which I would personally go "Ooooh, that looks nice, I think I can knock up a function or two to do whatever". Programming teams operate on compartmentalisation - breaking things into bits and then tweaking those bits one at a time to make what you want, like tweaking the sprite routines to do alpha-blending, or tweaking the collision detection to be more accurate, or tweaking the big boss destruction mechanism to make him harder. Without something to compartmentalise, you'll find it hard to attract programmers. It doesn't matter what language. It doesn't matter what file formats. It doesn't matter at the moment because you don't have anything to build from, and outside programmers will want to come into a project, learn it's code and extend it, not start from an empty repository.
My post might sound harsh, but it's supposed to provide encouragement - get something, anything, working and you'll have a lot more interest from people. I have several pet projects in the pipeline at the moment, including the one huge project that I've always wanted to do since I was a kid. I've only ever worked alone on them but I know from previous history, and my own attitude to un-started projects (Un-finished is fine! That's what I want to hack on!), that without at least *something* to build on first, it's hard to recruit people. If you got something working, though, and posted your code and the problems you have with it, I'd probably be looking through your code even if only out of curiosity.
I've spent the last three months coding an isometric game that I've been planning for DECADES. I do it in my lunch-hour and spare time I get at home, so I often choose small tasks and small chunks to do each time. The menus took minutes, when I was frustrated with my path-finding algorithms and wanted something simple and fun to knock up. The sound took literally about 50 lines of C and a library (and can play hundreds of simultaneous OGG/MP3 sound bites with minimal latency direct from disk files, caching them as appropriate). The isometric engine took a day or two.
The rest has been getting graphics (even placeholder graphics) created and working, sorting out engine bugs and time spent on silly things (like creating a windowing system, dragging items from a side-menu and have them alpha-blended over the existing game-space so you can "see" where you'll be putting them into the game, etc.). Three months down the line, I still only have a very crappy protoype isometric game with no actual gameplay mechanics implemented (but lots of scraps of paper!). It looks really cool, to me, because I can imagine what it will be like when it's finished, but to anyone else, it's a couple of days work with SDL and some iso-tiles. I lobbed in an A* library at first, for convenience and to get things working quickly, and then went back and re-wrote the whole path-finding code when I needed something a bit more special. I lobbed in graphics chopped from a ZX Spectrum game at first, then replaced them with some sprites stripped out of Nethack tile-sheets, then replaced them with isometric sprites from an example image that I asked the author's permission for. The sounds I nicked from FreeSound and cover the actions I need them to well enough (I've actually turned off the whole sound system because it works perfectly but gets on my nerves... every 100 revisions or so, I turn it back on to check I haven't broken anything). They weren't "the game", which is the hardest bit to get working how I want. Until "the game" exists, it's just some sprites on a video surface that people could emulate in a matter of hours.
When I start getting it to be a *playable* game, even if that's with every character looking the same, limited interaction, only 1% of the actual *gameplay* finished, etc. then people might want to start helping me.
Keep at it. Knock up a prototype. Give us a glimpse of what it *could* be. Give us something to build from, some code to edit, and we'll be away. But the first steps are the hardest of all.
