Developing a MMOFPS
I have ideas for an open source Massively Multiplayer Online First Person Shooter(MMOFPS). I'm wanting everyones opinion on how possible this could be or if I should even bother trying. My project could use the Nebula Device 2 game engine which would cut down on the development of the game engine. Then all the focus of the development team can go towards the actual game since there will already be an engine to work with. This way if I can find a dedicated team of coders/artists/modelers etc a playable version could probably be released in a year or less!
Since this would be free to play and free to download there would of course be the issue of paying for all the bandwidth that will be sucked up by the game. Well the solution I've come up with is to use peer to peer networking instead of client-master networking. This way I wouldn't have to pay for the master server and its bandwidth. The entire game network would depend upon the clients. Then compression could be used to lower bandwidth requirements to help prevent lag on the network and on lower bandwidth clients.
I just have an idea and i'm wanting a professional opinion from all of you that are into this type of stuff. I'm not looking to make the next everquest or world of warcraft and it's not gonna have anywhere near top of the line graphics. I'm wanting to create a first person shooter teamplay oriented game on one virtual battlefield. It will be simple at first and maybe it will slowly evolve and improve.
[1540 byte] By [
Nivek] at [2007-11-20 0:34:52]
# 2 Re: Developing a MMOFPS
Since this would be free to play and free to download there would of course be the issue of paying for all the bandwidth that will be sucked up by the game. Well the solution I've come up with is to use peer to peer networking instead of client-master networking. This way I wouldn't have to pay for the master server and its bandwidth. The entire game network would depend upon the clients. Then compression could be used to lower bandwidth requirements to help prevent lag on the network and on lower bandwidth clients.My opinion ? Don't bother. The client-server mode _alone_ is very hard to do good for low-latency requirement games. There are number of things you must compensate for - high latency between players, usually low upstream, lots of players behind NAT/FW (not connectable), lost packets, synchronization and many many more. In best you'll end up with one dedicated node that will have to do most of the work and in that case you're where you've been, in traditional client-server mode. (Also you're talking about compression - that most likely _increase_ the lag).
If you don't believe me, the only guys that actually tried to do P2P for FPS was ID software with doom3 engine, and they failed miserably. They have to switch back to client-server in mid-development - they couldn't make it stable even for 4 to 8 players (and you're planning massive ?). And that's ID software we're talking about, not some lousy coders.
# 3 Re: Developing a MMOFPS
Theoritically, this sounds very good, and initially you may get reasonable results as well, but I agree with JohnyDog and his points are valid. With only 2 players in mind, you have to keep track of the game at the both side, now there can be numerious reasons for the game going out of sync, for example, network latency. One player of game would be having a different view, while other will be in a total different world. For all the reasons that JD mentioned and more, you end up thinking that is it really worth doing that? At a later stage, when you find that you have made a mistake by following that design and you can't revert back, then you have to make more mistakes in hope to fix this, but remember, you wrongs doesn't make a right.
Ejaz at 2007-11-9 12:20:21 >
# 4 Re: Developing a MMOFPS
My opinion ? Don't bother. The client-server mode _alone_ is very hard to do good for low-latency requirement games. There are number of things you must compensate for - high latency between players, usually low upstream, lots of players behind NAT/FW (not connectable), lost packets, synchronization and many many more. In best you'll end up with one dedicated node that will have to do most of the work and in that case you're where you've been, in traditional client-server mode. (Also you're talking about compression - that most likely _increase_ the lag).
If you don't believe me, the only guys that actually tried to do P2P for FPS was ID software with doom3 engine, and they failed miserably. They have to switch back to client-server in mid-development - they couldn't make it stable even for 4 to 8 players (and you're planning massive ?). And that's ID software we're talking about, not some lousy coders.
That's a good poin there about lower bandwidth use with low upstream. Well i'm not sure how well this would go but maybe to prevent this from happening I could require a Download/Upload test before people can register their account and download the game. If their upstream/downstream doesn't meet the minimum amount they can't register or download the game. Hopefully this would keep lag resonable with higher upstream/downstream players?
Nivek at 2007-11-9 12:21:26 >
# 5 Re: Developing a MMOFPS
If we're talking about merely distributing a game/patches/content, that is no problem. You can districute it via P2P (bittorent) but much better is simply use fileplanet or rapidshare or another thousand sites that will happily host your files for advertisement revenue.
