The threading architecture of the game is driven by two things:
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.
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.
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.
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 the Model. For this, we use a combination of the Command Pattern and the Facade Pattern.
\ No newline at end of file
Every action that the model can do is coded as a subclass of the Command Class. The execute() method should contain the logic for what that command should do. Note that the execute() method is marked protected, so it will only be able to be called by code in the Model. The UI, the communications layer, and anything else outside of the model can create Command objects and give them to the Model, but cannot for the command to execute.
The game uses a queue to get information from one thread to the Model thread. Essentially, the Model has a thread that is just sitting in a loop waiting for commands to show up in its queue. As each arrives, the Model takes it off the queue and processes it. The Model has a Facade that to put commands into that queue:
That instruction runs on the thread the UI or communications layer is using and puts cmd into the queue. The Model's thread then takes the command out of the queue (in order) and processes it.
