Having gotten 90% the way through completing the network code for a PSP/PC title I have found that I have to do the network code for a top-down shoot-em-up for the X360 over live. I have to implement cooperative multiplayer (2 players only) over live where the playfield is a top down view with hundreds of baddies and lots of player bullets. And its a fast game. Anyone got absolutely any ideas whatsoever on how I should even begin to approach the idea of doing prediction under such conditions?

Use the standard methods. Either forward extrapolate bullets/vehicles, or display them time-lagged so you get "perfect" trajectories.

What is the particular problem you're having?

I have a potential of up to 300ms lag on a connection. We have lots of independent entities running around the screen reacting to the host and the client both of which will be dispatching said entities.

Now, if we take it for granted that the server has the overriding vote the client will always be in the past and any actions performed by the client given to the server will also always be in the past. At 300ms thats 18 frames behind. Might not seem a lot but in simulation terms thats a lot. Over time quantisation errors will mount up. If I sync up all the positions etc at regular interval that too will be noticeable. On an FPS or a racer you might not notice sync changes so much because your field of view is forward from your position and the other entities might be outside your view. In our game they are ALL going to be in view and I must admit that gives me the sweats...

You probably want to send data, rather than inputs, at this point. When a bullet is created, you can send time created plus direction plus velocity. This allows everybody to place the bullet in the right place when they receive the packet. Similarly, you can forward extrapolate the player entities, too.

The trick is to show explosions etc when it seems as if they should happen, but actually affect hitpoints only when the server decides that a hit really happened. For one-shot kill weapons, you have to wait for server acknowledgement before you show them, though.

I'm not sure if the X360 title is a new one or you have to port your PC/PSP title to x360 but here's my suggestion if it's a new title.

You could also go for a determinist solution (lock step). That way you have no server per se and everything is happening the same way on both station.

Brief steps
- Synchronize inputs (queue them locally, send to remote and execute at same time on both station).
- Synchronize clocks and random seed.
- Synchronize all events that could affect gameplay and that are dependent on the end user machine (like if you are waiting for a localized speech to stop before resuming the game, synchronize that since it could be of different length depending on the language used).

The only concern I have is your 300 ms ping time which is quite high. Lock step at this point could be noticeable since the simulation could lag.

You could always try dead reckoning algorithms on the client side. That may allow you to send fewer packets but keep entities mostly in sync.

I don't like the idea of lock-stepping.

This is a first party X360 game, not a port. However, saying that it is built on top of an engine that has never had networking support before so the AI, physics etc are already in place - dead reckoning on this kind of system is problematic.

Gotta love legacy code... :(

What I am thinking of doing is line of sight testing from the players weapon velocity and then compiling a list of potential kills and maybe even doing a certain amount of dead reckoning based on the last few frames of the weapon velocity and arc.

To give you an estimate of time involved: I wrote the low-level UDP and network-game related code for Whacked!, the first XBox Live game. The low-level reliable UDP code was stable in about a month, with continued tweaks+improvements throughout the project. Game related (and voice) code took about 10 months; the game passed all MS TCRs earlier than scheduled. When bandwidth for all the flying objects became an issue, said objects were removed from the network system and only hits where sent over the network.

Since XBL is relatively secure, you can compute collisions locally for each client, and tell the server they were hit. As long as spawning/firing is resonably network sync'd, all you have to send are hit messages (and on/off fire/spawn event messages). You can have thousands of objects, and very little bandwidth will be used. Additionally, the more objects, the harder it will be for the player to notice when remote clients get blown up when a projectile isn't close by. 300ms won't be a problem at all (I still test my physics-based PC game at 300ms; not a problem).

Now thats a confidence boost.

In the title I am currently working on I am using a methodology similar to the one you just described. I only send hit information.