Turn-based Game Plug-In Ideas


(fearlessfrog) #1

Our discourse is forum is doing well and we’ve built an enjoyable community around flight sims and games. Thank you to the Discourse team for such an awesome and open project. :heart:

As an ex-games developer (consoles mainly, not really a web guy) I’ve tinkered with Rails/Ruby a bit (badly) and added some very small plug-ins to our site, themed around what we tend to talk about. We have a Steam Store oneboxer (now in Discourse main I think), a METAR/TAF weather bot that goes and gets aviation weather reports and even a Random Aircraft Quiz Bot that sort of works and uses Wikipedia. All very small things to play with here.

I’ve got a few weeks coming up free and had an idea I wanted to run by the developer community here. I’m looking for opinions and advice. Essentially I’d like to play around with some turn-based games, using forum posts as the inputs and outputs.

Q1. Is there anything like this already that I should go look at first?

The bare bones idea is using a special category in our forum (to stop it cluttering up other topics) where players can join a game and then post their ‘moves’. The game is a simple state machine and could start off as something simple as tic-tac-toe. The bot effectively listens for commands, in the context of a parent topic it knows has started and then moves the state along. It would post replies as the form of output, using simple tile graphics to show a ‘board’. Storage would just be a couple of extra models or even something serialized in the posts that’s hidden. Are there plug-ins that already store conversation ‘state’ in posts?

I’m just thinking about this generically at the moment, but if the idea is unclear here is a narrative example to show what I mean. Here’s forum users Bob and Alice playing a game, the < indicates automatic replies by the plug-in:

Bob: Play game #mudspike-not-risk

< You are entered to play Mudspike Not Risk. Awaiting more players.

Alice: Play game #mudspike-not-risk

< You are entered to play Mudspike Not Risk. Players ready to play or add more players?

Bob: Ready

Alice: Ready

< Welcome to ‘Mudspike Not Risk Don’t Sue Hasbro Please’. Place your pieces on the board. Type ‘help’ for game help and rules.

(imagine some Excel like 1,2,3, A, B, C fixed axis on these to the left and above).
image

Bob: Unit1 B2
Unit2 D4
Unit3 D8
Ready

< Bob Pieces placed:
(just imagine them placed, just plain image tiles or some z-order overlay :slight_smile:)
image

Alice: Unit1 E2
Unit2 F1
Unit3 C3
Ready

< Alice Pieces placed:
(just imagine them placed again :slight_smile:)
image

< Pieces all placed. Bob moves first.

Bob: Move Unit1 D1
Attack Unit1 D2
Ready

< Attack rolls starting…
< Bob’s Unit 1 rolls a 3, Alice’s defending Unit 3 rolls a 3.
< Alice Unit 3 wins.
< Bob - use ‘End Turn’ or continue attack’.

Bob: Rage Quit.
< I do not understand the command ‘Rage Quit’. Use the command help or ? to assistance.

So the actual ‘game’ isn’t that important (I can do that bit ok, I’ll start very simple) it’s more about the underlying ideas of if Discourse would be bendable for this?

Q2. Is this a stupid idea and I should stop now and feel bad? Explain my stupidity please. :slight_smile:


(Régis Hanol) #2

I don’t know of one. Search on GitHub, maybe there’s one?

It’s not a stupid idea. I guess it all depends on the size of the game state you have to store. If it’s small, using custom fields should be fine. Otherwise, I would store the data in the database.


(fearlessfrog) #3

I couldn’t find much, but was thinking if anyone had already had a crack at it then they would probably travel through here.

Most of the unknowns for me are around the basic usability and worth of the idea, and for that it’s probably just ok to go build it small and find out. The main flaw is moving an interactive game state into a conversation flow; that is a little awkward. While it’s fun for others to watch along (peanut gallery for games etc), it only lends itself to ‘open board’ type games like chess.

The contact points with Discourse via the plug-in API are pretty light, in that apart from on(:post_created) and traversing the post then it’s pretty much plain ol ruby. My main lang is C++, so part of this is having some fun getting better at plain ol ruby objects. I am toying with some interactivity on the Ember side of things (just to reduce the command parsing awkwardness for usability with some direct clicks etc), but thar be dragons :dragon: for me on that side of things, so will limit it just to make it a bit more self-contained, i.e. learn one thing badly at a time.

For state storage, are Discourse plug-ins free to add their own model/db migrations and such? Is there a complex existing plug-in already that does that well that I could follow?

EDIT: plugin/instance.rb has all the answers:


#4

Sounds like a really interesting exercise … who knows what you might come up with.

btw, something related I worked out. Not multiplayer, unfortunately, but a lot less work!:


(James Kiesel) #5

I think its a neat idea.

It occurred to me that using either webhooks or a plugin which fires on the post_created event would allow you to interact with an api (and maybe apis for more well-known games like chess or tic tac toe already exist) that could be called and respond accordingly with game state, or written in the programming language of your choice etc.

That way
A. Your discourse instance isnt storing game state
B. You could have multiple ‘clients’ other than discourse, so people could play by email or WhatsApp or whatnot.


(fearlessfrog) #6

I agree, and the old gamedev in me has started with a client/server split just to keep the ‘core’ separate from the beginning out of habit anyway. I see the touch-points with Discourse being pretty clean, in that my ConsoleClient and DiscoursePluginClient are not that dissimilar so far.

The part I’m not sure about on how far to stretch the custom_field stuff I’m using just to spike this out. The custom text PG value per Topic, per Post, used by Discourse, and some serialization, means that I can store enough in there not to bother with a separate DB store so far. I can match up a new Discourse Topic with a new Game instance and store my ongoing state that way. The ‘Game’ model effectively uses a DiscourseStorageStrategy if I change my mind later and need to move it to AR or something.

I’ll put up a Tic Tac Toe progress so far up on Github when it’s playable. So fun it has been enjoyable to do and play around with. A lot of my time has been bike shedding with MacOS and docker, so that always takes longer than I plan. :slight_smile: