OOTetris Design
| Line 31: | Line 31: | ||
[[Image:CScommunication.jpeg]] | [[Image:CScommunication.jpeg]] | ||
| − | So basically what does the diagram tell us. There is a server-sided Thread called Server_connectClient. This thread waits till all Clients are connected to it. In the server GUI the user defines how many players the game is going to have. As soon as all clients are connected the game starts. That means on the server side for every client there are two threads constructed, S_toClient and S_fromClient. S_toClient is responsible for sending stone- and command-objects to the client. On the client's side a thread Client_fromServer is constructed which handles the client communication. It receives the stone- and command-objects from the server and handles those in whatever way. Besides handling the receiving objects this thread can also send commands to the server (more detail about the different commands later on). So on the server side the thread S_fromClient treats the receiving commands. So in general the server has 2 threads for every single client to communicate with | + | So basically what does the diagram tell us. There is a server-sided Thread called Server_connectClient. This thread waits till all Clients are connected to it. In the server GUI the user defines how many players the game is going to have. As soon as all clients are connected the game starts. That means on the server side for every client there are two threads constructed, S_toClient and S_fromClient. S_toClient is responsible for sending stone- and command-objects to the client. On the client's side a thread Client_fromServer is constructed which handles the client communication. It receives the stone- and command-objects from the server and handles those in whatever way. Besides handling the receiving objects this thread can also send commands to the server (more detail about the different commands later on). So on the server side the thread S_fromClient treats the receiving commands. So in general the server has 2 threads for every single client to communicate with it. Every client has just one thread which handles the communication. |
| + | |||
| + | ==Commands== | ||
| + | |||
| + | ==Common Classes== | ||
| + | |||
| + | ==Synchronization== | ||
Revision as of 00:40, 26 September 2008
Contents |
Introduction
During my Bachelor studies in Germany I had to implement a network based Tetris. It is possible to run the game with many players on different computers in a network. The game works quite well but the design in general is quite messy. The Design we came up with was more or less guided by our progress on programming different parts of the game. So we started out with the Server-Client Communication. After the basic communication was achieved we started implementing the tetris game itself with its graphical user interface and its game structure (game control).
The last couple of days I was trying to figure out, what would be the best way to start redesigning and refactoring the current design. So I figured it might be smart to go over every part of the design in detail and explain how it works. I think that is a good starting point to find out what has to be done differently. I think just by describing different parts I will notice things I need to change. I think describing in deail how it works helps also other guys to give me feedback.
The old Design
Class-Diagram (package overview)
The old design consists out of 5 different packages as you can see in the UML-Diagram above:
- The green package in the UML-Diagram is responsible for the Server-Client communication.
- The pink package controls the game. Thats where the game intelligence is implemented.
- The blue package is obviously the graphical user interface.
- The red package contains the different stones of the tetris game.
- The yellow package is a customized list which is used to the store the stones of every client.
State-of-the-art Class-Diagram
To be able to understand the whole Design, I think it makes sense to have a look at the more detailed version of the Class-Diagram:
This diagram shows the whole structure of all classes and their relationships a bit more in detail.
Network Structure
As I said before this is a multi player tetris which can be played over the network. To be able to do that a client-server structure is necessary. As you can see in the diagram there is a GUI for the Client as well as for the Server. The Server GUI (S_GUI) gets started. Here the player chooses either to setup his/her computer as server or just as client. In case it is setup as server, the server structure as well as the client structure are built. In case it is just a client, only the client (C_GUI) is started. To understand the server-client communication I attached a diagram, which describes the essentials of the network communication.
So basically what does the diagram tell us. There is a server-sided Thread called Server_connectClient. This thread waits till all Clients are connected to it. In the server GUI the user defines how many players the game is going to have. As soon as all clients are connected the game starts. That means on the server side for every client there are two threads constructed, S_toClient and S_fromClient. S_toClient is responsible for sending stone- and command-objects to the client. On the client's side a thread Client_fromServer is constructed which handles the client communication. It receives the stone- and command-objects from the server and handles those in whatever way. Besides handling the receiving objects this thread can also send commands to the server (more detail about the different commands later on). So on the server side the thread S_fromClient treats the receiving commands. So in general the server has 2 threads for every single client to communicate with it. Every client has just one thread which handles the communication.
