Elissataire

Overview

A Gift That Grew

Elissataire began as a simple Christmas gift; a personalized solitaire game featuring custom playing cards designed by my siblings, each depicting aspects of our mom's life.

The project evolved into a full solitaire framework supporting three distinct game modes -- Klondike, Spider, and TriPeaks -- each with their own rules, layouts, and win conditions. The modular design allows for easy addition of new variants while maintaining consistent card behavior and deck support.

Three Solitaire Variants

Klondike (Classic)

The solitaire everyone knows. Seven tableau piles with alternating colors, building foundations from Ace to King. Features both draw-1 and draw-3 modes with stock recycling and scoring.

Spider

Ten tableau columns with 104 cards across two decks. Three difficulty levels control suit complexity -- from single-suit for beginners to four-suit for experts. Complete same-suit runs from King to Ace to clear the board.

TriPeaks

A pyramid of 28 cards with a unique blocking system -- cards can only be played when uncovered. Match cards one rank higher or lower than the waste pile, with King-Ace wrapping for maximum strategy.

Personalized Decks

Each of my siblings designed their own deck with room to expand for new memories. The ScriptableObject-based deck system makes adding new decks effortless. I just assign 52 sprites and a card back, and the game handles everything else.

Systems Architecture

The codebase is built around the Strategy Pattern, allowing game rules and layouts to be swapped at runtime without modifying core card behavior. This separation of concerns made adding new variants straightforward while keeping the codebase maintainable.

┌─────────────────────────────────────────────────────────────────┐
│                         GameManager                              │
│  • Coordinates game state, UI updates, and mode switching       │
│  • Creates/destroys layout prefabs at runtime                   │
│  • Routes player actions to appropriate rule systems            │
└─────────────────────────────────────────────────────────────────┘
                              │
         ┌────────────────────┼────────────────────┐
         ▼                    ▼                    ▼
┌─────────────────┐  ┌─────────────────┐  ┌─────────────────┐
│   IGameRules    │  │  ILayoutManager │  │    BasePile     │
│  (Interface)    │  │   (Interface)   │  │  (Base Class)   │
└─────────────────┘  └─────────────────┘  └─────────────────┘
         │                    │                    │
    ┌────┼────┐          ┌────┼────┐              │
    ▼    ▼    ▼          ▼    ▼    ▼              ▼
┌──────┐┌──────┐┌──────┐┌──────┐┌──────┐  ┌─────────────┐
│Klond-││Spider││Tri-  ││Klond-││Spider│  │  Tableau,   │
│ike   ││Rules ││Peaks ││ike   ││Layout│  │ Foundation, │
│Rules ││      ││Rules ││Layout││      │  │Stock, Waste │
└──────┘└──────┘└──────┘└──────┘└──────┘  └─────────────┘

Technical Highlights

Spider's Same-Suit Run Validation

Spider solitaire has a unique constraint: you can only move stacks of cards if they form a descending same-suit run. This required implementing a "trapped card" system that visually indicates which cards are immovable due to suit breaks above them.

TriPeaks Blocking System

The TriPeaks pyramid requires a blocking map—each card knows which cards must be removed before it becomes playable. I implemented this as a dictionary mapping card indices to their blockers, updated dynamically as cards are removed.

Polished Interactions with DOTween

Every interaction has carefully tuned animation feedback: cards scale on hover, shake when invalid moves are attempted, and smoothly animate to their destinations. Complete suit runs in Spider trigger a satisfying cascade animation as cards fly to the foundation.

Technical Challenges

Unified Card Behavior Across Modes

The biggest architectural challenge was making CardVisual work seamlessly across three very different game modes. Klondike uses selection-based movement, Spider requires run validation, and TriPeaks uses click-to-play. The solution was a mode-aware click handler that routes to different behaviors:

Runtime Layout Switching

Switching between game modes required a clean teardown/setup cycle. Each layout is a prefab with a LayoutPrefabReference component that auto-discovers its piles on instantiation. The GameManager destroys the old layout, creates the new one, and reassigns all references—making mode switching feel instant.

Future Development

Elissataire continues to grow as a family project. Planned additions include:

Reflection

What began as a simple Christmas gift became an exercise in scalable game architecture. Building Elissataire taught me the value of planning for extensibility -- the Strategy Pattern paid dividends when Spider and TriPeaks were added in a fraction of the time Klondike took.

More than the technical lessons, this project reminded me why I make games: to create meaningful experiences for people I care about. One Spring Break during college, I confessed to my mom I had grown addicted to Spider Solitaire. I came to her genuinely concerned, and she just laughed and confessed that she had the same problem in her college years. Since then, Solitaire addiction has become an open problem in my family, and creating this game for my mom felt like a full-circle moment.