# DG Game

This folder contains documentations for games that this server can support,
both technical and business logic. Currently, we have:

- [Dice HiLo](https://hackmd.io/@tomm/dice1)
- [Dice Sicbo](https://hackmd.io/@tomm/dice3)
- [Dice Big Or Small](https://hackmd.io/@tomm/dice3_mini)
- [Wheel](https://hackmd.io/@tomm/wheel)
- [Roulette](https://hackmd.io/@tomm/roulette)
- [Slots](https://hackmd.io/@tomm/slots)
- [Baccarat](https://hackmd.io/@tomm/baccarat)
- [Poker High low](https://hackmd.io/@tomm/hilo)
- [Rock, paper, scissors](https://hackmd.io/@tomm/rps)
- [Hoo hew how](https://hackmd.io/@tomm/hhh)
- [Zodiac Racer](https://hackmd.io/@tomm/zodiac)

Note despite the project name `cards`, but there's other type of games
as well, and we will split this server into multiple services in future, if
needed.

Some game are easy, can be done within the scope of a single request. Some are
pretty complicated.

## Conventions

### Naming

Each game has a project-wide unique code name. Example: `dice_1`, `dice_3`,
... So that when you read the code (filename, constant, handler, tables), ...
you can immediately know which game it's for. Whenever adding new game,
be sure to assign it a unique and understandable code name.

### DB tables

Each game usually has following DB tables:

- `<code-name>_config`: store game config per Partner, and also serve as indicator
for whether Partner can provide this game to their user.

- `<code-name>_game_record`: store user betting data per games. Simple games
like `dice_1` might have just one level (`dice_1_game_record`). Games like
`dice_3` have a complex bet structure, in which one bet contains multiple
sub-bet, each can be either `Win`, `Lose`, `Draw`, .... Thus, they require
multiple game record level, i.e: `dice_1_game_record` for "big" bet, and
`dice_1_bet_record` for sub-bet.

The naming convention is:

- 1st level: `*_game_record`.
- 2nd and deeper levels: up to you, as long as it makes sense.

## Game types

### Single API games

In this type, user just submit a bet, and we "roll the dice". It's simple,
hence, it's the first game type we had done.

Example in our system:

- `dice_1`
- `dice_3`
- `dice_3_mini`

### Multiplayer games

Example in our system:

- `dice_1_multi`: 3 players can join a rooms together and bet on the same dice
number

Multi player games has suffix `_multi`, for example `dice_1_multi`. This type
of game is when a user is aware of other users activities when they're
playing together, against each others, or against our system. For more
detail, see next sections [Multiplayer games](#multiplayer-games). This type
requires websocket support and has much more complicated logics.

This type of game is the **top selling point** of our system, since not many
team can build this. And this will eventually be our main focus.

#### Common retractions

- Player can't play a same `_multi` game on different devices. This is to
prevent the case that a user can join the game as 2+ players and then to
control the game result at his will.

- Player can't play different `_multi` games on the same devices. The app
should already handle this logic. This note is mainly a reminder to check
when implement API.

- Player of different partners should not be able to play together. Different
partners have different configurations that can affect our processing. And,
it doesn't make sense to allow this use case, from partner perspective.

### Timing games

Example in our system:

- `dice_1_timing`

Timing games has suffix `_timing`. This type of game is similar to `_multi`, in
which many users can play together again our system. But it's "rooms" concept
is much wider. It allow scope allow many users to play (usually all user of a
Partner can place bet on same result). Its logic is simpler than the `_multi`
variants, but the amount of data we need to proces for each game is much
bigger.