Simple Demonstration:

The Four Game Project is a computerized adaptation of the "Four" board game, designed to increase accessibility and enjoyment by offering features such as AI opponents, game saving/loading, and support for players with color vision deficiency. The digital version aims to broaden the game's reach, making it suitable for a diverse audience including children and those with accessibility needs.

Problem Statement

The physical version of the "Four" board game limits accessibility and gameplay options, requiring players to be physically present and able to distinguish colors. The digital version addresses these issues by enabling remote play, AI opponents, and color-blind friendly modes, thus making the game more inclusive and flexible.

Our Approach

The development of our Four Game project followed a structured, iterative approach divided into four one-week iterations. This methodology allowed us to progressively build functionality while maintaining quality and addressing risks throughout the development lifecycle.

Iteration Structure

Our development process was organized as follows:

Iteration 1: Foundation and Planning

• Created initial user interface design

• Developed Fully Dressed Use Case Descriptions for core gameplay:

  • Setting up the game

  • Player Taking Turns

• Constructed a comprehensive domain model

• Finalized the vision document outlining project scope and goals

Iteration 2: Core Implementation

• Coded elements from Iteration 1, resulting in minor releases V1 and V2

• Developed a functional prototype

• Created additional Use Case Descriptions:

  • Choose player settings

  • Rotate and flip a piece

• Produced sequence diagrams for visualization of interactions

• Developed class diagram to structure code architecture

Iteration 3: Feature Enhancement

• Upgraded the game to include Iteration 2 functionalities (released as V3)

• Focused on user experience elements:

  • Choose display settings functionality

  • Place a piece functionality

• Created corresponding sequence diagrams and Use Case Descriptions

Iteration 4: Finalization and Quality Assurance

• Implemented all remaining elements from Iteration 3

• Achieved fully functional game status

• Conducted thorough JUnit testing for quality assurance

• Created networking documentation

• Documented design patterns implemented in the codebase

• Applied minor refinements based on testing feedback

• Released final version of the game

This incremental approach enabled us to manage project risks effectively while maintaining steady progress toward our vision of creating an accessible digital version of the Four board game with enhanced features and accessibility options.

Key Stakeholder & Interests

User Goals

• Start new games, choose modes and AI difficulty, save/load progress, view rules

• Access color-blind mode

• Use simplified instructions for kids2

System Features

• Human vs. human and human vs. AI modes

• Easy/Hard AI difficulty

• Save/load game

• Color-blind mode

• Runs on a single machine/terminal

• Simplified instructions

• Follows original game rules

Main Risks

• Building good AI for two levels

• Designing effective color-blind mode

• Implementing robust save/load

• Ensuring rules are followed

• Managing schedules and iterations

Information Expert

The Piece and Board classes use the information expert pattern. Each class manages its own data. For example, the piece handles its tiles, and the board manages its array of tiles.

Creator:
The creator pattern is used for tiles. Each piece creates its own tiles.

Low Coupling:
Classes only interact when necessary. For example, the board interacts with the selection class, which gets info from the player class, keeping dependencies minimal.

High Cohesion:
Game state aspects are separated into different classes (players, board, current player, selected piece) to keep each class focused.

Pure Fabrication:
The SaveGame class is a pure fabrication to handle saving, keeping this logic separate and maintaining cohesion and low coupling.

Protected Variations:
Protected variation is used to prevent code breakage. For example, instead of chaining getters, direct getters like getColour() are added.

Command / Command Holder:
Buttons use the command pattern to handle piece orientation and board actions, making it easy to expand controls.

Design Architecture

Accessibility and Optimization

We designed the Four Game to be accessible and efficient for all users. The game includes a color-blind mode and clear instructions to support diverse players. It is optimized to run smoothly on most systems, ensuring quick load times and responsive gameplay for an enjoyable experience.

Conclusion

The Four Game Project represents more than just a digital adaptation of a classic board game-it’s a leap toward inclusive, accessible, and modern gameplay for everyone. By transforming the traditional experience with smart AI, color-blind support, and flexible play modes, we are opening the doors for players of all backgrounds and abilities to connect, compete, and enjoy strategic fun wherever they are. Our iterative, user-focused approach ensures that the final product is not only robust and feature-rich, but also welcoming and engaging for a diverse audience. With this project, we’re not just preserving the spirit of “Four”-we’re reimagining it for a new generation of players.

Github: https://github.com/fahim-ysr/Four-Game-Project