Part of this is a Technical solution, the other part is a Design solution.
Peer to peer for this sort of thing has some fun drawbacks, especially as you're left with an interesting question of which client is authoritative, especially with lots of players. You can round robin between clients (this is actually useful for anti-cheating), but as everyone's talking to everyone else with different pings, things can get pretty weird.
It's a lot easier to use a server, have the server be authoritative, and have the clients just respond to, and send information to the server. The downside is that you're introducing extra latency on every action, on top of your normal lag.
It really depends on what kind of game you're making.
You're forced into using a asynchronous networking paradigm given the lag, synchronous paradigms (like lockstep) fair badly in high lag situations. This kind of networking is typically used in FPS/Driving and low latency input type situations, and you can easily find a lot of supporting information by looking at how those kind of games deal with their latency hiding. Even if your game isn't one of the above, you're going to want to steal how they do their latency hiding.
One of the more common techniques is to have two game worlds per client. One is the client world, which the user of the game sees. The other is the real world, which is as accurate as you can be given the networking data that you have. The trick is to make the client world always lerp towards the real world. Decision making usually happens on real data, although you can use client data if you want, but that can get weird fast.
This obviously means that not all clients will have the same data at the same time. At various intervals you're going to want to do a "sync up" between clients (i.e.: send as much of the full game state as you can). Sort of similar to how you get keyframes within video compression playback. You generate the intermediate frames using temporal deltas, but each keyframe is authoritative.
Designing for high latency is just as important as the technical side. Some things are just not possible. It also depends on how bad we're talking about. If you're at around 300ms, you can still get away with some FPS paradigms. If you're over 1 second, forget it, you won't be able to do any sort of on-the-fly targeting, or hit detection.
Games like WoW hide their latency quite well by using a few neat tricks
- Players don't collide with other players. This means it doesn't really matter how accurate your player data is, as it makes no difference to the simulation
- Minimal number of dynamic objects that impact determinism
By limiting the amount of items that are in the world that can possibly impact position/movement, you have far less data to send, and far less objects to lerp/simulate
- No hitscan targeting, because it will be hideously inaccurate and feel unfair.
The key is to make the game feel responsive, without actually being responsive. Having the client act immediately, while waiting on the result from the server/other clients and designing for that kind of interaction is why you don't notice the high latency in games like WoW.
