Pattern Oriented Software Design — Term Project

Card Game：turn-based chikawa

Team Members:

• 113598040 柯瑞霖
• 113598086 陳俞安
• 113598095 程翔

---

problem statement：

在現代快節奏的生活中，人們需要一種簡單但富有策略性的遊戲來放鬆心情，並同時提供與朋友互動的機會。然而，許多現有的卡牌遊戲要麼過於複雜，讓新玩家難以上手，要麼缺乏趣味性，導致玩家興趣容易消退。

主要問題包括：

1. 學習門檻高：現有的卡牌遊戲通常規則繁瑣，對新玩家不友好。
2. 缺乏創新性：許多卡牌遊戲重複舊的玩法，難以引起玩家的興趣。
3. 缺乏可愛和有趣的主題：許多卡牌遊戲的設計偏向硬核風格，難以吸引更廣泛的玩家群體，特別是喜歡輕鬆可愛風格的玩家。
4. 互動性不足：玩家之間的交流常被遊戲過於複雜的機制所限制。

我們希望設計一款以可愛的「chikawa」角色為主題的回合制卡牌遊戲，結合簡單易懂的規則和富有策略性的玩法，解決上述問題，並讓玩家在遊戲過程中體驗到可愛角色帶來的樂趣與與人互動的價值。

Description

一個以知名動漫<<吉伊卡哇>>為主題的網頁卡牌遊戲，我們以此卡牌遊戲來練習如何適當的應用 design pattern 來改善程式框架和在各種不同情況下，要如何使用 pattern 來解決問題

戰鬥外

• 玩家可以在此遊戲中抽牌
• 玩家可以使用在遊戲中抽到的卡牌來構成自己的牌組
• 玩家可以使用自己構建的牌組和敵人(奇美拉)戰鬥

戰鬥內

玩家回合

• 玩家可以在此遊戲中抽牌
• 打出多種類型的卡片
  • 角色卡 : 召喚角色到場上
  • 效果卡 : 可以對角色治療、增加攻擊、賦予新能力
  • 法術卡 : 對敵方指定目標進行攻擊
• 結束回合時場上角色會對敵人進行攻擊

敵人回合

• 敵人會對我方角色進行攻擊、對敵方角色進行治療
• 敵人會依不同情境採取不同行為

Future

調整戰鬥平衡，目前玩家太過強勢 新增關卡模式，使玩家有一個遊戲目標 加入課金系統???? 💯

Technique

• Spring Boot
• java Web

Class diagram

Sequence diagram

BattleController

showBattlePage

endPlayerTurn

drawCard

playCard

undo

UpdateCardDisplay

checkGameOver

GameController

showGameHomePage

toCards

toDeckPage

addCardToDeck

removeCardFromDeck

toDecksPage

drawCard

Design Patterns Summary & Storyboard

uml_pattern

story

Design Patterns in Our Code

Factory

• Motivation: 在我們的遊戲中，有三種不同類型的卡牌（角色卡、效果卡、巫術卡），每種類型可能包含多種具體卡牌。我們需要一種簡潔的方式來管理和創建這些卡牌實例，並確保它們的生成邏輯對使用者是透明的。
• Solution: 我們使用一個靜態的 cardPool 作為共享的卡牌模板池，並提供一個靜態方法 createCard(String name)，可以直接根據卡牌ID 返回對應卡牌的複製實例。這種方式避免了重複創建相同的卡牌物件，節省了資源。
• Consequence: 在創建卡牌時，可以直接使用卡牌的ID來生成對應的卡牌物件，簡化了卡牌的創建過程，並且降低了系統耦合度，易於擴展。但若卡牌模板池內的卡牌過多，可能增加記憶體的佔用。

Singleton

• Motivation: 在遊戲中，我們需要某些資源（如卡牌模板池或全局配置）只有一個實例，確保資源的唯一性和共享性。這樣可以減少資源浪費並統一管理，避免多個實例造成的不一致性。
• Solution: 使用 Singleton Pattern，確保 CardFactory 只有一個實例，並提供一個全局的訪問點。透過私有化構造方法並提供一個靜態的 getInstance 方法來獲取實例。CardFactory 通過 Singleton 確保只存在一個工廠實例，管理全局的卡牌生成邏輯。
• Consequence: 可以有效節省資源並統一管理，並確保 CardFactory 只有一個實例，但會引入全局狀態的依賴，可能增加系統的耦合性，進而降低測試的靈活性。

Command

• Motivation: 在遊戲中，不同的卡牌會執行特定的操作，例如對敵人造成傷害、召喚角色或撤銷該操作。隨著卡牌行為的複雜度增加，將操作封裝成獨立的命令物件可以提高系統的靈活性和可擴展性，並提供操作的撤銷功能。
• Solution: 使用 Command Pattern，通過抽象介面 Card 定義通用操作（play() 和 undo()），並由具體的卡牌類（如 SpellCard）實現具體行為。這樣卡牌的行為被封裝成命令並可以被執行者統一調用。play() 負責執行命令，而 undo() 提供撤銷功能。
• Consequence: 新的卡牌行為可以通過擴展 Card 類輕鬆添加，而不影響其他部分的代碼。但隨著卡牌種類增加，可能導致大量類別影響管理。

Decorator

• Motivation: 在使用效果卡時，可能會使得場上的角色有新的能力，但又不希望改變其結構或修改原始類別。Decorator 模式通過包裝並提供附加行為，實現功能的靈活擴展。
• Solution: 根據不同的附加能力定義不同的類別同時此類別繼承CharacterCard，新能力在各類別中自行新增定義。
• Consequence: Decorator 模式提供了比靜態繼承更大的靈活性。它允許將功能添加到單個物件中，而不會影響同一類中其他對象的行為。

State

• Motivation: 遊戲是一個狀態機，有各種不同的戰鬥階段，在不同的階段中有相似的行動要跳到不同狀態。遊戲運營可能需要隨著不同活動增減狀態或跳轉邏輯，因此使用 State 模式可以更加容易的擴展。
• Solution: 在介面 BattleState 定義所有轉移方法，並在各種狀態實作該有的轉移邏輯。將 BattleState 注入到 BattleManager，並在 BattleManager 中增加所有轉移方法，每個方法都委託給 BattleState。
• Consequence: 將狀態與行為耦合分離，更容易擴充或修改