《请修复后再运行》开发日志2：当一把程序员，体验修bug的乐趣

家人们好呀！我是一个人参加 Taptap 聚光灯的开发者 agoo，今天想跟大家唠唠这款以“修复 Bug”为核心的 Meta 解谜游戏在技术实现上的那些事儿。我特别希望玩家能通过真实的电脑文件操作，好好体验一把调试项目的乐趣，当然其中还有一些荒诞的小惊喜。这篇日志主要给大家分享我在 MessageBox、控制台项目和管道通信上的技术实践，希望能给其他开发者朋友们一些启发！

游戏的核心就是让玩家直面“报错”，所以我直接用了 Windows 的原生错误弹窗来模拟真实的程序崩溃提示（绝对不是我懒得自己做一个弹窗界面）。就像游戏启动时，会弹出一个超经典又让人头疼的错误窗口：“缺少 MSVCP140.DLL 文件！”

在 Unity 里要显示 Windows 原生弹窗，得用 PInvoke，只要提前声明一下函数就行。不过，获取游戏自身窗口的句柄 hWnd 比较麻烦，因为 Unity 没有提供相关 API。我的办法是先获取线程 Id，再用线程 Id 反向找出窗口句柄。

为了让玩家有“亲手调试程序”的感觉，我设计了一个独立于游戏窗口的伪控制台界面，模拟开发者在命令行里排查问题的过程。这是个.Net 控制台项目，玩家可以通过它查询不同 bug 的解决办法。

在游戏设定里，这个控制台是当年独游团队的程序员离职前写好的，方便其他团队成员排查和修复一些基本的 bug。这里我采用了类似《Her Story》的电脑查询系统，玩家需要输入自己遇到的 bug，然后系统会匹配出最符合的几个，并给出实际的解决办法。

当然啦，控制台可是游戏的核心，后面还打算穿插游戏的叙事，这部分内容我会在下一篇开发日志详细说说。

在.Net 中有不少优秀的控制台开源项目，我用的是 Spectre.Console，地址是：https://spectreconsole.net/ ，真的强烈推荐，非常好用。

由于游戏窗口和控制台窗口是两个独立的窗口，从程序角度讲就是两个独立的进程，在玩法上这两个进程需要互相沟通，这就需要用到一些进程通信的技术。我用了 Windows 的命名管道（Named Pipes）。

在 Windows 下用命名管道做进程通信不算难，我在控制台程序那边启动了管道服务器，Unity 这边启动管道客户端，两边 Connect 一下，后续就可以直接收发数据了。唯一要注意的就是，管道收数据一般是在独立线程中收的，而 Unity 是单线程的，所以收数据时要先加锁，回到主线程再处理数据。

这篇开发日志涉及到的都是一般游戏开发者不太会用到的技术，所以我觉得挺有分享价值的，说不定对哪个开发者朋友有用呢。我是因为早年上大学时学过 Windows 编程，写过 MFC（这真暴露年龄了），所以这些技术基本都学过，没想到这么多年后这些技术又有用武之地，哈哈。

说实话，这个游戏其实非常实验性，非常 meta，我都担心它算不算一款游戏。这段时间我花在这些技术实现上的时间很少，大部分时间都用在给游戏写背景设定上了，所以其实这是一款叙事向的解谜游戏，关于叙事这部分，我会在下一篇开发日志展开聊聊。

#TapTap聚光灯独立游戏 #聚光灯gamejam开发者日志