rorikstr/s21_tetris
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Update from 12

Browse source
This commit is contained in:
Administrator 2024-07-16 07:39:30 +00:00
parent e78f187cda
commit 8912bb7190
10 changed files with 130 additions and 130 deletions
Download patch file Download diff file Expand all files Collapse all files

122
README.md
View file

@ -1,6 +1,8 @@
# BrickGame Tetris
Summary: In this project, you need to implement the Tetris game in the C programming language using a structural approach.
💡 [Tap here](https://new.oprosso.net/p/4cb31ec3f47a4596bc758ea1861fb624) **to leave your feedback on the project**. It's anonymous and will help our team make your educational experience better. We recommend completing the survey immediately after the project.
# Contents
- [BrickGameTetris](#brickgame-tetris)
@ -21,34 +23,34 @@ Summary: In this project, you need to implement the Tetris game in the C program
## Introduction
The project must consist of two parts for implementing the Tetris game: a library that implements the game's logic, which can be connected to various GUIs in the future, and a terminal interface. The logic of the library must be implemented using finite-state machines, one of the possible descriptions of which will be given below.
The project must consist of two parts to implement the Tetris game: a library that implements the logic of the game, which can be connected to different GUIs in the future, and a terminal interface. The logic of the library must be implemented using finite-state machines, one of the possible descriptions of which is given below.
## Chapter I <div id="chapter-i"></div>
# General information
### BrickGame
BrickGame is a popular handheld console from the 90s with several ~~thousands~~ of built-in games developed in China. Originally, it was a copy of Tetris, developed in the USSR and released by Nintendo as part of the GameBoy platform, but also included many other games that were added over time. The console had a small screen with a 10x20 size playing field, which was a matrix of "pixels". There was a scoreboard to the right of the field with a digital display of the current game status, records and other additional information. The most popular games on BrickGame were Tetris, Tanks, Racing, Frogger, and Snake.
BrickGame is a popular handheld console from the 90s with several ~~thousands~~ of built-in games developed in China. It was originally a copy of Tetris developed in the USSR and released by Nintendo as part of the GameBoy platform, but also included many other games that were added over time. The console had a small screen with a 10x20 playing field that was a matrix of "pixels". To the right of the field was a scoreboard with a digital display of the current game status, records, and other additional information. The most popular games on BrickGame were Tetris, Tanks, Racing, Frogger and Snake.
![BrickGameConsole](misc/images/brickgame-console.jpg)
### History
Tetris was created on an Electronica-60 computer by Alexey Pajitnov on June 6, 1984. The game was a puzzle based on the use of "tetraminoes" - shaped pieces consisting of four squares. The first commercial version of the game was released in America in 1987. In the following years, Tetris was ported to many different devices, including cell phones, calculators, and PDAs.
Tetris was created on an Electronica-60 computer by Alexey Pajitnov on June 6, 1984. The game was a puzzle based on the use of "tetraminoes" — shaped pieces consisting of four squares. The first commercial version of the game was released in the United States in 1987. In the following years, Tetris was ported to many different devices, including mobile phones, pocket calculators and PDAs.
The most popular version of Tetris is the one for the Game Boy and NES consoles. But there are various versions of the game apart from it. For example, there's a version with three-dimensional pieces or a dueling version where two players get the same pieces and try to beat each other on points.
The most popular version of Tetris is the one for the Game Boy and NES consoles. But there are several other versions of the game. For example, there's a version with three-dimensional pieces, or a duel version where two players get the same pieces and try to beat each other in scoring.
### Finite-state machines
A finite-state machine (FSM) in the theory of algorithms is a mathematical abstraction, a model of a discrete device that has one entry, one exit and at each moment of time is in one state out of a set of possible states.
A finite-state machine (FSM) in algorithm theory is a mathematical abstraction, a model of a discrete device that has an input, an output, and is in one of a set of possible states at any given time.
During operation, the input of the FSM sequentially receives entry actions, and at the output the FSM generates exit signals. Transition from one internal state to another can occur not only from external action, but also spontaneously.
During operation, the input of the FSM receives input actions sequentially, and the output of the FSM generates output signals. Transition from one internal state to another can occur not only by external action, but also spontaneously.
FSM can be used to describe algorithms for solving certain problems, as well as for modeling almost any process. A few examples:
FSM can be used to describe algorithms for solving specific problems, as well as to model almost any process. Some examples:
- Artificial intelligence logic for games;
- Artificial intelligence game logic;
- Syntactic and lexical analysis;
- Complex application network protocols;
- Streaming data
- Streaming data.
Below are examples of using FSM to formalize the game logic of a few games from BrickGame.
@ -56,42 +58,42 @@ Below are examples of using FSM to formalize the game logic of a few games from
![Frogger](misc/images/frogger-game.png)
Frogger is one of the later games released on the Brickgame consoles. The game is a playing field on which the logs move, and by jumping over them, the player needs to direct the frog from one side to the other. If the player hits the water or the frog moves outside the playing field, the frog dies. The game ends when the player brings the frog to the other side or the last frog dies.
Frogger is one of the later games released for the Brickgame consoles. The game consists of a playing field on which logs move, and the player has to guide the frog from one side to the other by jumping over them. If the player hits the water or the frog moves outside the playing field, the frog dies. The game ends when the player gets the frog to the other side, or when the last frog dies.
In order to formalize the logic of this game, the following variant of a finite-state machine can be introduced:
To formalize the logic of this game, the following variant of a finite state machine can be introduced:
![Frogger's finite-state machine](misc/images/frogger.jpg)
This FSM has the following states:
- Start is the state in which the game waits for the player to press the ready to play button.
- Spawn is the state in which the next frog is created.
- Moving is the main game state with user input processing - moving the frog along the lane left/right or jumping forward/backward.
- Shifting is the state that occurs after the timer expires, which shifts all objects on the lanes to the right, along with the frog.
- Collision is a state that occurs if the frog hits the water after jumping, or if the frog is outside the playing field after shifting logs.
- Reached the other side is the state that occurs when a frog reaches the other side.
- Game over is the state that occurs after reaching the other side of the river or the last frog dies.
- Start is the state where the game is waiting for the player to press the ready button.
- Spawn is the state where the next frog is created.
- Moving is the main game state with user input processing — moving the frog left/right along the path or jumping forward/backward.
- Shift is the state that occurs after the timer runs out, where all objects on the paths are shifted to the right along with the frog.
- Collision is a state that occurs when the frog hits the water after jumping, or when the frog is outside the playing field after moving logs.
- Reached the other side is the state that occurs when a frog reaches the other side.
- Game over is the state that occurs after reaching the other side of the river, or when the last frog dies.
You can find an example of implementing a frogger using FSM in the `code-samples` folder.
An example of implementing a frogger using FSM can be found in the `code-samples` folder.
### Tetris
![Tetris](misc/images/tetris-game.png)
Tetris is probably one of the most popular games for the Brickgame console. It's not rare for the console itself to be referred to as Tetris. The goal of the game is to score points for building lines from the blocks generated by the game. The next block generated by the game starts moving down the playing field until it reaches the lower boundary or collides with another block. The user can rotate the pieces and move them horizontally, trying to make rows. Once filled, the row is destroyed, the player gets points, and the blocks above the filled row go down. The game ends when the next piece stops in the topmost row.
Tetris is probably one of the most popular games for the Brickgame console. It's not uncommon for the console itself to be called Tetris. The goal of the game is to score points by building lines of blocks generated by the game. The next block generated by the game starts moving down the board until it reaches the bottom border or collides with another block. The user can rotate the blocks and move them horizontally, trying to make rows. Once a row is filled, it is destroyed, the player scores points, and the blocks above the filled row fall down. The game ends when the next piece stops in the top row.
In order to formalize the logic of this game, the following variant of a finite-state machine can be introduced:
To formalize the logic of this game, the following variant of a finite state machine can be introduced:
![Tetris’s finite-state machine](misc/images/tetris.png)
This FSM has the following states:
- Start is the state in which the game waits for the player to press the ready to play button.
- Spawn is the state the game enters when you create another block and choose the next block to spawn.
- Moving is the main game state with user input processing - rotating blocks/moving blocks horizontally.
- Shifting is the state the game enters after the timer expires. It moves the current block down one level.
- Attaching is the state the game enters after the current block "touches" the already fallen blocks or the ground. If filled rows are created, it is destroyed and the rest of the blocks are shifted down. If a block is stopped in the topmost row, the game enters the "game over" state.
- Game over is a game over.
- Start is the state in which the game waits for the player to press the ready button.
- Spawn is the state the game enters when you create another block and select the next block to spawn.
- Moving is the main game state with user input processing — rotating blocks/moving blocks horizontally.
- Move is the state the game enters after the timer runs out. It moves the current block down one level.
- Attaching is the state the game enters after the current block "touches" the already fallen blocks or the ground. If full rows are created, it is destroyed and the remaining blocks are moved down. If a block is stopped in the top row, the game enters the "game over" state.
- Game over is the end of the game.
## Chapter II <div id="chapter-ii"></div>
## Project Requirements
@ -100,38 +102,38 @@ This FSM has the following states:
You need to implement the BrickGame v1.0 aka Tetris program:
- The program must be developed in C language of C11 standard using gcc compiler.
- The program must consist of two parts: a library implementing the logic of the tetris game, and a terminal interface using the `ncurses` library.
- A finite-state machine must be used to formalize the logic of the game.
- The library must have a function that accepts user input and a function that outputs a matrix that describes the current state of the playing field whenever it is changed.
- The program library code must be located in the `src/brick_game/tetris` folder.
- The program interface code must be located in the `src/gui/cli` folder
- The program must be built using a Makefile with the standard set of targets for GNU-programs: all, install, uninstall, clean, dvi, dist, test, gcov_report. Installation directory can be arbitrary
- The program must be developed in accordance with the principles of structured programming.
- Stick to Google Style when writing code.
- The program must be developed in C language of the C11 standard using the gcc compiler.
- The program must consist of two parts: a library implementing the logic of the Tetris game, and a terminal interface using the `ncurses` library.
- A finite state machine must be used to formalize the logic of the game.
- The library must have a function that accepts user input and a function that outputs a matrix describing the current state of the playing field whenever it is changed.
- The library code must be placed in the `src/brick_game/tetris` folder.
- The program interface code must be in the `src/gui/cli` folder.
- The program must be built using a Makefile with the standard set of targets for GNU programs: all, install, uninstall, clean, dvi, dist, test, gcov_report. The installation directory can be arbitrary.
- The program must be developed according to the principles of structured programming.
- Follow Google Style when writing code.
- Prepare full coverage of the library with unit tests, using the `check` library (tests must run on Darwin/Ubuntu OS). The coverage of the library with game logic with tests must be at least 80 percent.
- The following mechanics must be in the game:
- The following mechanics must be present in the game:
- Rotation of pieces;
- Moving pieces horizontally;
- Acceleration of the piece's fall (when the button is pressed, the figure moves all the way down);
- Display of the next piece;
- Destruction of filled raws;
- End of the game when the top border of the playing field is reached;
- All sorts of pieces shown in the picture below must be included in the game.
- Add support for all the buttons provided on the physical console for control:
- Horizontal movement of pieces;
- Acceleration of the piece's fall (when the button is pressed, the piece moves all the way down);
- Displaying the next piece;
- Destruction of filled rows;
- End of the game when the top of the board is reached;
- All types of pieces shown in the picture below must be included in the game.
- Add support for all buttons provided on the physical console for control:
- Start game,
- Pause,
- End game,
- Left arrow - movement of the piece to the left,
- Right arrow - movement of the piece to the right,
- Down arrow - piece falls,
- Left arrow — move the piece to the left,
- Right arrow — move piece to the right,
- Down arrow — piece falls,
- Up arrow is not used in this game,
- Action (piece rotation).
- The playing field must match the dimensions of the console's playing field - ten "pixels" wide and twenty "pixels" high.
- After reaching the lower boundary of the field or contacting another figure, the figure must stop. After that, the next piece, shown in the preview, is generated.
- The library interface must correspond to the description found in materials/library-specification.md.
- The playing area must be the same size as the console's playing field — ten "pixels" wide and twenty "pixels" high.
- When the figure reaches the lower boundary of the board or touches another figure, it must stop. After that, the next piece, shown in the preview, is generated.
- The library interface must match the description in materials/library-specification.md.
- The UI must support rendering of the playing field and additional information.
- Prepare a diagram in any format describing the used FSM (its states and all possible transitions).
- Prepare a diagram in any format describing the FSM used (its states and all possible transitions).
Pieces used:
@ -139,24 +141,22 @@ Pieces used:
### Part 2. Bonus. Scoring and game record
Add the following mechanics to the game:
Add the following mechanics to the game
- scoring;
- storing maximum points.
- Scoring;
- Store maximum score.
This information must be passed and displayed by the user interface in the sidebar. The maximum number of points must be stored in a file or embedded DBMS and saved between program runs.
This information must be passed and displayed by the user interface in the sidebar. The maximum score must be stored in a file or an embedded DBMS and saved between program runs.
The maximum number of points must be changed during the game if the user exceeds the current maximum score.
The maximum score must be changed during the game if the user exceeds the current maximum score.
Points will be accrued as follows:
Points are accumulated as follows:
- 1 row is 100 points;
- 2 rows is 300 points;
- 3 rows is 700 points;
- 4 rows is 1500 points;
- 4 rows is 1500 points.
### Part 3. Bonus. Level mechanics
Add level mechanics to the game. Each time a player gains 600 points, the level increases by 1. Increasing the level boosts the speed at which the pieces move. The maximum number of levels is 10.
💡 [Press here](https://forms.yandex.ru/cloud/65d4a02673cee73bdc52da80/)**, to give us feedback on this project**. It's anonymous and will help our team make your learning process better.
Add level mechanics to the game. Each time a player earns 600 points, the level increases by 1. Increasing the level increases the speed at which the pieces move. The maximum number of levels is 10.