I was thinking about making a game that uses peer to peer networking. There would be no PvP or trading to minimize the effects of cheating for players that don't want to cheat. I would have a built in system to cheat if a player wanted to. Each player would be responsible for all data relating to them. Stats, hp, items, etc.

NPC spawning and such would be deterministic and should behave the same on all systems, unless a user fiddled with the NPC system, which I no doubt some people would. Not sure what I'd do in that case. Maybe just check to see if the player is in range of certain npcs to apply damage and things to npcs on other users systems.

Making a central server to handle NPCs kinda defeats the purpose of a peer to peer system.

What do you think? Could it work?

Are you intending for an online RPG play style? Kind of like Phantasy Star Online? Or do you want a single, shared, persistent world instance?

There's been a lot of research in this area. The VAST library/project is one that might be interesting if you're going to try for a large, shared world.

For smaller game instances, you could just have a player "host" and other players "join," and support host migration if the first player stops; that would let NPC spawning be controlled by the host to allow for better gameplay -- being 100% deterministic in spawning (without involving player decisions) is actually really hard; what if some players are fighting a mob when it's supposed to also re-spawn?

The other question in P2P is how the players will find each other on the network. I start the game, and want to play with some friends -- how do I get in contact with them?

I was thinking that it might not be that bad if npc simulation is not 100% the same on every system. Some players might get some extra loot or something for killing a mob that's not there on everyone's system.

I have an idea where player systems could spawn mobs but on remote systems a single player could only have a few mobs by them spawned at a time. I was also thinking players could ignore mob spawns from remote systems if they wanted to, or maybe set friend ip's that they want to accept spawns from.

I'm thinking the player count could get pretty big. I might have a website where players could post thier ip's to get connected to other players, but once they have those ip's, everytime the game is run it would check to see if it can connect to them. Players that are connected to each other would share ip's.

Some players might get some extra loot or something for killing a mob that's not there on everyone's system.

So what happens when a player tells another player "can you help me with Fippy Darkpaw" and the other player doesn't see that monster?

What kind of gameplay do you need? Why do you need multiple players to talk to each other?

If your website is always online, you could automate the registration of currently-online player instances. Have the game post a message to the website when it starts, and another call to the website to get the list of IPs. Note that you'd have to either set up NAT traversal/introduction, or every player would have to set up port forwarding for this to work, though.

Well it would be for multiplayer PvE. I guess I might have to have a player or server responsible for spawning monsters, and despawning them/getting killed. I just don't want to have to send position updates for all monsters to a lot of players from one machine, so I'd have to come up with a deterministic movement simulation.

I just don't want to have to send position updates for all monsters to a lot of players from one machine, so I'd have to come up with a deterministic movement simulation.

What problem are you actually trying to solve?

I e, can you provide X here? "Right now, PvE multiplayer games suffer because X."
And can you provide Y here? "My solution solves X by doing Y."

The problem is not being able to support large amounts of monsters/players in an area at a time while keeping server bandwidth low. Peer to Peer is a solution for that.

The problem is not being able to support large amounts of monsters/players in an area at a time while keeping server bandwidth low.

Is that a problem anyone actually has?
Why does server bandwidth matter?
Is this a problem *you* have?

Peer to Peer is a solution for that.

That's yet to be shown, and there's some evidence to the contrary. Specifically, peer-to-peer grows as N-squared per client, whereas client/server grows as N per client, and N-squared only on the server.

What is your solution for handling large amounts of active entities in an area for client/server? Suppose there are 100+ players and 100+ mobs in an area in an action game, what would you do to keep server bandwidth low as possible? And what would be your projected server bandwidth, for only movement?

Peer to Peer may grow more in total data transfer per new user but it only grows by N for data that has to be handled for a single user. One more user to send/recieve from.

what would you do to keep server bandwidth low as possible? And what would be your projected server bandwidth, for only movement?

First, why are you so worried about low server bandwidth cost? Once your game is of any reasonable size, you'll be paying $2 per megabit per second per month inside some co-location facility if you want cheap bandwidth, or $8 per megabit per second if you want fancier bandwidth. That's something like $0.0008 per gigabyte of data.

Second, the actual numbers: If this is a RPG, you'd do interest management, where perhaps 10 players and 10 mobs would be of high interest, and sent perhaps 2 times per second, and 90 mobs and 90 players would be of low interest, and sent perhaps once per 5 seconds. (This is based on WoW-style RPG play mechanics.) Let's say that id + position + velocity + target + facing is about 12 bytes per entity. So, this is 10*12*2+90*12*1/5 == 792 bytes per second per player. 79 kB/s for 100 players. Not something I'd worry about on the server side.

Let's consider a MMOFPS, where you'd need your high-interest entities at 20 pps and your low-interest at 5 pps; you'd get 10*12*20+90*12*5 or about 7.8 kB/s. 100 players make that 780 kB/s -- you're at about ten megabits per second at that point.

Now, count packet overhead. In P2P, each player sends data to each other player, so each player sends at least 198 packets per second in the P2P case, and receives 198 packets, for RPG, and sends/receives 1998 packets per second in the FPS case. This is a rather high packet rate, that many residential firewalls/routers won't even be able to sustain. Then each packet has overhead -- let's count 32 bytes for framing and IP/UDP headers; that's 64 kB extra in packet overhead per player in P2P. That's almost as much as the entire payload data stream for the server to send data to all players!

Even a super-expensive bandwidth provider like Amazon EC2 charges less than $0.10 per GB per month (which translates to about four hours of payload for the hypothetical worst-case FPS gameplay session above.)

Peer-to-peer: Okay for distributed bulk file sharing; usually not the right answer for game networking.