Human versus human game use case diagram. Computer games and virtual reality. Modern Internet addiction. ? Design mode is available, where you can test the interaction of various properties

Use case diagrams.

Runtime

Theory Introduction

In order to more accurately understand how a system should work, describing the functionality of the system through use cases (Use Cases or precedents) is increasingly being used. This is the very first stage in system development - it precedes the analysis stage.

Use cases are a description of a sequence of actions that a system can perform in response to external influences from users or other software systems.

Use cases reflect the functionality of the system in terms of obtaining meaningful result for the user, so they more accurately allow functions to be ranked according to the significance of the result obtained. Each use case is a set of scenarios through which the functional requirements for the system are expressed.

Why use cases?

Use cases are intended primarily to define functional requirements to the system and manage the entire development process. The simplicity of the use case diagram allows analysts to easily communicate with customers during the requirements definition process, identifying constraints imposed on the system and on the implementation of individual requirements, such as system response time, which later fall into the section of non-functional requirements. All major activities such as analysis, design, testing are performed based on use cases.

During analysis and design, use cases provide insight into how the results the user wants influence the system architecture and how the system components must behave in order to implement the functionality the user desires.

During the testing process, the use cases described earlier make it easier to assess the accuracy of the implementation of user requirements and allow for step-by-step verification of these requirements.

Using use cases, you can describe the behavior of the system being developed without defining its implementation. Thus, they allow for mutual understanding between developers, experts and end users of the product. In addition, use cases help verify the architecture of a system during its development.

UML notation

Precedents involve interaction between actors and the system. An actor is a logically connected set of roles. Actors can be both people and automated systems.

Any use case must have a name that distinguishes it from other use cases. It must be unique within the enclosing package. The use case name is a text string. Taken by itself, it is called a simple name. The compound name is prefixed with the name of the package it is in. Usually, when depicting a precedent, only its name is indicated. The name can span multiple lines. In practice, to name precedents, short verb phrases in active form are used, denoting some behavior and taken from the vocabulary of the system being modeled.

In Fig. Figure 1 shows how actors and use cases are depicted in diagrams.

rice. 1. Diagram representation of actor and use case

Actor. An actor represents the role that a person, hardware device, or other system plays in a given system. As shown in the picture above, the actors are depicted as a human figure. You can define general types of actors and then specialize them with a generalization relation (see Generalization relation), as shown in Fig. 2.

rice. 2. Generalization relation between actors

Precedent.Precedent Usecase is a description of a set of sequences of actions (including options) performed by the system so that an actor can obtain a valuable result. Graphically, a precedent is depicted as an ellipse.

Precedents are organized by defining relations of generalization, inclusion and expansion between them. These relationships are used to highlight some common behavior (by extracting it from other use cases that include it) or, conversely, variations (by placing such behavior in other use cases that extend it).

A Actors can be linked to cases only by association relationships (see Association Relationship). The association between an actor and a use case indicates that they are communicating with each other, possibly by sending or receiving messages (Figure 3).

rice. 3. Association relationship between actor and precedent

Generalization relation (see Generalization relationship) between cases is similar to generalization relationships between classes. This means that a child use case inherits the behavior and semantics of its parent, can replace or complement its behavior, and can also be substituted wherever its parent appears (both parent and child can have concrete instances).

For example, in a banking system, there may be a “Verify Client” use case that is responsible for verifying the client’s identity. It can have two specialized children ("Check Password" and "Retina Scan"). Both children behave the same as the "Verify Client" use case and can be used anywhere their parent is used, but they each add their own behavior (the first checks a text password, the second checks a retinal image).

As shown in Fig. 4, generalizations between precedents are depicted in exactly the same way as generalizations between classes - as a line with an open arrow.

rice. 4. Generalizations, inclusions and extensions

Attitude inclusion between use cases means that at some point in the base use case the behavior of another use case is incorporated. An included use case never exists independently, but is instantiated (instantiated) only as part of the enclosing use case. You can think of the base use case as adopting the behavior of included use cases.

By having inclusion relationships, you avoid describing the same flow of events multiple times because the overall behavior can be described as a standalone use case that is included in a base use case. An include relationship is an example of delegation, in which a set of system responsibilities are described in one place (in an include use case), and other use cases include those responsibilities in their set when necessary.

Inclusion relationships are depicted as dependencies (see Dependency Relationship) with the stereotype (see Association Relationship) include. To specify a place in the flow of events where a base use case includes the behavior of another, you simply write the word include followed by the name of the included use case (see below).

The direction of the inclusion relation follows from the use case that is used to the use case that uses it. The direction of the arrow indicates that the extension point uses an include use case.

For example, when describing the scenario of a use case called “Monitor Order Fulfillment”, which uses another use case “Verify Customer”:

Main stream of events. Receive and check the order number, include (Check customer). Request the status of each part of the order and report to the client.

Expansion relation implies that the base use case implicitly contains the behavior of another use case at a point that is implicitly specified by the extending use case. A base use case may be autonomous, but under certain circumstances its behavior is extended by another. The base use case can only be extended at certain points, called extension points. You can think of the extending use case as transferring its behavior to the base use case.

The extension relation is used to model those parts of the use case that the user perceives as optional system behavior. This way you can separate mandatory and optional behavior. Extension relationships are also used to model individual subthreads that execute only under certain circumstances. Finally, they are used to model multiple threads that may be triggered at some point in a scenario as a result of explicit interaction with an actor.

An extension relationship is depicted as a dependency (see Dependency Relationship) with the stereotype extend. The extension points for the base scenario are listed in the supplementary section. They are simply labels that may appear in the underlying use case flow.

For example, the flow for the Place Order use case could be described as follows.

Main stream of events. include(Check Client). Collect all items of the customer's order. (Set priority). Submit your order for processing.

In this example, the phrase “Set priority” is an extension point. A use case may contain several extension points (each several times), identified by names. Under normal circumstances, the base use case in this example is executed without regard to order priority. If a priority order arrives, the thread will execute as usual until the expansion point (Set Priority), and the expanding precedent will be executed at it (Place Urgent Order), after which the main thread will resume work. If multiple extension points are defined, the extending use cases will be executed sequentially in their own threads.

So, inclusion relations are used to describe the required behavior of a system that is implemented by a use case and which is included in other use cases. Extension relationships are used to model optional system behavior.

System context. Any system contains some entities within itself, while other entities remain outside it. For example, a credit card verification system has accounts, transactions, and authentication mechanisms. At the same time, credit card holders and merchants are outside the system. Entities inside the system are responsible for implementing the behavior expected by entities outside. Entities outside the system and interacting with it constitute its context. Thus, the context is the environment of the system.

UML allows you to model context using use case diagrams, which focus on the actors surrounding the system. It is important to correctly define actors because it allows you to describe the class of entities that interact with the system. It is even more important to determine what is not an actor, since this limits the environment of the system: only those elements that participate in its operation remain in it.

System context modeling consists of the following steps:

Identify the actors surrounding the system. To do this, you need to find groups that require the participation of the system to perform their tasks; groups that are necessary for the system to carry out its functions; groups that interact with external software and hardware, as well as groups that perform auxiliary administrative and support functions.

Organize similar actors using generalization/specialization relationships.

Introduce stereotypes for each actor if this makes it easier to understand.

Place the actors on a use case diagram and determine how they relate to the system's use cases.

For example, it shows the context of a credit card system, where the focus is on the actors around it. First of all, these are two types of Clients (“Individual Client” and “Corporate Client”), corresponding to the roles that people play when interacting with the system. In this context, actors representing other organizations are also shown, such as “Trading enterprises” (with whom customers make card transactions, purchasing goods or services) and “Subsidizing financial institutions”. IN real world the last two actors are likely to be software systems themselves.

rice. 5.Modeling the system context

The same method allows you to model the context of the subsystem. The rectangle in the figure contains precedents that describe the system itself (which we are developing), and actors are entities external to the system.

For a more detailed analysis, the rules of the board game were presented in the form of block diagrams describing the main stages of the gameplay. The general diagram is shown in Figure 1.1.

Rice. 1.1.

This scheme includes the following subprocesses:

1. Initialization. Contains algorithms for determining the right to make the first move and issuing the initial number of cards to all players.

2. Development phase. Contains an algorithm for placing cards on the table, in the form of animals and their properties.

3. Phase of determining the food supply. Contains an algorithm for determining the number of food chips that will be available to players during the “food phase”.

4. Nutrition phase. Contains algorithms for feeding and applying animal properties.

5. The phase of extinction and receiving new cards. Contains algorithms for moving unfed animals to the dump, determining the number and issuing new cards.

6. End of the game. This scheme contains an algorithm for counting points and determining the winner.

Detailed diagrams of subprocesses are in Appendix B. Algorithmic description of the rules of the game.

Requirements Specification

The game being developed is a complete analogue of the board game Evolution, therefore, first of all, the entire game process must comply with and occur according to the rules of the original (board) game.

Business requirements:

Game against the computer;

Selecting the number of players.

Functional requirements:

Requirements for the system in terms of the rules of the game:

Issue cards;

Keep up-to-date information about the current cards in the hands of players and their animals with all the properties lying on the playing field;

Calculate the order of moves;

Determine and transfer the right to the first move;

Calculate interactions between different properties;

Determine the food supply based on the number of players;

Place cards in the discard pile;

Store information about the cards in the player’s discard pile;

System requirements from the player's point of view:

Start a new game;

Place a card in the shape of an animal;

Place the card as a property;

Skip turn;

Take a food chip from the food supply;

Place a food token on your animal;

Activate apply property;

Finish the game.

Use Case Model

Building a Use Case Diagram

Visualization of requirements is implemented using use-case diagrams (see Figure 1.2.).

Rice. 1.2.

Documenting use cases

Documentation of precedents is presented in the tables below (see. Table 1.1. - 1.15).

Table 1.1. Use case “Create a new game”.

Table 1.2. Use case “Set parameters”.

Short description	A use case allows the user to set parameters created game and start the gameplay.
Performers
Preconditions	The user clicked the " A new game»
Main thread	1. The player selects the set of cards to use: Standard set (84 cards) - default. Addition “Time to Fly” (+42 cards). 2. The player selects the number of players: 2 players - default. 3 players. 4 players. 3. The player clicks the “Create game” button. 4. Bots (computer-controlled players) are added to the created game in the number specified in the settings.
Alternative streams
Postconditions	The settings are now configured.

Short description
Executor
Preconditions
Main thread	2. The system displays a window in which the player is given the opportunity to select a location where to save the file in txt format. 3. The player selects the path, file name and confirms saving. 4. The system saves the game to disk and displays a message to the player. 5. The system offers to continue the game.
Alternative streams	A1. There is not enough disk space. a. The system displays a message that there is not enough disk space for recording.
Postconditions	The configuration and current state of the game are saved to a file on the hard drive

Table 1.4. Precedent “Continue the game”.

Short description	The use case allows you to continue a previously saved game.
Executor
Preconditions	Availability of a file with the saved game configuration on the disk.
Main thread	1. The player starts the system. 2. The player clicks on the “Continue Game” button. 3. The system displays a window in which the player is given the opportunity to select a saved game file. 4. The player selects the file and confirms the opening. A1. The file structure is incorrect. 5. The system restores the configuration, state and number of players from the file and loads the playing field.
Alternative streams	A1. The file structure is incorrect. a. The system displays a message indicating that the file is damaged. b. The system returns to the 3rd point.
Postconditions	The game configuration has been restored.

Table 1.5. Precedent “End the game”.

Table 1.6. Precedent “Play”.

Short description	The use case represents the gameplay.
Executor
Preconditions	The “Create a new game” precedent has been executed.
Main thread	Beginning of the game: 1. The system determines the turn order (Performs a draw based on the random chance). 2. The system transfers the right of the first move to the player selected as a result of the draw. 3. The “Get Cards” precedent for a new game is executed. Development phase: A2. The player has already missed his turn. 5. The player makes a move. A3. The player decides to go. A4. The player has no cards in his hand. 6. The system transfers the turn to another player. Forage determination phase: 7. The system, using the randomizer, determines the number of food chips that will be available during the feeding phase. 8. Food chips appear on the playing field. Power phase: A7. The player has already missed his turn. 9. The player makes a move. A9. The player decides to go. A5. The player clicks on the “Skip move” button. 10. The system moves the turn to the next player. Extinction phase: 11. The “Get Cards” precedent is executed during the extinction phase. Completion of the game: 12. The system counts the points scored by the players. 13. The system displays the overall result of all players. 14. The “Create a new game” and “Exit to menu” buttons appear.
Alternative streams	A1. All players received cards. a. The game moves to step 3. A2. The player has already missed his turn. A3. The player has no cards in his hand. A4. The player decides to go. a. The “Make a move” precedent is executed in the development phase. A5. The player clicks on the “Skip move” button. a. The “Skip turn” precedent is executed. A6. All players missed a turn in the development phase. a. The game moves to step 5. A7. The player has already missed his turn. a. The use case moves to step 8. A8. The player has no cards on the table. a. The “Skip turn” precedent is executed. A9. The player decides to go. a. The “Make a move” precedent is executed during the power phase. A10. All players missed a turn during the feeding phase. a. The game moves to step 9. A11. The "Get Cards" precedent in the extinction phase is complete. A11.1. None of the players received new cards. a. The right to make the first move passes to the next player. b. The game returns to step 3. A11.1. No players received new cards during the Extinction phase. a. The game moves to step 10. A12. The player scored the most points. a. The “Win” precedent is executed. A13. The player, together with another player, scored the same number of points, but more than the other players. a. The system additionally counts points for animals in the players' discard pile. b. If the player scores more points than the opponent, the “Win” precedent is executed. c. If the player scores fewer points than the opponent, the “Lose” precedent is executed. A14. A player has scored fewer points than another player. A15. The player clicked the “Create a new game” button. a. The “Create Game” use case is executed. A16. The player pressed the “Exit to menu” button. a. The "End Game" use case is executed.
Expansion point	· “Win” precedent. · “Lose” precedent.
Postconditions	A game has been played.

Table 1.7. Use case "Get cards".

Short description	A precedent allows a player to draw new cards from the deck.
Preconditions	The “Create a new game” precedent has been executed.
Main thread	For a new game: 1. The system gives the player 6 cards from a common deck. During the extinction phase: A1. All players received the required number of cards, or the deck ran out of cards. A2. The player's unfed animals are placed in the discard pile and the number of cards needed to be dealt is determined. 1. The system places unfed animals in the player's discard pile. 2. The system determines the number of cards required for issuing, equal to the number of surviving animals of the player + 1. 3. The system gives the player one card from the required number. 4. The system moves the turn to the next player. 5. The “Get Cards” precedent is executed during the extinction phase.
Alternative streams	A1. All players received the required number of cards, or the deck ran out of cards. a. The precedent ends. A2. The player's unfed animals are placed in the discard pile and the number of surviving animals is determined. a. The use case moves to step 3. A3. The player has no surviving animals and no cards in his hand. A3.1. There are no cards in the deck. a. The system determines the number of cards required for issuing, equal to 6. A3.1. There are no cards in the deck. a. The “Lose” precedent is executed. b. The use case moves to step 4. A4. The player is given all the required number of cards. a. The use case moves to step 4.
Postconditions	The player received new cards.

Table 1.8. “Win” precedent.

Table 1.9.Precedent “Lose”.

Table 1.10. “Skip move” precedent.

Short description	The precedent skips the player's turn.
Preconditions	The player has the right to move.
Main thread	1. The system ends the player's turn. During the current phase, the player will no longer receive the right to move.
Alternative streams	A1. The game is in the feeding phase, there are chips in the food supply and the player has unfed animals or animals with unfilled fat reserves. a. The system displays a message stating that the player cannot skip a move because... must take a food token. b. The precedent ends.
Postconditions	The player misses a turn and can no longer move in the current phase.

Table 1.11.Precedent “Make a move”.

Short description	A precedent allows a player to make a move.
Preconditions	The player has the right to move.
Main thread	Development phase: Power phase: A5. The player applies the ability.
Alternative streams	A1. The player places a card in the form of an animal. a. The precedent “Place a card in the form of an animal” is executed. A2. The player places the card as an ability. a. The use case “Put a card as an ability” is executed. b. The Make a Move use case ends. A3. There are no food chips left in the food supply. The player has no properties that can be applied. a. The “Skip turn” precedent is executed. A4. The player takes a food token from the food supply. a. The “Take a food token” precedent is executed. A5. The player applies the ability. a. The “Apply property” use case is executed. A5.1. The player has no properties that can be applied. a. The Make a Move use case ends.
Postconditions	The player makes a move in the current phase.

Table 1.12. Precedent “Place a card in the form of an animal.”

Short description	A precedent allows the player to create a new animal.
Preconditions	The player has the right to move.
Main thread	A1. The player released the card. 2. The player drags the card to an empty space on his playing field. 3. The system allocates a space and informs the player that the card will be placed in the form of the player's animal. A2. The card is located above another card on your playing field or on the opponent's field. 4. The player releases the card. 5. The card is placed on the player’s playing field with the animal facing up.
Alternative streams	A1. The player released the card. A2. The player released the card over another card on his or her opponent's playing field. a. The “Put card as property” precedent from step 3 is executed. A3. The player released the card over the opponent's playing field.
Postconditions	An animal card appears on the current player's playing field.

Table 1.13. Use case “Place a card as an ability.”

Short description	A precedent allows the player to assign a trait to a chosen animal.
Preconditions	The player has the right to move.
Main thread	1. The player clicks on the selected card and holds it. A1. The player released the card. 2. The player drags the card onto an animal on his playing field. 3. The system highlights the animal card and informs the player that the card will be located as the property of this animal. 4. The player releases the card. 5. The name and characteristics of the property appear above the selected animal.
Alternative streams	A1. The player released the card. a. The card does not change position and remains in the player’s “hands”. A2. The player released the card to an empty space on his playing field. a. The precedent “Place a card in the form of an animal” from step 3 is executed. A3. The player released the card onto an empty space on the opponent's playing field. a. The card is returned back to the player's "hands". A4. The player released the card over the opponent's animal. a. If the property can be used on other players' animals, then the use case moves to step 5. b. If the property cannot be applied to the animals of other players, then the system informs the player that this property can only be applied to their own animals, and the card is returned back to the player’s “hands”. A5. The property on the map is a paired property. a. The system applies the property to the selected animal and asks the player to specify the second animal. b. The player indicates the 2nd animal. c. The system has specified cards next to each other. d. The name of the property and a connecting line between these properties appear above the selected animals. A5.1. The player has only 1 animal. a. The system informs the player that a paired property cannot be placed because The player does not have enough animal cards. b. The card is returned back to the player's "hands". A6. There are 2 properties to choose from on the map. a. The system displays a modal window with property options. b. The player clicks on the selected property. c. The use case moves to step 5. A7. The ability cannot be applied twice on the same animal card. a. The system informs the player that the ability cannot be placed twice on the same animal.
Postconditions	On the player's playing field, the name and characteristics of the property that it possesses are added to the animal card.

Table 1.14. Precedent “Take a food chip.”

Short description	The precedent allows the player to feed one of his animals.
Preconditions	The player has the right to move.
Main thread	1. The player clicks on the food chip in the food base and holds it. A1. The player released the chip. 2. The player drags the food token onto an animal on his playing field. 3. The system highlights the animal card and informs the player that this animal will receive +1 to its food supply. 4. The player releases the food token. 5. The selected animal is marked with a food token, and the food supply is replenished by +1 unit.
Alternative streams	A1. The player released the chip. a. The chip does not change position and remains in the feed base. A2. The player's animal has already been fed. a. The system highlights the animal card and informs the player that this animal cannot receive a new food token because is fully fed. b. If a player releases a food chip, the chip returns to the food base. A3. The player released the food piece outside of his playing field. A4. The player released the piece outside the animal card on his playing field. a. The chip returns to the food base.
Postconditions	The player's current animal replenishes the food supply by 1 unit.

Table 1.15. Use case “Apply property”.

Short description	The use case allows the player to activate the ability of their animal.
Preconditions	The player has the right to move.
Main thread	1. The system highlights the properties of the animal that can be activated. 2. The player clicks on an available property. 3. The system processes the selected property and displays the result of application on the playing field, or communicates it to the player.
Alternative streams	A1. The "Predator" property has been used. a. The system highlights animals that may be attacked. b. The player chooses an animal that is going to attack. c. The system checks the protective properties of this animal. d. If there is a protective property, then the system transfers the move to the player whose animal is attacked; after selecting the property, the move is returned back to the attacking player and the precedent moves to step 3. e. If there are no properties or it did not work, the animal is considered eaten and disappears from the field. The attacking player's animal receives 2 food units. A2. The ability can be used once per round. a. The system marks the property as used, such property can no longer be used in this round.
Postconditions	The property of an animal belonging to the player is activated.

Send your good work in the knowledge base is simple. Use the form below

Students, graduate students, young scientists who use the knowledge base in their studies and work will be very grateful to you.

Posted on http://www.allbest.ru/

Introduction

1. Domain analysis

1.1 Problem statement

1.2 Algorithmic representation of the rules of the game

1.3 Requirements Specification

1.4 Use case model

1.4.1 Building a use case diagram

1.5 Overview of development tools

1.6 Analysis of analogues

1.7 Chapter Conclusions

2. Game design

2.1 Design model

2.1.1 Game architecture

2.2 Development of a graphical user interface.

2.2.1 Interface structure

2.2.2 Main menu

2.2.3 Game screen

2.3 Implementation of the interface in the Unity environment

2.3.1 Main menu

2.3.2 Game screen

2.6 Chapter Conclusions

3. Development

3.1 Moving cards

3.2 Player playing field

3.3 Implementation of a computer behavior algorithm.

3.4 Chapter Conclusions

Conclusion

Bibliography

APPENDIX A. Properties of the basic version of the game "Evolution".

APPENDIX B. Algorithmic description of the rules of the game.

APPENDIX B. Source code of the computer behavior algorithm.

Introduction

Over the past 20 years, there have been rapid trends in the development of the video game market. Starting its journey from slot machines, this area gradually covered almost all digital devices that each of us uses every day: computers, tablets and mobile phones. Apart from this, there is also a market for board games, which has a significant number of fans and interesting projects. Research in this area has shown that about 62% of people who enjoy gaming prefer to play on a computer, mobile phone or tablet, about 14% like to play board games with friends, the remaining 24% prefer both. This difference in indicators indicates a loss of interest in board games, which in turn is due to the following factors:

· most people cannot play a board game due to lack of time, space or the necessary company, since almost all board games are designed to be played by 2 to 4 people;

· there is no opportunity to practice alone and find new winning strategies for yourself;

· A board game box can take up a lot of space, and some cards or chips can get damaged or lost.

Compared to board games, computer games are more adaptable and easy to use. You can play your favorite game at any time and on any device. There is also the opportunity to play offline against a computer or via the Internet, finding new opponents and improving your skills. And another important factor is that computer games are easier to store and take up only a few megabytes of memory on your hard drive.

As part of the final qualifying work, the board game “Evolution” is considered - this is a simulator of the development of life on Earth, based on the Darwinian principle of natural selection. Each player develops his own population of living creatures, giving them various properties - adaptations to environmental conditions.

This game is presented only in desktop version, which means it has the previously discussed set of factors that determine the main problem of the study. To solve this problem, it is necessary to develop a computer version of the game, which in turn determines the relevance of the research topic.

Currently, there are a large number of different tools for developing computer or mobile games. Each of them has its own characteristics, its pros and cons. The most preferable engine for implementing the Evolution game was the Unity engine, due to its free distribution, huge community and the ability to create cross-platform games in the high-level programming language C#.

The object of this study is the board game “Evolution”, the subject of the study is the development of a computer version of this game using game engine Unity.

The goal of the work is to develop a computer version of the board game “Evolution” using the Unity game engine.

To achieve this goal, the following tasks must be completed:

1. Study the rules of the board game “Evolution” and, based on them, determine the functional requirements and describe the use case.

2. Design the architecture of the game being developed.

3. Develop the design of game objects and graphical user interface.

4. Implement a computer version of the game based on the designed models using the Unity environment.

At the analysis stage, research methods such as abstraction and decomposition are used to represent the object as a system. Object-oriented analysis and design are used to describe the interaction of all system elements.

1. Domain analysis

1.1 Problem statement

“Evolution” is a board game for a company of 2 to 4 people, where each player develops his own population of living creatures, endowing them with various properties necessary for survival. Properties help animals in the struggle for food resources, the supplies of which are limited. Creatures that do not get food die, and those that survive allow you to introduce even more animals and properties into the game. The winner is the one of the opponents whose population will be the most developed and numerous by the end of the game.

