我是一名软件开发者，工作了几年，可能十年，但我从来没有参与过游戏开发。 大约一年前，我开始开发 GridLocust，这是一个反向防御塔游戏，玩家指挥外星生物对抗自动化防御系统。 我做了我知道的事情：我将其视为软件项目。 一些东西转变得非常好，另一些东西就是多余的。 这是我的工作方式，希望能帮助来自同一背景的人。 两种仓库：设计和代码。 游戏设计存放在自己的仓库中：设计文档，平衡表格，层级布局作为JSON，设计决策。 Unity 项目存放在单独的仓库中。 设计可以改变而不影响代码。 在编码中，我不需要有关故事情节，游戏设计等的所有信息。 层级被作为JSON存放在单独的仓库中，Unity 通过相同的文件构建迷宫。 框架优先。 简单规则： 如果有一个大社区背后的框架， 不要从零开始。 人物控制，AI大脑和武器来自TopDownEngine。 寻路是A* Pathfinding Project Pro。 地形是MapMagic 2，我的迷宫生成器作为自定义节点添加。 艺术和声音来自资产商店包。 这个规则已经多次救了我免于自己构建状态机，寻路和输入系统。 代价是必须真正学习每个框架的特点，并使它们协同工作。 Git用于所有内容，问题作为项目文档。 每个功能都有一个分支和一个PR，尽管我是独自一人。 每个工作都从GitHub问题开始，项目板上有一个路线图，估计和一个“有趣”的字段。 问题最重要的是 决策跟踪：六个月后，“为什么守卫的逃脱倒计时从最后一个守卫死后开始，而不是低血量？”有一个答案，日期。 提交和PR链接回问题，所以git历史作为项目文档。 门槛：没有艺术决策，没有比较表格。 我建立了一个系统，能够快速在地图上布置对象。 每个视觉决策都通过 门槛：（i）编辑器工具渲染一个JSON文件中的网格变体。 （ii）每行改变 一个参数。 （iii）脚本生成联系表。 （iv）我从表格中选择。 它涵盖了墙材质，照明气氛，摄像机角度，VFX时钟，HUD肖像和商店封面。 在此之前，我会调整滑动条一个小时，然后忘记它之前的样子。 每个艺术决策都有多个变体。 遥测和一个可以玩我的游戏的机器人。 我写了一台“指挥员自动飞行器”，它有程序化策略/战术来几乎像人类一样玩游戏。 它只给屏幕上显示的对象发命令，遵循与玩家相同的规则。 它在批次中运行，头无遮蔽。 每次运行写入一个带有版本号的波浪，死亡，损伤比例，运行结束，花费的资源的记录。 记录进入Elasticsearch，一个脚本将一个批次转换为平衡报告。 当我说“Three Mouths太容易了”，我有五个胜利中的五个来指出，而不是仅仅是一种感觉。 当然，机器人也有一些bug。 也许我在这里走得太远了，因为玩测试可以更便宜。 没有单元测试。 我诚实地对自己说，没有自动化测试套件。 验证是玩模式，审计菜单等。 一个构建仍然可以将玩家无法加载的场景打包。 我从常规软件工作中学习了： 版本控制，小PR，问题作为决策的记录，数据驱动配置，自动化和可观察性。 我没有学到： “它编译，打包”。 游戏感觉更好地通过游戏和视觉接受门槛来判断，而不是测试。 无耻的广告： GridLocust免费在itch上。 玩家指挥外星生物对抗自动化防御系统。 曲折：玩家是人类殖民者，他们的机器已经不再承认。 游戏反馈或工作流程反馈都欢迎。 https://tendrils-foundry.itch.io/gridlocust