Rad Roller Rad重构:第1部分

几年前,我开始从事一款名为Rad Roller的游戏。 或者,相反,我开始摆弄Unity游戏引擎,看看我能做什么。 我之前曾尝试过游戏开发,但是这些途径通常是一次性的教程,而且它们“离金属越来越近”,因此甚至很难达到可玩性。

尽管当时还没有名字,但Rad Roller还是我第一次超越“哇,我的项目全部完成,’Hello World’开始工作!”的阶段。 看看过去的这个惊人的工件:

尽管上面的.gif显然非常令人印象深刻,但从软件开发和工具的角度来看,这也是我很确定的业余爱好者的不幸例证。 真正达到这一点对我来说是个人的一项伟大成就,而在这里停下来思考一下如何实际设计一款游戏将是明智之举。 我实际上所做的是继续努力了几年。

到一年左右的时间过去了,我已经整理了相当不错的水平书。 根据Unity docs的建议,它们都位于不同的场景中。

在这一点上,尽管我可以按照自己的意愿添加尽可能多的新场景,但如果不对每个场景进行长时间的修改,就无法真正更改游戏现有功能。 这是一年多前我停止在Rad Roller上工作的原因的很大一部分。 我给自己挖了一个洞,而挖自己也不在我的雷达范围内–我接受了在另一个城市从事的艰巨工作。 在经过70分钟的车程后,将这个混乱的问题放在我的优先列表上并不高。


但是后来我被解雇了! 下岗,实际上。 发生这种情况并不能很好地支付我的抵押贷款,但是在让我给Rad Roller留出更多的顶空方面非常有效。 游戏中存在很多问题,因此可以在许多不同的方向上进行改进,但是现在我要解决“场景太多”的问题。

由于Rad Roller的结构方式,我认为使用单一场景是正确的方法:许多离散的关卡,通常都由一组相似的对象构成,可以轻松保存为预制件并动态加载。 可以通过易于创建和解析的JSON文件定义各个级别的配置。 这种类型的加载具有支持用户生成的关卡创建的附加副作用。 尽管目前还不具备此功能,但以这种方式实施整个系统将使将来的淘汰变得非常容易。

使用这种方法,我可以启动一个(主要是)空的shell场景,然后实例化JSON配置中引用的所有对象和位置。

在使Rad Roller代码库变得可行时,我还有很长的路要走,但这是积极的第一步。 在几个小时的过程中,我可以在运行时动态加载所有GameObject,从而获得了第一层工作的大部分替代品。 即使达到这一点,也大大降低了项目的脆弱性,这真是太棒了。

重构列表中的下一个:取消代码意粉化。 烤宽面条?