Animals and their properties are presented in the game in the form of cards. Where on one side the symbol of an animal is depicted - a lizard, and on the other side various properties, such as: “Predator”, “Waterfowl”, “Symbiosis”, “Burrow”, etc. In total, there are 19 different properties in the basic version of the game (see Appendix 1). Each card lying on the player's field with the animal symbol facing up is one of his creatures. Properties are placed under the animal, so that other players can see what properties it has. Some cards indicate two properties at once: in this case, the player must choose which one he wants to give his creature. When an animal dies of starvation or is eaten by another animal with the Predator property, it, along with all its properties, is sent to the player's discard pile.

Beginning of the game. The deck of cards is shuffled. Each participant is given six cards. The game lasts several rounds until the cards in the deck run out. Each round consists of four stages:

? development phase;

? phase of determining the food supply;

? power phase;

? phase of extinction and receiving new cards.

At the beginning of the game, the player who will go first is randomly determined. In each subsequent round, this privilege is transferred clockwise to another player. During the development phase and the feeding phase, players take turns walking. A player who passes or for some reason cannot move in this phase misses his turn until the end of the phase. The stage ends when all players can no longer make a move.

Nutrition phase. During this stage, players take turns taking one food token from the food supply and using it on any of their creatures that has not yet been fed. For normal animals, one red food token is required for it to be considered fed, but some properties increase this requirement. You can also get food chips by using properties such as “Predator” or “Piracy”; in this case, the additional food chip will be blue. A fed animal cannot receive new food chips, except when the “Fat Reserve” property is applied to it; when this property is in effect, a red food chip is converted into a yellow chip. If all of a player's animals are fed and their Fat Reserve is full, the player can no longer take food tokens from the food supply or gain them from using properties. However, if there are food chips left in the food supply and the player still has unfed animals or animals with an unfilled “Fat Reserve,” he must take chips from the food supply. When all the animals are fed and their “Fat Reserve” is full, or the food supply has run out and the players have played all the properties that they wanted to use in this phase of the turn, the feeding phase ends.

Rice. 1.1. Gameplay algorithm.

This scheme includes the following subprocesses:

1. Initialization. Contains algorithms for determining the right to make the first move and issuing the initial number of cards to all players.

2. Development phase. Contains an algorithm for placing cards on the table, in the form of animals and their properties.

3. Phase of determining the food supply. Contains an algorithm for determining the number of food chips that will be available to players during the “food phase”.

4. Nutrition phase. Contains algorithms for feeding and applying animal properties.

5. The phase of extinction and receiving new cards. Contains algorithms for moving unfed animals to the dump, determining the number and issuing new cards.

6. End of the game. This scheme contains an algorithm for counting points and determining the winner.

Detailed diagrams of subprocesses are in Appendix B. Algorithmic description of the rules of the game.

1.3 Requirements Specification

The game being developed is a complete analogue of the board game Evolution, therefore, first of all, the entire gameplay must correspond to and occur according to the rules of the original (board) game.

Business requirements:

? game against the computer;

? selecting the number of players.

Functional requirements:

Requirements for the system in terms of the rules of the game:

? issue cards;

? store up-to-date information about the current cards in the hands of players and their animals with all the properties lying on the playing field;

? calculate the turn order;

? determine and transfer the right to the first move;

? calculate interactions between different properties;

? determine the food supply based on the number of players;

? place cards in the discard pile;

? store information about the cards in the player’s discard pile;

? count the final points and determine the winner;

System requirements from the player's point of view:

? start a new game;

? place a card in the shape of an animal;

? put a card as a property;

? skip a move;

? take a food chip from the food supply;

? place a food token on your animal;

? activate\apply property;

? finish the game.

1.4 Use case model

1.4.1 Building a use case diagram

Visualization of requirements is implemented using use-case diagrams (see Figure 1.2.).

Rice. 1.2. Use case diagram.

1.4.2 Documenting use cases

Documentation of precedents is presented in the tables below (see. Table 1.1. - 1.15).

Table 1.1. Use case “Create a new game”.

Table 1.2. Use case “Set parameters”.

Short description	The use case allows the user to set the parameters of the game being created and begin the gameplay.
Performers
Preconditions	The user clicked the "New Game" button
Main thread	1. The player selects the set of cards to use: Standard set (84 cards) - default. Addition “Time to Fly” (+42 cards). 2. The player selects the number of players: 2 players - default. 3 players. 4 players. 3. The player clicks the “Create game” button. 4. Bots (computer-controlled players) are added to the created game in the number specified in the settings.
Alternative streams
Postconditions	The settings are now configured.

Table 1.3.Precedent “Save the game”.

Short description
Executor
Preconditions
Main thread	2. The system displays a window in which the player is given the opportunity to select a location where to save the file in txt format. 3. The player selects the path, file name and confirms saving. 4. The system saves the game to disk and displays a message to the player. 5. The system offers to continue the game.
Alternative streams	A1. There is not enough disk space. a. The system displays a message that there is not enough disk space for recording.
Postconditions	The configuration and current state of the game are saved to a file on the hard drive

Table 1.4. Precedent “Continue the game”.

Short description	The use case allows you to continue a previously saved game.
Executor
Preconditions	Availability of a file with the saved game configuration on the disk.
Main thread	1. The player starts the system. 2. The player clicks on the “Continue Game” button. 3. The system displays a window in which the player is given the opportunity to select a saved game file. 4. The player selects the file and confirms the opening. A1. The file structure is incorrect. 5. The system restores the configuration, state and number of players from the file and loads the playing field.
Alternative streams	A1. The file structure is incorrect. a. The system displays a message indicating that the file is damaged. b. The system returns to the 3rd point.
Postconditions	The game configuration has been restored.

Table 1.5. Precedent “End the game”.

Short description	The precedent allows you to log out of the system or finish a game.
Executor
Preconditions
Main thread	While in the main menu: 1. The player presses the “Exit” button. 2. The system requests exit confirmation “Yes\No” 3. The system completes its execution and exits to the desktop. While in the game: 1. The player presses the “Exit to menu” button. 2. The system requests confirmation of the “Yes\No” exit. 3. The system exits to the main menu.
Alternative streams
Postconditions	The game is over.

Table 1.6. Precedent “Play”.

Short description	The use case represents the gameplay.
Executor
Preconditions	The “Create a new game” precedent has been executed.
Main thread	Beginning of the game: 1. The system determines the turn order (Performs a draw based on the random chance). 2. The system transfers the right of the first move to the player selected as a result of the draw. 3. The “Get Cards” precedent for a new game is executed. Development phase: A2. The player has already missed his turn. 5. The player makes a move. A3. The player decides to go. A4. The player has no cards in his hand. 6. The system transfers the turn to another player. Forage determination phase: 7. The system, using the randomizer, determines the number of food chips that will be available during the feeding phase. 8. Food chips appear on the playing field. Power phase: A7. The player has already missed his turn. 9. The player makes a move. A9. The player decides to go. A5. The player clicks on the “Skip move” button. 10. The system moves the turn to the next player. Extinction phase: 11. The “Get Cards” precedent is executed during the extinction phase. Completion of the game: 12. The system counts the points scored by the players. 13. The system displays the overall result of all players. 14. The “Create a new game” \ “Exit to menu” buttons appear.
Alternative streams	A1. All players received cards. a. The game moves to step 3. A2. The player has already missed his turn. A3. The player has no cards in his hand. A4. The player decides to go. a. The “Make a move” precedent is executed in the development phase. A5. The player clicks on the “Skip move” button. a. The “Skip turn” precedent is executed. A6. All players missed a turn in the development phase. a. The game moves to step 5. A7. The player has already missed his turn. a. The use case moves to step 8. A8. The player has no cards on the table. a. The “Skip turn” precedent is executed. A9. The player decides to go. a. The “Make a move” precedent is executed during the power phase. A10. All players missed a turn during the feeding phase. a. The game moves to step 9. A11. The "Get Cards" precedent in the extinction phase is complete. A11.1. None of the players received new cards. a. The right to make the first move passes to the next player. b. The game returns to step 3. A11.1. No players received new cards during the Extinction phase. a. The game moves to step 10. A12. The player scored the most points. a. The “Win” precedent is executed. A13. The player, together with another player, scored the same number of points, but more than the other players. a. The system additionally counts points for animals in the players' discard pile. b. If the player scores more points than the opponent, the “Win” precedent is executed. c. If the player scores fewer points than the opponent, the “Lose” precedent is executed. A14. A player has scored fewer points than another player. A15. The player clicked the “Create a new game” button. a. The “Create Game” use case is executed. A16. The player pressed the “Exit to menu” button. a. The "End Game" use case is executed.
Expansion point	· “Win” precedent. · “Lose” precedent.
Postconditions	A game has been played.

Table 1.7. Use case "Get cards".

Short description	A precedent allows a player to draw new cards from the deck.
Preconditions	The “Create a new game” precedent has been executed.
Main thread	For a new game: 1. The system gives the player 6 cards from a common deck. During the extinction phase: A1. All players received the required number of cards, or the deck ran out of cards. A2. The player's unfed animals are placed in the discard pile and the number of cards needed to be dealt is determined. 1. The system places unfed animals in the player's discard pile. 2. The system determines the number of cards required for issuing, equal to the number of surviving animals of the player + 1. 3. The system gives the player one card from the required number. 4. The system moves the turn to the next player. 5. The “Get Cards” precedent is executed during the extinction phase.
Alternative streams	A1. All players received the required number of cards, or the deck ran out of cards. a. The precedent ends. A2. The player's unfed animals are placed in the discard pile and the number of surviving animals is determined. a. The use case moves to step 3. A3. The player has no surviving animals and no cards in his hand. A3.1. There are no cards in the deck. a. The system determines the number of cards required for issuing, equal to 6. A3.1. There are no cards in the deck. a. The “Lose” precedent is executed. b. The use case moves to step 4. A4. The player is given all the required number of cards. a. The use case moves to step 4.
Postconditions	The player received new cards.

Table 1.8. “Win” precedent.

Table 1.9.Precedent “Lose”.

Table 1.10. “Skip move” precedent.

Short description	The precedent skips the player's turn.
Preconditions	The player has the right to move.
Main thread	1. The system ends the player's turn. During the current phase, the player will no longer receive the right to move.
Alternative streams	A1. The game is in the feeding phase, there are chips in the food supply and the player has unfed animals or animals with unfilled fat reserves. a. The system displays a message stating that the player cannot skip a move because... must take a food token. b. The precedent ends.
Postconditions	The player misses a turn and can no longer move in the current phase.

Table 1.11.Precedent “Make a move”.

Short description	A precedent allows a player to make a move.
Preconditions	The player has the right to move.
Main thread	Development phase: Power phase: A5. The player applies the ability.
Alternative streams	A1. The player places a card in the form of an animal. a. The precedent “Place a card in the form of an animal” is executed. A2. The player places the card as an ability. a. The use case “Put a card as an ability” is executed. b. The Make a Move use case ends. A3. There are no food chips left in the food supply. The player has no properties that can be applied. a. The “Skip turn” precedent is executed. A4. The player takes a food token from the food supply. a. The “Take a food token” precedent is executed. A5. The player applies the ability. a. The “Apply property” use case is executed. A5.1. The player has no properties that can be applied. a. The Make a Move use case ends.
Postconditions	The player makes a move in the current phase.

Table 1.12. Precedent “Place a card in the form of an animal.”

Short description	A precedent allows the player to create a new animal.
Preconditions	The player has the right to move.
Main thread	A1. The player released the card. 2. The player drags the card to an empty space on his playing field. 3. The system allocates a space and informs the player that the card will be placed in the form of the player's animal. A2. The card is located above another card on your playing field or on the opponent's field. 4. The player releases the card. 5. The card is placed on the player’s playing field with the animal facing up.
Alternative streams	A1. The player released the card. A2. The player released the card over another card on his or her opponent's playing field. a. The “Put card as property” precedent from step 3 is executed. A3. The player released the card over the opponent's playing field.
Postconditions	An animal card appears on the current player's playing field.

Table 1.13. Use case “Place a card as an ability.”

Short description	A precedent allows the player to assign a trait to a chosen animal.
Preconditions	The player has the right to move.
Main thread	1. The player clicks on the selected card and holds it. A1. The player released the card. 2. The player drags the card onto an animal on his playing field. 3. The system highlights the animal card and informs the player that the card will be located as the property of this animal. 4. The player releases the card. 5. The name and characteristics of the property appear above the selected animal.
Alternative streams	A1. The player released the card. a. The card does not change position and remains in the player’s “hands”. A2. The player released the card to an empty space on his playing field. a. The precedent “Place a card in the form of an animal” from step 3 is executed. A3. The player released the card onto an empty space on the opponent's playing field. a. The card is returned back to the player's "hands". A4. The player released the card over the opponent's animal. a. If the property can be used on other players' animals, then the use case moves to step 5. b. If the property cannot be applied to the animals of other players, then the system informs the player that this property can only be applied to their own animals, and the card is returned back to the player’s “hands”. A5. The property on the map is a paired property. a. The system applies the property to the selected animal and asks the player to specify the second animal. b. The player indicates the 2nd animal. c. The system places the specified cards next to each other. d. The name of the property and a connecting line between these properties appear above the selected animals. A5.1. The player has only 1 animal. a. The system informs the player that a paired property cannot be placed because The player does not have enough animal cards. b. The card is returned back to the player's "hands". A6. There are 2 properties to choose from on the map. a. The system displays a modal window with property options. b. The player clicks on the selected property. c. The use case moves to step 5. A7. The ability cannot be applied twice on the same animal card. a. The system informs the player that the ability cannot be placed twice on the same animal.
Postconditions	On the player's playing field, the name and characteristics of the property that it possesses are added to the animal card.

Table 1.14. Precedent “Take a food chip.”

Short description	The precedent allows the player to feed one of his animals.
Preconditions	The player has the right to move.
Main thread	1. The player clicks on the food chip in the food base and holds it. A1. The player released the chip. 2. The player drags the food token onto an animal on his playing field. 3. The system highlights the animal card and informs the player that this animal will receive +1 to its food supply. 4. The player releases the food token. 5. The selected animal is marked with a food token, and the food supply is replenished by +1 unit.
Alternative streams	A1. The player released the chip. a. The chip does not change position and remains in the feed base. A2. The player's animal has already been fed. a. The system highlights the animal card and informs the player that this animal cannot receive a new food token because is fully fed. b. If a player releases a food chip, the chip returns to the food base. A3. The player released the food piece outside of his playing field. A4. The player released the piece outside the animal card on his playing field. a. The chip returns to the food base.
Postconditions	The player's current animal replenishes the food supply by 1 unit.

Table 1.15. Use case “Apply property”.

Short description	The use case allows the player to activate the ability of their animal.
Preconditions	The player has the right to move.
Main thread	1. The system highlights the properties of the animal that can be activated. 2. The player clicks on an available property. 3. The system processes the selected property and displays the result of application on the playing field, or communicates it to the player.
Alternative streams	A1. The "Predator" property has been used. a. The system highlights animals that may be attacked. b. The player chooses an animal that is going to attack. c. The system checks the protective properties of this animal. d. If there is a protective property, then the system transfers the move to the player whose animal is attacked; after selecting the property, the move is returned back to the attacking player and the precedent moves to step 3. e. If there are no properties or it did not work, the animal is considered eaten and disappears from the field. The attacking player's animal receives 2 food units. A2. The ability can be used once per round. a. The system marks the property as used, such property can no longer be used in this round.
Postconditions	The property of an animal belonging to the player is activated.

1.5 Overview of development tools

The Unity game engine was chosen as the environment for developing the computer game “Evolution”. Unity is a multi-platform tool for developing 2D/3D games and interactive content. Today, version 5 of the engine is available, which implements all the latest 3D and 2D technologies. One of these technologies is the UI System, which contains classes that greatly simplify working with 2D elements. . This technology is most suitable for creating a gaming space and interactive interface for the computer game “Evolution”. The basic set of UI elements and their purpose are presented in Table 1.16.

Table 1.16. A basic set of UI elements in Unity.

UI element name	Purpose	Display
	It is an abstract space in which the UI is configured and drawn. All UI elements must be children of Canvas.
	Area for grouping elements. May contain a background image or color.
	It is a graphic object loaded onto the stage, which can be used for level decoration, as a 2D game object, icon, etc.
	The Text component, also known as the Label, has an area for entering text that will be displayed. It is possible to set the font, its style and size. There are options for setting alignment parameters; horizontal and vertical overflow settings that control the behavior of text when it does not fit the width or height of the allocated rectangle.
	A button consists of an image and text, as well as a special button script. The text is located as a separate element inside the button. You can configure the button to appear in different states: normal state, hover state, click state, and button block state. Contains the button click event.
	This object allows the user to select one option from a list of options.
	This object allows the user to scroll an image or other area that is too large to fit within the specified frame.
	Uses to select numeric values ​​from a specified range.
	A complex component that includes an area for displaying content, a vertical and horizontal scrollbar for scrolling content within this area.
	It is a switch that allows the user to enable or disable an option. In addition, you can combine several radio buttons into a group in cases where only one of the options should be selected.
	Allows the user to enter text. Contains 2 events: text change and end of text change.

One of the main features of the Unity game engine is a convenient and fully customizable interface, which combines an editor of scenes, game objects, scripts, animations, and also provides the ability to instantly launch and debug the application or game being developed. In Figure 1.3. A screenshot of the editor window is shown. All resources and objects can be moved using Drag-and-Drop methods.

Rice. 1.3. Unity editor window.

The tabs used in the editor window are described in more detail below:

1. Scene View. In this window, you can navigate around the game world, move and rotate scene objects, and also change their scale.

2. Game View. Represents an image game world, drawn from the installed camera. Here you can see what the game will look like for the player. You can also launch and test the game.

3. Project Window. In this window you can work with all project resources: images, fonts, scripts, saved objects, scenes, etc. Unity supports a huge number of different media formats.

4. Hierarchy Window. Represents a hierarchy of game objects located on the current scene.

5. Inspector Window. Allows you to view, change and delete properties\scripts of the currently selected object. And also add new properties\scripts to the object.

6. Toolbar. Contains tools for transforming game objects in the Scene View window, Buttons to start and stop the application in the Game View window, a Layout drop-down menu that is responsible for the arrangement of windows in the editor.

7. Console Window. Provides output to the log of messages, warnings and errors.

Unity also has the following benefits:

1. Openness of documentation. Unity comes with complete documentation and examples for every engine feature that you can refer to at any time.

2. Developer community. Unity has an active online community ready to help new users. Also, Unity Technology developers often listen to users and add new features to the game engine based on their requests. In addition, there are many official and unofficial video courses that help you understand aspects of game development using this game engine.

3. Cross-platform. The same code written in the Unity engine can be transferred to various platforms (PC, Mac, Android, iOS, Web, game consoles) with minimal changes. This is a huge plus, which reduces the time for game development by several times.

4. Asset Store. Unity has its own store where you can find a huge number of different plugins and resources for creating a game. Of course, some of them are free, some are paid, but they are all collected in one place with easy search and the ability to download, integrate and immediately get working functionality.

The Visual Studio 2015 environment was chosen as a tool for writing program code. In this work, Visual Studio is used as the best alternative to MonoDevelop, which is presented by default in the Unity game engine.

The high-level programming language C# was chosen as the programming language.

1.6 Analysis of analogues

During the research of the subject area, the only currently working analogue of the computer implementation of the board game “Evolution” was found. The interface of this analogue is shown in Figure 1.4.

Rice. 1.4. User interface of an analogue game.

This analogue has the following advantages:

? A game mode is available against 1 computer at 3 difficulty levels. In this version, the complexity is manifested in providing a “head start” to the computer (the computer plays one round without the participation of the player, after which the player joins);

? 1 vs 1 network mode available;

? Design mode is available, where you can test the interaction of various properties;

? clear and intuitive user interface based on point-and-click;

? there is a record in the game process log of all the moves of the player and his opponent;

? the ability to view the code (an array containing the parameters of the current game: the number of cards in the deck, the turn order and the list of cards in the players’ hands);

? It is possible to look at the cards in the player's discard pile.

This analogue has the following disadvantages:

? the game is located on the VKontakte social network, which makes it impossible to play without an Internet connection;

? The presented game, in addition to the usual set of cards, contains cards from the “Time to Fly” add-on, which causes dissatisfaction among players, since there is no choice of a set of cards.

Let us highlight the main criteria for comparing the analogue and the game we are developing (see Table 1.17.):

1. Is it possible to run the game offline against a computer?

2. Is it possible to play online via the Internet?

3. Do the game rules match the original game?

4. Is it possible to select the number of players?

5. Is it possible to change the computer difficulty level?

Table 1. 17. Comparison of the criteria for the game of the analogue and the game being developed.

Based on the current results, we can conclude that the game being developed will be improved in the sense that it will allow you to play without an Internet connection. And there will be the ability to select the number of players, from 2 to 4. Thus, this analysis helps to identify the advantages and disadvantages of an analogue game and evaluate the competitive advantage of the game being developed.

1.7 Chapter Conclusions

As a result of the analysis of the rules of the board game “evolution”, an algorithm was presented in the form of block diagrams, describing in detail the stages of the game process. Functional requirements for the system from the point of view of the rules of the game were developed. A diagram of use cases is constructed and the main and alternative order of system actions when initializing a use case by a player is described. Conducted short review capabilities and advantages of the Unity game engine. The pros and cons of the found analogue are considered and the advantages of the game being developed are determined.

2. Game design

2.1 Design model

During the object-oriented analysis, classes responsible for the functionality presented in the precedent were assigned to each use case. In table 2.1. shows the correspondence between precedents and game classes, as well as a brief description of these classes.

algorithm interface file user

Table 2.1. Correspondence between precedents and game classes.

Precedent	Class name	Class Description
Create a new game		Responsible for displaying UI elements on the screen and user interaction with them.
		Responsible for loading screens.
Set parameters		Static class for storing game settings.
		The main class of the game implements game logic and manages all processes and elements in the game, and also allows you to save and load the game.
Continue game
Finish the game
	PlayerController	Responsible for initializing players. Controls the turn order.
		Responsible for the transition between phases of the game.
Get cards		Stores information about the type of player, his cards in his hands, on the table and in the discard pile.
		Responsible for storing and displaying cards in the player’s hands.
		Represents a deck of cards.
		Responsible for storing and displaying cards in the player’s discard pile.
		It is a card with two properties depicted on it.
		Stores information about the property shown on the map. The name, description and image of this property.
Win
Lose
Skip turn
Make a move
Place a card in the shape of an animal
		It is a card on the player's table, placed in the shape of an animal.
Place card as property
		Responsible for storing and displaying cards “on the table” of the player.
		It represents a card property located on the player’s table, as a sign of a specific animal.
Take a food chip
		Responsible for generating, storing and displaying food chips during the feeding phase.
		Represents a food chip of a certain color (Red, Blue, Yellow) that is used when feeding the player's animal.
Apply property
		Responsible for processing the selected property and displaying the result on the playing field.

2.1.1 Game architecture

Visualization of game logic is implemented using class diagrams. This diagram consists of two parts: the first part is the classes that describe the display of game objects, the second part of the classes describes the game logic. These classes are connected using the EvolutionGame class, which is responsible for the game process and intercepts events from other classes of the system. A class diagram representing the game architecture is shown in Figures 2.1. - 2.3.

Rice. 2.1. Class diagram. Part 1.

Rice. 2.2. Class diagram. Part 2.

Rice. 2.3. Class diagram. Part 3.

2.2 Graphical user interface development

2.2.1 Interface structure

Based Based on the data obtained as a result of analysis and design, a graphical user interface structure was developed, which contains connections between the main game screens and modal windows called up on these screens. This diagram also contains the names of the events that initiate the call of these windows. The interface structure is shown in Figure 2.4.

Rice. 2.4. Interface structure.

2.2.2 Main menu

Main menu ( see fig. 2.5.) of the game consists of the game name, background image and 3 buttons: “New game”, “Continue game” and “Exit”. When you click on the “New Game” button, a modal window for setting up game parameters opens (see Fig. 2.6.), which contains switches for selecting a set of cards (the basic set is set by default and is not available for selection), selecting the number of players, as well as a button “Start game”, when clicked, the playing field will load.

Rice. 2.5. Main menu

Rice. 2.6. Window for setting game parameters.

2.2.3 Game screen

Screen The game consists of 2 areas: the front area and the playing field. The front area (see Fig. 2.7.) contains a top menu with buttons: “Show/hide game log”, “Save game”, “Exit to menu”. Also in the upper part of the front area there is a window with the game log, notification text and information about the current phase in which the game is located. At the bottom of the front area there is a panel with cards “in the player’s hands”. This panel can be collapsed and expanded by clicking the mouse. When you double-click on any animal card, it is scaled to the center of the screen (see Fig. 2.8.).

Rice. 2.7. Frontal area.

Rice. 2.8. Detailed map view.

The gaming table (see Fig. 2.9.) is located in 3D space and contains 2 areas: the player and the opponent. These areas are used to place cards of animals and their properties. Between these areas there is a food base with food chips. Also on the gaming table there are buttons for selecting players, a deck indicating the remaining number of cards, and a “Reset” button, when clicked, a modal window opens containing cards of animals that died as a result of the extinction phase.

Rice. 2.9. Game screen. Gaming table.

2.3 Implementation of the interface in the Unity environment

To implement game levels and the main menu, Unity uses the scene mechanism. A scene in the context of Unity is a kind of container in which various game objects, sounds, lighting, and user interface elements can be placed.

Based on the designed graphical interface, 2 scenes were created in Unity:

· “Menu” - represents the main menu of the game.

· “Game” - represents the gaming space where the entire gameplay directly takes place.

All scenes, just like any other resource, are saved in the Assets folder of the project and can be opened in the editor window. In Figure 2.10. shows the saved scenes of the project.

Rice. 2.10. Project resources - game scenes.

Cameras are used to capture and display objects in the game space. The camera can be installed in two modes: orthographic and perspective. When using an orthographic camera, the image of objects does not decrease as the distance increases. This mode is used to create two-dimensional and isometric worlds; in all other cases, a perspective camera is used (see Fig. 2.11.).

Rice. 2.11. Camera settings in the Unity editor.

To create the game, it was customary to use the UI system of the Unity game engine. All UI elements are located on a canvas (Canvas), which determines the placement of 2D objects in the game space. The Render Mode property is responsible for this, and contains the following values:

Screen Space - Overlay. In this mode, the canvas is scaled to fit the screen and drawn without connection to the scene or camera (the UI will be drawn even if there is no camera on the stage). If the window size is changed, the canvas will be stretched to fit the screen size. The canvas will be drawn on top of all other graphic elements.

Screen Space - Camera. In this mode, the canvas is drawn on a plane perpendicular to the camera's view, at some distance from the point of view. The size of the canvas does not change with distance; it is always scaled to fill the camera frustrum view. The interface will be obscured by any 3D elements that are in front of the interface plane.

World Space. In this mode, the canvas is located in world coordinates and is a flat 3D object.

2.3.1 Main menu

On the image 2.12. the main menu scene and the hierarchy of objects located on this scene are shown. The canvas on which the UI elements are located has the RenderMode property set to Screen Space - Overlay. Elements such as: ParamsWindow, ExitConfirm, ContinueGame are modal windows and are in an inactive state by default.

Rice. 2.12. The Main Menu scene and the hierarchy of game objects

MenuManager is an empty GameObject containing a class for managing menus.

Settings - an empty GameObject containing a class with game settings. This object is passed when the game scene is loaded in order to have information about the selected settings.

2.3.2 Game screen

On the image 2.13. The “Playing field” scene and the hierarchy of objects in this scene are shown. Elements of the frontal area are located on the canvas with the Render Mode property equal to Screen Space - Overlay, this means that the display of these elements does not depend on the camera. The playing field is a canvas located in 3D space and rotated at an angle of 30 degrees relative to the camera. A perspective camera is used to display this scene.

Rice. 2.13. The “Playing Field” scene and the hierarchy of scene objects.

A general representation of the game scene, how it looks to the player, is shown in Figure 2.14.

Rice. 2.14. Debugging the “Playing Field” scene.

2.4 Game save file structure

The save file must be presented in an easy-to-read format and contain information about all current game states:

· current game settings;

current phase of the game;

· current right of movement;

· cards in the hands of players;

· animal cards located on the players’ table;

· animal cards that are in the players’ discard pile;

· properties and connections between animals;

· information about the properties used;

· information about fed animals;

· number of food chips in the food supply;

· cards in the deck.

The JSON format is most suitable for describing this information. JSON (JavaScript Object Notation) is a simple data interchange format that is easy to read and write for both humans and computers. The approximate contents of the file are shown in Figure 2.15.

Rice. 2.15. Game save file structure.

2.5 Designing computer behavior

To create an algorithm for the behavior of a computer-controlled player (hereinafter referred to as a bot), a mechanism based on a random number sensor was designed. Each bot action is determined based on incoming conditions, such as: the current phase of the game, the number of cards in hand, the number of animals on the table and their properties, as well as the value obtained as a result of using a random number sensor.

All actions have a certain probability, this is done so that the bot, for example, does not miss the progress of the game without having time to place several cards on the table and thereby simplifies the task for the player.

Similar documents

Development of a computer game "Evolution" using the Unit game engine. Comparison of the criteria of the analogue game and the game being developed. Graphical user interface development. Camera settings in the Unity editor. Game save file structure.

thesis, added 02/11/2017


Exploring basic application programming concepts operating system Windows. Studying the history of the creation of the universal programming language C. Graphical user interface development. Review of the rules of the game and the operating algorithm.

course work, added 11/09/2012


The concept and evolution of games, analysis of their various genres and existing analogues. Selecting software to implement the game, writing a plot and choosing a game development environment. Algorithms for making educational games flexible. Description of software modules.

thesis, added 10/27/2017


History of the development of the Java programming language. The history of Tetris - a cult computer game invented in the USSR. Rules of the game, features of scoring. Creation of the program interface, its implementation in the Java environment, coding, testing.

course work, added 09/27/2013


Features of creating a series gaming applications, logic game. Software the simplest calculator, function generator. Development of interface elements for a simple graphic editor, electronic notebook, text editor.

training manual, added 10/24/2012


Description of the computer progress algorithm in the "user-computer" mode in the game "Battleship". Description of a set of classes, their fields and methods. Development of an interface and user manual for the game. Listing of a program written in Java.

course work, added 03/26/2014


Justification of the need to develop a program for the game "Tetris". Mathematical and graphical parts of the algorithm. Choosing a programming language and environment. Debugging program text, developing a user interface. Testing, user manual.

course work, added 01/17/2011


Study of the general rules of the game of checkers, user and programmer instructions. Characteristics of the main algorithms that perform tasks of the Life Widget class. Evaluating computer and human moves. Construction of a search tree for the best move based on function evaluation.

test, added 12/20/2012


Features of programming arcade games in the Python environment. Brief description of the Python programming language, its features and syntax. Description of the computer game "Tanks" - rules of the game, explanation of key lines of code. Demonstration of the program.

course work, added 12/03/2014


Study of the specification of the logic game "Mineweeper". System and functional application design. Development of software modules. An overview of the classes required to create the interface of this application. Tools for implementing a logic game.

Use case diagrams partially describes a use case - a precedent for using the designed system, giving partial description partial application of the system from the point of view of a conditional external observer (behind which, ideally, is the agreed point of view of the participants in the work). In this case, the description focuses on What the system must do in relation to its external environment (periphery), and not on that How she does this.

In other words, the diagram is partial specification.

Let us recall that in the approach under consideration, identifying the main (but not all possible) precedents at the initial stage of development plays a key role, which distinguishes this approach from a purely algorithmic one. In this case, successful scenarios (options) are usually considered first.

Note that in the case of fairly large software systems, we do not use the term “algorithm”, for example - it is inappropriate to talk about “text editor (text editing) algorithm”, etc. The reason is clear - in complex cases we can reliably describe (analyze, check, etc.) some branches top-level algorithm, but not the complete algorithm itself, which assumes a complete description of all possible branches.

In other words, the script is partial algorithmization.

Example. Registering a patient for an appointment at the clinic.

This simple example assumes something like the following hidden use case scenario behind it (it is natural to make it a comment on the name of the use case):

"The patient calls the clinic to make an appointment with a doctor for preventive purposes. The clinic registrar finds the nearest free period in the registration log, coordinates the time with the patient and records it in the log"

Make Appointment (coordinate an appointment [with a doctor]) – the name of the precedent. Patient (patient) – the role of a person. The connection between an actor and a precedent is an association of communication (for short, communication is in the form of messaging)

Example 2: Clarifying the previous diagram (by expanding it).

The second diagram shows more details of the situation. New actors appear here: Scheduler - registrar, Doctor - doctor, Clerk - employee, and new precedents CancelAppointment - cancel an appointment, RequestMedication - request treatment and PayBill - pay a bill.

Large UML modeling frameworks have versioning capabilities. In this case, we can consider a view to be a group of diagrams related either to latest version, or to everyone. The second is obviously preferable.

Already the very first example poses before us “the main question of all times and peoples”: “Well, why do I need these precedent diagrams?” An even more popular option: “Who needs them anyway - all these diagrams!” During the learning process, it is better not to hide it within yourself, but to redirect it to yourself, paraphrasing and specifying it. To whom exactly and when exactly and for what exactly are they useful?

The programmer, of course, will see for himself the possibilities of software implementation - the outlines [architecture, structure] of the future program. To understand other possibilities, you just need to imagine yourself in a different role. As a client – ​​to evaluate the usefulness of using the system in your work. In the role of customer and director - when discussing the task. In the role of a tester - when preparing tests for running certain branches of the software system.

The moral is old - it is useful to take the place of another, to look at the world through his eyes.

But let's look again at a specific example. Why is such clarification necessary? For a person familiar with the subject area (domain) - in this case, the health care system - this diagram does not new information. For him, it is already implicitly contained in the first precedent and can be derived from it. However, firstly, not all people are equally familiar with this domain. Secondly, they may have different opinions both on the domain itself and on what features of it should be reflected in the system being developed. Finally, we may simply forget in the future what we agreed on.

Simply put, to understand the need for diagrams at all, it’s enough to imagine yourself as just a person who doesn’t know everything, doesn’t remember everything, doesn’t know how to do everything, etc. In short, it would be nice to be more modest...

Description of communications. Sequence diagrams [system] - sequence diagrams

Sequence diagrams of some system of objects - a model artifact (part of the documented description) of use cases used for partial description behavior some system of objects in the form of possible, main (successful) and alternative scenarios.

The main purpose of such diagrams is to display events transmitted by executors to the system across its boundaries. Each of them gives a schematic description precedent scenario as a sequence of events generated by external actors - and compact, visible(for analysis, control, etc.) description of events generated within the system itself. In other words, the diagram tries to answer the question: “what main events are initiated from the outside” rather than how exactly the system reacts to external signals. Not exactly and completely - only to the extent possible.

Let us note here a new interpretation of the old behavioral approach (behaviorism, from behavior), which is basic for cybernetics. The structure of the system is important - but Not in itself, but only insofar as it ensures the desired behavior, the correct reaction to external signals. It is not so important how the system is designed - what is more important is that it imitates the desired behavior. Device of various so-called “smart” machines “virtually” - this applies to both real and virtual machines. Simply put, it should not and cannot resemble the real thing. And the behavior is real.

In cybernetic terms, all internal subsystems (related to the description of objects of a given system) are considered as a “black box”, and the system itself is considered as a translucent, or “gray box”. As before, what is outside the box is considered to be related to logic, inside the box - to implementation of the system(hidden in the structure of the box - whether it concerns the definition of the structure of the data associated with it or the methods). In the “transparent” case, we mean the implementation of the highest level.

Recall that classes and objects in OOP describe—at a more or less abstract level, respectively—a static representation of a model. They contain an indication of methods - a named reference to the definition of rules (algorithms) potential behavior of objects, while hiding the actual behavior of objects in relation to each other. Simply put, they answer the question “how can [one] given object behave” rather than the question of how objects behave—together, as a whole.

The behavior of a system of objects is considered here as a coordinated interaction of objects, recorded in the form of a time scale of execution of message sending methods - a message trace. The passage of time is displayed by the coordinate “from top to bottom”, objects sending messages (sources) are to the left, receiving messages are to the right (message receivers). If possible.

From procedural programming, we are very familiar with the concept [state] traces, which describes the actual behavior of an object in the form of a sequence of changes in its states. In this case, each of the states is described in the form of a named set of variable values ​​- characteristics of the state of the object at a certain point in time. The imperative (command) management model implies that someone(top-level executor) commands changes to a subordinate object, calling procedures associated with it in accordance with some rule - an algorithm, a program for changes to a subordinate object. Call track– and there is a branch of execution of the algorithm, represented as a sequence of names of the corresponding procedures.

In this case, we are again talking about the call path - more precisely, about the path of messages initiating such calls. But in a more complex case of a system of objects that change (through calling a method of the source object) the states of the receiver object (and also, possibly, as a side effect, the states of other objects). A change in state is now interpreted as “an event in the life of an object.”

There are still external objects that initiate internal messaging processes, but in more complex cases there is no single main “commander” and no hierarchy of subordination.

Example. Hotel reservation.

message

The external object that initiates the message flow is the Reservation window. The Reservation window object sends a makeReservation() message to the appropriate HotelChain service. That, in turn, forwards the makeReservation() message to the Hotel. If the hotel has available rooms, the Hotel object calls the Reservation and Confirmation methods.

Each of the dotted vertical “lifelines” represents the event-filled time of the potential existence of some object - in the form of changes in the states of other objects and changes in its own states. Each arrow describes a call to a method for sending a message. The arrow goes from the sender to the receiver of the message, highlighting the activity bar (message processing period - activation bar) on the time coordinate.

In the diagram, the Hotel object calls itself (self call) to determine the availability of a room. If the IsRoom condition is true, Hotel creates Reservation and Confirmation objects. The asterisk on the available call means iteration - a cyclic call (in order to find out whether the room is available for all days of the guest's expected stay). The expression in square brackets means a condition (predicate).

The diagram also includes an explanatory comment in the form of text on a rectangle with a curved corner - possible and, in any non-obvious case, necessary for any other UML diagram.

Diagrams of cooperation (interactions) –

collaboration diagrams

Collaboration diagrams, like sequence diagrams, are diagrams that describe interactions. They contain the same information as sequence diagrams - but from a different perspective, focusing not on describing the communication processes between objects (in the form of a sequence of calls), but on defining the role of objects as a source and receiver of messages. In a word, here we are trying to answer not the question “how” communication actually occurs, but Who and to whom messages can be forwarded.

Example. Same thing - booking a hotel room.

an object

message

Rectangles representing object roles are labeled with the name of the class and/or object (in the latter case, the class name is separated from the object name by a colon). Messages on the cooperation diagram are numbered. In this case, lower-level messages - sent during the processing of a certain message - are numbered with prefixes separated by dots from the message number top level– in accordance with the sequence of these calls.

In other words, in this well-known way (linear tree notation) the fact of the following or nesting of message processing processes hidden here - one into the other - is encoded. As before, they cannot overlap.

Description of the structure. State diagrams. Statechart diagrams.

State diagrams, or automata diagrams, are perhaps the most familiar to us. Or rather, must be we are familiar with - at least from the introductory course of discrete mathematics.

Let us recall the general provisions. A finite state machine is a model of a possible response (in the form of a direct and reverse reaction) of a modeling object to external events - changes in the external environment (surroundings, periphery, situation, context, etc.)

The concept of an automaton is central to understanding the logical diagram of the functioning of a computer as a device that performs step by step one and only an operation (like any other) that simulates an application operation (applying a function to an argument). Implicitly, the concept of an automaton lies at the beginning of basic programming concepts - for example, the treatment of programs as converters of streams and/or sequential files. But in this case, we should remember earlier concepts. Not about computers or programs, but about the equally famous dog of Academician Pavlov...

In general, the machine reacts to such changes in the environment

• clearly determined by a change in the state of its internal structure, invisible from the outside and hidden inside it; Such internal states are named but not described in automata theory.
• a change in the state of the environment - implicit, since the presence of such states of the environment is implied, but the states themselves are not determined.

Feedback is a change in the behavior (internal state) of an automaton that occurs (indirectly) as a result of its own actions to change the environment.

Explicitly defined communication automaton with environment, in the form

• set of possible input and output messages. Their role in the theory of automata is played by elementary signals, letters (in OOP, of course, objects).
• two functions (or one operator) that determine, based on the current input message and internal state, the output message and the next internal state. Respectively called the exit function and transition function.

If When) there are no input messages, the machine describes source(or sender) of previously prepared output messages. If When) there are no output messages, the automaton describes the receiver (addressee, recipient) and the output message handler.

• input - typing on the keyboard - [presumably] a valid (active, correct) general user identifier - like a passport number; in this case, this is the social security number of the client SSN (social security number),
• entering a [presumably] valid personal identifier of the user as a client of this bank PIN (personal id number)
• sending this information for validation.

The description of possible [internal] authorization states begins with the name. Getting SSN - get SSN, Getting PIN - get PIN, Validating - check and Rejecting - refusal, if the default scenario fails. Next, transitions from state to state are defined, for every couple states and all possible combinations messages.

What is described in set theory in terms of the fundamental concept Cartesian product sets.

A significant difference between state diagrams in UML (compared to classical automata theory) is the ability to describe structural states, i.e. states that are themselves systems. The subtle point here is the passage of messages across system boundaries. The contours of the UML approach adopted here are outlined by us when discussing the concept precedent.

But the capabilities of languages ​​are always determined by the need to solve some problem, and before “getting inside the box (black or gray),” it’s worth thinking about which one? The classical theory of computational complexity defines an “information explosion” - an abundance of information that a person cannot manage (manage) in terms of exponentials (for example, 2 n). Which is beyond doubt, but... In programming practice, polynomials (in this case, at least n 2) are already in the general case not manageable - not controlled, analyzed, verified, etc. To look chaos in the face, all you have to do is imagine a machine with 50 states. It seems not much... if not for 2500 possible transitions.

This concerns any diagrams - binary and other graphs, regardless on the interpretation, the type of description task and the method of solving it. I hope that now it will become much more substantive for us not only to understand the origin of UML, but also all other structural methods in programming and, in general, the purpose of mathematical formalisms. And you said - “an empty abstraction, divorced from life”... Whose life? - Not from the life of a model descriptor.

Let's pay attention to interesting feature example. Authorization is not a thing (physical object), not a system of such objects, but process. And at the same time, of course, it is the object of our current attention and description.

Activity diagrams –

activity diagrams.

Activity diagrams are, in essence, well-known flowcharts with a number of features that reflect a change in the procedural approach under the influence of OOP and those ideas of partial descriptions that we associated earlier with the iterative approach.

In particular, the interpretation of algorithms as a cumulative description of many successful and unsuccessful use case scenarios - in complex cases, described only partially at each stage of development.

The most noticeable differences are visible in the following example.

Example. Scheme of operation of an ATM Machine for servicing a client (Customer) of a bank (Bank).

As before, conditions (predicates) are represented by diamonds, methods ([custom] operators) by rectangles with rounded ends.

A guard condition is interpreted here as a check for whether an incorrect course of events should occur - i.e. bad scenario. Essentially, the need to handle a logical exception (caused by a failure of “logic time”, not “execution time”).

Swimlines separate the “swimmers” - the objects whose methods are executed. As can be seen from the example, in fact they are interpreted here as subjects of activity, performing some general work.

In sharp contrast to the early imperative and later procedural approaches. In the first object performs command, in the second – actions are being carried out. In both cases - without an explicit indication of the subject (actor) initiating (starting, activating) the action (operation). Flowcharts (i.e. flow diagrams) express the flow of control transfer - with an implicit control subject and an explicit control object. In this case, it is more appropriate to talk about subjects - within the framework of the distribution and transfer of powers and responsibility for this or that part of the work.

Continuing the analysis of these cases, we can allow two interpretations of the example, depending on the specific subject area.

· The ATM and the bank together constitute a server system that performs work for the initiating client (actor) - who has priority, reflected in the order of subjects.

· All subjects perform some common work, pursuing the interests of mutually beneficial cooperation. The client initiates the work not because he has absolute priority - but only because “this time someone still has to start first.” In other words, in other diagrams a different order of arrangement of subjects is possible.

Of course, the first interpretation, characteristic of modern “client-server” approaches, is more suitable for this subject area.

We are accustomed to viewing such diagrams as complete descriptions. But in the context of the approach under consideration, there is another important interpretation of diagrams, based on the capabilities of the descriptor. It can be assumed that we are at that stage of development when the relationships between the subjects have not yet been determined or are unknown to us. Somehow(for now) need to be described.

An immediate consequence of the “division of labor” that arises here between several actors is the need to coordinate the emerging parallelism in the execution of actions. In the diagram, such coordination is indicated by a new type of branching - fork and join of processes.

Parallelism is an extremely complex topic, subject to many interpretations. In the context of the need to describe the subject area, it is natural to continue the topic of division of labor between subjects based on the need to achieve a common result. In this "multi-processor" version, the order of actions is not important.

Based on the capabilities of the descriptor, a different interpretation is possible. We know that this process must begin at some point and end at some point. But [yet] we don’t know exactly the order of actions.

The task of describing the subject area.

The domain model displays conceptual classes - the main, from the modeler’s point of view, classes of concepts related to the subject domain (not to the software implementation).

In the case of business modeling - the activities of large enterprises - they usually talk about business logic, business modeling, etc. In UML, a domain model is represented as a set of class diagrams , on which properties and methods are named, but in general are not implemented. In other words, whenever possible, class interfaces are defined.

Formally speaking, in the approach under consideration, the construction of class diagrams in its basic principles differs little from that adopted in “regular OOP”. The most significant difference comes from the motives for the division of labor discussed above. If possible, the programmer complicit in the previous stages, but answers for the software implementation stage. Inside it, he is free to allocate classes based on the need to solve internal problems of software implementation - within the framework of his role, he cannot do this. Domain classes are defined by the realities of the domain.

True, in the proposed approach this no longer means unilateral subordination - as urgently necessary, it (occasionally) - as feedback(feedback) - may ask to change the task due to the impossibility of completing the task under given conditions - for example, with given time resources (i.e. on time).

Let us recall (as food for thought) that historically the concept of a feedback loop appeared in cybernetics (more precisely, in automata theory) precisely in connection with the need for a formal description of the complex behavior characteristic of alive creatures But not real machines, the most common (due to simplicity) examples in today's programming literature.

The domain model displays:

· domain objects or conceptual classes;

· associations between conceptual classes;

· attributes and operations of conceptual classes (names of properties and methods).

Example of a class diagram. Order payment scheme.

The example implies approximately the following (successful) payment scenario for an order by a client of a certain trading and transport company: “The client who ordered a list of goods (see item - characterization of the properties of the goods in a separate point of the order) can pay for the order with a credit card (credit), cash (cash) or bank check (check)"

Please note that class diagrams, in addition to the classes themselves, describe in the form of a graph a variety of real connections (associations) between classes.

In other words, when describing the structure of classes, we use the theory of sets and relations (relation). relational the approach we considered earlier when mastering relational databases. Let us note here the possibility of indicating the multiplicity of relationships, which describe more precisely (in comparison with “one” and “many”) how many objects (instances) of one class can be in a given relationship with another class. 0..1 - no more than one, 1 - exactly 1, 1* - no less than one, etc.

Some confusion here usually comes from the variety of types of connections. Here, association is any possible connection between classes, regardless of what further relationship between objects it implies.

Some of them - as before - relate to the description of the data structure. These are, for example, the Customer-Order relationship and the “part-whole” relationship (aggregation, aggregation relationship) between the Order and OrderDetail classes.

Others (generalization) - to describe the relationship of classes by inheritance. See the example for the relationship of the Payment class with the Cash, Check and Credit subclasses. This is a static (fixed) connection between classes, implying the possibility dynamic(changeable) connection between object and class. At each moment in time, an object is assigned to some specific class - but then this object’s affiliation can change. This is what actually distinguishes the concept of a class in OOP from a type in procedural programming.

Bookmarks for the future. In addition to “just connections,” a peculiar feature of UML is the ability to define other, custom types of connections, as well as group classes into packages- for reasons other than those we discussed earlier. Including the future, still unknown to us.

Usually packages (as well as initially modules and components) are associated with solving special problems of processing programs as data (for example, compilation), but we are free to use them for some other, original reasons (if they are truly original).

Object diagrams. *

Object diagrams are used much less frequently than class diagrams. In fact, we are descending here to the level of software implementation. It is useful to use them when a graphical representation helps to draw the attention of development participants to those features of the implementation that are difficult to recognize from the text of the program.

As an informal motivation, it is easy to imagine the temperature in the team when a programmer returns from vacation, having not dedicated his colleagues to the specifics of the implementation. As you know, according to Parkinson’s law (also known as the law of falling sandwiches), the need to correct program code occurs precisely during the absence of the programmer who wrote it! In any case, such examples will be remembered for a long time...

Example 1: Recursive Relationships

Here we assume a hierarchy of classes describing departments of the university.

Example 2: Inherited static links.

mathStat, math, statistics, appliedMath, mathEd – objects, references to the Department class

Probably a more complex and important example is the description of the not always obvious possibilities of changing in a program the belonging of one object to various classes– regarding the inheritance hierarchy.

Component Diagrams and Deployment Diagrams –

Component and deployment diagrams

Component[software system architecture] – a module, part of the [text] of a program, traditionally associated with automation, algorithmic processing of program code (programs as data). When using UML, they are treated as physical analogues of class diagrams and are described in a similar way. In other words, component diagrams are a formal analogue of class diagrams, intended to describe software architecture and the structure of a software system.

And in this capacity, they are not so important for an application programmer. But let us once again pay attention to one important point. We are accustomed to the fact that programming tasks are set by the customer - set from outside programming. But, undoubtedly, a very large part of the tasks arises within programming itself - whether they concern software or hardware, the software or hardware part of it. Thus, modules were initially treated more as units of compilation (assemblies) - but paved the way for object programming as universal modeling method. What in modular programming is treated as a named constant (the module name denotes a fixed interface and its implementation), in object programming becomes the name of a variable (the object name denotes a variable interface and implementation).

In component programming, the concept of components goes even further and has a clearer definition. Simply - a named, but [yet] not implemented interface. Having been born in an environment of purely system problems (it is especially important here to remember the problem of version support), it becomes a solution tool here any tasks (of increased complexity).

Deployment diagrams are intended primarily to describe physical configuration(architecture) software and hardware. Thus, the following example shows the relationships between the software and hardware components of a real estate transaction processing software system.

Example. The physical environment to support the sale of real estate.

Here Real Estate Server and Bank Server are the servers of a real estate agency and a mortgage bank that provides a loan to its client (customer) in response to his application (application). PC is a client computer that allows the user of the software system we are developing to make requests to both the bank and the agency, in accordance with the list of offers available in its database.

Hardware devices are represented by nodes. Each software component is associated with a node and is represented in the diagram as a rectangle with a double loop in the upper left corner. Highlighted with a separate icon (circle) interface– a set of service functions (support capabilities) provided by the corresponding systems to the client.

The conceptual understanding of the term is transparent. The client cannot know the complex internal structure of the systems (although he should know that it is complex and therefore appreciate the work of the developers). Furthermore. Not being a highly qualified specialist, he should not interfere with their functioning - even when there is a reason for this physical ability. This gives an indirect definition of moral boundaries, an honest client and simply - cultured person. Not a hacker.

However, for the normal functioning of the entire system, he has the right to gain access to the interface - a description of which he, most likely, knows only in the form of a user manual in informal text or graphic form, i.e. on ordinary human language. Simply put, someone still needs to explain to him the basics - “what, how and why.”

In fact, the only significant innovation here is the special designation of the symbol for interface, considered separately from its software or physical implementation (see discussion above). Apparently, the Unified Modeling Language still needs further unification. Well, all people are people, including the creators of modeling languages.

But I would not like to end our review of UML with this, but with an appeal to the reader.

1. Conceptualization of the system: The idea behind the app is a memory development game.

2. Analytical model is an accurate, clear representation of the problem that allows you to answer questions and build solutions.

3. Design model is the implementation of solutions to problems understood at the analysis stage.

Brief description of the game: figures of various shapes and colors appear on the screen, the player clicks on the last appeared figure, if the choice is made correctly, a new figure appears. The essence of the game is that the more figures on the screen, the more difficult it is to make a choice.

Complexity. The game must support standard difficulty options (for example, easy, medium, hard). The user should be able to customize their game difficulty.

Levels. Regardless of the difficulty type, the game must support levels. Level determines maximum amount figures on the screen. Those. the number of figures is a function of the level.

Hints. If it is difficult to select a figure, the player can choose a hint.

Database. If possible, player information should be stored in the system.

Additional requirements. Everything must be done so that the game is scalable, i.e. the user could connect different difficulty options to his game.

We will use an iterative approach to develop the application. At the first iteration, we will implement only a small part of the requirements, as this will provide the earliest feedback.

Model of use cases, precedents

Let's consider precedents A game And Difficulty setting.

The main artifacts in use case modeling are use case diagrams, use cases, and use case sequence diagrams. Many newcomers to the field of OOA/P when modeling use cases focus only on use case diagrams, which inherently does not bring significant benefits. It is important to understand that charts only show names, names precedents, and not the precedents themselves.

Figure 1. Use case diagram

Let us remind you that precedent is a story about the use of a system by an actor, which can later be projected into use case sequence diagrams for greater clarity.

Identification of actors. The only active person is the Player. The player is not part of the system, because the system cannot control his actions, we can only expect a certain sequence of actions from the player.

Identification of initial events. Let's determine which events initiate precedents A game And Difficulty Setting. In this case, the initial event is a request for the corresponding services provided by the system.

Identification of end events. End events should also be defined. For the precedent Setting Difficulty, this will be setting the difficulty parameters of the game, everything is clear here. For precedent A game the situation is different: use case A game can continue until the game is won or lost. The final event of the Game precedent will be the event when the player gets tired of this service, i.e. exit the game.

Preliminary recommendations: only complete transactions that make sense to the user of the system should be selected as precedents. Although leading methodologists have already defined a style of writing precedents, this does not mean that we must strictly follow it (or not follow it just because of disagreement). Let's not forget that precedents answer the question “what”, and not the question “how”, i.e. There is no need to describe in the precedent how this or that result is achieved.

Precedent A game.

Precedent Difficulty setting.

Many colleagues may find it absurd to model such a small task. But that’s the beauty of it, that a small example only illustrates the principles without distracting us from the principles themselves discussed in this manual. Otherwise, if you get carried away by the game itself (the subject area), you may forget why we have gathered here today.

Now we'll design use cases into use case sequence diagrams. Although there is no such concept in UML, it will allow us to recreate a certain logical link in the reasoning for building models.

Figure 2. Use case sequence diagram A game

Figure 3. Use case sequence diagram Difficulty Setting

Application analysis

There is no need for domain analysis, because the application has no analogues in the real world. Let's analyze the application: we will highlight aspects of the software application that are visible to the user and reflect his point of view. But the analysis of the subject area can be carried out according to a similar scheme.

Application class model.

One of the artifacts of application analysis is class diagrams. applications. This means that in models it is not advisable to display classes that belong to the implementation level (lists, trees, etc. abstract data types).

Classes. We will highlight precedents as a source of potential classes, but this is not the only source. Typically classes correspond to nouns. For example, from the sentence - the system (screen) displays the figure, you can select potential classes System(screen), Figure.

Problem: One part of speech may flow smoothly into another. Don't agonize over the question for too long correlation of keywords with a list of potential classes. Class models will be refined over time, and it is most often impossible to build an absolutely correct model right away. Although this does not mean that this is a useless activity.

Let's select potential classes for our example: player, game, figure, difficulty, level, ellipse, rectangle.

Comment: generally speaking, for each use case you usually have to build your own class model. But since the application is small, we will build a single class model for both use cases.

Properties. Let's define the properties of the classes. Properties are concepts that do not have their own identity. In this case, for example, the color of the figure (but if we were building a graphic editor, the color would most likely have such individuality). Such properties can be found in the list of potential classes.

A common mistake when isolating properties is writing to the properties of object classes that are complex objects. For example, you can as a class property a game indicate difficulty, but class complexity has its own unique behavior, individuality is important to it, so it is better to connect these two classes with each other through association.

Comment: If you are building an application or domain model, then you should also not specify an internal identifier as properties. This kind of attribute has no meaning in the real world, but only brings convenience for implementation.

Associations. Next, we will establish connections – associations – between the selected classes. Connections can be extracted from the same precedents, verbs are potential communications. In other words – as before – the problem of understanding words in natural language in one capacity or another remains.

For example, a game is defined by its difficulty.

Figure 4. Application class diagram

There are two associations in the diagram - the game is determined by difficulty, the figure is determined by the complexity.

Knowing the Design Pattern Low binding, I see a potential mistake that one of these associations is superfluous, but which one I will decide at the design stage.

Operations. When modeling classes, you can immediately identify the most obvious operations. For example, a figure can be drawn.

Recommendation: Generally speaking, the class diagram is built in parallel with the interaction diagram; the interaction diagram displays the messages sent between objects. A message is a call to a class function. So it is better to take class operations from interaction diagrams.

Generalizations. Next, we organize the structure of the class hierarchy by inheritance by identifying the general structure. The general structure can be distinguished among classes Ellipse, Rectangle etc. to class Figure. This generalization can be arrived at from two considerations. Bottom-up generalization: in a superclass Figure common features between classes must be defined Ellipse, Rectangle(coordinates, color, lifetime). Specification from top to bottom: let's select from the description of the game noun phrases consisting of various circumstances with the specified noun. For example, “rectangle shape” or “ellipse shape”.

Figure 5. Application class diagram with summary

Comment: perhaps this generalization will provide a point of further expansion of the types of figures displayed on the screen.

Summary: Class models are useful for more than just defining data structures. Tracing class models allows you to express certain types of behavior, e.g. precedents.

Application State Model

Another artifact of the application analysis phase is statecharts. State diagrams are required for domain objects that have non-trivial, including cyclic, behavior. Most classes in our case do not require the use of state diagrams; a list of operations is sufficient to describe them. For example, this is the Figure class - for this application it does not matter what state the figure is in.

Let us identify classes that have different states. For example, this is the class A game. This class can be in states Games, Victories etc.

Let's highlight the class states Games. To do this, let’s mentally imagine an object of the class A game, trying to understand the differences of this object in states Game, Win, Lose. In the Game state, the object draws a figure, but in other states it does not. In other words, the association between classes A game And Figure present in a state A game, and in states Victory And Losing this association is absent (thus the states Victory And Losing indistinguishable to me).

Due to the small scale of the example, it may seem that these models are not necessary. In practice, in this case, they can be attributed to software implementation, but here there is a desire to give an example of modeling a state diagram.

Event selection. After selecting the states, it is necessary to select the events that cause the transition between states.

· A signal event is the event of receiving or sending a signal.

· A change event is an event caused by the execution of a Boolean expression.

· A time event is an event caused by the achievement of an absolute time moment or the expiration of a time interval.

Change event Compliance with game conditions translates a class object A game from the state Games in a state Victory. Change event Failure to comply with game conditions translates a class object A game from the state Games in a state Losing. Thus, different events bring the object into different states.

Events are points on a time line, and states are intervals.

Figure 6. State diagram for a class A game

Events can also occur within states, but these events do not cause transitions between states. For example, in the Game state, the events of drawing figures and the events of the player choosing a figure occur.

The state diagram of an object is an automaton (graph), the vertices of which are states, and the edges are events.

Summary: this concludes the process of analyzing the application domain. After this, the resulting models should be reviewed again and adjusted if necessary. The main purpose of the analysis is to identify the problem without giving any particular advantage to any implementation option.

Application design

System design is the choice of a high-level strategy for solving problems.

Application interaction model

Let's return to precedents, because interaction models are built on precedent models. Artifact sequence diagrams of precedents answered the question “what”, in this section we will construct sequence diagrams that answer the question “how” when solving problems of the Game use case.

Let's turn to the Game use case scenario, which is initialized after the event of the Player launching this service.

Initializing the game. According to design patterns, a controller class is needed that will take over the “fire” of events from the user. Let the Game class be responsible for starting the game.

Creating a figure includes a sequence of actions: randomly determining the parameters of the future figure and creating the figure according to the parameters.

Determining the values ​​of the attributes of the future figure. Since a figure is determined by attributes (type, color, position), and the values ​​of the attributes must be random, a class is needed that will be responsible for the random formation of attribute values ​​- a class Algorithm. Attribute values ​​depend on the difficulty of the game. In other words, here we notice class binding Algorithm And Complexity- i.e. attribute values ​​are a function of Difficulties. Thereby Complexity passed to the class Algorithm as a parameter. Means, Complexity must be passed as a parameter when starting the game.

Creating a figure. The parameters of the future figure are defined, but which class will be responsible for creating the figure? Here we apply the Creator design pattern, according to which the class that has more information about the object will be created, this is the Algorithm class. The Algorithm class will return the position of the new piece to the Game class. After the shape is created, the class waits for the user to select a shape.

Selecting a figure. The Game controller class will handle this event. The controller class itself checks the correctness of the player’s choice of figure, since it has all the information for this. If the Player made the right choice, then the system again draws a new figure, otherwise the game goes into the Losing state.

Figure 7. Use case sequence diagram A game

Summary: Not everyone can agree with me on the approach taken here to the analysis and design of this particular system. Generally speaking, it reflects a rather subjective view of things.

AFTERWORD FOR HACKERS. MAIN RESOURCE.

Of course, not everything said above was 100% clear and 100% useful for you - in the sense of 100% readiness tomorrow start developing complex software systems with 100% reliability . It seems that systems that are so relevant today are 100% information protection “from evil hackers hiding somewhere.” I don’t believe that 100% guarantees are possible here - or necessary at all. In any case, this modest manual did not set itself unattainable goals. It's just instructions for a not yet qualified user (client) of the UML language. Written, as far as possible, “in a human way.”

No one is perfect - neither you, the “client of education,” nor I, your “server.” You didn’t study enough or I didn’t study enough, now it’s too late to look for those to blame. Here we made only the first iteration in the preparation process. Of course, for sufficiently reliable programming of complex systems, you still need to go deeper, specialize, and know and be able to do a lot more. It is clear. But this manual is about something else. Here I did not want to take a step forward, but step back- to show you that first you need to be able to re-understand already passed. Often – misunderstood, passed by.

A hacker is not an evil criminal. At least initially. On the contrary, a programming enthusiast is also called a hacker. Then the hackers are you and me. Well, without interest in work, life is boring. We are still people, not robots. Everyone is not perfect, everyone is individual.

But at first we all undertake to do 1) everything 2) at once 3) perfectly. And this is normal - as long as it does not greatly affect others, near and far. The moment of truth comes when our ideal scenario ends in failure. Then some begin to learn to work seriously, and those who are cooler begin to look for those to blame. “They didn’t teach enough, they didn’t teach it the right way” - in general, they didn’t provide enough resources. Darling, did you invest a lot yourself? Isn’t hidden behind your unshakable faith in the limitless power of your own intuition hope for chance and... ordinary laziness, unwillingness to work?

Hack-work is day labor, routine and hack work, and a “cool hacker” is an extremely unreliable person. Free or for good money, but if such a person takes on the development of systems that are no longer toy, the real harm will be no less than from any “evil hacker” (usually a virtual one). Then everyone will pay. Really. And then no one will be interested anymore.

The point here is not the money itself, contracts and other artifacts. These are just symbols of a social contract, signs of trust and agreements between people. You just have to record things for the future so as not to forget the past. The main resource is the resource of human relationships. If you don’t multiply it, then really – who needs all this mathematics? It’s a deal - agreed?

I hope now you better understand what and who exactly I was counting on. This is the math...

BIBLIOGRAPHY

1. Grady Booch, James Rambo, Ivar Jacobson - UML Language. User guide. Publishing house DMK Press, 2007, 496 p. A classic from the creators of UML.

2. Craig Larman - Using UML 2.0 and Design Patterns. Williams Publishing, 2008, 736 pp. Reflects the dominant engineering approach to OO AP today.

3. J. Rambo, M. Blaha - UML 2.O. Object-oriented modeling and development. 2nd ed. - St. Petersburg: Peter, 2007. - 544 p. The same thing, with a slightly more practical twist.

4. Rational University – materials of the academic program of IBM Corporation (see http://www.ibm.com/ru/software/info/students/): Essentials of visual modeling, Fundamentals of Rational Rose. A treasure trove of examples, tests and labs.

Additional literature.

1. Martin Fowler. UML. Basics. Publishing house Symbol-Plus, 2006, 192 p. Quick reference.

2. Rational University– materials of the IBM Corporation academic program (see http://www.ibm.com/ru/software/info/students/): Mastering Object-Oriented Analysis and Design, Managing the Management of Iterative Development and others.

3. Bertrand Meyer. Object orientation design of software systems. Publishing house Russian edition 2005, 1204 p. Reflects a more classical view of the modern situation. Requires good mathematical preparation.

Additional literature - for teachers.

F. Novikov. Description practical work students (LP) in the discipline “Analysis and Design on UML” - Department of “Programming Technologies”, St. Petersburg State University of Information Technologies, Mechanics and Optics, St. Petersburg, 2007

Above, the author focused on individual preparation. But the only reliable way to practically test the understanding of the above concepts of OO AP - especially “criterion 36.6” - is collective, team development. Methodological development F. Novikova gives a good start here - in the form of a diagram for carrying out relevant laboratory work. Although the author would personally recommend tasks of a playful nature for their implementation, which do not pretend to be serious. For example - chess, checkers, and other board games.

However, it's worth re-reading Romeo and Juliet, to understand that the true meaning of the quote does not refer to the roses themselves. Even - rational or virtual. The main theme of the tragedy is indicated at the very beginning: Two equally respected families in Verona, where events meet us...

Students of this course have access to licensed software products from IBM and Microsoft - to do this, just contact the course teacher (the author of this manual)

Within the limits defined by a popular joke. Teacher to teacher: “Well, the students were stupid. I explained and explained – I already understood everything, but they still wouldn’t understand!”

It is said that Newton uttered this famous phrase in connection with a discussion of the distribution of academic hours for classes in foreign languages ​​and mathematics.

According to the curriculum: (- but see afterword J

Russian-language terminology relating to the problems under consideration has not yet been fully established. In case of difficulties with translation, the author, in order to avoid ambiguous understanding, uses “tracing paper”. Inaccurate translation of other people's realities into one's own gives rise to extremely difficult problems.

Collaboration - cooperation. In Russian the word collaborator has a negative meaning, which is why they often talk about cooperation diagrams.

The author of the chapter is Anastasia Sabirzyanova. I made only minor stylistic changes - because I like her lively and honest style of presenting the development process. It’s clear that if she wanted, she could be deceitful... After all, Anastasia graduated from the Faculty of Computational Mathematics and Computer Science at KSU and already has quite a lot of experience in the practical development of commercial applications. However, that’s probably why I couldn’t... N.B.

What is true is taking into account the need to treat other parts of speech as nouns in such cases. Let us recall the example “Authorization”, where we interpret the operation authorize as a process. N.B.

Keywords: meaning glossary– a compact list of basic terms describing the subject area. As for the rest, Anastasia’s opinion fits well with the concept of OO AP. Model – not only and not so much final result development. This is the current result of understanding the problems associated with it. Hence the necessity and usefulness of samples. N.B.

Not always, not absolutely. The description of the subject area has priority - default, other things being equal. But let us remember that the main task of the iterative method is (more or less) uniform progress everyone types of work. An internal identifier - for example, the primary key of a database table - can also be chosen not at random, but based on the tasks of the software implementation. One can imagine the extreme exceptional a situation where, due to implementation problems, it is necessary to limit the description of the subject area. The difference is that justification requires isolated exceptions, not general rules. N.B.

We did not touch upon the extremely useful concept in this manual design pattern(besides, to be honest, I don’t remember such a template). For now - before getting to know him through literature (see for example), the reader here and further can read him like this: “ Leading developers with extensive experience recommend creating the following class in this situation.” N.B.

In simple cases. In general, the message refers per call, and the ratio of messages and operations has to be specified specifically. N.B.

As well as the desire to prevent possible errors at an earlier stage. N.B.

It is no coincidence that I highlighted above subjects actions. Basically, I agree with Anastasia in her understanding of the essence of the approach, expressed earlier and in the introduction to the example. All developers are subjects, or simply people. Not gods, but not robots either. And each person has his own personal approach to solving problems, depending on theoretical qualifications, practical experience and many other things that are extremely useful for understanding problems, but do not clearly predetermine solutions. Life is complex - languages ​​are simple.

The diseases of modern programming, which UML is trying to cure, come from the opposite. Without understanding the problems, we are often confident in advance that the solution is unique. Each one is their own. That is why the temperature “on average in the hospital” often rises above normal 36.6 - N.B.

Remy Coolom (left) with the Crazy Stone computer program against Grandmaster Norimoto Yoda

In 1994, the computer beat the world champion in checkers, and in 1997 - in chess. Today, computers are superior to humans in absolutely all popular games with complete information, except one.

U classic game with 2500 years of history is very simple rules, but computer programs can’t even come close to beating the best grandmasters, writes Wired.

The ancient game can be considered the “eastern version of chess.” Like chess, it is a game with complete information, that is, at any moment in the game, all players have complete information about the state of the game and influence the game with discrete actions. Here, success does not depend on luck or reaction speed.

Despite the growth in computer processing power (the world chess champion today would probably lose even to your home PC), algorithms for playing Go at an expert level remain an unsolved and one of the most interesting problems in AI. The problem is that very few people are able to rise to ninth dan in the game. To do this, you need to study in Japan or Korea for several years. There, talented children are taken from home to study at the Go Academy from about 9 years old.

Advanced amateurs almost always get stuck at a certain level of play and can't improve their performance: "It takes a mental leap to break that lock, and it's the same problem in software development," explains David Fotland, lead designer of the PA-RISC processor at Hewlett Packard company in the 70s. He tested the Go program on a processor of his own design. “The question is how to evaluate the entire board, not individual fragments.”

The game has long been popular not only in the east, but also in the west, especially among mathematicians and physicists. For example, Einstein often played Go, as did the famous mathematicians John Nash and Alan Turing.

Computer programs for Go have been developed for 45 years; this problem has received almost as much attention as chess programs. The first was written by game theory genius Alfred Zobrist in 1968. She could beat an absolute beginner who had just learned the rules (recording of the first human-computer game). The start seemed optimistic. A huge amount of time and intellectual effort was spent over the next four decades, but even with advances in computing power, the programs could not defeat even the advanced amateur.

The reason can be understood if we compare Go with chess. At first chess game White has 20 possible moves, and Black has 20 possible responses. After the first move there can be 400 different positions on the board. Now compare the numbers in Go: on a 19x19 board, black has 361 possible initial moves, and white has 360 possible responses. This means 129,960 possible combinations after the first round alone.

The so-called "branching factor" - the average number of moves available in each round - is 35 in chess and 250 in Go. Games with strong branching make it difficult for standard algorithms that use the minimax rule to create a tree of possible combinations. Even taking into account the analysis of not all, but only promising branches for a deeper analysis. What works in checkers and chess does not work in Go. Selecting promising branches in the tree of possible Go combinations is often a completely mysterious process. Even the players don't understand how they do it: "You just look at the board and you know," they say.

Again, in chess you can almost always tell who is winning, at least by the number of pieces. In Go, only experts can interpret a situation.

The average number of moves in a game: in chess - about 40, in Go - 200. Taking into account the branching factor and these statistics, the powerlessness of computers becomes clear.

The talented French programmer Rémi Coulom achieved his first success with the Crazy Stone program in 2006, when he guessed to combine minimax and the Monte Carlo method. New algorithm he called the branch tree calculation Monte Carlo Tree Search or MCTS. The Frenchman won the championship computer programs UEC Cup in 2007 and 2008, but this never brought him fame and Remy abandoned development. But in 2010, he received an offer from the Japanese game developer Unbalance - and in 2011, the first commercial version of Crazy Stone was released. In 2013, Remy returned victoriously to the championship.

However, in 2014 there was a setback. In the final confrontation against the Zen program, the audience realized that something strange was happening after the third move. The Zen program, after the standard placement of two stones in the corners, suddenly placed a third stone near the center. Nobody played like that, it was clearly an “inhuman” decision. Soon, Crazy Stone's winning expectations rose to obscenely high levels, over 60%. Apparently, the program considered the group of stones in the upper right corner to be safe, even though it was not safe. Since a successful strategy directly depends on the correct assessment of the board, spectators began to whisper about Crazy Stone's possible defeat. And so it happened: on move 186, Crazy Stone admitted defeat, and Zen became the new UEC Cup champion.

However, Kulom still has the opportunity for revenge. As a finalist, he earned the right to play against a real human grandmaster with a four-stone handicap. This year Norimoto Yoda came to the tournament. The Japanese grandmaster sat down at the table wearing a traditional green kimono. Remi Koulom is wearing rimless glasses and a blue sweater, which he wore at the last championship.