引言
国庆跳脱舒适圈抽空和小伙伴们一起组队参加了72小时的LudumDare游戏开发比赛，完成了一款挺满意的作品，拿出来炫耀一下（不是）和大家分享一下，希望能收到更多评论和评分，也在此记录一下开发历程。
欢迎大家来试玩：https://ldjam.com/events/ludum-dare/49/deepwell-safety-inc
作者：六氟化鼬 https://www.bilibili.com/read/cv13471969?spm_id_from=444.41.0.0 出处：bilibili
酷炫的主菜单：
游戏演示gif：
游戏一图流介绍：
我是负责程序的@izaya，小队成员4人（1策划、1美术、2程序），都是步入社会的社畜了（虽然没多久），感觉是很适合game jam的平衡配置了。由于之前也参加过大大小小的各类game jam的经验，所以这次参加国外party性质的LD，本身目的就是尝试一下新鲜事物，和国外游戏开发同行相互试玩作品和交流评论。因为LD作品发出来，稍微发几篇po都有很多热心的英文彩虹屁留言，而且比赛本身也没有功利性质，就是个party。
由于时差的原因和相比48小时更宽裕的72小时流程，10月2号早上6点开始的比赛，小伙伴们也约了9点多在开发地点碰头，开始了一上午的头脑风暴。最后基于主题Unstable的“不稳定”的解读，敲定下了一个以操控格子方块（俄罗斯方块）堆叠存储策略为核心的，以外部故事剧情为驱动的结合类型策略经营游戏，也就是我们的Deepwell Safety Inc.。具体的“不稳定”要素体现在，存储空间会天然有重力的作用，有些物品易碎一不小心从下方抽走物品后会摔坏、有些物品有冷、热源属性，也会有相对应的物品需要保存在低温下、或者遇到高温会扣耐久度之类的、以及有些物体有辐射属性这种。我们设想中这个机制的有趣点在于，由于不停地有客人有货物存/取的需求，玩家可能在不经意间，直接会从堆积成山的仓库里抽取物品，进而导致类似于叠叠高积木那种效应、更甚至会发生冷、热、辐射、易爆、易碎这些元素的连锁反应，导致有趣的事情发生。再类比一下就类似三消游戏那种，连环反应，但通常如果发生了可能就不是什么好事了（笑）。当然，策略点在于：为了避免那种情况的发生，玩家需要记住某些重要物品的位置、学会分区化管理，类似这种游玩策略。（策划同学设计了一下前十几天的渐进式教学游玩任务，会潜意识地逐步介绍各个机制，强无敌）
游戏外层背景我们则敲定了一个未来的科幻世界，玩家经营的是一家类似仓库的保存公司，也比较符合一些类似“放射性”这种机制的设定。但我个人感觉那种冰、火、电元素的魔法世界应该也可以圆的通。之所以选了科幻，是因为美术大佬比较擅长而已，最终来看已完成的部分确实diao炸了（还有很多UI交互我没时间做了…）如果已经试玩了游戏的话，你可能会发现其实这种题材的类似游戏，市面上也有一些，比如Papers Please，还有最近新出的Potion Craft，最近策划同学和我都玩过，感觉这种切入点很小的世界观叙事类游戏还是很有表现力的。讨论出这样的游戏玩法设计，可能也有一部分这些影响在。
大家一起定下了游戏内容和玩法后，开发就真正开始了。由于玩法选得比较扎实、大家的意见也统一，游戏开发过程中便也没有什么反复。在确定了核心体验后，到开发后期也最多砍掉了一些“可未来拓展的”设计部分而已。Game jam游戏其实完成度最终能到这个程度，我是超级满意的。
接着介绍一下我的开发内容：由于有2名程序，虽然有些沟通和处理merge的成本，但对程序来说真的是超级友好！我们俩一开始分析了下游戏的架构，将它拆分成了两个相对独立的模块：类似俄罗斯方块的仓库玩法核心+外层的类似galgame的对话、接单叙事系统。看起来是不是只有两块？其实真正进入开发后，还有很多琐碎的子模块，比如说主菜单、音效系统的接入、甚至最后的打包和上传到网页端、以及做完两个大模块后也得要有一个人将他们很好地对接好。所以说如果一个程序来做完所有部分真的非常的伤…（之前的game jam经历是血淋淋的教训）而且特别是敲了2-3天的代码的后期，处理完自己负责的部分后，根本没什么心情动力去做那些边角料的部分了，这也是很多game jam作品最后完成度不高的主要原因。
我们选用的是Unity引擎，我负责的是外层叙事+接还订单的部分。本着用好手中的工具的想法，我从长期以来不买立省100%的Unity Assets Store的仓库里挑了Node Canvas插件来实现对话流程系统；Lean GUI和Dotween插件来辅助做一下卡片拖拽和UI过渡等；Odin插件来简单绘制一些ScriptableObject的任务配置的界面，让策划好在Unity里配置（Unity原生的真心shit一样…自己写Editor代码拓展起来也贼麻烦，Odin的Attributes用过的都说真香）。俄罗斯方块部分的程序同学据我了解是直接手撸，通过手写的网格系统加上Raycast之流的功能实现检测和拖拽方块，对我这种有工具就“拿来吧你”的开发者来说，是更高级的大佬形式了（最后实现也没什么bug！）。
说是这么说，看起来用已有的插件实现一些功能会很简单对不对？NoNoNo，NodeCanvas我是现场学的…各种魔改插件的代码，结果只能来的及实现一个需要很复杂的节点连接才能组成的对话节点图系统，导致策划和我都浪费了不少时间在配图、改图上。做一些简单的UI动画，更顺手的方式还是直接K一个Unity的Animation，很多不必要的时间都花在了处理Lean GUI插件的推拽卡片的适配上了…最终代码的模块化各种被破坏，引用各种乱传…不过好在最后还是堪堪能用了，欣慰欣慰。
我们采取的是相对佛系的打法，前两天都各种回家睡觉，第三天晚上通宵肝一下。在3号晚上，我将日程系统和可以配置对话和关联任务的功能交付给策划，让他可以开始配表（之前策划则是在实现纸上原型验证各种数值和机制设计），在4号下午才将外层的接受、完成订单的UI交互、金钱系统完成，在5号0点（结束前6小时）才将各个系统以及另一名程序的仓库系统之间的交互逻辑处理完，正常跑通游戏的流程。这时候两名程序的好处体现出来了，在我还深陷各个模块的对接处理逻辑时，另一名完成了相对独立的仓库模块的程序大佬，在5号下午就开始实现那些我顾及不到，但对游戏完成度很有影响的部分了，例如主菜单、接入音频、打包测试等，真的分摊了很大一部分工作内容。
可以通过提交记录看到，我们前两天还是很悠哉地有好好睡觉的，但最后4号下午到5号凌晨就开始了疯狂提交修改赶进度…
值得一提的是，最终游戏呈现的内容，我们也顺利地裁剪掉或者简化了一些不必要地设计，比如接收订单会展示物品在一块checklist板子上呈现出来给勾选；复杂的仓库界面冷热、辐射视图的切换功能；可以查看未来取东西的人的日程的日历之类的系统。从成品来看，取舍还是相当成功的。不过遗憾的是，游戏没有功夫去做多语言支持了，只能用着策划同学的半机翻的塑料英语了……
综上，这次LD开发给了我这些经历体验：
- 认识并磨合了团队内的大佬们
- 跳脱了平日里的工作-生活死循环，一同完成了一款满意的作品
- 锻炼了一下码力，以及学习了一系列新插件的用法
- 与国外游戏开发者相互评论、试玩和交流
最后非常感谢几位大佬：bigyellow、AegisFate、rock-gong。