Seeking Architecture Advice for a Terminal-based Board Game with Ratatui - Multithreading and Ownership

ello Rustaceans,

I'm a beginner Rust programmer and currently embarking on a project to create a terminal-based board game. While I've started to get a handle on the unique aspects of Rust, I'm finding the ownership and borrowing rules to be a challenging (but rewarding) learning curve. I'm aware that the choices I make for my project's architecture can heavily influence how well these Rust features are leveraged.

I've decided to use the "ratatui" library for handling the UI, and I have a question regarding the threading model of this library. I'd like to use multithreading for handling mouse events in my application and would love to hear your insights about how this could work with "ratatui". Could someone help me understand how the threading model of "ratatui" fits into an architecture that plays nice with Rust's ownership and borrowing rules?

Additionally, I'm trying to understand how to best structure my application overall, in terms of game state, rules, and user interaction layers. Any advice or resources would be greatly appreciated!

Lastly, I've been trying to find a good walkthrough or tutorial specifically for "ratatui". While I've read the library's documentation, I think seeing some worked examples or a more in-depth guide would be very beneficial. If anyone knows of such resources, could you kindly share them?

Thank you all for your help. I'm really enjoying learning Rust and being part of this community. Any advice you can provide would be greatly appreciated!

Best Regards!

From a quick look at the ratatui Git repo:

ratatui is a terminal UI library that supports multiple backends:


Moreover, the library does not provide any input handling nor any event system and you may rely on the previously cited libraries to achieve such features.

So assuming you use the default crossterm backend, mouse events will be handled by that library (see crossterm docs) and not by ratatui itself.

You may wish to have a look at the examples in the examples/ folder. You can run the examples from the command line using cargo run --example barchart or cargo run --example block, etc. In particular, the canvas and table demos might be a good starting point for your game, as they show how to capture keyboard events during the app's main loop, and then refresh the display.

As for multi-threading, the canvas and table demos actually do everything in one thread (although there may be background threads started by crossterm or other libraries; I haven't checked). If your game doesn't do much computation between player moves, i.e. you don't have a fancy AI, a single-threaded approach makes sense since it's simpler. Otherwise, you could move the AI to a separate thread and communicate with it using message channels.

1 Like

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.