Godot卡牌游戏框架：一小时搭建可交互对战原型-三亩地-编程学习日记

1. 项目概述：为什么需要一个卡牌游戏框架？

如果你正在用Godot引擎琢磨着做一款卡牌游戏，无论是像《杀戮尖塔》那样的DBG（牌库构筑）肉鸽，还是想复刻《炉石传说》的TCG（集换式卡牌）对战，你大概率会卡在同一个起点上：如何让一张“卡牌”在游戏里活起来？这不仅仅是画一张漂亮的PNG图片那么简单。一张卡牌需要能被鼠标或手指拖拽、旋转、缩放，需要能响应点击事件来“打出”，需要能在牌桌、手牌、牌库、墓地等不同区域间移动，并且附带攻击力、生命值、费用、卡牌描述文本等动态数据。当你需要管理几十上百张这样的卡牌，并处理它们之间复杂的交互逻辑时，从零开始编码会迅速变成一个令人头疼的泥潭。

这就是“卡牌游戏框架”存在的意义。它不是一个限制你创意的“模板”，而是一套预先构建好的、可复用的核心系统。它帮你处理好了所有枯燥、重复但必需的底层工作——比如卡牌的物理表现、输入交互、状态管理和区域逻辑——让你能把宝贵的开发时间集中在游戏最有趣的部分：设计独特的卡牌效果、构建平衡的数值体系和打磨核心玩法循环。网络上提到的“Card Framework”资产就是一个典型的例子，它提供了一个轻量级、可扩展的起点。而本指南的目的，就是带你深入这套逻辑的内核，不仅教你如何使用现成的框架，更重要的是让你理解其设计思想，从而具备定制和扩展的能力，真正在1小时内搭起一个专业卡牌游戏的坚实骨架。

2. 核心架构设计：拆解一个卡牌游戏的五脏六腑

在动手写第一行代码之前，我们必须像建筑师审视蓝图一样，厘清一个卡牌游戏需要哪些核心模块。一个健壮的框架通常采用基于节点和组件的模块化设计，这与Godot的节点树思想完美契合。

2.1 核心实体：卡牌（Card）的本质是什么？

在代码世界里，一张卡牌至少是以下三者的结合体：

数据实体（CardData）：这是一个纯数据的资源（Resource），通常继承自Resource类。它定义了卡牌的静态属性，如唯一ID、名称、费用、攻击力、描述文本、卡牌图标路径等。它不包含任何视觉或逻辑，只是一个数据的容器，可以被序列化保存（例如存盘或网络传输）。
视觉表现（CardVisual）：这是一个2D场景（PackedScene），通常以Control节点（如PanelContainer）或Node2D为根。它负责将CardData中的数据渲染到屏幕上：显示卡图、文字、数值等。它处理与外观相关的一切，如不同状态下的样式（手牌中的缩小版、战场上的放大版）、动画效果（抽牌、打出、死亡）。
逻辑控制器（CardController）：这是一个附加在卡牌视觉场景根节点上的脚本。它是卡牌的“大脑”，负责：
- 持有对CardData资源的引用。
- 管理卡牌的状态（在手牌、在战场、在墓地、被选中、可拖拽）。
- 处理输入事件（鼠标进入、点击、开始拖拽、结束拖拽）。
- 与游戏规则引擎通信（尝试打出卡牌、触发效果）。

这种数据-表现-逻辑分离的设计至关重要。它允许你轻松地更换卡牌美术风格（只需替换CardVisual场景），或者为同一张卡牌数据创建不同的视觉效果，而无需改动核心逻辑。

2.2 游戏区域（Zone）系统：卡牌的“家”

卡牌不会凭空存在，它们总是归属于某个区域。一个典型的框架会抽象出“区域”的概念。每个区域（如HandZone,DeckZone,BattlefieldZone,GraveyardZone）都是一个Node2D或Control节点，它负责：

空间管理：定义卡牌在该区域内如何排列（水平堆叠、弧形展开、网格布局）。
逻辑归属：判断一张卡牌是否“属于”这个区域，并触发相应的入场/离场事件。
交互规则：定义该区域内的卡牌是否可以被打出、被攻击、被拖拽。

区域之间通过信号进行通信。例如，当一张卡牌从HandZone被拖向BattlefieldZone时，HandZone会发出card_removed信号，而BattlefieldZone在接受到卡牌后，会发出card_added信号，并触发重新排列卡牌的动画。

2.3 游戏状态与规则引擎（Game Manager）

这是游戏最高级别的指挥官。它通常是一个单例（Autoload），负责：

初始化游戏：创建玩家，初始化牌库，洗牌，分发起始手牌。
管理回合流程：控制“回合开始”、“主阶段”、“战斗阶段”、“回合结束”等状态的切换。
执行游戏规则：这里是核心逻辑所在。当玩家试图打出一张卡牌时，Game Manager会进行裁决：费用是否足够？目标是否合法？时机是否正确？
处理效果解析：卡牌描述文本如“对敌方角色造成3点伤害”或“抽两张牌”，需要被解析并转化为具体的游戏指令。这通常通过一个“效果系统”来实现，每种效果（DamageEffect, DrawEffect, HealEffect）都是一个独立的可执行对象。

2.4 输入与拖拽系统

流畅的拖拽体验是卡牌游戏的灵魂。框架需要一套统一的输入管理机制，尤其是在支持多点触控的移动设备上。这套系统需要：

区分点击与拖拽：通过判断鼠标/触摸点移动的距离和时间阈值。
处理拖拽中的卡牌：将正在拖拽的卡牌置于所有UI之上，并可能显示一个半透明的“幽灵”图像。
实现区域检测：当拖拽结束时，系统需要检测卡牌释放在哪个区域上方，并通知该区域处理“放入”逻辑。
处理无效操作：如果卡牌被释放在非法区域，它应该平滑地动画回原始位置。

3. 一小时极速搭建：从零到可运行的卡牌对战原型

理论说得再多，不如动手搭建。下面我们以Godot 4.x为例，一步步构建一个最简化的、但包含完整交互循环的卡牌对战原型。我们的目标是：两个玩家，每个玩家有牌库、手牌、战场，可以抽牌、将手牌拖到战场打出。

3.1 第一步：项目初始化与核心场景创建（10分钟）

新建Godot项目，选择“Forward+”渲染器（适用于2D）。
创建资源文件夹结构：在文件系统中创建Scenes/,Scripts/,Resources/CardData/,Art/等文件夹，保持项目整洁。
创建卡牌数据资源（CardData）：
- 右键点击Resources/CardData/文件夹，选择“新建资源”。
- 搜索并选择“脚本”，创建一个新脚本，命名为card_data.gd。但更优雅的方式是先创建一个自定义资源。
- 新建一个脚本card_resource.gd：
```
# card_resource.gd extends Resource class_name CardResource @export var card_id: String = "" @export var card_name: String = "未命名卡牌" @export_multiline var description: String = "" @export var cost: int = 0 @export var attack: int = 0 @export var health: int = 0 @export var texture_path: String = "" # 卡图路径
```
- 保存后，你就可以在资源文件夹中右键“新建资源”，找到CardResource，并创建具体的卡牌数据资产，如card_fireball.tres，在其中设置名称、费用、描述等。

3.2 第二步：构建卡牌视觉场景与控制器（20分钟）

创建卡牌场景：
- 新建一个Node2D场景，保存为Scenes/Card.tscn。根节点命名为Card。
- 为根节点添加一个脚本Card.gd，这将作为我们的CardController。
设计视觉层：
- 在Card节点下添加一个Sprite2D节点，用于显示卡牌背景或卡图。将其纹理设为一张默认卡背图。
- 添加一个Label节点作为费用显示，调整位置到卡牌左上角。在检查器中为其创建一个唯一的名称，如CostLabel。
- 同理，添加显示攻击力、生命值、卡牌名称和描述的Label节点。
- 最后，添加一个ColorRect节点，覆盖整个卡牌，将其颜色设为透明，但鼠标筛选（Mouse Filter）设为“停止”。这个节点将作为我们检测输入事件的碰撞区域。为其添加一个CollisionShape2D子节点并设置矩形形状。
- 你还可以添加一个AnimationPlayer节点，用于后续的悬停、选中动画。

编写卡牌控制器逻辑（Card.gd）：

# Card.gd extends Node2D class_name Card # 导出的变量，方便在编辑器中链接 @export var cost_label: Label @export var name_label: Label @export var attack_label: Label @export var health_label: Label @export var description_label: Label @export var card_sprite: Sprite2D # 核心数据引用 var card_data: CardResource # 卡牌当前状态 enum State { IN_DECK, IN_HAND, IN_PLAY, DISCARDED } var current_state: State = State.IN_DECK # 引用所属的区域 var current_zone: Node = null # 初始化，用数据更新视觉 func initialize(data: CardResource): card_data = data update_display() func update_display(): if not card_data: return cost_label.text = str(card_data.cost) name_label.text = card_data.card_name attack_label.text = str(card_data.attack) health_label.text = str(card_data.health) description_label.text = card_data.description # 加载卡图 if card_data.texture_path: var tex = load(card_data.texture_path) if tex: card_sprite.texture = tex # 输入处理 - 鼠标进入 func _on_mouse_entered(): if current_state == State.IN_HAND: # 播放一个轻微上浮的动画，提示这张牌被聚焦 var tween = create_tween() tween.tween_property(self, "position:y", position.y - 20, 0.1) # 输入处理 - 鼠标退出 func _on_mouse_exited(): if current_state == State.IN_HAND: var tween = create_tween() tween.tween_property(self, "position:y", position.y + 20, 0.1) # 输入处理 - 开始拖拽（在鼠标按下时判断） func _on_input_event(viewport: Node, event: InputEvent, shape_idx: int): if event is InputEventMouseButton and event.button_index == MOUSE_BUTTON_LEFT: if event.pressed and current_state == State.IN_HAND: # 通知游戏管理器：开始拖拽这张卡 get_node("/root/GameManager").start_card_drag(self) # 将自己设为“正在被拖拽”状态，可以提升z-index或复制一个幽灵图像

> **注意**：这里我们使用了 `_on_input_event` 连接到 `ColorRect` 的 `input_event` 信号。更复杂的拖拽系统（如跨区域、无效放置回弹）需要游戏管理器统一协调，卡牌自身只负责触发事件和响应状态变化。 ### 3.3 第三步：实现区域（Zone）系统（15分钟） 1. **创建基础区域场景**： * 新建一个 `Node2D` 场景，保存为 `Scenes/Zone.tscn`。根节点命名为 `Zone`，附加脚本 `Zone.gd`。 * 添加一个 `Area2D` 节点作为子节点，并为其配上 `CollisionShape2D`。这个区域将用于检测被拖拽的卡牌是否被放入。 2. **编写基础区域逻辑**： ```gdscript # Zone.gd extends Node2D class_name Zone signal card_added(card) signal card_removed(card) @export var zone_type: String = "Generic" # 例如：Hand, Deck, Battlefield var cards_in_zone: Array[Card] = [] func add_card(card: Card): if not card in cards_in_zone: cards_in_zone.append(card) card.current_zone = self add_child(card) card_added.emit(card) rearrange_cards() # 重新排列卡牌 func remove_card(card: Card): if card in cards_in_zone: cards_in_zone.erase(card) card.current_zone = null remove_child(card) card_removed.emit(card) rearrange_cards() func rearrange_cards(): # 这是区域的核心功能之一：定义卡牌如何摆放 # 例如，手牌区水平等距排列 if zone_type == "Hand": var card_width = 100 # 假设卡牌宽度 var total_width = card_width * cards_in_zone.size() var start_x = -total_width / 2 + card_width / 2 for i in range(cards_in_zone.size()): var card = cards_in_zone[i] var target_x = start_x + i * card_width var tween = create_tween() tween.tween_property(card, "position:x", target_x, 0.3).set_trans(Tween.TRANS_BACK) tween.parallel().tween_property(card, "position:y", 0, 0.3) # 战场区可以按网格排列 elif zone_type == "Battlefield": # ... 网格排列逻辑 pass ``` 3. **实例化具体区域**：复制 `Zone.tscn` 多次，创建 `HandZone.tscn`, `DeckZone.tscn`, `BattlefieldZone.tscn`，并分别修改其 `zone_type` 导出变量。你还可以为它们添加不同的背景精灵以示区分。 ### 3.4 第四步：创建游戏管理器与整合（15分钟） 1. **创建游戏管理器单例**： * 创建脚本 `GameManager.gd`。在“项目设置 -> Autoload”中，将其添加为单例，名称设为 `GameManager`。 2. **编写核心游戏循环逻辑**： ```gdscript # GameManager.gd extends Node var player_hand: Zone var player_battlefield: Zone var player_deck: Zone var opponent_hand: Zone var opponent_battlefield: Zone var opponent_deck: Zone var current_player: String = "Player1" var current_phase: String = "Main" # Main, Battle, End var player_mana: int = 10 # 示例法力值 var card_being_dragged: Card = null var drag_ghost: Sprite2D = null # 拖拽时的幽灵图像 func _ready(): # 假设这些区域节点已经在主场景中，并通过路径或信号连接 setup_game() func setup_game(): # 1. 初始化区域引用（这里需要你根据实际场景结构修改） player_hand = get_node("Main/PlayerHandZone") player_battlefield = get_node("Main/PlayerBattlefieldZone") player_deck = get_node("Main/PlayerDeckZone") # ... 初始化其他区域 # 2. 构建牌库 var deck_list: Array[CardResource] = [] # 加载预先创建好的卡牌资源，例如： for i in range(20): # 假设牌库有20张牌 var card_data = load("res://Resources/CardData/card_example.tres") deck_list.append(card_data) # 3. 洗牌并填充牌库区域（这里简化，直接实例化卡牌） deck_list.shuffle() for data in deck_list: var card_scene = load("res://Scenes/Card.tscn") var card_instance: Card = card_scene.instantiate() card_instance.initialize(data) player_deck.add_card(card_instance) # 4. 初始抽牌（例如抽5张） for i in range(5): draw_card_for_player("Player1") func draw_card_for_player(player: String): var deck = player_deck if player == "Player1" else opponent_deck var hand = player_hand if player == "Player1" else opponent_hand if deck.cards_in_zone.size() > 0: var card = deck.cards_in_zone[0] deck.remove_card(card) hand.add_card(card) # 可以在这里触发一个抽牌动画 func start_card_drag(card: Card): if current_phase != "Main" or card.current_zone.zone_type != "Hand": return # 非主阶段或非手牌不能拖拽 card_being_dragged = card # 创建幽灵图像（可选） # drag_ghost = Sprite2D.new() # drag_ghost.texture = card.card_sprite.texture # drag_ghost.modulate.a = 0.7 # add_child(drag_ghost) func _input(event: InputEvent): if event is InputEventMouseMotion and card_being_dragged: # 更新幽灵图像位置 # if drag_ghost: # drag_ghost.global_position = get_global_mouse_position() pass if event is InputEventMouseButton and event.button_index == MOUSE_BUTTON_LEFT: if not event.pressed and card_being_dragged: # 鼠标左键释放 # 检测释放位置在哪个区域 var drop_zone = get_zone_under_mouse() attempt_play_card(card_being_dragged, drop_zone) card_being_dragged = null # if drag_ghost: # drag_ghost.queue_free() func get_zone_under_mouse() -> Zone: # 使用物理射线检测或遍历所有区域判断鼠标位置 var mouse_pos = get_global_mouse_position() for zone in [player_battlefield, opponent_battlefield]: # 检查所有可放置区域 if zone is Zone and zone.get_global_rect().has_point(mouse_pos): return zone return null func attempt_play_card(card: Card, target_zone: Zone): # 游戏规则裁决 if not target_zone or target_zone.zone_type != "Battlefield": # 放回原处 card.current_zone.add_card(card) return if card.card_data.cost > player_mana: # 法力不足，放回原处 print("法力不足！") card.current_zone.add_card(card) return # 规则通过！ player_mana -= card.card_data.cost card.current_zone.remove_card(card) target_zone.add_card(card) # 触发“入场”效果 on_card_played(card) func on_card_played(card: Card): print("卡牌打出：", card.card_data.card_name) # 这里可以连接更复杂的效果系统

构建主场景：创建一个Main.tscn场景，将实例化好的各个区域（手牌区、战场区、牌库区）拖入场景中，并排布好位置。最后，将Main.tscn设为项目的主场景。

至此，点击运行，你应该能看到一个基本的卡牌游戏界面：可以抽牌，手牌中的卡牌可以拖拽，拖到战场区域会消耗法力并放置，拖到其他地方则会弹回。一个最核心的循环已经完成。

4. 框架进阶与深度定制：超越基础模板

有了可运行的原型，我们就可以探讨如何将这个简陋的框架打磨得更专业、更强大。这涉及到架构的优化和系统的扩展。

4.1 效果系统（Effect System）的设计

硬编码的卡牌效果（如“造成3点伤害”）是不可维护的。我们需要一个灵活的效果系统。一种常见的设计是使用“命令模式”。

创建基础效果类：

# effect_base.gd extends Resource class_name BaseEffect # 所有效果都需要实现一个“解析并执行”的方法 func resolve(source: Card, target: Node = null, game_manager: GameManager = null): pass

实现具体效果：

# effect_damage.gd extends BaseEffect class_name DamageEffect @export var damage_amount: int = 0 func resolve(source: Card, target: Node = null, game_manager: GameManager = null): if target and target is Card: # 假设Card有一个take_damage方法 target.take_damage(damage_amount) print(source.card_data.card_name, " 对 ", target.card_data.card_name, " 造成了 ", damage_amount, " 点伤害")

# effect_draw.gd extends BaseEffect class_name DrawEffect @export var draw_amount: int = 1 func resolve(source: Card, target: Node = null, game_manager: GameManager = null): if game_manager: for i in range(draw_amount): game_manager.draw_card_for_player("Player1") # 这里需要更动态地确定玩家

在卡牌数据中关联效果：修改CardResource，增加一个效果列表。

# card_resource.gd (补充) @export var play_effects: Array[BaseEffect] = [] @export var death_effects: Array[BaseEffect] = []

在游戏管理器中触发效果：在on_card_played或卡牌被摧毁时，遍历并执行对应的效果列表。

func on_card_played(card: Card): for effect in card.card_data.play_effects: effect.resolve(card, null, self) # 这里的目标需要根据卡牌描述或玩家选择来确定

这样，你只需要在编辑器中为每张卡牌资源配置不同的效果实例和参数，就能实现千变万化的卡牌效果，而无需修改核心代码。

4.2 网络同步与状态同步（面向多人对战）

如果目标是制作在线对战游戏，架构需要彻底改变。核心思想是：游戏管理器不再拥有权威状态，而是作为一个客户端，接收来自服务器的权威状态更新，并负责渲染。

权威服务器：你需要一个独立的服务器（可以用Godot的高层网络API、ENet，甚至其他语言编写），它运行着完全相同的游戏规则逻辑，但只有它计算的结果是真实的。
客户端预测与回滚：为了流畅性，客户端可以预测自己的操作（如拖拽出牌），并立即在本地显示。如果服务器认可这个操作，则无事发生；如果服务器拒绝（如法力不足、非法目标），客户端需要“回滚”到服务器的权威状态。这非常复杂，是多人游戏开发的核心难点。
精简方案：对于回合制卡牌游戏，可以采用“锁步”模拟。每个操作（打牌、结束回合）都作为一个“命令”发送给服务器。服务器按顺序处理所有玩家发送的命令，然后将处理后的完整游戏状态广播给所有客户端。客户端收到状态后，完全根据这个状态重新渲染界面。这样避免了复杂的预测和回滚，但会有一点延迟感。

4.3 性能优化与批量处理

当战场上有上百个单位、手牌和牌库有大量卡牌时，性能可能成为问题。

对象池（Object Pooling）：不要频繁地instantiate()和queue_free()卡牌实例。在游戏初始化时，就创建好一个足够大的卡牌对象池。需要显示卡牌时，从池中取出一个闲置的并初始化；卡牌进入墓地或牌库“背面朝上”时，将其放回池中并隐藏，而不是销毁。这能极大减少内存分配和垃圾回收带来的卡顿。
绘制调用合并（Draw Call Batching）：Godot会自动对2D精灵进行批处理，但前提是它们使用相同的纹理和材质。确保卡牌背景、通用图标等使用图集（Texture Atlas），而不是大量分散的小图片。
避免每帧遍历：不要在_process里遍历所有卡牌来更新位置。位置更新应由区域（Zone）在卡牌增减时，通过Tween动画触发。状态检查（如检测卡牌死亡）可以在回合阶段切换时批量进行。

5. 实战避坑指南与心得分享

在真正用这套框架开发项目的过程中，你会遇到许多教程里不会提的“坑”。以下是我从多个项目中总结出的关键经验：

5.1 输入处理的“坑”：区分点击、拖拽与长按

Godot的输入事件流是：_input->_unhandled_input-> 特定节点的_gui_input或_input_event。对于卡牌这种既是UI（可点击）又是游戏对象（可拖拽）的元素，输入处理容易混乱。

最佳实践：将拖拽的发起判断放在卡牌节点的_input_event中（连接自Area2D或ColorRect）。一旦判定为开始拖拽，立即在GameManager中设置card_being_dragged，并消费掉该输入事件（get_viewport().set_input_as_handled()），防止事件继续传递。后续的鼠标移动和释放判断，统一在GameManager的_input或_unhandled_input中处理。这样逻辑清晰，职责分离。
移动端适配：移动端是InputEventScreenTouch和InputEventScreenDrag。你需要将上述逻辑适配到触摸事件上，并注意处理多点触控（通常只响应第一个触点）。Godot 4的InputEvent系统已经做了很好的抽象，很多情况下InputEventMouseButton和InputEventScreenTouch可以共用逻辑。

5.2 动画与状态同步：别让画面“抽搐”

当你同时改变卡牌的数据（如生命值从5降到3）和其所属区域（从战场到墓地）时，如果顺序不当，动画会打架。

黄金法则：先处理逻辑状态，再触发视觉动画。例如，一张卡牌死亡时：
1. 游戏管理器将其从战场区域的cards_in_zone列表中移除。
2. 将其逻辑状态标记为DISCARDED。
3. 然后，通知战场区域播放该卡牌的“死亡动画”（例如旋转缩小、变透明）。
4. 动画播放完毕后，再通过信号通知墓地区域接收这张卡牌（此时卡牌可能已经隐藏或重置位置）。
使用Tween和Signal：Godot的Tween节点和信号系统是制作流畅动画的利器。为每一个重要的状态转换（移动、翻转、缩放、销毁）都创建对应的动画函数，并让动画在完成时发出信号。其他逻辑（如从内存中移除对象）应等待这个完成信号，而不是假设一个固定的动画时间。

5.3 数据管理与序列化：如何保存一局游戏？

你的CardResource是Resource，可以被轻松保存。但游戏中的Card实例节点是无法直接序列化的。你需要建立一套映射系统。

游戏状态快照：创建一个GameState资源类，用来保存某一时刻的游戏状态。它应该包含：
- 玩家信息（生命值、法力值、手牌数量上限）。
- 每个区域中卡牌的card_id数组（顺序很重要）。
- 战场上每个卡牌实例的额外状态（如当前攻击力、生命值、是否具有“嘲讽”等临时效果）。
保存：在保存时，遍历所有区域，将其中卡牌的card_id和实例数据（如当前生命值）记录到GameState中，然后使用ResourceSaver.save()保存为一个.tres文件。
加载：在加载时，读取GameState，根据card_id从资源库中加载对应的CardResource，然后重新实例化Card节点，并用保存的实例数据覆盖其初始数据，最后将它们添加到正确的区域中。这个过程就像是按照清单重新摆一盘棋。

5.4 扩展性思考：当框架不够用时

你可能会发现，框架的Zone系统无法很好地处理“奥秘”区（悬于战场上的隐藏卡牌），或者“装备”区（附着在其他卡牌上的卡牌）。这时，不要强行修改基础框架，而是考虑组合与继承。

创建新的区域类型：继承自Zone，创建SecretZone和EquipmentZone。在SecretZone中，重写rearrange_cards方法，让卡牌以背面朝上、重叠的方式排列。在EquipmentZone中，你可能需要维护一个卡牌与宿主卡牌的映射关系。
使用组件系统：Godot 4的节点系统本身就是一种组件模式。你可以为卡牌添加额外的功能组件。例如，创建一个EquipmentComponent脚本，附加到卡牌上，它负责处理装备的“佩戴”和“卸下”逻辑，以及提供额外的属性加成。这样，基础卡牌框架完全不用关心“装备”是什么，它只管理卡牌的移动和显示，而具体功能由组件提供。

记住，一个好的框架不是铁板一块，而是一套乐高积木。它提供了最常用、最稳固的部件（卡牌、区域、管理器），并留下了清晰的接口和扩展点。你的创意，就是用它搭建出独一无二城堡的过程。一小时搭建的只是一个毛坯房，但有了坚实的地基和清晰的蓝图，内部的精装修和加盖楼层，就全凭你的想象力和技艺了。

日记详情

Godot卡牌游戏框架：一小时搭建可交互对战原型