OriginalArticle, Reprinted, please keep the author's signature!
Recently, I had a headache in translation work. I think the Three Kingdoms interest group organized by the company has almost stagnated on the Three Kingdoms development issue. As a result, I tried again, but this time it was a little decent. I shared my ideas and methods and learned them together.
The Three Kingdoms are quite popular in Shanghai. If you do not know the gameplay and rules, click here.
Today we are going to talk about the first step of implementation. In order to simplify the demand as much as possible, we initially wanted to implement something quite simple, that is, to support automatic combat between two players. The specific description is as follows: set two players in one scenario. There are only three basic cards in the game board heap: Kill, Flash, and peach. Among them, only kill and Tao are active game cards, that is, they can be played in their own action round; flash is passive game cards, and only when others kill themselves can flash, otherwise, a little amount of physical strength is deducted, while a little more physical strength is added to the use of peach. Similarly, to simplify the implementation, only cards that can be used are required. Moreover, if your number of cards is greater than your physical strength, discard the cards until the number of cards is equal to your physical strength. In this case, the game ends when the force of one cube is 0!
To sort out the requirements, it is not difficult to find the following requirements to be implemented:
1. Conditions for the end of the game: The game ends when a player dies.
2. Implement the card heap. Note that the cards in the card heap need to be removed from the card heap and shuffled.
3. Logic Implementation of killing, flashing, and picking.
4. Calculate from the hand card whether there are available cards.
5. Implement gamer polling.
In the design process, I thought like this: a game is actually played in one scenario until the game ends. Therefore, the scenario is defined first:
/// <Summary>
/// Indicates a game scenario.
/// </Summary>
Public Class Scene
{
Private Readonly Player [] players;
}
The scenario defines the game players, because the players in the scenario are fixed after the scene is generated, so readonly is used.
Similarly, the game is actually a loop, and the condition for the end is that players die. Therefore, first define the conditions for the player to die:
Private Bool Isgameends ()
{
Return Players. Where (P => P. isdead). Count () > 0 ; // If you select isdead player, the game ends.
}
In this way, because the player class is referenced in it, a player class is created to design it as needed.CodeAs follows:
Player
/// <Summary>
/// Indicates players in the game.
/// </Summary>
Public Class Player
{
Private Readonly List < Gamecard > Handcards = New List < Gamecard > ( 20 );
Public Player ( String Name, Byte Maxhp)
{
This . Name = Name;
This . HP = Maxhp;
This . Maxhp = Maxhp;
}
/// <Summary>
/// The name of the player.
/// </Summary>
Public String Name { Get ; Private Set ;}
/// <Summary>
/// Indicates whether the player has died.
/// </Summary>
Public Bool Isdead
{
Get { Return HP = 0 ;}
}
/// <Summary>
/// Indicates the current HP of the selected military commanders.
/// </Summary>
Public Byte HP { Get ; Private Set ;}
/// <Summary>
/// Indicates the maximum HP of the selected military commanders.
/// </Summary>
Public Byte Maxhp { Get ; Private Set ;}
}
Handcards indicates the number of cards that a player can hold. The maximum number of cards is 20. The code for defining a game card is as follows:
Gamecard
/// <Summary>
/// Indicates the card used as a game in the game.
/// </Summary>
Public Abstract Class Gamecard
{
/// <Summary>
/// The color of the card.
/// </Summary>
Public Cardmark { Get ; Protected Set ;}
/// <Summary>
/// The card size.
/// </Summary>
Public Cardvalue value { Get ; Protected Set ;}
/// <Summary>
/// The name of the card.
/// </Summary>
Public String Name { Get ; Protected Set ;}
/// <Summary>
/// Use cards for target players.
/// </Summary>
/// <Param name = "Source"> Use the card source object. </Param>
/// <Param name = "target"> Use the target object of the card. </Param>
Public Abstract Void Use (player source, player target );
}
Until now, the required definition has been basically completed. There are many irregularities in the Code. The reason why the code is displayed is to express your own thinking process. There will be a lot of refactoring of the current Code later.
After the definition is complete, the next step is to carefully analyze the process and write the version that can be run first. (To be continued ...)