Skip to content

Feature/zarns/rust#304

Open
zarns wants to merge 2 commits intobcollazo:feature/catanatron-rustfrom
zarns:feature/zarns/rust
Open

Feature/zarns/rust#304
zarns wants to merge 2 commits intobcollazo:feature/catanatron-rustfrom
zarns:feature/zarns/rust

Conversation

@zarns
Copy link
Copy Markdown
Contributor

@zarns zarns commented Mar 9, 2025

This isn't ready to merge. I got frustrated trying to get catanatron-play to run games using the Rust backend so I surrendered to claude-3.7 and tried vibe coding. This sort of works if you run maturin dev in catanatron_rust then run catanatron-play --players=RR,R --rust

RR is for RustRandom and R is the Python impl of RandomPlayer.

Granted, this sort of works, but makes little sense to me. I'll keep trying, but if anybody wants to give this a stab, now would be a good time 😆

@bcollazo
Copy link
Copy Markdown
Owner

Haha at "surrendered to Claude and tried vibe coding" 😅 Thanks for opening this PR nonetheless, definitely helpful if not for at least the discussion. 👍

So... sounds like indeed this might be tougher than expected. If its too much trouble / complicated, maybe it is best to be kept separate.

Some other ideas we should probably weight this approach with are:

  • Having the Rust expose some sort of backend that the Python does IPC (inter-process communication) 😬 . What I am thinking is that for the deeper Alpha Beta (one of the main promises of Rust impl) we may not need to run a bunch of games (running just 1 would be good).
  • Keep separate, and use Rust just for rollout collection, and have CSVs (or arrow format better?) files with the data be the "API". Similarly for any other type of ML player we might want to play, since I believe the files or "tensorflow weights" could also be an API between Python and Rust.
  • (I think you might've mentioned this) Expose a webserver that answers the "next best move" in Rust, and have an HTTPPlayer or so in the Python world. This is similar to option 1, and would allow for 1v1s between a human and a strong catanatron.

What do you think? I like from these other approaches that definitely seem simpler (3 feels anyways like an additional "feature" for the catanatron codebase), and I'm a fan of simpler. It also doesn't close out the door on figuring out on building a Pyo3/Maturin wrapper in the future.

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