unity3d横版游戏移动
Clearly, I'm telling about my experience and my vision, but many things would be common for any project, and maybe you'll find some useful tips for yourself.
显然，我在说我的经历和远见，但是对于任何项目，很多事情都是很常见的，也许您会为自己找到一些有用的技巧。
(Sculpting on the idea foundation)
The main idea was pretty simple — let's make a labyrinth, a maze! Although you can find some simple games in such genre at the store, but I believe that you should bring something more into the game than just following genre cliche. I have a deep concern about game-design in general, loving the stories and full adventure experiences with a distinct start and the prominent ending. I could not make here an exception to my ideals. Additionally I wanted some interesting gameplay mechanic. My approach was to add another variable to the whole escape the labyrinth concept. And after some brainstorming, the new idea was born. That was the chain and the system of chain-switches. So the main character's movement is restricted by the chain length and the paths that player chose. With that in mind, you'll need not only to find the exit but to find the shortest way possible! And what if I tell you that your chain is quite short and you can go further only after a Chain-switch that will provide the new anchor point and the new chain with different length. Now, the game starts to be more difficult, because you'll need to find the right order of those switches inside the labyrinth. And if that was not enough for you — then let's add doors, that you need to open with special activators somewhere inside a labyrinth and then to come back still thinking about the switches and the chain.
主要思想很简单-让我们迷宫，迷宫！ 尽管您可以在商店中找到这类游戏中的一些简单游戏，但是我相信您不应该仅仅关注游戏类型，而应该为游戏带来更多东西。 总的来说，我对游戏设计深感忧虑，喜欢故事和全面的冒险经历，并且有着明显的起点和突出的结局。 我不能在这里将我的理想作为例外。 另外，我想要一些有趣的游戏机制。 我的方法是在整个迷宫概念中增加另一个变量。 经过一番集思广益，新想法诞生了。 那就是链条和链开关的系统。 因此，主要角色的移动受到链长和玩家选择的路径的限制。 考虑到这一点，您不仅需要找到出口，而且还需要找到最短的方法！ 而且，如果我告诉您您的链条很短，并且只有在提供新锚点和不同长度的新链条的链开关之后，您才能走得更远。 现在，游戏开始变得更加困难，因为您需要在迷宫中找到这些开关的正确顺序。 如果这还不足以满足您的需要，那么我们添加一扇门，您需要在迷宫内部的某个地方用特殊的激活器打开，然后再回头思考开关和链条。
(Understanding the limits)
Certainly, it was not easy to plan all of those features ahead. Some of them were made because of technical limitations and strict time management. The purpose was to make it as fast as I can and not to dramatically increase the complexity of all game-aspects in the process of development. The chain was made using the joints, and could not be processed by game engine physics after some length, literally bursting into pieces. So I've needed to restrict its length and still be able to continue the path. Indeed, there was a solution to write fully custom chain scripts faking the real physics, but that was a time-consuming task that I could not afford.
当然，要预先计划所有这些功能并不容易。 其中一些是由于技术限制和严格的时间管理而制作的。 目的是尽可能快地完成它，而不是在开发过程中显着增加所有游戏方面的复杂性。 链条是用关节制成的，经过一段长度后，游戏引擎物理学无法对其进行处理，实际上会破裂成碎片。 因此，我需要限制其长度，并且仍然能够继续前进。 确实，有一种解决方案可以编写完全自定义的链式脚本，使真实的物理原理变得不真实，但这是我无法负担的耗时的任务。
Still, I've managed to maintain some length to the chain, and the initial thought was to make small labyrinth chambers where you need to find the shortest way, but that was not enough. If the whole game was like that, then it'll be quite tedious because you have just one repetitive task without changing the experience, or even the difficulty. Still, those ideas played a part in the final game.
尽管如此，我还是设法保持了一定的距离，最初的想法是制造一个迷宫式小室，在那里您需要找到最短的方法，但这还不够。 如果整个游戏都是这样，那将是非常乏味的，因为您只需完成一项重复的任务，而无需更改体验或难度。 尽管如此，这些想法仍在最后的比赛中发挥了作用。
(Inspiration and thoughts: Prototyping experience)
After some prototyping, it was clear that labyrinths, where you have to go astray from the shortest route and even have some backtracking, were the most interesting ones. So the final decision was to add separate gameplay sections one after another — the big labyrinths with multiple switches and small labyrinths with the shortest way possible. All of them connected with some empty corridors to free the player's mind from the sense of constant challenge. But right in the time of testing came another idea that provided a new critical thought — we need more gameplay mechanics. Because being in the same walls of these labyrinths one after another, even with some difficulty curve, was still not enough to keep players attention.
经过一些原型制作后，很显然迷宫是最有趣的地方，在迷宫中，您必须走出最短的路线，甚至需要回溯。 因此，最终的决定是一个接一个地添加单独的游戏区-具有多个开关的大迷宫，以及以尽可能短的方式进行的小迷宫。 它们全都与一些空旷的走廊相连，使玩家的精力从不断挑战的感觉中解放出来。 但是恰恰在测试时，出现了另一个提供新批判性思维的想法-我们需要更多的游戏机制。 因为即使在迷宫般弯曲的情况下，一个又一个地位于这些迷宫的同一堵墙中，仍然不足以吸引玩家的注意力。
To add up for the attention span, do not forget that the game is targeted for Mobile platform. Never design it to have lengthy game-sessions without any break. I've decided to make saves on every chain-switch, so the player can leave at any moment and never be far away from the previous game session. Of course, I' m having some intentions of how the game should be played, but my maximum intended uninterrupted session is about 5 minutes. That just includes scenes where the music is presented.
为了增加注意力范围，请不要忘记该游戏是针对移动平台的。 切勿将其设计为长时间进行游戏而不会中断。 我已经决定在每个链开关上都进行节省，因此玩家可以随时离开，并且永远不会离开上一个游戏环节。 当然，我对如何玩游戏有一些意图，但是我最大预期的不间断会话时间约为5分钟。 这仅包括呈现音乐的场景。
Returning to the mechanics variety, I've added puzzles involving chain as the tool to solve them. It is a great game-design solution — to reuse world objects that you already familiar with as the new purpose tool.
回到力学方面，我添加了涉及链条的难题作为解决它们的工具。 这是一个很棒的游戏设计解决方案-将您已经熟悉的世界对象作为新用途的工具进行重用。
There were various ideas of many different puzzles with this new tool, but the final decision was to implement just one type with variation in its difficulty. If you think that your game needs all of your new ideas and its variations, but you have no time to implement them, then stop! Your goal here is to finish the game. In the case, you'll not implement those features now, or even till the end of the development cycle — the one solution is to update game later, and the second and more radical — to make a completely new game later with all the lacked features. If you'll have the core product in your hand, then it would be easier to continue. Just not let the features to stop the release. Do it only if they are the critical part of the complete product that adds a unique experience to it and you can not imagine the game without those features.
对于这个新工具，存在着许多不同难题的各种想法，但是最终决定是仅实现一种难度有所不同的类型。 如果您认为您的游戏需要所有新的想法及其变体，但又没有时间实施它们，那就停下来！ 您的目标是完成游戏。 在这种情况下，您将不会立即实现这些功能，甚至直到开发周期结束时才实现这些功能-一种解决方案是稍后更新游戏，而第二种或更彻底的解决方案-在以后所有缺少的条件下制作全新的游戏特征。 如果您掌握了核心产品，那么继续进行会更容易。 只是不要让这些功能停止发布。 仅当它们是为产品添加独特体验的完整产品的关键部分，并且您无法想象没有这些功能的游戏时，才可以这样做。
(Skim over technical stuff: How the world was built)
The chain was made with configurable joints with locked motion on all axes. Then instantiated as chain segments, with 4 rigidbodies connected together by 4 joints in one segment. The chain sources are similar to the wells. For proper functioning, I just removed segments that were going under the surface and instantiated new ones when the last joint of the segment went close to the surface. Also, the last joint's rigidbody was restricted to have vertical movement only to stand as the anchor. Additionally, the rope has special collision material without much friction.
链条由可配置的关节制成，并在所有轴上锁定运动。 然后实例化为链段，在一个段中通过4个关节将4个刚体连接在一起。 链源类似于井。 为了正常运行，我只是移除了在表面下移动的线段，并在该段的最后一个关节靠近表面时实例化了新的线段。 同样，最后一个关节的刚体被限制为只能作为锚点站立才能进行垂直运动。 此外，绳索具有特殊的防撞材料，没有太大的摩擦。
The player was made with a rigidbody that has simple follow to target script to move it. And the target has a navigation agent on it. So when we move our joystick, then we move the target only with the navigation system, and the player's rigidbody tried to reach the target by physical force. If we would have just the navigation system, then the chain could not stop it, and the player acted just as the kinematic rigidbody with absolute position control. The only issue with the force application is that with the variable count of chain segments, we also have the variable in attached mass to the player. Then if you have to much mass at the end limit of the chain, it will explode. And otherwise, the player would be dragged backwards by the chain or not move at all. So I applied a change in mass relative to the actual chain length. But the most interesting solution against the chain explosion — destabilization of its physics, was to limit the maximum velocity in its singular parts by a custom script.
播放器是用刚体制成的，刚体可以简单地跟随目标脚本来移动。 目标上有一个导航代理。 因此，当我们移动操纵杆时，我们只能通过导航系统来移动目标，而玩家的刚体试图通过物理力来达到目标。 如果我们只有导航系统，那么链条就无法阻止它，玩家就可以充当具有绝对位置控制的运动刚体。 施加力的唯一问题是，随着链段数量的变化，我们在球员身上的附着质量也有所变化。 然后，如果您必须在链的末端限制很大的重量，它将爆炸。 否则，玩家将被链条向后拖动或完全不移动。 所以我改变了相对于实际链长的质量。 但是，针对链爆炸的最有趣的解决方案-破坏其物理稳定性，是通过自定义脚本来限制其奇异部分的最大速度。
The Labyrinth itself was made out of the smaller mazes, puzzles and the corridors that connected them all. When I first started to design those mazes — I just took my pen and squared paper and started to sketch them out wall by wall. But after numerous changes because of the real prototyping, and how it was affected by the chain, I was sure that it was the most ineffective way of doing things. So, I've made a custom editor window for my mazes. It was just like the pen and paper but with a saved state that could generate the complete maze out of walls, floor, and chain-sources prefabs. I've also added control over the chain-sources length, and it was the complete solution to the designing labyrinth problem.
迷宫本身是由较小的迷宫，拼图和连接它们的走廊组成的。 当我第一次开始设计那些迷宫时，我只是拿起笔和方格纸，开始逐壁画出它们。 但是由于真实的原型以及它如何受到链条的影响而进行了无数次更改之后，我确信这是最无效的处理方式。 因此，我为迷宫创建了一个自定义编辑器窗口。 就像笔和纸一样，但是保存状态可以从墙壁，地板和链式来源的预制件中产生完整的迷宫。 我还增加了对链源长度的控制，这是设计迷宫问题的完整解决方案。
PrefabUtility methods and not the common Instantiate because otherwise, you'll get clones of your prefab objects detached from the original prefab.
PrefabUtility方法，而不要使用常见的实例化方法，因为否则，您将获得与原始预制件分离的预制件对象的克隆。
(Post-processing)
Bloom is a must-have option, but I also like Depth-of-Field and the simple FXAA solution. With the new post-processing stack the steps to implement it properly were quite simple. I've also added trigger sphere above the player, that had another profile with the Chromatic Aberration effect, which moved onto the player at the switch time. Plus, the separate profile for the ending cinematic. But after one of the updates, everything stopped working, and after testing on the device, I've stumbled on another issue. With a little bit of RenderDoc, the reason was clear and immediately fixed, but I hope that we would see the official fix from Unity team.
Bloom是必不可少的选择，但是我也喜欢景深和简单的FXAA解决方案。 使用新的后处理堆栈，正确实施它的步骤非常简单。 我还在播放器上方添加了触发球体，该球体具有另一个带有“ 色差”效果的轮廓，该轮廓在切换时移到了播放器上。 另外，电影结尾的单独配置文件。 但是在其中一项更新之后， 一切都停止了工作 ，并且在对该设备进行测试之后，我偶然发现了另一个问题 。 有了一点RenderDoc ，原因就很清楚并且可以立即解决，但是我希望我们能看到Unity团队的正式修复。
(Start of the Optimizations road)
When the game was almost ready, and the initial playthrough on my device was done, I've tried to launch the game on not so powerful device that I had earlier in the development. That was pathetic. I have noticed small dips on my device before, but after the initial steps with solving the overheating problem, I thought that I would never see such a dramatic stutter.
当游戏即将准备就绪，并且设备上的初始播放已经完成时，我尝试在开发初期没有的功能强大的设备上启动游戏。 那太可悲了。 我之前注意到设备上有一些小凹痕，但是在解决过热问题的最初步骤之后，我认为我再也看不到如此剧烈的断断续续了。
Time Manager
Time Manager上更改时间步长的另一个技巧对我不起作用，因为它过于依赖大量的物理计算。 当我尝试增加时间步长时，连锁店经常爆炸达到其极限。
All of that work was done prior to the weak device testing. So I've started to look closer into the profiler.
所有这些工作都是在弱设备测试之前完成的。 因此，我开始更加仔细地分析探查器。
One interesting point was that I had too many audio sources that were enabled all the time. But I never needed them all simultaneously, and the events of playing them were quite deterministic. I've ended up with almost all the sources disabled by default, and enabling them only for the needed sound activation and then disabling them right after the end of the sound.
有趣的一点是，我一直都启用了太多音频源。 但是我从来不需要同时使用它们，而且演奏它们的事件是确定性的。 我最终默认情况下几乎禁用了所有源，仅在需要的声音激活时才启用它们，然后在声音结束后立即禁用它们。
Update method inside them. Just rename your Update method to ManualUpdate and call it from outside. In my case, all of my puzzles were onto the scene, and they called their update methods, also every pillar inside every puzzle had its own update method, and even pillar's triggers had their own update methods. Without those multiple automatic updates and calling update method manually on every object from a single place, I've managed to significantly reduce the overhead of Unity's internal methods calls.
Update方法时。 只需将Update方法重命名为ManualUpdate并从外部调用即可。 以我为例，我所有的难题都在现场，他们称之为更新方法，每个难题中的每个Struts都有自己的更新方法，甚至Struts的触发器也都有自己的更新方法。 如果没有这些多个自动更新，并且没有从一个地方手动对每个对象调用更新方法，那么我已经设法显着减少了Unity内部方法调用的开销。
Standard shaders — then you are insane! Maybe in some rare cases with small materials count and small shader variants complexity, because standard shader has tons of them, you could accomplish it while targeting top-tier devices only. But in my case, I've ended up with almost all shaders changed to use custom ones, based on mobile surface variants. But I haven't found a good way to simulate metallic/smoothness with a custom lighting model, so only shiny metallic materials ended up with standard shader. However, if you see the compiled versions, then it is no brainer to choose the right one when you have over 190 operations in the standard shader versus less than 70 in a custom one. Remember that PBR approach, which includes the default standard shader, is really GPU intensive and far too complex for mobile. You should use shaders specifically optimized for mobile right from the beginning of development. Make them for yourself, or use those that are built into Unity.
标准着色器来发布您的手机游戏，那就太疯狂了！ 也许在少数情况下，材料数量少且着色器变体复杂度较小，因为标准着色器包含大量着色器，因此您可以仅针对顶级设备来实现它。 但就我而言，基于移动表面变体，我几乎将所有着色器更改为使用自定义着色器。 但是我还没有找到一种使用自定义照明模型模拟金属/平滑度的好方法，因此只有闪亮的金属材料才能使用标准着色器。 但是，如果您看到的是编译版本，那么当您在标准着色器中执行190次以上操作，而在自定义着色器中执行少于70次操作时，就可以选择正确的版本了。 请记住， PBR方法(包括默认的标准着色器)确实占用大量GPU，并且对于移动设备而言过于复杂。 从开发开始就应该使用专门针对移动设备优化的着色器。 自己动手制作，或使用Unity内置的功能。
(The next stop: Frame debugger)
The next performance tip is to check the frame debugger for unusual batching breaks. Or just to see how many drawcalls you need to render the whole scene.
下一个性能提示是检查帧调试器是否存在异常的批处理中断。 或者只是为了查看渲染整个场景需要多少次调用。
I had strange behavior when debugger revealed that some objects rendered sequentially break the batch despite having the same material. Even the message was unclear because it said that I have different light sources for them. But the whole scene used the only one directional light source! Those objects had the same material, and all their properties were the same! But not all of them because I was looking only into the material and rendering properties. The true reason was that I changed my lightsource to custom culling by layers. And the breaking sequence object was in a specific layer that just was not lit.
当调试器发现尽管具有相同的材质时，某些顺序渲染的对象破坏了批处理，但我的行为却异常。 甚至消息也不清楚，因为它说我为它们使用不同的光源。 但是整个场景只使用了一个定向光源！ 这些对象具有相同的材质，并且它们的所有属性都相同！ 但是并不是全部，因为我只关注材质和渲染属性。 真正的原因是我将光源更改为按层自定义剔除。 中断序列对象位于未点亮的特定图层中。
Anyway, sometimes the frame debugger shows a strange order of rendering that breaks the batching. Some of those occurrences were ridiculous, and the manual material render-queue correction helped to resolve it.
无论如何，有时帧调试器会显示奇怪的渲染顺序，破坏批处理。 这些情况中有些是荒谬的，手动进行材质渲染队列校正有助于解决该问题。
CPU, but in my case, the difference even on the weak device was just marginal in comparison to the custom static batching through the StaticBatchingUtility. And dynamic batching was still more effective for me at saving drawcalls than custom static one at the edge cases.
CPU造成了一定的影响，但是在我的情况下，与通过StaticBatchingUtility进行的自定义静态批处理相比，即使是在较弱的设备上，其差异也很小。 在边缘情况下，动态批处理比自定义静态批处理在保存调用时更有效。
The other things that the frame debugger pointed out were the shadows and cascades. If you are curious, then every shadow cascade is pretty much another shadowpass for the entire screen. So, if you have several batches inside shadowpass then multiply that number to the number of cascades you've got. I've just disabled the cascades after this discovery. But I still needed decent real-time shadows and ended up with adjusting the camera clipping distance and switching to the close-fit shadows at medium quality. I know that they are not the prettiest ones, but it was much better than having stable ones with inferior resolution or none shadows at all.
帧调试器指出的其他内容是阴影和级联。 如果您很好奇，那么每个阴影级联几乎都是整个屏幕的另一个阴影通道。 因此，如果您在shadowpass中有多个批次，则将该数字乘以您已获得的级联数。 发现之后，我刚刚禁用了级联。 但是我仍然需要像样的实时阴影，最后调整摄像机的剪切距离，并以中等质量切换到紧密配合的阴影。 我知道它们不是最漂亮的，但比分辨率低或根本没有阴影的稳定镜头要好得多。
Bloom to use fast-Mode — square filter inside the shader instead of more complex circular. Sadly that was not enough. So I've ended up with changing the resolution scale factor inside effect's initial frame buffer. It is using half-Res by default, but I've seen big improvements when used not the half resolution but just one-third of it. Shrinking it further to one-fourth had almost no effect with further degrading visuals. So my solution to post processing on mobile is one third! Or using completely custom solutions.
Bloom更改为在着色器中使用快速模式-正方形滤镜，而不是更复杂的圆形。 可悲的是，这还不够。 因此，我最终更改了效果的初始帧缓冲区内的分辨率比例因子。 默认情况下，它使用的是Half-Res，但我看到使用的不是一半的分辨率，而只是三分之一的分辨率，它已经有了很大的改进。 将其缩小到四分之一几乎不会影响进一步降低视觉效果。 因此，我在手机上进行后期处理的解决方案是三分之一！ 或使用完全定制的解决方案。
(Almost there: Polish!)
Naturally, every project is unique, and you should think about yours in particular, but here I just wanted to show which parts I've decided to put in my polish process and why.
自然，每个项目都是独特的，您应该特别考虑您的项目，但是在这里，我只是想展示我决定在抛光过程中放入哪些部分以及原因。
The first steps of polish were made right after the first alpha test and before the performance optimizations. With the initial feedback, I've added minor features that were almost there, but have not quite stood out.
抛光的第一步是在第一次alpha测试之后和性能优化之前进行的。 在最初的反馈中，我添加了几乎已经存在的次要功能，但是还没有脱颖而出。
The first one was the colored floor, that I had a vision right from the start of development, but in the actual process all the pallets that I could think of looked kind of unnatural. So in the first round, I've ended just with the color gradient from bright to dark during the whole game path. But the test showed that this was not enough. With a bit of struggle through all the colors combinations, the right one was created. Even this small visual detail had a noticeable impact on overall game feeling. With the distinction between stages, you had more sense of accomplishment and progress.
第一个是彩色地板，从开发伊始我就拥有愿景，但在实际过程中，我能想到的所有货盘看起来都不自然。 因此，在第一轮中，我仅以整个游戏过程中从亮到暗的颜色渐变结束。 但是测试表明这还不够。 经过所有颜色组合的艰苦努力，找到了合适的颜色。 即使是很小的视觉细节也对整体游戏感觉产生了显着影响。 通过区分各个阶段，您将获得更大的成就感和进步感。
The other notion was the urge to have more fun and dynamic feel of the player. Even though I was not a fan of it at first, but I've managed to find a small compromise that felt better but not overhauled the calm feel of the character. That was the locking of the crystal within the player to never rotate relatively to the world. But to the player that felt like the inner crystal turned on every move. Actually, when I was just a kid, I've had a ball that had another one inside of it. That inner part floated in a small amount of liquid substance that was not noticeable, and when you rolled it on the surface, it looked like it's hovering without any rolling at all. This feature slightly reminded me of that unique feeling.
另一个想法是渴望让玩家拥有更多乐趣和动感。 尽管我一开始并不喜欢它，但是我设法找到了一个小妥协，虽然感觉不错，但并没有改变角色的沉稳感。 那就是将水晶锁在玩家内，使其永远不会相对于世界旋转。 但是对于那些感觉就像内在的水晶在每一个动作中开启的玩家。 实际上，当我还是个孩子的时候，我有一个球，里面有另一个球。 内部漂浮在少量液体中，这并不明显，当您将其滚动在表面上时，看起来好像在盘旋而没有任何滚动。 此功能使我想起了这种独特的感觉。
After all of the performance changes the game started to work as intended even on that low-performance device. Not the lowest, but that was OK for me. And then I've got some time to think about other features that will impact on the overall game feeling and were critical to my vision.
在所有性能更改之后，即使在该低性能设备上，游戏也开始按预期工作。 不是最低的，但这对我来说还可以。 然后，我有一些时间来考虑其他功能，这些功能会影响整体游戏的感觉，并且对我的愿景至关重要。
The first one was leaving the scratches on the floor and was quite fast implemented as decals pool. Even though you may never see it, but it definitely adds up to the labyrinth atmosphere.
第一个是将划痕留在地板上，并很快实施为贴花池。 即使您可能从未见过，但绝对可以增加迷宫般的气氛。
The second feature that affected the overall feel in my eyes were some stones in the corridors that should've to add more dynamic to the empty cold world. That was just the vision thing, and also without any trouble implemented into the final game. It presented an oddly satisfying feel every time when you see those small stones falling into the dark.
影响我眼睛整体感觉的第二个特征是走廊上的一些石头，这些石头应该为空旷的寒冷世界增添更多活力。 那只是愿景，在最终游戏中也没有任何麻烦。 每当您看到那些小石头掉入黑暗中时，都会给人一种奇特的满足感。
(Release point)
After all of the testing is done and you're satisfied with the polish, you're ready for the release!
在完成所有测试之后，您对抛光剂感到满意之后，就可以开始发布了！
For me, the main goal right from the beginning was to make single-player experience without any distractions. So the decision was clear: no Ads, no in-game purchases, no loot-boxes. For those features, you should design the game from the beginning to heavily rely on them to be an essential part of the experience. In my case, I knew that the whole game for an average player is going to be about three to four hours of experience. Thus I placed a reasonable fixed price and let it go. It is not enough time passed since the release to think of any substantial sales and also without any promotion yet. But as a developer, I am quite satisfied with the game, and if ever someone will like it then it is a success for me.
对我而言，从一开始的主要目标就是在没有干扰的情况下提供单人游戏体验。 因此，决定很明确：没有广告，没有游戏内购买，没有战利品箱。 对于这些功能，您应该从一开始就设计游戏，并高度依赖它们作为体验的重要组成部分。 以我为例，我知道对于一个普通玩家来说，整个游戏将需要三到四个小时的经验。 因此，我设定了合理的固定价格并放开了。 自发布以来没有足够的时间考虑任何实质性的销售，也没有任何促销。 但是作为一名开发人员，我对这款游戏非常满意，如果有人喜欢它，那对我来说就是成功。
(P.S.)
In the end, there were some features left behind. Particularly one still needs to be done to complete the game atmosphere, but it is not something radically changing the experience, so that can be done as a post-release update. The rest of the features could never go out. Sadly for me, I've got an exciting idea right at the time of testing the final release. I think that happened because there was a week pause in the development, and I've got a fresh look after a return. Maybe someday there would be the second game, but right now all the ideas will wait for their hour to be brought back on the new development cycle.
最后，还剩下一些功能。 尤其仍然需要完成游戏的气氛，但这并不能从根本上改变体验，因此可以作为发行后的更新来完成。 其余功能永远不会消失。 对我来说可悲的是，在测试最终版本时，我有了一个令人兴奋的想法。 我认为发生这种情况是因为开发工作有一个星期的暂停，并且在返回后我有了新的外观。 也许有一天会有第二场比赛，但是现在所有的想法都将等待他们的时间重新回到新的开发周期。
(P.P.S.)
unity3d横版游戏移动
