Game design doc + Players have a max size #730
Conversation
Codecov Report
📣 This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more @@ Coverage Diff @@
## develop #730 +/- ##
===========================================
+ Coverage 87.00% 87.23% +0.22%
===========================================
Files 37 37
Lines 1655 1661 +6
Branches 126 0 -126
===========================================
+ Hits 1440 1449 +9
+ Misses 215 212 -3
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. |
| [212](https://github.com/tresinformal/drakkar/issues/212)|4. Heal | ||
| [222](https://github.com/tresinformal/drakkar/issues/222)|5. Targeting system | ||
| [223](https://github.com/tresinformal/drakkar/issues/223)|6. Minimap | ||
| Drakkar is a multiplayer game featuring dragons of different colours trying to chase and eat one another. The game resembles agar.io, with the addition of a Rock-Paper-Scissor dynamic via the RGB colours. |
There was a problem hiding this comment.
It makes the core idea of the game really clear. I did not know about the Rock-Paper-Scissor dynamic till now, luckily I did not change (hopefully) any code that defines this behavior
doc/game_design.md
Outdated
|
|
||
| ### Interactions | ||
| A player running into another one triggers a collision. | ||
| Upon a collision, the colour of the involved dragons is compared, and the dragon with the strongest colour wins, according to the following Rock-Paper-Scissor logic: |
There was a problem hiding this comment.
"and the dragon with the strongest colour wins"
Maybe 'stronger' is better here? Because there is actually no strongest color, they are only stronger comparing to the colors that are weaker than them
There was a problem hiding this comment.
ah, good point!
|
|
||
| The winning dragon then munches on the losing one, growing a bit in the process, while the loser shrinks a bit. | ||
| The loser then turns invulnerable for a short duration, so that it has a chance to escape its victor and avoid being munched on indefinitely. | ||
| During this time, the invulnerable dragon cannot be involved in a collision with the stronger player (it simply ignores it as it runs into it), but can still collide with the weaker player. |
There was a problem hiding this comment.
So the idea here is that invulnerable means immune to damage but still able to deal damage
There was a problem hiding this comment.
Yes, correct! If you lose a collision and then run into the player weak to your colour, you can win.
| As described above, players change size upon interaction with other players. | ||
| When a player falls under a certain size, it "dies". | ||
| While dead, the player cannot interact with either of the other players (and so ignores collisions). | ||
| After some time, the player is revived, upon which it returns to its starting size and can interact with other players again. |
There was a problem hiding this comment.
I am curious about the fairness to return to the starting size after revival, but it is hard to say and I don't have experience playing arga.io, we will see after achieving the minimal viable game of course.
Also, do the kill/death stats matter in determining the winner? Might be useful if there is a tie.
There was a problem hiding this comment.
Also, do the kill/death stats matter in determining the winner? Might be useful if there is a tie.
They don't, so far we solve ties with a coin flip. I like the idea of using death stats instead, sounds more fair! Let's keep it in the back of our heads for now.
There was a problem hiding this comment.
I am curious about the fairness to return to the starting size after revival, but it is hard to say and I don't have experience playing arga.io, we will see after achieving the minimal viable game of course.
This is because of the "natural decay" thing. If a player reaches the minimum size and dies, then it has no way to interact and thus it cannot grow. Upon reviving, because of the decay it will immediately die again. Being revived at your starting size avoids this. Is there a logic flaw in this?
|
|
||
| There is also an upper limit to the size a player can reach, so it does not inflate to occupy the whole environment and automatically trigger collisions with other players. | ||
|
|
||
| Players progressively shrink over time, as an incentive to avoid players simply sitting around and waiting for the timer to run out after having reached a winning size. |
There was a problem hiding this comment.
Will a player die due to natural shrinking? Or there will be a lower limit too?
There was a problem hiding this comment.
Hm, this has never been discussed I think. What do you reckon is best? Maybe "natural" shrinkage should stop when the player reaches the minimum size before a player dies?
|
|
||
| ### Environment | ||
| Players can move and interact within a rectangular environment. The environment has hard boundaries: players cannot move beyond these boundaries. | ||
| Otherwise, players can move freely, there are no obstacles other than other players within the environment. |
There was a problem hiding this comment.
If there are no obstacles, would it be impossible to lose the enemy?
There was a problem hiding this comment.
That's a risk, yes... If both players are equally skilled at maneuvers then the chase might be long... But I think walls help a bit already. Then indeed this is something we can aim to improve for a later version.
| A player can also move backwards, going in the opposite direction to the forward one. | ||
| To change direction, a player can pivot left or right with dedicated keys. | ||
|
|
||
| Movement is immediate: when a movement key is pressed, the player moves accordingly; when a movement key is released, the player stops moving. |
There was a problem hiding this comment.
In my reworked movement system there is possibility to add (significant) inertia to the players, like the Mario Brothers. If you are not satisfied with the current settings we could discuss and change.
There was a problem hiding this comment.
To be clear, is this already implemented? If so, then I need to correct this section indeed. I'm not very aware of how movement is handled these days.
|
It is time to merge this, thanks to the deadline posted on Discord and copy-pasted here:
|
Oops, this should have been 2 separate PRs... Oh, well.
Game design document (see #728 and chat in the big table)
I made a first version for a design document, detailing everything that the game should do and contain for the minimum viable game (it's not that much!). Please review and feel free to object, I may have missed something.
@EvoLandEco and @ollyturner, please pay especially close attention to the rules I detailed for player size and invulnerability. Let me know if you spot that this would not work in practice, or if you have a better system in mind, or if I have left something important aside.
Once we reach a consensus on the rules, I'll make some housekeeping in the issues to make them consistent with the proposed plan.
Also, we should have a defined policy for how to add or changes features from the design doc, when we want to take the game in a new direction. I think that any new feature or idea should be discussed first, then added to the design doc if well received, and then only we should be able to start working on it (by making issues and tests, and solving them).
Any idea on how to implement this?
Test and solution for: