Top-down multiplayer shooter question

Well considering in MMOs you could have hundreds of people gathered in the same area with the server having to send each client the packets for every one else. I am sure just 2 players and 50 NPCs is no problem at all. All depends on how advanced you would want the AI to be.

MMO's are not depending on extremely fast and precise positioning and targethittin as such a game ou are describing, but obviously if you are looking at a game like Left4Dead 1&2 you are closer to your numbers at least.

It also has nothing at all to do with AI as you probably in the end just want to send position, direction, speed and maybe some triggered action.

With great prediction-coding I would say it can be done.

Seminal article on topic.

I dont think the input-synchronous method applies to shooters.

Also, you have to consider bullets and missiles. That can multiply your entities to something ungodly.

You can do the maths. 2D = possible integer arithmetics (to a pixel or 1/2 pixel precision), say 16 bits per x, y component, orientation as a 16 bit angle. That's 6 bytes for describing a simple position/orientation matrix (probably could squeeze it further without too much loss of precision).

To get the best possible game, 30 fps send rate. say you have 48kBps upload (384kbps). That leaves you with about 1.4K per packet per frame to play with. That's a lot, it's roughly one MTU.

Without compression (huffman), and a entity size of approximately 10 bytes, that leaves you with about 120-140 entities to play with.

If you factor in compression techniques (delta compression, bitpacking, huffman compression on packets), I'd say around 200+ entities per network update.

That's if I have my maths right. [grin] If you go four players, that reduces your entities by half. But you can decrease the send rate and increase the amount of entities you can transmit over one frame. It's all trade-offs.

On LAN, it would be trivial. You could brute-force it easily. 30 fps network tick is very good for a nice snappy response. Also if you go peer-to-peer, some of the bandwidth load can be left to the client.

Also, consider things you can 'fake' so it looks reasonably accurate but don't use bandwidth at all (think Quake3 plasma rifle).

Small gotchya to Olii's post [which is an awesome post - and this is a small gotchya that most people don't need to worry about, but it's good to know].

So sending at 30fps, you would actually lose (if I remember) 20B per packet on your header with UDP (IPv4 (12) + UDP header (8)), plus whatever your specific packet format looks like. So with header size (H), you're losing H*30 (>= .6k) on header alone.

So at most, you really only have .8k...

Also, and this is just me being at work too long... if you go up to four, divide by 3, not 2... (you're sending to 1 person in a 2 player game, you're sending to 3 in a 4...)

Peace!

Quote:

I dont think the input-synchronous method applies to shooters.

Sure it can. You just have to accept the round-trip latency for one of the two players in co-op. The C4 Engine (a game engine with a focus on high-performance high-end FPS rendering) currently only does input-synchronous networking, for example. Also, I seem to recall that Quake II did this, too, and it seems to have been a fun game at the time :-D

It actually seems the input-synchronous method *is* the best fit for arcade-ish games, if you can design your game around a certain pre-defined amount of input lag. That's how most online fighters like SFIV work, since there's zero room in there for client-side prediction due to fairness.