好吧，作为第一个……除了仅针对Android的发行版和终点处的十二个被放弃的项目，然后是的，这是我们的第一款具有多个平台的游戏。 这一切是怎么开始的？ 很简单，我们从事另一个项目，我们称之为“ Project A”，已经工作了很长时间，并决定是否在几个月内为我们制作游戏并培训我们的营销技能，然后我们将立即发布“ Project A”拥有丰富的游戏推广经验。 但是明星们不同意，公鸡没有吹口哨，“ A计划”放下了整整一年。 但是这个故事不是关于他的，而是关于一个名为“ Cubicity：Slide Puzzle”的逻辑游戏。
根据第一个计划，计划了以下内容：最少的图形，最少的UI和所有可能最小化的东西，该游戏应该具有当今休闲游戏的风格，在市场上与Match-3一样多。 结果，我们的目标如下：将圆形切屑以给定的形状连接，并在四个方向上滑动。 那些已经玩过Cubicity的人知道，我们离这项任务还很遥远，但是对于仅由两个人组成的团队而言，我们已经比其他任务有了很大的飞跃。
如果其中一位读者希望在这里找到成功快速开发游戏的秘诀，那么您应该知道没有秘诀。 这里我们没有分享丰富的经验或知识，这里仅描述了一个小公司的一个项目的历史。 是否成功，我们仍然不知道。 但是对于你们中的许多人来说，我们的读者是开发人员自己过去的信息。
回到Cubicity的创建历史，我们主要只在Unity上工作，任何自重的Unity开发人员的标准设置都在这里：Newtonsoft.json，Zenject，Cinemachine，Dotween等。...如上所见，游戏的第一个原型看起来就是这样，立方体薄煎饼。 经过一个星期的思考如何使游戏多样化并吸引玩家，一个绝妙的主意就来了。看一下立方体或圆形角色的Asset商店。 好吧，它开始了，毫不犹豫地买了几包角色。 角色现在在其上移动的块发生了相同的情况。 他们还列出了一些新的游戏元素，从大约30种新商品中选择了中性的东西作为开始，例如重定向方块/箭头，电梯和传送。 他们决定将其余的设置为新的级别，并将它们一次引入30-35个级别。
老实说，我们不记得是什么促使我们一开始做这么多的级别，但实际上，第一个版本中有95个级别。 实际上，有很多事情，我们对此感到不只一次的遗憾。 你为什么对不起 但是由于游戏是原始的，并且在此过程中发生了很多变化。 通过进入95个级别中的每个级别并进行更改，我经常不得不参加“ Groundhog Day”。 所有级别都需要2个月的连续运行时间。 这些还不是100％完成的水平，但是非常接近。 在富有成效的日子里，从头到纸再到现场的10个关卡并不难。 但是有时候，当您感觉像来自Lascivious California的Henk Moody经历了创作危机时，您认为一切都枯燥无味，但是新的一天又有了新的想法。
如果我们谈论视觉组件，那么一切都会更加复杂。 与大多数游戏中一样，渲染是在屏幕外的分辨率低于原始分辨率的屏幕上进行的，并在主表面上发光，但是绘制UI的目的是为了清晰度和可读性，而无需更改分辨率。 因此，我们获得了两全其美的体验-不是模糊的UI，而是游戏中的渲染过于繁琐。 为了进行平滑处理，实验选择了2倍MSAA + FXAA，因为它们能以最少的资源提供最佳的图像。 听起来合理的判断是，逻辑游戏不需要每秒60帧，因此我们决定不重新发明轮子，而是将帧数限制设置为30fps（更不用说，即使是游戏机通常也会这样做）。 设置边框限制不仅对能量消耗有积极影响，而且对手机的发热也有积极的影响，从而防止手机因过热而小跑。
摆在我们面前的是一个艰难的决定，这些都是终点。 由于在该级别的每次启动时都是从玩家可用的那些角色中随机选择角色的，因此从角色绘制人物的任何缩略图会很麻烦。 您可能不相信它，但是正是这个问题解决了最长的时间，并被推迟到以后。 那时的多维数据集似乎并不是一个令人毛骨悚然的想法，纸上绘画帮助达到了这个水平，并把每个人都带到了自己的位置。 之后，决定使用相同的字符代替多维数据集，但是使用较小的字符会变得更好，但这仅适用于我们。 几天后，这些角色被部署并突出显示，谁更清楚了谁，但仍然不尽人意。 最终版本在一个月后通过反复试验被采用，并且花了几周的时间来为完成创建图标。 再见夏天，再见！
以我们的拙见，云层看上去很宜人。 但是实际上，这是最简单且不太脏的hack。 当他们刚决定添加云时，首先想到的是制作360度视频背景。 这种方法还没有取得成功，因为对于移动平台而言，希望使游戏适应在LTE上下载的大小限制。 为了使视频看起来比压缩成碎片的压缩效果好一点，他本人必须分配10-15 MB的内存，再加上游戏中有云的夜晚水平，实在太大了（Android上游戏的整个最终版本占用61 MB）。 第二个愿望是为云端编写自己的系统，这对于开发人员来说很诱人，但作为一个想要尽快完成游戏的人，这是不合适的。 解决方案的形式是为云创建纹理，创建具有无限粒子寿命的粒子系统，并且粒子总数也有限。 之后，我们在两个常量之间添加了随机大小以及随机旋转。 结果令人非常满意-我们的天空充满了美丽的云彩，当我们看着它们时不想让我们哭泣。
游戏中的阴影（在移动版本中）完全由四边形组成，它们只是手动布置，因为我不想在移动版中添加真实阴影。 原因之一是在带有OpenGLES 2.0的移动平台上缺少软阴影，并且在弱设备上当然会降低性能。
如前所述，我们使用2倍MSAA + FXAA进行平滑，但这还不是全部！ 此外，AmplifyColor已添加到我们的后处理过程中-这是一笔物超所值的资产，可让您使用不同的Lut-s进行后处理。 使用正确的厕所，情况会更好。 在开发过程中，我们尝试了不同的方法，包括标准的统一后期处理堆栈，但是在构建过程中，其着色器和选项占用了很多东西，以至于童话和笔都无法描述。 有些解决方案非常漂亮，但在不是刚上市的手机上效果却很差（相信我，如果您认为现在每个人都至少拥有“普通”手机，那您就错了。仍然有很多人会花40美元买一台中文手机，在评论中向您投诉，您的DOOM没有继续使用微波炉。
游戏的平衡性总是不容易的，甚至现在想法浮出水面，关卡是否过于复杂，难关级别是否经常消失等等。 在用一只左脚保持平衡的同时，我们决定引入使玩家更轻松的工具（“后退”，“炸弹”，“冰块”，“传送”），是的，它变得更容易生活，但对我们而言并不如此，仅对未来的玩家而言。 我们还有更多工作和错误。
我们进入了游戏菜单，力量和神经达到了极限，创意天性hit住了刹车，我们也不会躲起来，我不得不受到其他游戏的启发，这要归功于它们。 现在，“早上乌龟出来了！”。 第二天早上不正确，但是出来了，UI已准备好用于先前创建的布局。
对时尚，时髦，青年的渴望也没有绕过我们。 我们决定添加基于云的保存，通常不后悔。 这不是最容易的任务，因为在不同的平台上，不同的云存储提供商。 在Steam上，它是Steamworks，用于移动设备，GooglePlay和GameRoom。 因此，我必须统一存储系统，以替代所需的平台。 首先，我们决定将EasyMobile用于这些目的，但是，迟早，这个想法还是被放弃了。 该插件本身很好，并且具有大量功能，但是我们真的不喜欢使用本机云存储的细节。 结果，选择权落在了Firebase实时数据库和通过Facebook进行的身份验证上。 简而言之，我必须经过7个地狱才能使其正常工作（这不是编程问题，而是需要在100,500个设置中进行，而这需要在应用程序的100,500个位置以及在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个月。 听了一篇文章的建议后，我们选择了星期二和星期三发布。 我们决定在w3bsit3-dns.com上进行准确的评论，在几个论坛上发布有关该游戏的新闻，并在社交网站（尤其是Instagram）上投放炸弹（当然是付费的）。 所有这些都有效，我们将在故事的第二部分（但仅稍后）中学习。
到底我们有什么？ 创建快速游戏并不总是那么快。 并且可能需要将创建游戏的预期时间乘以5。请可以在您不熟悉的领域为您提供实用建议的人。 尽可能放松，因为创建某些东西（不仅仅是游戏）会消耗大量精力。 呆滞的香肠和在开始项目时的用处不大是不值得的。 好吧，钱，找钱，您将需要它。 从我们这里，感谢您的关注，祝您好运，并在下一篇文章中与您见面。