The threading architecture of the game is driven by two things:
1. LibGDX has threading requirements because you never want UI stuff to have the possibility of becoming unresponsive if a computation takes a long time. If you are doing UI development for the game, you should read about that at [LibGDX Threading](https://libgdx.com/wiki/app/threading). If you aren't doing UI development, it's enough to know that the code in the model has to run on a different thread that the threads the UI is using.
2. The communication between the clients and the servers runs on sockets. Each socket gets its own thread that is responsible for handling all incoming and outgoing messages. Again, you don't want that to get hung up if a message requires significant processing to handle, so we want the actions that the model does in response to a message to run on a different thread than the socket thread.
For both of these reasons, the model has its own thread where all of its operations should happen. This means that we need some way for the UI and the communications layers to be able to queue a request to model. For this, we use a combination of the Command Pattern and the Facade Pattern.
