V4 Architecture

Development
1

This is a follow-on to the V4 Motivation and and Goals article.

The V4 architecture will have a group of services providing support for a reference game app implementation and other auxiliary functions such as website status pages. A modular architecture should facilitate building and testing V4 capabilities, as well as making it possible to scale as needed or swap out implementations without disturbing the system as a whole.

Services

Several services will support user account management, notification, browsing and searching a game library, finding games, and managing game state.

All services will meet the following requirements:

  • Every service will have a JSON REST API
  • Every service will be rate limited
  • Every service will support pagination for any endpoints likely to return much data

User Management Service

A user management service provides a way for users to register and manage their accounts.

If we are providing authentication, we need to support:

  • registration, including confirmation by email
  • password recovery

We need to support:

  • user avatar
  • user nickname (need not be the same as account name?)

Notification Service

A notification service provides access to messages. Messages have individual users as recipients.

Game Library Service

A game library service provides access to a collection of available game modules. For each game module, metadata, a URL for a game box image, and a URL for the game module file should be provided.

Game Management Service

A game management service provides access to a collection of ongoing games. Games must be searchable by user, name of game, name of game instance, ctime, mtime, whether they are public or private, whether active/completed/inactive. The game management service should provide access to game metadata and a URI for retrieving game state or joining an active game, as well as the ability to register new games.

Game Service

A game service provides access to the state of an ongoing game. A game service can load a game log and send and receive game state changes. In cases where no trusted third party is required, one of the players may host the game service.

Apps

Player App

A player app interfaces with the various services to display game information and accept moves.

The player should have an interface for browsing and searching game libraries and downloading modules, with the possibility of connecting to multiple library providers.

Editor App

An editor app facilitates creation and editing of game modules.

4 Likes
2

Very good statement. Thanks for breaking up the tangled V3 into more manageable things.

Additionally, you have to be very precise in your nouns for this service oriented architecture. I think your “Game Library” is a good noun for things in your library (represented by modules). However, I think Game Management and Game nouns might use some refinement. Perhaps Game Management is a good noun (and might provide stats for all games created, in progress, or completed), but Game might be made better as Game In Progress or something for people to spectate or take on a player side.

For apps, I would appreciate that a player app would accept automated players that could accept and make moves, could validate moves according to rules, or other automated observer player apps that could log a game so people could discover a good game log and view what happened. All these would be optional for game modules, but I think well received for well done games.

Good job, this is really an improvement!

3

Sounds good.

I would also consider the following:

Registration:

  • account creation & login using external services like Google and Facebook

Game Service

  • For offline play, the player will also serve as the host
  • For secure/trusted play, are we considering that it will be mandatory to be online?

I’m also creating a document with the features and functionalities to be considered in the app.

Here’s the link for reference.

It’s a work in progress and I will be updating it as I progress and get feedback.

2 Likes
4

A very good document, and we both have made comments on it. Thanks.

Related to V4, each service should show what objects it manages. Most of these things are already baked into V3: games, players, boards, pieces, cards, dice, etc. I assume every object would have the basic CRUD (create,retrieve,update,delete) APIs. Additionally, I would love listeners for all of CRUD actions and also other “verbs” (such as moved,flipped,drawn,rolled) so you can get a notification when a game is created, game has ended, piece is moved, card is drawn, dice are rolled, etc.

1 Like