几年前，我开始从事一款名为Rad Roller的游戏。 或者，相反，我开始摆弄Unity游戏引擎，看看我能做什么。 我之前曾尝试过游戏开发，但是这些途径通常是一次性的教程，而且它们“离金属越来越近”，因此甚至很难达到可玩性。
尽管当时还没有名字，但Rad Roller还是我第一次超越“哇，我的项目全部完成，’Hello World’开始工作！”的阶段。 看看过去的这个惊人的工件：
尽管上面的.gif显然非常令人印象深刻，但从软件开发和工具的角度来看，这也是我很确定的业余爱好者的不幸例证。 真正达到这一点对我来说是个人的一项伟大成就，而在这里停下来思考一下如何实际设计一款游戏将是明智之举。 我实际上所做的是继续努力了几年。
到一年左右的时间过去了，我已经整理了相当不错的水平书。 根据Unity docs的建议，它们都位于不同的场景中。
在这一点上，尽管我可以按照自己的意愿添加尽可能多的新场景，但如果不对每个场景进行长时间的修改，就无法真正更改游戏现有功能。 这是一年多前我停止在Rad Roller上工作的原因的很大一部分。 我给自己挖了一个洞，而挖自己也不在我的雷达范围内–我接受了在另一个城市从事的艰巨工作。 在经过70分钟的车程后，将这个混乱的问题放在我的优先列表上并不高。
但是后来我被解雇了！ 下岗，实际上。 发生这种情况并不能很好地支付我的抵押贷款，但是在让我给Rad Roller留出更多的顶空方面非常有效。 游戏中存在很多问题，因此可以在许多不同的方向上进行改进，但是现在我要解决“场景太多”的问题。
由于Rad Roller的结构方式，我认为使用单一场景是正确的方法：许多离散的关卡，通常都由一组相似的对象构成，可以轻松保存为预制件并动态加载。 可以通过易于创建和解析的JSON文件定义各个级别的配置。 这种类型的加载具有支持用户生成的关卡创建的附加副作用。 尽管目前还不具备此功能，但以这种方式实施整个系统将使将来的淘汰变得非常容易。
使用这种方法，我可以启动一个（主要是）空的shell场景，然后实例化JSON配置中引用的所有对象和位置。
在使Rad Roller代码库变得可行时，我还有很长的路要走，但这是积极的第一步。 在几个小时的过程中，我可以在运行时动态加载所有GameObject，从而获得了第一层工作的大部分替代品。 即使达到这一点，也大大降低了项目的脆弱性，这真是太棒了。
重构列表中的下一个：取消代码意粉化。 烤宽面条？
