我和我女朋友的第一个电子游戏。 用Unity开发。 第一部分

如果不考虑Android的发布以及即将发布的许多废弃项目,那么是的,它是我们的第一款适用于多个平台的游戏。 这一切是如何开始的? 很简单 我们从事另一个项目,我们称之为“项目A”,当我们决定在几个月内制作一款游戏并用它来训练我们的营销技能时,我们就已经进行了很长时间的研究。当我们在游戏推广方面更有经验时,发布我们的“ A项目”。 但是该计划失败了,“ A项目”整年都保持不变。 但是,这个故事与“ A项目”无关,而是与一个名为“ Cubicity:Slide Puzzle”的逻辑游戏有关。



第一稿如下:最少的图形,最少的UI以及尽可能少的一切,该游戏必须具有当今休闲游戏以及Match-3风格的风格。 结果,我们的目标如下所示:将圆形令牌连接到图形中,并通过四次滑动将其移动。 那些已经玩过Cubicity的人知道,我们并没有完全改变任务,但是在只有两个人的团队的情况下,我们在其他方面进行了激烈的改进。



如果某些读者希望在这里找到成功快速开发游戏的秘诀,那么就没有这样的秘诀了。 在这里,我们没有分享广泛的经验或知识,我们只是讲一个小公司项目的故事。 而且我们还不知道它是否成功。 但是对于我们的读者来说,这是开发人员过去发送的信息。

让我们回到创建三次方的历史。 主要是我们只与Unity合作,这是每个体面的Unity开发人员的标准集:Newtonsoft.json,Zenject,Cinemachine,Dotween等。 从上图可以看出,游戏的第一个原型仅包含立方体和筹码。 经过一周的思考,如何改进游戏并吸引游戏玩家,这是一个尤里卡时刻...在Asset Store上寻找一些立体或圆形角色。 因此,毫不犹豫地购买了几包角色。 角色现在在其上移动的块发生了相同的情况。 此外,还列出了新的游戏元素列表,其中包含近30个新项目,我们首先从中选择了中性的内容,例如重定向块/箭头,电梯和传送。 我们决定将其余的留给新级别,并在30-35个级别中逐一介绍。




老实说,我们甚至不记得是什么激发了我们在第一步中创造了如此多的关卡,但是我们拥有了自己的能力,因此第一版包含95个关卡。 说实话太多了,我们对此感到遗憾。 为什么后悔? 由于游戏尚未完全准备就绪,发布后发生了许多变化。 似乎我们陷入了“土拨鼠日”,因为我们需要在95个级别中的每个级别进行更改。在各个级别上花费了两个月的连续工作。 那些水平还没有100%准备就绪,但我们离那里并不遥远。 在最富有成效的日子里,很容易将10个级别从头部转移到纸张,然后再转移到场景。 但是也有几天,您感到自己像是来自加利福尼亚州的汉克·穆迪(Hank Moody),他正遭受作家的封锁,您认为自己触底,但新的一天带来了新的想法。

关于视觉组件,它有点难。 像大多数游戏一样,绘制是在屏幕外的表面上进行的,分辨率小于原始表面,但会在主表面上模糊不清,但是绘制UI时,分辨率没有任何变化,以提高清晰度和可读性。 因此,我们获得了两个世界中的最佳体验-不是模糊的UI,也不是游戏中性能突出的渲染。 经过大量实验后,我们选择2倍MSAA + FXAA进行抗锯齿,因为它们以最少的资源提供了最佳的图像。 我们合理地得出结论,逻辑游戏不需要每秒60帧,因此决定不重新发明轮子,而是将帧限制设置为30fps(即使是游戏机通常也这样做)。 设置边框限制不仅对能耗有积极影响,而且对手机的发热也有积极的影响,可以防止手机因过热而节流。

接下来,我们必须做出一个艰难的决定,那就是终点。 每次启动关卡时,都会从可供玩家使用的角色中随机选择角色,这就是为什么绘制某些角色的缩影会造成问题的原因。 您可能不相信它,但是在不断拖延它之后,我们花费了大量时间来解决该任务。 达到终点的多维数据集似乎并不是一个糟糕的主意,纸上绘画帮助达到了这个水平,并将每个人都带到了正确的位置。 后来决定使用相同的字符代替多维数据集,但是使用较小的字符。 它变得更好,但仅对我们而言。 几天后,这些角色被翻转并突出显示,谁是谁却变得更加清晰,但仍然不能令人满意。 最终版本在一个月后通过反复试验通过,之后花了几周的时间来创建用于完成的图标。 再见夏天,再见!



根据我们的拙见,云层看上去很宜人。 但是实际上,这是最简单的方法。 当我们刚决定添加云时,首先想到的是制作360度背景视频。 这种方法失败了,因为对于移动平台,希望使游戏适合通过LTE下载的大小限制。 如果我们希望视频不被过度压缩,则必须给它10-15 MB。 再加上游戏中带有云层的夜晚水平,这实在太多了(整个最终的Android游戏构建需要61 MB)。 第二个愿望是为云编写我们自己的系统。 对于开发人员而言,这很诱人,但是对于想要尽快完成游戏的人来说,这是不合适的。 解决方案的形式是为云创建纹理,并创建具有无限生命周期的粒子系统(通常还有限数量的粒子)。 之后,我们在两个常量之间添加了随机大小以及随机旋转。 结果真的很令人满意,我们的天空到处都是乌云密布的云朵,并没有让我们哭看着它们。



游戏中的阴影(移动版本)完全由手工组成的四边形组成,因为我们不想在移动版本中添加真实阴影。 原因之一是使用OpenGLES 2.0的移动平台上没有柔和的阴影,当然,弱设备上的性能也会下降。



如前所述,我们使用2倍MSAA + FXAA进行抗锯齿,但这还不是全部! 我们还在后期处理中添加了AmplifyColor,因为这是一笔合理的金钱,可让您在后期处理中应用不同的Lut-s。 正确选择的倍率会使照片变得更好。 在开发过程中,我们尝试了不同的方法,包括标准的统一后处理堆栈,但是在构建过程中,其着色器和选项确实花费了很多。 有些解决方案非常漂亮,但在不是很新的手机上却效果很差(相信我,如果您认为每个人现在至少都拥有“普通”手机,那您就错了。很多人仍然拥有40美元的中国手机并抱怨在您的评论中说您的DOOM在垃圾处理方面进展不佳。

游戏的平衡总是不容易达到的,甚至现在我们有时仍然认为关卡可能太困难了,那些硬关卡可能太频繁出现了等等。 在尽可能地平衡之后,我们决定引入工具,使玩家的生活更轻松(向后移动,炸弹,冰块,传送),是的,对于未来的玩家而言,生活变得更容易,但对我们而言并不容易。 对我们来说,工作和错误的数量有所增加。

我们进入了游戏菜单,我们的力量在减弱,神经nerve绕。 创造力刹车。 坦白地说,我们必须从其他游戏中获得灵感,为此我们深表感谢。 最后,我们做到了,UI可以在以前的布局上使用。



我们也想变得时尚。 因此,我们决定增加对云存储的节省,对此并不后悔。 这个任务并不是最容易的,因为在不同的平台上有不同的云存储提供商。 在Steam上有Steamworks,在移动设备上有GooglePlay和GameRoom。 因此,我们必须统一保存系统,以便可以用它代替所需的平台。 最初,我们决定将EasyMobile用于这些目的,但很快我们放弃了这个想法。 该插件非常好,并且具有很多可能性,但是我们真的不喜欢使用本机云存储。 结果,我们选择了Firebase实时数据库和Facebook身份验证。 简而言之,我们必须经过所有工作才能完成所有工作(这与编程无关,而与100500设置有关,必须在100500个应用程序位置以及Facebook,Firebase等中完成)。 同样在数据库中也有流量限制,为了保存它,每次写入时,我们都会创建一个GUID并将其写入数据库和设备中。 因此,如果我们看到设备上和云中的GUID匹配,则可以确定我们不需要从云中读取所有数据,但是可以使用数据的本地副本。 结果,添加了同步,但是...对我们来说,最奇怪的错误之一是Firebase数据库在某些情况下的明显行为。 由于使用了Json,我们序列化了用于存储状态的类,但是Firebase有时表现得有些奇怪。

例如,如果我们将字典对象传递给Firebase,则:

var dict = new Dictionary<int, SlotState> { { 0, new SlotState() }, { 1, new SlotState() }, { 2, new SlotState() }; 

当我们从数据库中读取它时,我们不会得到一个Json对象,而是一个Json数组(什么?)。
好吧,好的,我们将在所有地方使用列表,并且不会出现问题,对吗? 但这似乎是不对的。

如果我们用Firebase编写:

 var dict = new Dictionary<int, SlotState> { { 0, new SlotState() }, { 1, new SlotState() }, { 100500, new SlotState() }; 

甚至:

 var dict = new Dictionary<int, SlotState> { { 0, new SlotState() }, { 1, null }, { 2, new SlotState() }; 

当我们从数据库中读取它时,我们将获得一个包含键和值的Json对象。

好了,开发人员的逻辑可以理解,但是可能会导致一段时间后出现错误(还记得上面提到的为保存而添加的GUID吗?因此,很少从数据库中读取相对频繁的条目) 。

何时发布? 这个问题最常听到。 但是有必要为这一天做好充分的准备。 我们必须列出市场清单,选择发布日期,避免大笔交易,有很多细微差别将发布推迟了大约2个月。 根据一篇文章的建议,我们选择了星期二和星期三发布。 我们决定在4pds上进行评论,在几个论坛上介绍该游戏,并在社交网络中,尤其是在Instagram上进行广告宣传(当然需要付费)。 所有这些都起作用了,您可以从故事的第二部分中找到答案,但是稍后。

到底我们有什么? 创建游戏并非总是一个快速的过程。 可能需要将开发游戏的预期时间乘以5。请可以在不熟悉的行业中为您提供实用建议的人。 抓住每一个机会放松一下,因为创建某些东西(不仅仅是游戏)会消耗大量精力。 与项目开始时相比,放开疲惫感和用处不大是不正确的。 和金钱,寻找金钱,您将需要它。 从我们这里,感谢您的关注,祝您好运,并在下一篇文章中与您见面。

Source: https://habr.com/ru/post/zh-CN443020/


All Articles