Skip to content
This repository has been archived by the owner on Sep 20, 2023. It is now read-only.

Add renaming plants and gotchi #16

Open
cedric-h opened this issue Aug 15, 2020 · 1 comment
Open

Add renaming plants and gotchi #16

cedric-h opened this issue Aug 15, 2020 · 1 comment
Assignees

Comments

@cedric-h
Copy link
Contributor

cedric-h commented Aug 15, 2020

stolen roughly from IRC

Step 1 -- Message Spec

You need to add variants to the enum messages that go between the clients and servers.
The place to start for that is in hcor, specifically hcor/src/wormhole/mod.rs
that's where all of the Asks and Notes are defined; for more info on those build the crate level backend documentation.
(as the crate-level documentation will tell you, Asks are things the client wants the server to do, and AskedNotes are messages from the server that respond directly to Asks.)
so in hcor/src/wormhole/mod.rs, the structs you're looking for are Ask and AskedNote.
add a Nickname or Rename variant to PlantAsk. I don't think the variant should need to store more than a tile id and the name you want to set it to? I can't imagine we'd need more information than that to change a plant's name.
For renaming Gotchi, the path is less clear; there's no GotchiAsk. Just add GotchiRename or Rename to Item and once we have a bunch of Gotchi routes we'll probably pull that out into a discrete GotchiAsk.
Adding an AskedNote should be somewhat simpler, since all AskedNotes are stored alongside each other without any sort of nesting. You will have to chose what you want your rename routes to return; cloning the entire plant or gotchi and sending that back over the network is a possibility, as is simply returning (), it's your call.

Step 2 -- Responding Serverside

If you compile backend, you should already get a handful of errors saying that your new Asks you've added aren't handled by the server. You can address that by going to the appropriate places (/backend/wormhole/session/tile/plant/mod.rs and /backend/wormhole/session/item/mod.rs) and adding routes to handle renaming. Consider reading that entire plant/mod.rs (it's not very long at all) to get a feel for the patterns (In particular, I want you to see how all routes have their own file). I would copy /backend/wormhole/session/tile/plant/summon.rs to a new file, nickname.rs, and start whittling down from there (for example, summoning a plant has to set up timers for that plant, which isn't necessary when you're just renaming. Also, summoning inserts a plant, I think you'd rather modify a plant, so consider the .plant_mut method.) Note that all of the route files start with an enumeration of possible error cases (man, we could make those so much shorter and prettier with thiserror), then have the actual implementation of the route, then end with (hopefully comprehensive) tests of that route.

FYI:

  • Note that routes which can't be handled by a single user's Session (like transferring items between two different users) are sent to the Server to handle, because the Server is the only thing capable of handling interactions between multiple users. Renaming plants/gotchi only requires a single user and a single user's Session, so this isn't entirely relevant to what you're doing.
  • Consider checking the documentation on SessSend in /backend/session/mod.rs or looking at the implementation of handle_ask at the bottom of that file. SessSend is your primary tool when implementing Asks and timer responses, so it may be useful to learn why it exists and works the way it does.

Step 3 -- hcor: Rust API Bindings

At the bottom of the nickname.rs you copied from plant/summon.rs, there should be a test function which runs against some common error cases. A lot of plant/summon's error cases come from the fact that it has to consume a valid item to properly execute, and fail otherwise without consuming the item, but because nickname doesn't have to do anything of the sort, it should be a lot simpler. You'll note, though, that the test doesn't send the Ask message to the server directly through the websocket, instead it simply calls methods like

let mut hs = Hackstead::register().await?;
hs.slaughter().await?;

or

let open_tile = hs.free_tile().expect("fresh hackstead no open land?");
open_tile.plant_seed(seed_item).await?;

To make it super-duper easy to write clients, tests, and illustrative documentation in Rust, hop back to hcor to add methods on Plant and Item to assist in renaming. I would start by copying an existing handling method -- maybe plant_seed on Plant, and then changing the Ask and AskedNotes (as well as the return type) to match ones you configured in step 1.

Step 4 -- Clean up the Test

This should be pretty straightforward, once you have your Rust bindings to the API.

let (_, seed_arch) = hcor::CONFIG
    .seeds()
    .next()
    .expect("no items in config that are seeds?");

let mut bobstead = Hackstead::register().await?;

let seed_item = seed_arch.spawn().await?;
let open_tile = bobstead.free_tile().expect("fresh hackstead no open land?");

let plant = open_tile.plant_seed(seed_item).await?;
plant.rename("bobby jr.").await?;

// refresh bob's stead
bobstead = Hackstead::fetch(&bobstead).await?;
assert_eq!(
    bobstead.plant(&plant).name,
    "bobby jr."
);

Good luck, and if you run into anything, just hit me up on IRC!

@Muirrum Muirrum self-assigned this Aug 15, 2020
@Muirrum
Copy link
Member

Muirrum commented Aug 16, 2020

Added asks/asked notes in hackagotchi/hcor@e36b12f

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants