-
Notifications
You must be signed in to change notification settings - Fork 11.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[example/turnip-town] Move package and README #13535
base: main
Are you sure you want to change the base?
Conversation
The latest updates on your projects. Learn more about Vercel for Git ↗︎
5 Skipped Deployments
|
|
||
use turnip_town::turnip::{Self, Turnip}; | ||
|
||
friend turnip_town::game; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I ended up following a pattern where there's a sequence of cascading friends: game
is field
's friend, and field
is turnip
's friend. This was so that game
could perform privileged operations on field
and same for field
on turnip
. I couldn't come up with a great way to avoid that without putting everything in one big file, but suggestions welcome.
/// | ||
/// Fails if the field (represented by its ID in the game's table) | ||
/// does not exist. | ||
public fun simulate_weather( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I went back and forth on whether this should be an entry
function. The main benefit of doing that is to not have to commit to it being part of the module interface, but in the end it's not feasible to do that, because this function is going to be called against multiple fid
s in the same Game
and he rule about entry
functions not accepting a previously modified input is going to get in the way of that.
Overall it seems like too many things might be coupled under the notion of entry
function here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wow! That's a lot of code and looks cool! Left some comments as a first round of "style / practices" review, will have a second iteration on architecture and friends.
Thanks for the review @damirka ! Just going to address the style comments now.
On this, I was considering splitting this up into separate PRs for |
36595e0
to
a8df961
Compare
Pushed an almost complete rewrite of the demo. Now, instead of demonstrating shared/permissioned access to a game between the game admin/service and the player, we are demonstrating a game that allows multiple players to interact with each other's resources. Additionally, instead of a "weather" dynamic, crops are watered by individuals, fetching water from a well that outputs a fixed quantity of water every epoch (it does not accumulate). The parameters of the game are now as follows:
New tests have been added for all these features -- test coverage for this package is 99.14%. |
@damirka, ping (as requested), could you review please! |
...for turnip-town (the end-to-end simulation game example). Test Plan: New move unit tests: ``` turnip-town/move$ sui move test ```
+ Reference `Display` for `Deed` in README.
This is an almost complete rewrite of the demo. Now, instead of demonstrating shared/permissioned access to a game between the game admin/service and the player, we are demonstrating a game that allows multiple players to interact with each other's resources. Additionally, instead of a "weather" dynamic, crops are watered by individuals, fetching water from a well that outputs a fixed quantity of water every epoch (it does not accumulate). The parameters of the game are now as follows: - Turnips need as much water as their size to stay fresh every day. - They can grow an additional 20 size units a day if given enough water (1 unit of water = 1 unit of growth). - Each player gets access to 100 units of water per day, via their well. Water must be used in the transaction it was fetched from the well -- it cannot be stockpiled. - If there is more than 100 units of additional water left, it is stagnant and the turnip will also lose freshness (it will rot). - Turnips need to grow to at least 50 units before they can be harvested. - Each player owns a field and a well. Only they can plant turnips on their field, and take water from their well. - Any player can water crops in anybody else's field, and any player can harvest crops as well, but harvested crops go to the field owner's Kiosk. New tests have been added for all these features -- test coverage for this package is 99.14%.
6216f0e
to
64ee7ec
Compare
## Description New and shiny Turnip Town. ## Test plan How did you test the new or updated feature? --- ## Release notes Check each box that your changes affect. If none of the boxes relate to your changes, release notes aren't required. For each box you select, include information after the relevant heading that describes the impact of your changes that a user might notice and any actions they must take to implement updates. - [ ] Protocol: - [ ] Nodes (Validators and Full nodes): - [ ] Indexer: - [ ] JSON-RPC: - [ ] GraphQL: - [ ] CLI: - [ ] Rust SDK: - [ ] REST API:
Description
...for turnip-town (the end-to-end simulation game example).
Test Plan
New move unit tests: