我感到很难受,我几乎完全放弃了有关A:\ dventure的文章,但这不是我过去几个月唯一放弃的事情。 大约一周前,我第一次在TooManyGames上以半可玩状态公开展示了A:\ dventure,供人们进行游戏测试。 每个尝试过它的人都说,他们喜欢游戏的流畅性,喜欢它的微妙但古怪的幽默,而且他们通常喜欢C:\ raft的新游戏风格。 但是,令人们最惊讶的是我告诉他们我只是一个月又一个月地工作。
现在,如果您已经阅读了大约6个月前的以前的博客文章,那么您将读到它是一个完整的谎言和营销技巧,但实际上这是事实。 您会发现,感觉自己的空闲时间无济于事,在Unity中绊脚石,试图使其以可行的方式行事,而不是以直观的方式行事,我便放弃了所做的一切。

我已经提到过我曾与Godot一起玩过游戏,最初我之所以没有启动该项目的原因是因为当时3.0尚未稳定。 我一直是个粉丝,尽管我没有实践经验可以制作出像样的东西。 另外,由于我的空闲时间比开始进行A:\ dventure时的预期时间要长,所以在我不知道它之前,Godot 3.0已经发布并且我的游戏在开发中没有任何进展。 因此,距离TooManyGames还有一个月的时间,我想我最好还是参加那场骗局时总是做我一直做的事情,而只是尝试快速注入一些新东西。
在3.0版本中,Godot添加了C#支持,如果您知道C#,那就太酷了。 我确实知道C#,但是看到Unity和Godot的API之间几乎没有相似之处,这并不是说您了解在Unity C#中工作的所有知识都会帮助您过渡到Godot的。 相反,因为无论如何我都必须重写所有内容,所以我选择使用GDScript作为游戏的首选语言。 由于游戏的设计非常小巧轻便,因此不必包含Mono运行时,可以使二进制文件更小。 另外,由于我的游戏在任何时间点的逻辑和对象计数都很简单,因此我不担心使用解释语言对游戏可能造成的性能缺陷。 这使我更加关注游戏代码的总体质量以及使用专为游戏创建而设计的简单python语言快速编写内容的能力。

Godot的UI创建工具可与Unity相提并论,可用于锚定和调整大小的UI,这很酷。 我能够重新创建以前使用过的大多数UI,然后使用我在Unity中学到的大部分内容来创建更多UI,因此第二次使用它的速度大大加快。 但是,与Unity不同,Godot在2D重型,低分辨率游戏的开箱即用的像素完美缩放方面表现出色。 与如今看到的许多像素艺术游戏不同,A:\ dventure只能以320×240的分辨率渲染,并且一切都是像素完美的。 每个像素都与我的资产息息相关,因此能够在不进行过多过滤的情况下适当缩放它们非常重要。 您将不会看到2×2和3×3的像素混合,也不会看到像高分辨率像素艺术游戏那样的“网格”之间的资产混合。 在上一篇文章中,我谈到了在Unity中如何处理这种渲染是一项艰巨的任务。 Godot消除了那些烦恼,所以现在我不必花太多时间摆弄我的资产来使事情看起来正确。
实现游戏玩法从未如此简单。 Godot开箱即用的信号系统非常优雅且易于使用,并且消除了我在Unity中做同样的事情所需的大量代码和样板。 简单直观的事件注册使您可以轻松查看和设置逻辑,以执行与输入处理相关的动作,将多级管道排队以构建地牢,甚至触发动画。 在基于回合的游戏中,如此多的编程以基于事件的方式更好地发挥了作用,所以这就是我一直要采用的方法。 拥有可以让我毫不费力地走那条路的工具,只会使我以我想象中的方式实现它就更加令人满意。
总的来说,自从切换以来,整个工作环境都变得更加自然,因此我将继续按照这个方向进行游戏。 即使我在两个引擎上拥有相同水平的经验,也可以将事情发展到同一点,并花费更少的时间。 您可能会把这归咎于我,比起我刚开始进行这项工作时,我已经有更多要做的计划了,但是即使如此,对于更换引擎我也不感到后悔。
后续帖子将更多地与我正在开发的功能的更新以及游戏本身的发展有关。