fixed game logic

This commit is contained in:
2025-03-05 19:02:51 +01:00
parent 2fbe4a6052
commit 74797e935a
15 changed files with 186 additions and 138 deletions

View File

@@ -1,7 +1,7 @@
# Game logic
This section will detail how the player's action are interpreted into the game.
We will only talk about pieces and not polyominos. In this project, pieces are an abstraction of a polyomino. Though if you want to know more the polyominos in this project, check [this other file](Pieces_representation.md).
We will only talk about pieces and not polyominoes. In this project, pieces are an abstraction of a polyomino. Though if you want to know more the polyominoes in this project, check [this other file](Pieces_representation.md).
## Order of operations
@@ -26,9 +26,34 @@ Then the rest of actions will be tested in the list's order.
Finally, gravity and lock delay are applied last.
Moving and soft dropping can be held but hard dropping, holding and rotating needs to be released and pressed again to happen.
## ARR and DAS
The sidewise movement of the piece is defined by two parameters: DAS and ARR.
**DAS** stands for Delayed Auto Shift and **ARR** for Auto Repeat Rate.
Theses can be changed by the player.
The parameters will be refered to as DAS and ARR, while the in-game values will be refered to as the piece's DAS ans ARR.
- Initially, both the piece DAS and piece ARR are at 0. When moving the piece in one direction,
the piece will move one position and then wait for the player to hold that direction as long as the DAS value.
_So for exemple if DAS is set to 20, on the first frame piece DAS will be set to 1 and the piece will move once.
The next movement will be delayed by 20 frames, so the piece will move again 20 frames later, on the 21th frame, or when the piece DAS = (DAS +1)._
- Then, if the player still holds the same direction, ARR takes on.
The piece will move every ARR frames.
_So in our exemple if ARR is set to 5, this means the piece will move every 5 frames after the 21th frame.
So on the 21th frame piece DAS = 21 and piece ARR = 0.
On the 26th frame, piece ARR = 5 so the piece moves and piece ARR is set back to 0._
Now DAS can be buffered, that is if a direction is held before the piece spawn, it will have an initial DAS value corresponding to the number of frames held.
_So in our example where DAS = 20 and ARR = 5, if we held a direction during 30f then hold without releasing this direction, the piece will move instantly on the frame it spawns.
Then, ARR will start counting on the next frame. So the piece will move on frames 1, 6, 11, etc._
When trying to hold two directions at the same time, only the direction held last will be applied.
So for example if you were holding left and you suddendly start holding the two directions at the same time, the piece will go right.
In the two directions are first pressed at the same frame, left will take priority.
## Leniency mechanics
In a general sense, we try to be kind to the players. Some of the following mechanics are just standards in a lot of stacker games, while other have been added because of this game using polyominos of high sizes and thus being way harder to play.
In a general sense, we try to be kind to the players. Some of the following mechanics are just standards in a lot of stacker games, while other have been added because of this game using polyominoes of high sizes and thus being way harder to play.
When a piece touches the ground, there is a short time period before it automatically locks. This period is called _lock delay_. Lock delay is reset everytime the piece move. To not allow for infinite stalling, there is another longer period called _forced lock delay_ that does not reset when moving the piece.
The player has a hold box in which they can temporarly store a piece. In this game, we allow the player to swap between the held piece and the active piece as much as they want. Once again to not allow for infinite stalling, forced lock delay does not reset when holding a piece.
@@ -40,7 +65,7 @@ IRS and IHS will fail if they actually loose the player the game when it would h
A common mechanic of stacker games is kicking. This happen when rotating a piece makes it collide with a wall. The game will try to move the piece in a few predetermined spot close to the current position until one of them allow the piece to not be in a wall again. If no positions allow for that, the rotation is simply cancelled.
This concept works very well for games with up to tetrominos or pentominos, but when using polyominos of any size we can't choose a few predetermined spots for each piece.
This concept works very well for games with up to tetrominos or pentominos, but when using polyominoes of any size we can't choose a few predetermined spots for each piece.
Since this game uses polyomino of high sizes which are very unplayable, we will try to be complaisant to the player and allow as much kicking spots as possible, while trying not to make him feel like the piece is going through walls. To solve this problem, this game introduce a new Rotation System called **AutoRS**, which does not have a predetermined list of spots to fit the piece but instead adapt to its shape. Its algorithm goes as follow: