云风的 BLOG

这个月玩了许多游戏，有电子游戏也有桌游。主要是想更好的理解卡牌构筑类游戏的设计点，回答我自己在设计过程中的一些疑问。今天写一篇关于卡牌构筑类游戏的总结。

卡牌构筑类的电子游戏引爆于 2017 年的 Slay the Spire 杀戮尖塔（它或许受到了 2014 年 iOS 上 Dream Quest 的启发），启发了数以千计的类似游戏诞生。追其源头，是从更早的桌游开始。所以，我对这个类型的桌游做了一些研究。对于有兴趣的同学，我推荐 Youtube 上的 How to design a DECK BUILDING board game ，它做了非常不错的总结。我也是在看完这个视频后了解到一些过去没玩过的桌游。

桌游中的卡牌构筑机制，始于 2007 年的星际争霸。这是当年我最喜欢的桌游之一，曾经几个周末都和朋友玩它。它的缺点是需要特别大的桌面空间，还有几个肯花一下午时间玩上一盘游戏的朋友聚在一起。如今，大场地易得，玩友却几乎无法筹齐了。当时在玩的时候，尚未意识到其中的战斗卡牌玩法开创了一个新机制，只是觉得有趣：在游戏中，随着科技升级，可以从卡池中购买一些新的高级的战斗卡放到自己的牌库中，增加或增强自己战斗获胜的几率。这似乎是一个比扔骰子更好的随机方案，在此之前，同样需要花一整天玩的桌游 Axis & Allies ，就需要反复在骰子塔中哗啦啦的扔骰子。

真正第一个围绕这个游戏机制设计的桌游是 2008 年的 Dominion 领土。在领土之前，也有诸多用不同卡牌构筑成一个玩家自己的牌库的游戏。例如经典的万智牌和游戏王。但它们最大的区别是，万智牌这样的玩家牌堆构筑过程是在游戏开始之前，而领土这样的游戏是以固定几张基础牌组成的牌库开始，在游戏过程中逐步完善自己的牌库。这给了玩家全新的体验：不仅需要用精心组合的卡牌击败对手，还要选择合理的成长线路。在 BoardGameGeek 网站上，把万智牌的组卡机制称为 Deck Construction ，而将领土的机制归为 Deck, Bag, and Pool Building 。本文讨论的是后者，在这个机制分类中，构筑的是卡堆中的卡片还是黑布包里的指示物并不重要。它们都是把玩家每次选择的可能性放在一个黑箱中抽取，玩家可以自主的在游戏过程中改变这些选择的可能性：购买新的卡片、升级、销毁已有的卡片。btw, 玩万智牌的同学跟我说，万智牌玩家也不总是提前组好自己的牌去和别人玩，临时开包轮抽组卡也是一个特别流行的玩法。这个轮抽机制在 BGG 上被列为 Closed Drafting ，和它差不多的机制还有把卡片公开摆放在桌面上，玩家轮流选择，被称为 Open Drafting 。

Dominion 于桌游就像 Slay the Spire 于电子游戏一样，卡牌构筑机制迅速的启发了大量的新游戏，各种细节被不断的打磨、和其它游戏机制整合在一起。现在打着这个标签的桌游超过了 4000 个。为什么这个机制如此吸引玩家？我觉得卡牌构筑机制就像 RPG 游戏的升级过程，不同的是，成长的不是玩家操作的角色的各项数值，而是一组卡牌。玩家可以在短短的几十分钟内就能享受到这种成长过程。卡片又是一个极好的游戏规则载体：它可以把不同新奇的游戏元素写在卡片上，减少了玩家一次性学习全部游戏规则的成本。同时，抽取卡牌的机制让玩家同一时间面对的选择变少：玩家只能从手牌中的行动中做选择，而游戏本身却可以设计更多的玩法，却不需要一下全扔给玩家。相比传统的扔骰子制造的随机性，牌堆的管理给了玩家更好的掌控感：概率是不断变化的，可以随游戏进程被玩家操控控制。

阅读全文 "卡牌构筑类游戏小结" »

云风 提交于 08:00 PM | 固定链接 | 留言 (4)

这个月我一直在做具体的游戏设计。因为以前从来没有真正独立设计过游戏，比我预想的难很多。

上次提到 ，我想做一个基于卡牌构筑（ deck building ）玩法的 Roguelike 游戏，但并非杀戮尖塔这样的卡牌战斗 （card battler ）游戏，而更接近缺氧这种生存建造为主的玩法。游戏的题材还是 之前的构想 ：维护一艘太空飞船在银河中探索。

经过一长段时间的思考，在扔掉了成打的点子，本子上涂写了半本手稿后，我感觉在这个游戏的设计上又推进了一点，现在有了一些更具体的玩法设计。今天总结记录一下：

阅读全文 "一个卡牌构筑游戏的构想" »

云风 提交于 05:17 PM | 固定链接 | 留言 (9)

十月底的周末带娃去岩馆抱石时就觉得不太对。左脚的大拇指根部隐隐作痛，爬了几条线就歇着了。第二天自己去爬高墙，好像更严重了点，干脆回家休息。

这几年体检查出来尿酸过高（500+）。医嘱是注意饮食，已经没再喝酒，也不吃海鲜和动物内脏这些高嘌呤食物了，虽然我挺喜欢吃的。这次不算是第一次疼，去年疼过一天就好了。但这次比较严重。感觉和那几天有朋友从江苏快递了几只大闸蟹有点关系。接下来几天左脚明显肿了，几乎无法走路。脚很疼，不过尚在可以忍受的范围内，比不了那次尿道结石 的痛苦。我乐得在家打游戏，反正出门是不用想了。

阅读全文 "痛风" »

云风 提交于 12:52 PM | 固定链接 | 留言 (10)

在马山攀岩的最后一天，异星工厂的太空时代扩展包发售了。回到家中就开始玩，肝了 300 个小时，前天晚上终于通关了。准确说是系统告诉我赢得了游戏，但我知道后面还有很多事情要做。和原版一样，虽然发火箭名义上赢得了游戏，但白瓶科技是在火箭之后才有的；这次抵达了星系边缘就告诉我赢得了游戏，但钷素科技包（黑瓶）的原料都没见到。不过，我得暂时放一放，最近在这个游戏上花掉了所有时间，都没做别的事情。先写一篇总结，最近的体验太多，需要记录一下。不然热乎劲过了就忘了。

虽然太空时代最精彩的部分在五个风格迥异的星球，让玩家体验不同的方式玩这个游戏。但我想先谈谈 2.0 在基础系统上所做的工作。

阅读全文 "异星工厂太空时代游戏总结" »

云风 提交于 02:16 PM | 固定链接 | 留言 (3)

最近去了一趟南宁马山县。攀岩一周，身体很累，心里很舒服。这周除了爬石头，什么都没想，脑子全部放空了。

“一款好游戏，胜过两款伟大游戏”…… 这世上最容易做的就是“多”，如果我们不小心，就可能会把三四款游戏都塞进一个游戏里。有时候，决定什么内容不该加到游戏里，比决定什么内容该加进入更加总要。—— 《席德梅尔的回忆录》

这几天，读了本书《席德梅尔的回忆录》：《文明》是在陪产假中诞生的，它一开始更像是《铁路大亨》的延续，一个全球规模的《模拟城市》，一个实时模拟游戏。它开发了很久都没有找到正确的方向，一度项目被搁置。而重新继续这个项目后，经过了搁置期的思考，才试着将其改为回合制游戏。

席德还有款失败的作品《恐龙游戏》，他从 1991 年开始鼓捣这款游戏的原型，到 2000 年第 6 届 E3 展后彻底放弃。一开始几个版本像是恐龙版文明，核心玩法是基因衍化，但随机基因突变并不好玩；其后简化了复杂的规则，却变得很无聊。“好像不是你在玩计算机，而是计算机在玩你。如果游戏要一下子表达太多东西，那简化游戏设计会有帮助；但如果你在一款回合制游戏上投入了足够多的时间，你就会希望能够控制所有有趣的决策”。

回合制走不通，游戏原型转为了即时制。席德之前就有一款成功的即时制游戏《葛底斯堡战役》。但这个《恐龙争霸》却因为恐龙题材难以嫁接足够多的远程武器以至于无法平衡。

然后，这款恐龙游戏又演化成了口袋妖怪，或是更接近恐龙万智牌。平平无奇的“借鉴”让这款游戏毫无新意。卡牌形式很好玩，但是“这些卡牌的互动方式与《万智牌》太像了。如果你能加入自己的想法，那借鉴一点创意是可以的，但我从来不觉得恐龙游戏有足够多的新元素可自证清白。”席德忍受不了这一点，最终彻底放弃了这个项目。

阅读全文 "一些进展" »

云风 提交于 03:57 PM | 固定链接 | 留言 (2)

“首先，设计师创建了一些游戏机制。然后，他们把这些游戏机制用一些具有代表性的虚构元素包装起来。在游戏过程中，这些机制之间会产生一系列事件。这些事件会触动玩家潜意识中的触发器，从而激发出情感。最后，这些情感交织到一起，变成了一种综合的体验。” —— Tynan Sylvester 《Designing Games: A Guide to Enginerring Experiences》

我非常认同 Rimworld 作者 Tynan 对电子游戏的定义：游戏是一种制造体验的人工系统。游戏用一种工程手段制造体验，目的是激发人类的情感。在《体验引擎》的书中论述，追踪情感的真正源头非常困难，因为情感的触发由大脑的潜意识处理，自动表达的。即使不知道为什么会产生某种情感，我们的理性还是会想当然的为之安排一个原因。这些想当然的原因往往是错的。这种现象被称为情感错位，因为情感错位的存在，想要了解游戏如何影响我们是十分困难的事情。

我最近把游戏开发工作中的具体实现停了下来。因为我意识到，游戏核心固然是设计一些机制，程序实现可以把这些机制做出来并加以测试，但游戏机制只是手段而不是目的。我对游戏设计的理解还不够，所以还需要继续以设计游戏的角度去挖掘游戏深层次的东西。以游戏爱好者的角度去玩那些好评如潮的游戏体会游戏带来的乐趣是不够的，还需要多玩一些毁誉参半但制作者有自己想法的作品。当然，还需要回避一些仅仅是把已有游戏换一个虚构层做出来的仿冒品。

成为好的 Designer 之前，必须做一个更好的 Gamer 。我相信自己比之前是一个更好游戏玩家。因为相比之前，我可以更快的学习游戏规则，忽略游戏的表象，直接去感知作者想表达的东西。玩一些 steam 上只有几个评价且好评率不高的游戏，即使是半成品，对我来说也不算是太难的事了。具体游戏的评价，我大多直接写在 steam 上，而这里，我想记录一些最近想到的比较形而上的总结。

阅读全文 "我对电子游戏的分类" »

云风 提交于 02:03 PM | 固定链接 | 留言 (7)

这个月没有写什么程序。月初停下手头的开发工作，花了一周时间，作为 Indieplay 评委试玩了 200 多个参选游戏中的 100 多个。这个工作暂停之后，我就对前两个月对自己想做的游戏产生了许多疑惑。虽然写了不少代码，但仅限于基础玩法的外在功能：我实现了一整套类似边缘世界和缺氧里的工人系统，让小人可以在场景中活动起来，采集物资，建设建筑。让机器可以通上电运转起来，把原料加工为成品。但这些似乎只是一种模拟过程，而并非游戏。

我感觉自己对游戏到底想展现怎样的游戏体验没有清晰的认识。虽然在这篇采访中 也提到，（缺氧的最初设计是）“希望整个游戏运行在一个开放的（虽然简单的）模拟之上”。但我觉得模拟毕竟不是游戏，难以给玩家提供丰富的游戏体验。或者说，至少对于我这样的玩家，没有清晰的游戏目标和挑战是不行的。而且，实现一个丰富的游戏环境模拟面临的挑战我现在还无法评估，至少在当下，这不是我优先想做的东西。

我给游戏定下的基调是基地建设加生存挑战类型，或许应该有一些资源管理和 Roguelike 元素。工人管理或自动化元素是我比较喜欢的，但玩过几千小时类似游戏后，我感觉这些元素只是给予玩家体验的一种手段，并非目的。单独玩某个特定玩法，或许也能有趣，但体验却会大相径庭。

阅读全文 "最近玩的几个游戏" »

云风 提交于 04:47 PM | 固定链接 | 留言 (12)

我独自开发游戏已经有三个月了。这三个月里，我是 Ant Engine 唯一活跃用户，这是一个很好的机会来挖掘对于一个独立游戏开发者来说，引擎哪些地方有缺失。现阶段，我还是希望把精力放在游戏开发上多一些，所以引擎方面恰恰够用就好。虽然，完善引擎这件事做起来会更愉快，因为这些工作对于我比较顺畅，容易想清楚，游刃有余；而一个人开发游戏，更多的时候是手跟不上心而产生的烦闷。

我还是想挑战一下自己，把游戏设计好，实现好。引擎方面的事情，把想到的东西先记录一下。或许完成手头的游戏项目，沉淀更多，再回头做引擎，愉悦感更强一些。

首先，可视化编辑器 对我来说不重要。所以暂时就不维护了。我更需要的是一些快速验证眼下游戏设计中想法的功能，这些就在游戏 demo 中顺带实现就好，看起来没必要放在编辑器里。这和现阶段没有美术参与也有关系。因为对我自己做独立游戏来说，我不在乎开发进度，先做美术还是后做美术，区别不是很大。本来我自己就喜欢传统 roguelike ，几个 ascii 字符就能脑补所有的美术表现。我想，游戏原型阶段就不需要美术在编辑器里做创作了，用一些几何体就够用。这也是为什么我在三个月前最先完善的就是 Ant 引擎中预制几何体 这个功能的原因。

我在使用 Ant 引擎的时候，发现因为缺乏具体 API 文档而只能不断的阅读源代码（毕竟有很多模块不是我自己动手写的，无法全部了然于心）。而且并非每个模块的设计都满意，这让我经常有修改引擎的冲动。做了一段时间后，我找到一个方法来解决这个开发问题。我可以额外再做一个精简版的框架，按目前开发游戏的需求，从最基本的功能做起，逐步完善。这样就能隔绝引擎已经做好的部分：好用的模块直接做一些浅封装，有问题的部分可以多花些精力做不侵入（破坏老代码）的改进。

本来根据游戏类型的不同，使用引擎的方式就会有很大差异。我希望可以有不同的这样的框架针对具体类型游戏做二次封装。这样，在二次封装上写游戏的花，后面就可以更放心的裁剪底层实现。我更希望让 ECS 框架还原成更原始的设计：面向数据，避免添加太多的辅助模块。

阅读全文 "Ant 引擎的一些改进计划" »

云风 提交于 11:21 AM | 固定链接 | 留言 (31)

我在用 C 构建项目，尤其是和 Lua 混合使用时，一直很头疼 C 没有一个统一的模块管理器。Lua 的模块管理虽然简单，但毕竟有且够用。一种方法是把 C 模块封装成一个个 Lua 模块，让 Lua 帮助管理，每个 C 模块是独立的，相互不可见。

但当 C 模块之间发生关系时，就比较麻烦。当然，简单的方法是通过链接器把它们都链接在一起，通过函数名前缀以区分。或是利用操作系统的动态库加载器来管理模块。

最近有了一点有趣的想法，觉得一个最简的模块管理器其实复杂度并不高。花了半天功夫实现了一下，感觉还不错。

https://github.com/cloudwu/cmod/

阅读全文 "一个简单的 C 模块管理器" »

云风 提交于 06:14 PM | 固定链接 | 留言 (3)

我倾向于在 C 程序里使用整数 handle ，而不是指针。尤其是需要做弱引用的时候。

我认为，一个好的 handle 生成算法，应该满足：

1. 即使 handle 被销毁了，它这个数字也应该被保留，不应该被新的 handle 复用。posix api 里的文件 id 就不符合这一点。
2. 提供一个 api 可以判断一个 handle 是否有效，其时间复杂度为 O(1) 。
3. 从 handle 对应为对象的内存地址的时间复杂度应该为 O(1) ，不应该比指针有明显的性能问题。虽然 hash 表理论上可以满足 O(1) 的时间复杂度，但在糟糕的场景（hash 碰撞发生时）并不能保证这一点。
4. 构造 handle 时间复杂度也为 O(1) 。
5. handle 的数字位宽最好不要超过 32 bit 。

阅读全文 "32 位 handle 的一种生成方法" »

云风 提交于 03:44 PM | 固定链接 | 留言 (10)

这两天思考了一下，基于工厂生产的基地建设类游戏给玩家提供的核心体验到底是什么？以及，我们去年被取消的游戏到底还差点什么。接下来我要制作的游戏的注重点应该在哪里。

我玩的时间比较长的两个基地建设类游戏：异星工厂和缺氧，它们的玩法其实差异很大，但却给人一些近似的体验。对于这个问题，我想过很多次，得出的结论是，它们的确有一些共通之处：

玩家在玩这两个游戏时的情感体验过程非常类似，大致是这样的：

阅读全文 "基地建设（工厂）类游戏的玩家体验" »

云风 提交于 09:14 PM | 固定链接 | 留言 (4)

游戏行业从业 20 多年，一直在做底层开发，即使是帮助其他团队写上层游戏逻辑，也都是实现某些特定的功能模块。直到最近，我想单独开发游戏，才好好想想架子该怎么搭。

从最初的原始 demo 开始，由于缺乏经验，写着写着经常有失控的感觉。好在一个人做，重构的心理负担不大。想改的时候，停下来花上两三天全部重写也不太所谓。最近总算顺畅了一点，感觉需要整理一下思路，所以写一篇 blog 记录一下。

任何复杂的软件问题，都可以通过拆分为若干子问题减少复杂度。

我认为，游戏的上层逻辑，即 gameplay 部分，主要分为三块：数据模型、外在表现和人机交互。

“数据模型”是 gameplay 的核心部分，即把游戏的画面等外在表现以及图形界面、操作控制（鼠标键盘控制器等）等剥离后的东西。如何判断一个模块是否属于数据模型，是否有不属于它的部分没有拆分出去，最简单的方法是看它是否有直接调用游戏引擎的代码。拆分干净后，这块不应该包含任何与图形、界面、时钟、控制输入有关的接口。除了一些必要的文件 IO 接口（主要是用来读取 gameplay 相关的策划数据，写 log ，做数据持久化等），也不应该涉及任何 OS 的 API 。

这样，我们就可以方便的对它进行整体或局部的测试。必要时还可以更换游戏引擎，甚至从文本 roguelike 换到 3D 表现都不会受影响。

“外在表现”当然是指游戏的画面表现、声音声效等等，通常这由游戏引擎实现，但还会有大量的代码存在于 gameplay 的实现中。这一块代码也会维护大量的状态，但不会涉及数据持久化。简单的判断方法是：如果游戏保存进度时，所有这里的所有状态都可以舍弃，下次读取进度后，这些状态又能被重建，而玩家不会感觉丢失了任何数据。

“人机交互”是游戏软件必要的部分，如果没有“人”的存在，游戏也就没有意义了。这块分为两个部分：图形界面用于展示游戏的数据给人看，同时接收一些来至界面的间接输入；控制器（包括并不限于手柄鼠标键盘触摸屏等）对游戏的直接控制。

对于联网游戏，还应包括第四大块：“网络输入”。这篇 blog 仅讨论非联网游戏。

阅读全文 "gameplay 框架设计总结" »

云风 提交于 01:57 PM | 固定链接 | 留言 (11)

在矮人要塞 like 的游戏中，都有一套基于工人的任务分发系统。玩家通常不能像 RTS 中那样直接操作工人去工作，而是对要做的事情下达任务，等着工人自主去完成。

由于任务数量通常远多于工人数量，这个任务分发系统中大多配有优先级设置，可以让诸多任务有条不紊的进行。调整优先级变成玩家主动操控的渠道。初玩这类游戏，会有点不习惯：感觉难以在微观层面直接做自己像做的事情。像捡块石头放进指定仓库这件事，无法像玩 RTS 游戏那样，先点选工人，再针对石头发出拾取指令…… 但习惯之后，恐怕又回不去了。比如我在玩 Ratopia 时，就对操控鼠王直接干活烦躁不已。

这类游戏，我玩的时间比较长的有三个，按时长排序为：缺氧 (ONI) 、边缘世界 (Rimworld)、矮人要塞 (DF)。其它如 Songs of Syx 、Prison Architect 等很多也有所涉猎。其实，这些游戏在设计工人任务系统的细节上也有所不同。

以我游戏时长最长的缺氧和边缘世界相比较，同样是提供玩家主动操控的能力：Rimworld 可以给工人的任务队列直接下达指令（这更接近 RTS 的玩法），而 ONI 则是通过给单个任务本身排优先级实现的。ONI 设计了警报级任务，可以越过一切优先级设定，强制立刻完成。虽然 ONI 也保留了指挥单个小人移动到指定位置，但实际游戏中几乎没什么用。

对于拾取物品，Rimworld 可以封禁、解禁单个物品，而 ONI 没有这个设计。ONI 的工人几乎不会主动把地上的东西搬入仓库，除非下达清扫指令。

这些细节的不同，可能来源于作者设计时的思维轨迹，很大程度上也取决于游戏的其他玩法。例如 Rimworld 偏重手控成分很重的战斗，而 ONI 没有战斗成分。Rimworld 强调人物之间的情感联系，ONI 里的都是工具人。

我比较喜欢 ONI 的系统，打算用这个规则打底设计自己的游戏。下面是设计的草稿：

阅读全文 "工人任务分配系统" »

云风 提交于 03:49 PM | 固定链接 | 留言 (5)