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.

迷宮本身是由較小的迷宮，拼圖和連接它們的走廊組成的。 當我第一次開始設計那些迷宮時，我只是拿起筆和方格紙，開始逐壁畫出它們。 但是由于真實的原型以及它如何受到鏈條的影響而進行了無數次更改之后，我確信這是最無效的處理方式。 因此，我為迷宮創建了一個自定義編輯器窗口。 就像筆和紙一樣，但是保存狀態可以從墻壁，地板和鏈式來源的預制件中產生完整的迷宮。 我還增加了對鏈源長度的控制，這是設計迷宮問題的完整解決方案。

Just keep in mind that for editor time instantiation you should use 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)

It is personal preference but I love post-processing and could not imagine my game without it. 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.

當游戲即將準備就緒，并且設備上的初始播放已經完成時，我嘗試在開發初期沒有的功能強大的設備上啟動游戲。 那太可悲了。 我之前注意到設備上有一些小凹痕，但是在解決過熱問題的最初步驟之后，我認為我再也看不到如此劇烈的斷斷續續了。

For the overheating — the steps are straightforward, I did not need 60fps, so locked that to 30. Plus custom resolution scaler that limited the short screen size to 720p. One other trick with changing time-steps at Time Manager did not work for me, because of such a reliance on heavy physics calculations. When I've tried to increase the time-step, the chain quite frequently exploded reaching its limits.

對于過熱—步驟很簡單，我不需要60fps，因此將其鎖定為30。加上自定義分辨率縮放器，將短屏幕尺寸限制為720p。 在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.

有趣的一點是，我一直都啟用了太多音頻源。 但是我從來不需要同時使用它們，而且演奏它們的事件是確定性的。 我最終默認情況下幾乎禁用了所有源，僅在需要的聲音激活時才啟用它們，然后在聲音結束后立即禁用它們。

Some scripts benefited from manual updates instead of the proprietary ones, especially when I had many similar objects with the same script and an 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內部方法調用的開銷。

The last but one of the most important things within optimization is the rendering part. If you want to ship your mobile game with 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.

無論如何，有時幀調試器會顯示奇怪的渲染順序，破壞批處理。 這些情況中有些是荒謬的，手動進行材質渲染隊列校正有助于解決該問題。

Also, frame debugger showed that despite having almost all of the rendered objects as static, I had a lot of batches that did not make any sense. Just because I had so many of them, that the batcher made many static batch meshes, and never tried to group them by position. In that case, I had my labyrinth walls at one screen made up from 5 or 6 different batches. But those made of the same material! I've ended up with adding only floor objects as static because all of them made it inside one batched mesh. And the rest was left with the walls batched dynamically without any issues, with their material queue corrected to a unique one. The dynamic batching makes some hit on the 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.

而且，幀調試器顯示，盡管幾乎所有呈現的對象都是靜態的，但我有很多批次沒有任何意義。 正因為我有很多這樣的東西，所以批處理程序制作了許多靜態批處理網格物體，并且從未嘗試將它們按位置分組。 在那種情況下，我的迷宮墻在一個屏幕上，由5個或6個不同的批次組成。 但是那些用相同的材??料制成！ 我最后只添加了地板對象作為靜態對象，因為它們全部都在一個批處理的網格內完成。 其余的墻壁則沒有問題地動態地進行批處理，其物料隊列已校正為唯一的。 動態批處理對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中有多個批次，則將該數字乘以您已獲得的級聯數。 發現之后，我剛剛禁用了級聯。 但是我仍然需要像樣的實時陰影，最后調整攝像機的剪切距離，并以中等質量切換到緊密配合的陰影。 我知道它們不是最漂亮的，但比分辨率低或根本沒有陰影的穩定鏡頭要好得多。

The last one inside frame debugger and performance is post processing. Even with only a couple effects enabled, those were almost the heaviest ones — Bloom and Depth of Field. Both of them used sampling the frame to low resolution but having different input texture and different filter shaders. I've had already changed 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和景深。 他們倆都使用低分辨率對幀進行采樣，但是具有不同的輸入紋理和不同的濾鏡著色器。 我已經將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.

最后，還剩下一些功能。 尤其仍然需要完成游戲的氣氛，但這并不能從根本上改變體驗，因此可以作為發行后的更新來完成。 其余功能永遠不會消失。 對我來說可悲的是，在測試最終版本時，我有了一個令人興奮的想法。 我認為發生這種情況是因為開發工作有一個星期的暫停，并且在返回后我有了新的外觀。 也許有一天會有第二場比賽，但是現在所有的想法都將等待他們的時間重新回到新的開發周期。

PPS (P.P.S.)

翻譯自: https://habr.com/en/post/450468/

unity3d橫版游戲移動

總結

以上是生活随笔為你收集整理的unity3d横版游戏移动_制作游戏并不困难。 回顾Unity3D上的小型移动项目的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。