Skip to content
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

Open
wants to merge 6 commits into
base: main
Choose a base branch
from
Open

Conversation

amnn
Copy link
Member

@amnn amnn commented Aug 29, 2023

Description

...for turnip-town (the end-to-end simulation game example).

Test Plan

New move unit tests:

turnip-town/move$ sui move test

@vercel
Copy link

vercel bot commented Aug 29, 2023

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name Status Preview Comments Updated (UTC)
sui-docs ✅ Ready (Inspect) Visit Preview 💬 Add feedback Sep 23, 2024 0:17am
5 Skipped Deployments
Name Status Preview Comments Updated (UTC)
explorer ⬜️ Ignored (Inspect) Visit Preview Sep 23, 2024 0:17am
multisig-toolkit ⬜️ Ignored (Inspect) Visit Preview Sep 23, 2024 0:17am
mysten-ui ⬜️ Ignored (Inspect) Visit Preview Sep 23, 2024 0:17am
sui-kiosk ⬜️ Ignored (Inspect) Visit Preview Sep 23, 2024 0:17am
sui-typescript-docs ⬜️ Ignored (Inspect) Visit Preview Sep 23, 2024 0:17am


use turnip_town::turnip::{Self, Turnip};

friend turnip_town::game;
Copy link
Member Author

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(
Copy link
Member Author

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 fids 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?

Copy link
Contributor

@damirka damirka left a 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.

examples/turnip-town/move/sources/turnip.move Outdated Show resolved Hide resolved
examples/turnip-town/move/sources/turnip.move Outdated Show resolved Hide resolved
examples/turnip-town/move/sources/turnip.move Outdated Show resolved Hide resolved
examples/turnip-town/move/sources/field.move Outdated Show resolved Hide resolved
examples/turnip-town/move/sources/admin.move Outdated Show resolved Hide resolved
examples/turnip-town/move/sources/field.move Outdated Show resolved Hide resolved
examples/turnip-town/move/sources/field.move Outdated Show resolved Hide resolved
@amnn
Copy link
Member Author

amnn commented Aug 29, 2023

Thanks for the review @damirka ! Just going to address the style comments now.

That's a lot of code and looks cool!

On this, I was considering splitting this up into separate PRs for turnip, then field, then game + admin, then README -- just curious whether that would have been helpful?

@amnn
Copy link
Member Author

amnn commented May 24, 2024

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:

  • 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%.

@amnn
Copy link
Member Author

amnn commented Sep 23, 2024

@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%.
## 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:
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants