Multi-player gopher game system
I find it interesting that I stumbled upon this capsule and specifically this subspace when I did.
I recently started designing a game "system" (for lack of a better word at present) for Gopher to allow multi-player turn-based game engines to be written in a more-or-less UI agnostic way (which means they could theoretically be ported to Gemini or to the Web with little to no change). A game engine will provide the game logic and handle input (user actions) and output (text to display and a list of user actions/moves) through a programming interface, and the game system will handle the actual user input and output through generated Gopher menus.
So with a chess game, for example, when a player wants to view their game through Gopher, the chess system would send a "view" action to the game engine, the game engine would respond with text representing the chess board (possibly as ASCII art) and a list of possible actions back to the game system, and the game system would generate and respond with a menu containing the text and action links (menu items) back to the user. Then if the user selects one of the actions, the process would repeat but with the action the user selected rather than a "view" action. Games like chess can take a move as text input, so such an action would be a composite of "move" and the user's input (e.g., "d2d3"). The text input for an action would be provided by a type `7` menu item in Gopher.
The game system will also take care of managing users/players (authentication) so the engine doesn't have to. One of my design goals for this game system is to simplify user interactions and to minimize storing user information on the server, so a user will provide a secret (a "password"), and that secret will be used to generate their user name with a one-way process; in other words it'll use tripcodes. (The Gemini version could instead use a client certificate to identify a user. I came up with the tripcode mechanism for Gopher, which doesn't have client certificates.)
Also, since a user might accidentally (or not so accidentally) refresh a game page after they perform an action (thus sending the same action request to the server again), the game system will verify that the user actually makes a new move through the use of move tokens. A token is generated for each new move and is included in the request of each move. A token is invalidated when a move is made. The game engine will be informed whether the provided token is valid with each action so can do whatever makes sense (e.g., simply treat it like a "view" action); the game engine will also return whether the token should be invalidated (i.e., after the player makes a valid move).
I'm already thinking of a few games that could be written with this system:
- Chess
- Rock-paper-scissors
- Risk
- MTG
- Solitaire (yep, it can also support single-player games)
(Of course, I'm an expert at starting projects but not finishing them, so this project may never come to fruition. If I do end up writing actual code I may just post it to source hut or codeberg or whatever and let anyone run with it who's interested.)
Thoughts?
2025-10-15 · 7 months ago · 👍 dragfyre, travisshears
3 Comments ↓
🚀 mbays · 2025-10-15 at 20:19:
Sounds good. I implemented a gemini game system a while ago with a similar separation of concerns. Some of it is quite gemini-specific, but maybe you could get some ideas from it. The "game engines" are just executables/scripts called by the system with appropriate arguments.
🦂 zzo38 · 2025-10-16 at 19:14:
Another game can be Pokemon, in which case players select their moves simultaneously; a player will select a move (for one or two active pokemons, depending if it is single or double battle) without knowing the opponent's selection, and then after both players make all of their selections then the moves will be executed. Before the game starts, players must submit the teams (except for random battles).
(Rock paper scissors (and variants such as "restricted rock paper scissors" with cards) is also based on simultaneous moves.)
📻 Christopher [OP] · 2025-10-16 at 23:25:
@zzo38 yep, I thought of that. The game engine can easily hold on to players' moves and then execute/reveal them once all players have made a move. My game system won't have to do anything special to support that type of game.