WildWestOnline

Prototyping a game engine for the Bang! card game

Trading card games: a form of competitive activity played according to rules. It is turn based, cards have properties and have rules. Currently, there is no effective way to prototype trading card games and then be able to test the workings and the implications of rules in these games.

Defining Cards with DSL: Domain-Specific Languages (DSLs) are specialized computer languages tailored for a specific domain. They produce concise and intuitive programs, making it easier for both programmers and non-programmers to read, write, and understand the language.

Key Features

• Game DSL
• Serializable game
• Support classic Bang!
• Support extensions
• Replay
• Multiplayer online

MetaModel

• Game: Global metaclass which contains all elements in a game.
• Player: Players who are participating in a game.
• Card: Cards that are used in a game. Cards can have multiple properties, define additional rules, have actions that can be played and have side effects that happen when they are being played.
• Action: Any action changing the game state. It can be performed by the user or by the system.
• Effect: Action applied when playing a card. An Effect may be resolved as a sequence of actions
• Selector: Selectors are used to specify which objects an effect should affect.

graph TD;
    GAME(Game) --> PLAYER(Player);
    GAME --> CARD(Card);
    GAME --> QUEUE(Queue);
    CARD --> ACTION(Effect);
    QUEUE --> ACTION;
    ACTION --> ACTIONTYPE(Type);
    ACTION --> PAYLOAD(Payload);
    ACTION --> SELECTOR(Selector);

Loading

Card DSL

So basically,

• cards can set some attributes on its own (maxHealth, weapon etc)
• it can trigger actions on event
• it becomes active in certain conditions
• it can also change behavior of other card or even system mechanics

Here’s a quick taste of the card effect DSL used to define Bang! content. Playable card: Stagecoach — draw 2 from deck

extension Card {
    static var stagecoach: Self {
        .init(
            name: "Stagecoach",
            type: .playable,
            description: "Draw two cards from the top of the deck.",
            effects: [
                .init(
                    trigger: .cardPlayed,
                    action: .drawDeck,
                    selectors: [
                        .repeat(2)
                    ]
                )
            ]
        )
    }
}

Effect solving

• The process of resolving an effect is similar to a depth-first search using a graph
• Some effects may be blocked while waiting for user input. Then options are displayed through state.

graph TD;
    N1(1) --> N2(2);
    N2 --> N3(3);
    N2 --> N6(6);
    N3 --> N4(4);
    N3 --> N5(5);
    N6 --> N7(7);
    N6 --> X6(/);
    N1 --> X1(/);

Loading

Modular Architecture

This project uses a modular architecture, dividing functionality into focused feature modules:

• Core: Self-contained Domain and Business logic (AppFeature, GameFeature, SettingsFeature, SettingsClient)
• Data: Data acces layer (CardsClientLive, SettingsClientLive)
• UI: Feature UIs (HomeUI, SettingsUI, GameUI, AppUI)
• Utilities: Supporting libraries (Redux, Utils, Theme)

 graph TD;
    APP(App) --> UI(UI);
    APP --> DATA(Data);
    UI --> UILIBRARY(Library)
    UI --> CORE(Core);
    DATA --> CORE;
    DATA --> DATALIBRARY(Library)

Loading

Redux-Style State Management

The Redux module implements a unidirectional data flow, making app state predictable and testable. This pattern is utilized throughout core and UI modules.

Redux architecture is meant to protect changes in an application’s state. It forces you to define clearly what state should be set when a specific action is dispatched.

• There is a single global state kept in store.
• State is immutable.
• New state can be set only by dispatching an action to store.
• New state can be calculated only by reducer which is a pure function.
• Store notifies subscribers by broadcasting a new state.
• Each side-effect is implemented as an asynchronous action.

graph TD;
  subgraph Main
    View --> Action
    Action --> Reducer
    Reducer --> State
    State --> View
  end
  subgraph Background thread
    Reducer --> Effect
    Effect --> Action
  end

Loading

Store projection

The app should have a single real Store, holding a single source-of-truth. However, we can "derive" this store to small subsets, called store projections, that will handle a smaller part of the state for each Screen. So we can map back-and-forth to the original store types.

flowchart TD
APP[App] --> APPSTORE(Store)
APP --> |compose| VIEW(View)
VIEW --> |observe| STOREPROJECTION(StoreProjection)
STOREPROJECTION --> |derive| APPSTORE

Loading

Online gameplay diagram

sequenceDiagram
    User->>UI: event
    UI->>Engine: action
    Engine->>State: update
    State-->>UI: notify
    State-->>AI: notify
    AI->>Engine: action
    Engine->>State: update
    State-->>UI: notify

Loading