As far as I can see, it's because two people are playing on the same connection (i.e. connected to the same router). By making one player use their mobile's data via a hotspot, we've managed to get way past wave 30-40 disconnecting, all the way to wave 59 (where we died).

Other alternatives that might work which I haven't tested:

1. One player connects through a proxy/VPN
2. Both players connect to a Hamachi server
3. One/both players use a wired connection to their router
4. I don't know if OMD 2 has a LAN mode, but if it does, consider using it. You could use Steam Remote Play, or disconnect your Internet to do it. There are also programs out there which allow you to create a LAN network that's actually normally used by pirated OMD 2 clients to connect to one another, though I can't remember the name.

"Alt-tabbing causes crashes"
Another rumour is that alt tabbing at any point causes the issues. A decent guess, but not true. And likely verified by every one of you reading this guide.

Unfortunately, alt tabbing doesn't really mean anything in the context of the game code. Some games will change from fullscreen to borderless windowed mode, some don't. Orcs Must Die 2 doesn't do that. Normally, that causes VSync/the FPS limit to be altered, and for less resources to be allocated to the game, at least in theory. I'm sure alt tabbing might make it worse if it did change window modes, but it doesn't.

"Robot bought a cheap Steam netcode package to save money"
A few people across the forum have said that it's because Robot Entertainment bought a cheap Steam netcode package back in 2011 when the game was originally developed. This is false.

The only part Steam is involved in is the matchmaking process, which allows you to invite a Steam friend to your lobby, and to allow them to join it. After that, the rest is handled by Robot's client netcode, which by when I say netcode, I mean all the code that handles the players being in a lobby, that synchronises enemy spawning, positioning and attacking all in the game.

So how does Robot keep players connected together? A technique called peer-to-peer (P2P) networking. One player is designated the host, and everybody else sends and receives anything important that happens in the game to the host.

A community manager for Robot Entertainment once said on Reddit (I believe) that the code for the game is way too old to be changed. This will be true. As a software developer myself, it's easy to infer it's probably for one of two reasons:

1. Robot's netcode uses a library (a bundle of code to help achieve something to happen, like show how a character looks on your screen) that does some basic P2P setup, and then built their whole game's networking on top of it. It's likely the developers who wrote the original Robot netcode are long gone from the company.
2. Robot's netcode is actually already implemented by the game engine they used, and understanding how to debug and fix an issue related to how an engine messes up with local P2P connections is an issue that goes beyond even a talented gameplay programmer's job (because it's the job of game engine programmers). Because the game engine it's built off (Vision) is likely ancient now compared to Unity or the Unreal Engine, it's not worth anyone's time or money to solve.

Either reason is going to be incredibly complex, making the risk too high for it to be discovered, investigated, debugged and patched because of how many potential hours it would take.

Based on observation, local coop issues didn't happen until a certain patch happened, or when the network card firmware on the majority of computers (probably Windows 10) were upgraded to allow this bug to happen. This is because I've seen no discussions really until this year, around 7 years after the game was incredibly popular, about disconnecting being rampant.

When the waves get incredibly intense, it seems that an overload of information being sent across the wire occurs. Because the latency on a local network is insanely small, within 1-10ms, this might result in a high queue of packets being received, needing to be decoded and read, and translated into actions that the game wants to do.

It's possible that this overflow of network updates causes a buffer overflow in one of the game's queues, which basically means there is so much stored for processing, and that the queue is so much smaller than that, it falls over and causes an exception to be thrown.

A popular way of handling concurrent tasks (needing to do a lot at the same time to keep FPS high) is to make threads. To utilise the cores on your processor, it will create a new thread to handle all the P2P work. With this queue falling over problem, the thread it's all happening in crashes, causing all P2P networking to just stop. This results in that network timeout message you know all too much about, and when the timer runs out, the lobby dies.

Under ordinary circumstances, a buffer overflow would cause the game to crash completely. Something we've all seen before. But by being in a new thread, this happens silently.