Skip to content

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

1 Commit
 
 

Repository files navigation

Requirements Specification for Monopoly Bank

A Local Web App for Supporting Physical Monopoly Games

1. Introduction

Purpose

The "Monopoly Bank" application serves as a supportive tool for the classic physical Monopoly game. It provides a simple web-based interface to handle operations such as transactions, property ownership tracking, buying properties, paying rent, mortgages, and viewing game history, without replacing physical dice, money, or board elements. The app focuses on acting as a "transactions center" to reduce manual errors and enhance gameplay transparency.

Scope

  • In Scope: Core transaction management, property tracking, and session history for 2-4 players in a local network setup.
  • Out of Scope: Full digital simulation of Monopoly (e.g., no automated dice rolls, board movement, or rule enforcement beyond basic calculations like mortgage amounts). Variants of Monopoly rules are not supported.
  • The app runs locally via Docker, with a host player (acting as banker) starting a server that others join via browsers on phones or laptops.

Audience

This document is intended for developers implementing the app, as well as potential users or reviewers for validation.

2. MVP Overview

This section summarizes the essential features for the Minimum Viable Product (MVP), ensuring focus on core functionalities. Features are prioritized using MoSCoW (Must-have, Should-have, Could-have, Won't-have).

Feature Area MVP Essentials (Must-Have) Rationale
Game Sessions Create and join sessions via unique code or QR; Support 2-4 players; Host acts as banker with exclusive bank operations; End session when a winner is declared (locking further changes). Enables basic multiplayer setup and game lifecycle.
Properties Track ownership, price, mortgage status, houses/hotels; Allow viewing of all properties and their states; Support building houses/hotels per rules; Mortgage/unmortgage with automatic amount calculations. Provides visibility and management of key game assets.
Transactions Players start with $1500; Support bank-to-player and player-to-player transfers; Property purchases from bank or players; Reverse incorrect transactions. Handles core money and asset flows during play.
History & Balance Log all transactions with timestamps, players involved, and amounts; Allow players to check their current balance. Ensures transparency, auditability, and informed decision-making.

3. Functional Requirements

3.1 Core Features (MVP)

These are the must-have functionalities, grouped by area.

  • Game Sessions:

    • Must: Users create temporary accounts with a username to join.
    • Must: Host (banker) performs bank-exclusive operations on their machine.
    • Must: Players join via unique code or QR on local network.
    • Must: Limit to 2-4 players.
    • Must: Lock session after declaring a winner.
    • Should: Automatically assign starting capital ($1500) upon joining.
  • Properties Tracking:

    • Must: View information about any property (state, type, price, ownership, mortgage status, houses/hotels).
    • Must: Players build houses/hotels evenly across color groups per rules.
    • Must: Mortgage properties to receive half purchase price; unmortgage with 10% interest debit.
    • Should: Dedicated section for viewing personal properties.
  • Transactions:

    • Must: Bank and players transact with each other (e.g., pay rent, collect $200 for Go).
    • Must: Purchase properties from bank or other players at agreed prices.
    • Must: Reverse incorrect transactions to maintain accuracy.
    • Should: Automatic balance updates after each transaction.
  • History and Balance:

    • Must: Log all actions with timestamps, players involved, and amounts.
    • Must: Players view their current balance at any time.
    • Should: Filter history by player or type.

3.2 Post-MVP Features

These are enhancements to consider after MVP.

  • Host can approve/deny join requests.
  • Session recovery for interrupted games.
  • Require confirmation for transactions.
  • Export history to PDF.
  • Player profiles with game session history.
  • Turn notifications.

4. Non-Functional Requirements

  • Security: No authentication required for local play, but prevent unauthorized transactions via session codes and data integrity checks (e.g., validate inputs to avoid double-spends).
  • Usability: Intuitive interface, easy to navigate on mobile or desktop; responsive design.
  • Performance: Real-time transaction updates (<1s delay) via WebSockets; handle up to 4 concurrent users without lags.
  • Reliability: Track and display all movements to all players; offline-first support (e.g., queue actions and sync on reconnect).
  • Deployment: Ship as a isolated Docker container for local hosting.

5. Technical Requirements

Component Choice Reason
Backend Nest.js Handles APIs, real-time features, and business logic efficiently.
Frontend Next.js React-based.
Database PostgreSQL Relational database for structured data like transactions and properties; supports persistence.
Real-Time Communication WebSockets Enables live updates for balances, history, and notifications.
Deployment Docker Ensures easy local installation and isolation.

6. User Stories

These stories describe key features from the user's perspective, prioritized for MVP. Each is concise with brief acceptance criteria.

  1. As a user, I want to join a session via QR code to connect easily.
    Acceptance: Scan → Enter username → Join with $1500.

  2. As a player, I want to view my balance for game decisions.
    Acceptance: Real-time updates post-transactions.

  3. As a player, I want to transfer money/properties to pay debts or buy.
    Acceptance: Select details → Submit → Update balances/history.

  4. As a player, I want to view full transaction history.
    Acceptance: Log with filters, accessible to all.

  5. As a player, I want to see all property info (state, price, etc.).
    Acceptance: Searchable list.

  6. As a player, I want a dedicated view of my properties.
    Acceptance: With mortgage/build options.

  7. As a host/banker, I want to transfer assets to players.
    Acceptance: Banker UI → Auto-log.

  8. As a player, I want to mortgage properties for cash.
    Acceptance: Select → Auto-credit half price.

  9. As a host, I want to reverse incorrect transactions.
    Acceptance: Select txn → Undo → Restore state.

7. Game Rules Integration

The app supports (but does not fully enforce) standard Monopoly rules. Key rules integrated:

  • Bankruptcy Rule: If bankrupt to another player, transfer all assets; if to bank, bank seizes assets. (App: Manual declaration, auto-transfers.)
  • Winning Rule: Last remaining player is winner; session locks. (App: Host declares via UI.)
  • Evenly Building Rule: Houses must be built evenly across color groups. (App: UI warns on uneven builds but allows manual override.)
  • Building Hotels Rule: Hotel after four houses; houses removed. (App: Auto-update property status.)
  • Mortgaging Properties Rule: Receive half purchase price. (App: Auto-calculate and credit.)
  • Remove Mortgage Rule: Debit mortgage value + 10% interest. (App: Auto-debit on unmortgage.)

Rules not automated (e.g., auctions) are handled physically.

8. Appendices/Notes

  • Assumptions: Standard Monopoly board/properties; no custom variants. All players on same local network.
  • Glossary: Txn = Transaction; Host = Banker role.
  • Open Questions: How to handle property auctions? (Post-MVP consideration.)
  • Notes: This document focuses on MVP essentials; expand as needed based on feedback.

About

web development project

Resources

Stars

0 stars

Watchers

0 watching

Forks

Releases

Packages

Contributors