Monster Card Game design and implementation of the framework chapter

In fact, Monster Card game is not fully implemented, or does not fully implement the functionality required by requirements analysis requirements. Even those parts of the implementation, after reading a column about Java SE written by an undergraduate, feel that their program is weak and can be called a flawed one. The revolution has not been successful, the procedure still needs to be perfected ah-^. But who can say that this is not a process of progress? Look at those toddler children who can think of the destructive power of the future. So, good start is always worth stealing, hahaha ...

Because the demand is not very clear, coupled with the time is more urgent, so has not been well designed to start writing programs, so, the inevitable change again and again, to overturn ...

Because the servlet did not learn how to learn is also in the sophomore thing, so, forget almost the same, resulting in the design of the class duplication, I drip mom, that Tuo code is not I wrote ...

In short, communication, multi-threading, class inheritance, shared data, polymorphic ... It's still a lot to learn. The specific idea is the server side and the Client for command interaction, and the entire game logic is implemented by the server side, so as to avoid the trouble to wear objects back and forth, so that also have to serialize and deserialize the object is much more troublesome, do not know the local area network game is the use of this logic.

There are probably a few classes on the server side:

Monstercard class: Defining the properties of a card

Deck class: Used to produce a pile of cards, in this game a total of 40 monster cards.

Player class: Used to define a player, this player has 40 monster cards and 8000 drops of blood, and then according to the player's battle situation to reduce the card or deduct the operation of the study.

Myserverreader class: Set up a thread to operate on a monster card from a player or opponent based on a command sent by the opponent's player

Myserverwriter class: Set up a thread to operate on the monster cards of yourself or the opposing player according to the commands you have issued.

Servertest class: Responsible for communicating with the client and sharing the player's data.

The client has only one class:

Clienttest class: Responsible for communicating with the server, establishing two threads, sending and receiving commands issued by the client and receiving commands from the server side respectively.

Monster Card Game design and implementation of the framework chapter