Query on whether my use case fits well with Amethyst

#1

Hi All,

I’d like to know if Amethyst capabilities will allow me to fulfill the use case requirements below:

Use case requirements for chess client desktop app:
1- Must communicate via TCP client with existing chess server(the Internet Chess Club)
2- Must have multiple resizable windows asynchronously receiving, sending and displaying messages
3- Must have color control for fonts, backgrounds; all widgets
4- Must support resizable window where chess board and pieces enlarge and shrink along with window
5- Must allow user to move chess piece with mouse by dragging it
6- Support for tabbed windows and other GUI widgets

How much of this can I get from the Amethyst crate?
Will I need additional crates?

Rust enthusiast,

samq

(Azriel Hoh) #2
  1. There’s no built in thing to easily talk to an existing protocol, so you’d have to write one yourself. Take a look at TcpNetworkSendSystem and TcpNetworkRecvSystem maybe? Those are abstractions over something else that actually sends the network data.
  2. Amethyst isn’t a good use case for that.
  3. amethyst_ui provides UiText and UiTransform components which lets you draw text, and Tint to change its colour. There are basic widgets (button, label), but not much beyond that. amethyst_imgui is an external crate that integrates amethyst with imgui. I haven’t used it myself so can’t comment much.
  4. Possible with AutoFovSystem, but in combination with the next point, kind of difficult.
  5. Sprites can automatically be scaled with AutoFovSystem, which operates on Transform and ScreenDimensions. Mouse interaction operates with UiTransform, whose coordinates are not consistent with Transform (world coordinates vs screen coordinates). I have written code to consolidate the two, but wouldn’t recommend it.
  6. Don’t know of any GUI in Rust that already integrates with a game engine that supports that.

The requirements are really strict, so I would recommend reducing them. If GUI is that important, then Amethyst (alone) isn’t a good fit at this point; best try integrate it with another framework.

2 Likes
(Connor Spencer Harries) #3

To build on what @azriel91 said regarding networking, whilst there’s no built in “protocol” concept it is incredibly easy to build a protocol of your choosing on top of the amethyst_network crate.

I’m currently implementing a protocol using TCP that requires using a session-specific ISAAC generator at either end (stored as components) to decode/encode packet identifiers. I have a simple resource wrapping a VecDeque for storing outbound packets and an encoder and decoder system which offload the actual IO work to the amethyst_network crate, it was extremely easy to move from a tokio codec based system when moving to amethyst.