Comment by beefsack | Hacker News Reader

Comment by beefsack | Hacker News Reader

On the topic of online board games, I've been really interested in the idea of a pure play-by-email (PBE) system where there isn't a frontend or web interface at all. By that, I mean that a full game rendering is emailed to each player, and they take their turns by replying to the email with the commands they wish to execute.

I started one in Go a number of years ago[1] and I feel I managed to prove to myself that a pure email interface is possible and actually really convenient in some cases. I even managed to implement over 20 games[2]. It was only ever used in my closed circle of friends, but we played thousands of games and many found it simple to participate in slow periods at work or school.

If anything, my biggest takeaway was that if you want to really reach a level of expertise in a new technology, you need to find a project that you can pour your heart into. I've probably breached 100k LOC for the project and I've been working on it for over half a decade. I'm currently redoing the project in Rust as an attempt to become highly skilled in that[3].

[1] https://github.com/Miniand/brdg.me

[2] https://github.com/Miniand/brdg.me/tree/master/game

[3] https://github.com/brdgme

The board game Diplomacy had a really thriving play by post community, which morphed into play by email. I'm actually not sure if there is a platform that actually supports play-by-email anymore (the ones I used to use seem defunct).

But there's this (claims to support play by email but I couldn't find actual directions in 2 minutes of reading around): http://www.diplomaticcorp.com/

When I played this ~10 years ago the main interface was just plain email. You'd send and email with the body containing commands like so:

signon gamename password A PAR-BUR A MAR-SPA F BRE-MAO signoff

Then there was a website that subscribed to your game as a observer and would render views of the map

A lot of 18XX games seem to have strong play-by-post communities too, which are interesting from a pure play-by-email perspective because they have already encoded a command vocabulary which could be implemented instead of needing to design from scratch.

Dunno about other games, but Lichess[0] has a correspondence gameplay mechanism[1]

[0] https://lichess.org/

[1] https://i.imgur.com/nYgMjuB.png

This is tangential to the play-by-email thread of discussion, but I want to share that I've had a positive experience at http://playdiplomacy.com

We have an ongoing series of games at work hosted by the wonderfully named service 'backstabbr.com'.

This is not the same thing, but you might be interested in taking a look at the excellent online Terra Mystica implementation (https://terra.snellman.net/) if you haven't seen it already.

It's a web interface, but the underlying representation is text-based, and you can type in the commands directly if you want. This leads to some nice features--for example, you can plan your moves several steps ahead of time, and you get a game log for free.

There creator wrote a blog post about that particular design decision: https://www.snellman.net/blog/archive/2014-12-08-command-lan...

Yeah, in my experience having a pure text interface proves to be a very complex design challenge but it enables so much cool stuff. One interesting side effect is that it makes writing bots quite simple.

You might be interested in http://gamesbyemail.com/

I've played a lot of Mergers on there, and that's actually what inspired me to make my own. It's not pure PBE as it just uses emails for notifications and you make your plays in the web interface.

From days of old, I used to play on gamerz.net - http://www.gamerz.net/pbmserv/ While some of them have graphical views now, in days of old it was all monospace ascii in an email message. The game there that I especially enjoyed was Firetop Mountain - http://www.gamerz.net/fm/Main/

This is really cool, thanks for sharing.

How do you find Rust for this code base compared to Go?

The main reason why I wanted to switch from Go to Rust was I was finding the type system a bit too weak for game implementations. There were even some games I was having trouble implementing at all without resorting to `interface{}` throughout the data structures.

Rust has been a challenge but now that I'm fairly proficient it's very well suited to implementing the game data structures. Parsers are much more pleasant to implement in Rust too; I've written a custom parser combinator for game input and it's much easier to handle input in Rust than it is in Go.

I, as well, don't love go and I prefer rust especially for the type system.

I would like to hear the negative side of switching from go to rust.

It's not that I don't like Go, it definitely has its place, but for this particular use case I found it a little painful.

Personally, the things I really missed after moving to Rust are quick compile times and very high quality editor plugins. These are areas which the Rust community are putting a lot of effort into at the moment though so I'm hopeful they'll continue to improve.

Would you care to write an "Experience Report" for benefit of the Go community and development future?

Pretty, pretty please!

The rationale and idea is described on https://blog.golang.org/toward-go2#TOC_5.3. and https://blog.golang.org/toward-go2#TOC_8. , with an important note to later "publish it" (i.e. just link) on https://golang.org/wiki/ExperienceReports.

Yours seems to be an awesomely perfect case — a real-world situation, with additional case study of how a new language helps you solve the pain points!

Reply on news.ycombinator.com