動態游戲案例分享
一、安吉游戲案例分析滾筒
安濟游戲案例：滾筒
滾筒是一款經典的娛樂游戲，安濟游戲很早就開始開發這款游戲，并在不斷優化和更新。滾筒游戲的目標是操作球體滾過障礙物，收集金幣和鉆石等獎勵，越過終點線。這個游戲不僅可以消磨時間，還可以提高玩家的反應能力和手眼協調能力。
設計特色
滾筒游戲的設計特色是通過動態隨機生成關卡，滾筒球體旋轉時會不斷收集道路上的獎勵，而且搭配上清新的音效和精美的背景畫面，玩家一旦開始游戲，便很難停下來。此外，游戲還提供了多種皮膚和升級方式，讓玩家有更強的自主參與性。
玩法簡介
滾筒游戲的玩法簡單易懂。玩家只需要通過左右滑動屏幕來控制球體滾動的方向。玩家需要通過收集金幣和鉆石，來解鎖更多高級關卡，并搭配玩家喜歡的個性化皮膚。滾筒的精妙之處在于每個玩家的游戲體驗是不一樣的，因為游戲中的地圖會隨機生成，每次玩都會感到新鮮和驚喜。
流行原因
滾筒游戲之所以在市場上深受歡迎，是由于其簡單的玩法和具有挑戰性的關卡設計，以及人性化的游戲設置。此外，滾筒還具有非常高的可玩性，能夠長時間保持玩家的興趣。玩家可以從游戲中獲得愉悅的體驗，同時鍛煉自己的反應能力和眼手協調能力。
游戲分類
在游戲分類方面，滾筒屬于益智休閑游戲，不需要玩家付出太多心理壓力和身體消耗。玩家可以隨時啟動滾筒游戲，同時也能隨時結束游戲。這種類型的游戲是為休閑娛樂而生的，而滾筒在這方面可以說是做的非常出色。
在全球范圍內的表現
滾筒游戲在全球的表現也相當搶眼。自從游戲上線以來，它就快速獲得了全球玩家的喜愛和支持。游戲在各大應用商店中都獲得了非常高的下載量和評分。同時，在社交媒體上，滾筒游戲也有著廣泛的社群，玩家們可以通過分享自己的游戲截圖和記錄，來展示自己的游戲成果，同時也能吸引新的玩家加入。
總結
滾筒游戲的成功，不僅僅是依靠其簡單的玩法和優秀的游戲設計，更在于安濟游戲可以不斷更新和優化游戲玩法和體驗。安濟游戲的成功，可以為其他游戲廠商提供很好的借鑒和參考，如何不斷完善和調整游戲體驗，以及如何提高用戶滿意度，都是值得其他游戲公司學習的地方。
二、MMO游戲優化經驗分享沙龍總結
昨天去上海參加了UWA公司的張鑫和張強進行了一場關于MMO游戲開發和性能優化的沙龍，活動鏈接為： UWA優化日上海站|傳統MMO手游性能該如何突圍？。雖然第二場場景分塊加載部分的內容沒有預期中對目前的項目那么有幫助，再加上最后因為趕火車沒有聽完Q&A的環節就離開了（然而還是沒有趕上火車，此中悲苦就不提了。。。），有些疑問沒有提出來討論，略有遺憾，但對于我這樣一個剛剛接觸Unity的新兵來說，收獲頗豐。因此這里做一個簡單的記錄和整理，只包含現場討論我印象比較深的一些點，與講座內容的順序沒有直接對應關系，更加詳細、條目性的內容可以參考官方放出的正式文檔。
張鑫博士介紹了UWA成立這一年多時間內做過的事情，我還是比較贊賞有組織在做這件事情的，可以說是Unity引擎和用戶之間除了官網文檔和官網技術支持之外的一座橋梁。雖然說他們目前的存在價值和盈利方式依賴于Unity引擎和這樣一個生態圈，但是對于程序員來說，它們比單純的引擎部門接近游戲產品，和做產品的比又更純粹，沒那么功利，介于兩者之間。如果有合適的機會我還是挺想做一做這樣的事情的，哈哈~
目前來說，能有這樣的一群人幫忙提供一些技術上的分享，一些坑可以拿出專門的時間和精力去踩和分析，對于沒有引擎組的小團隊來說是非常好的事情。
張鑫博士提到他們提供熱更新方案，會后單獨問了一下還是只支持Android的版本，Lua方案的熱更新還沒有人力去做。希望后面可以有人力來做一些這方面的踩坑和性能優化工作……
在UI系統的優化中，著重提到了Mesh重建的過程，這通常是一個消耗最大的部分，因此也是優化需要關注的重點。在NGUI中，這一過程發生在Panel的LateUpdate函數中——由于NGUI是插件的形式，因此這一過程是在C#中的，每次需要改變渲染網格時都會銷毀內存中的mesh進行重建操作。而對于UGUI來說，這一過程是在Cavas的BuildBatch中進行的，已經被封裝成了Native的實現，因此在UGUI中這部分沒有額外的堆內存分配，這也是UWA官網把UGUI在運行時分配的堆內存大小標準定義為小于2M，而NGUI的建議標準是小于20M的核心原因。
那么，如何降低UI系統中Mesh重建的次數呢？主要從以下兩點出發：
上述兩點分別對應兩個優化思路：
針對第一點，除了不要進行不必要的ui修改操作之外，對于需要頻繁切換的復雜界面，張鑫博士給出的建議是：
一個使用案例是背包界面，有大量的item，創建過程消耗也會很大，如果內存允許的話，使用上述方法會有最小的性能開銷。
而盡量減少Mesh重建影響的范圍則對應一個基本原則——動靜分離，即把不需要動態改變和需要頻繁地動態改變的組件分離出來。按照上述的第二點，可以使用canvas進行動靜分離。就是說比如某個組件下面掛的東西是一個會動態變化的部分，那就把它獨立成一個canvas。比如仍然以背包界面為例，滑動內容會導致界面的變化，在滑動過程中每幀都會有Mesh的重建操作。把滾動的部分做成單獨的Canvas，這樣背景圖片和標題等部分就不會被每幀重建了。
這里需要著重注意的是一些會頻繁改變的動態部分，比較容易遺忘，比如聊天中的動態表情，角色坐標信息的顯示等部分，在開發過程中需要著重注意。
之前有討論過動靜分離的概念，但是進行分離的基本規則和原理并不是很清楚，張鑫博士的沙龍從性能分析的具體數據出發，結合具體函數的作用，講解得清晰透徹。
另外有幾點關于ui優化的筆記：
UWA做了一個血條性能分析的Demo，也是和UI有關。
通常MMO游戲中血條會比較多，比如一些PVP或者PVE玩法中，血條會有幾十個甚至上百個，他們會隨著怪物的死亡等消失，又會隨著新的怪物產生而重新出現。這里需要注意的點有如下幾個:
多線程渲染是我在網易的時候跟過的一個大坑。。。當然不是我做的開發，而是我們項目比較早在使用引擎組做的這一功能，從集成過程到做兼容性測試遇到過很多問題，比如某些設備上莫名其妙的Crash。
張鑫博士說他們從他們的經驗來看，Unity 5.3版本之后多線程渲染的功能已經是一個比較穩定的版本了，現在已經有正在運營的項目在開啟多線程渲染。因此整體上還是可以比較放心地開啟的。多線程渲染對于PostEffect的提升效果很大，他們做了一個測試可以讓CPU消耗從平均20ms降低到平均2ms，也有項目開始之后出現頓卡。
與之前了解的一樣，開啟多線程渲染之后的性能提升效果根本上和是CPU瓶頸還是GPU瓶頸有關，不同設備效果不同，不同游戲的瓶頸也不同，因此要各個項目自己測試來看，因此UWA官方的說法是——
這部分提到如果在觀察Profile面板時發現WaitingForJob很高，就說明CPU在等子線程，就已經有性能問題了，當出現PutGeometryJobFence的時候，性能問題就已經很嚴重了。
MMO開發中角色陰影已經成為了一個標配，UWA經過測試，Unity官方的Build-in ShadowMap的性能還是最好的，推薦使用，只是效果相對差，而且在Mobile設備上無法支持原生的軟影（存疑，需要自己測試一下效果）。
而Projector的實現方式比較適合只有一個角色需要陰影的情況，推薦了兩款插件：
陰影這塊是我們項目目前要研究的重點內容之一，我們在考慮全部動態陰影的方案來部分替代烘焙的LightMap。這部分市面上的產品只觀察到韓國的兩款Unreal的手游這么來做，之前在網易內部使用Forward Lighting一直都是烘焙的方案。這塊如果有朋友了解什么信息還希望不吝賜教~
這是比較有意思的一塊內容，之前的思路一直都是大部分情況下統一使用異步加載，只有在明確知道資源非常小，而且不重要的模塊使用同步加載的方案，比如一個只有幾個面的dummy model之類的。
UWA給出的建議是：在Loading界面中，如果不需要表現平滑的加載進度和加載界面的話，可以使用同步加載，其他的過程中使用異步加載。原因是——
如果覺得加載時間過長，而對于加載過程中的玩家體驗不需要過多關注的項目可以參考這一思路。這的確是我之前的經驗所沒有包含的部分。
另外，在Unity中，對于異步加載來說，也可能會造成頓卡，因為不是所有的過程都是異步的。IO部分可以做到完全異步，但是內存中的初始化的部分過程可能仍然是同步的，比如一張1024 1024大小的貼圖異步加載，通常設備上都會可以感受到卡頓，因此建議大于這個尺寸的貼圖統一進行預加載*。
與此相關的還有一個Unity的小知識。Unity默認每幀給2ms的時間讓CPU拷貝內存東西到GPU中，比如貼圖、網格頂點等，默認的Buffer是4M大小，因此這里也會影響資源加載到最終渲染到屏幕上的時間。這兩個參數是可以調整的，具體接口參考官方文檔。另外默認4M正好是一張32位的1024 1024大小的貼圖大小，如果使用了2048 2048或者更大的貼圖格式，這個Buffer會增大為對應的大小，并且不會在縮小回來。因此建議資源中的最大尺寸可以給一個定義，盡量不要出現只有偶爾幾張貼圖使用非常大的尺寸的情況。
除了常規的降低骨骼數量和動畫曲線數量之外，Unity 5.2之后提供了一個culling Group的功能，用在模型位置一直綁定一個球的方式做碰撞體來優化判定，不在視錐范圍的的物體不進行Animator的Update。這一功能主要針對腳本邏輯的Update，Animator沒有提供單獨的接口根據距離來控制Update頻路，一個可行的思路是自己重寫其Update接口，然后傳入更高的Delta Time來模擬降頻的功能。不過以我之前用Havok的降頻功能來做性能對比的話，除非角色數量非常高，否則這部分骨骼骨骼的更新的優化空間不是非常大，不過Unity這塊具體的數據要進行測試才知道。
Animator中有一個Optimize Game Objets的選項，可以降低Update的消耗，UWA建議使用。這是因為默認情況下每根骨骼都是一個GameObject，每幀骨骼更新之后會需要修改它們的Transform。
對于Animator的Active和Deactive的操作有很大的性能消耗，這在之前斗魚上的直播中已經提到過了，這里還是像ui一樣，建議將角色移出視窗之外的方式來進行緩存，或者只把組件Active和Deactive，來提升性能。
除了上述的一些問題之外，還有一些比較了零碎的筆記，不進行贅述，只記錄如下：
這一部分是張強同學做的講座，基于地形的方式實現了的大世界動態加載功能。其實這部分本來是我期望去聽和討論的部分，以為我們項目正好在進行這塊的技術預研，但是我們不是使用地形，而是基于靜態Mesh，另外視角我們更傾向于平視而非2.5D，因此這部分對于我們的幫助沒有想象中的大。
我個人覺得這部分的一個問題是整個工程是基于一個Demo性質的實現，而非正式的項目，因為時間關系沒有在后面進行深入的交流，因此也不清楚目前的實現是否在正式的項目中應用了。一些應用方面的疑問其實講座正文中沒有講到：
這部分可以直接參考官方給出的PPT，我做的筆記不太多，這里只放了一些沒有來及提出的問題，幸好加了兩位主持人的微信，回頭整理好問題再一并請教，有答復了再修改本文。
這次上海之行，一天時間往返上海杭州，只為了這兩場講座。從收獲來說，雖然和預期稍有不同，但是還是很值得的。感謝張鑫博士和張強同學兩位主持人的分享，你們辛苦啦也感謝UWA公司組織這樣免費的技術沙龍，祝愿貴公司越來越好~
2016年11月26日于杭州家中
三、什么是幼兒園自主性游戲
幼兒園自主游戲即幼兒在一定的游戲環境中根據自己的興趣和需要，以快樂和滿足為目的，自由選擇、自主開展、自發交流的積極主動的活動過程，這一過程也是幼兒興趣需要得到滿足，天性自由表現，積極性、主動性、創造性充分發揮和人格建構的過程。
自主游戲不等于教師對幼兒的放任自流。幼兒的自主游戲不是幼兒的自由活動，幼兒想怎么玩就怎么玩。對于幼兒在自主游戲中存在的問題，教師要細心的觀察，適當的干預，幫助他們就決問題，促使游戲順利進行。
教師在不打斷幼兒自主游戲的前提下，適當的給幼兒以啟發、指導，幫助他們克服困難。教師不能因為自主游戲是幼兒的自我探究活動而放任不管，須知教師是幼兒游戲的導航者、解讀者、支持者。
擴展資料：幼兒自主性游戲的特征
1、游戲計劃的生成性
游戲計劃不是教師事先憑想象制訂的，而是根據兒童在游戲中的表現，根據兒童的需要及存在的問題來制訂下一次的游戲計劃，在兒童的游戲活動中不斷生成新的計劃，可以使游戲的開展更加能滿足兒童的愿望和需要。這樣，避免了游戲指導的盲目性和導演性。
2、游戲環境的多樣性
幼兒在玩游戲的時候，環境也不是一成不變的。它要根據幼兒游戲的不斷深入，生活經驗的不斷積累，從而進行豐富、變換。在不斷生成的游戲中，環境具有多樣性和開放性，幼兒想玩什么游戲，是他們的權利。
3、教師角色的多重性
教師以多重身份指導游戲，有利于對游戲的有效指導。當幼兒需要游戲材料時，教師是游戲材料的提供者；當幼兒需要幫助時，教師是游戲的支持者和援助者；當幼兒需要教師一同游戲時，教師是兒童游戲的伙伴和參與者；
當幼兒不需要教師介入時，教師是游戲的觀察者；當兒童在分享游戲經驗時，教師是傾聽者和發問者。