某天，我看到流行的、一筆畫完類型的小遊戲，於是就在那想，這種遊戲的關卡構建是不是都是人工構建的，還是說程序可以隨機生成。
結果想着想着就想動手試試，恰好最近在研究一款叫playcanvas的3d引擎，於是弄了個3d Demo。
爲了快速演示，demo裏的格子沒用特別複雜的模型，而是用了簡單的正方體模型，演示的效果是隨機生成一個有解的佈局，通過觸碰或滑動屏幕來構造一次走完的路線。
demo沒花我太多時間，大概兩個小時就搞定了。
要不不開始，一開始便不可收拾，我不想它就是個簡單的演示demo。
所以接下來的週末，我都沉迷在這個demo的優化過程中了。界面怎樣在短時間內美化？到底隨機地圖的關卡怎麼構建？是不是該用小程序雲？能不能做點只有小遊戲可以實現的功能？
一系列問題突然在我腦海中盤旋。
顯然最後都實現了，現在回想起來有種類比於“爲什麼當年高考都能扛過去”的感覺，所以這裏記錄一下開發歷程中的思考。
代碼邏輯，太枯燥這裏就不細說了，有興趣的同學可以線下交流，這裏通過幾個問題拋點大家能理解的業務思路。
界面怎樣在短時間內美化的？
有朋友說目前的視覺不太好看，我只想說，兩週的開發時間，而且只是下班後或者週末的業餘時間搞的項目，從策劃到交互到視覺到開發，都一個人包辦，你想要專業級的視覺呈現，是不是太苛刻了。
所以，視覺上走的是一種折中的開發方式，比如說，不做2d的，做3d的，在視覺表達上，3d引擎爲我提供了透視、光照、陰影等現有的效果處理方式，我可以輕鬆的畫出一些低精度模型，加點光加點影，畫面就顯得不會太違和。
所以，我第一次用3dmax畫了個小雞模型。。。
其他UI層面的元素，就用photoshop稍微畫畫就好。
到底隨機地圖的關卡怎麼構建？
對於有解關卡的隨機構建其實很簡單，大體邏輯是：隨機定點，然後從三個可選方向中選一個行走，一直走到無路可走時，此路線就是一個關卡，目前遊戲中有個“發起挑戰”的模式，其實就是這個思路的縮影。
但怎麼判斷這些關卡的難度呢？這成了我最頭疼的問題，依據總個數？不行，只能算是其中一個維度。按照起點和終點的距離？好像也沒有固定的算法。到最後我也沒得出判斷難度的程序判斷標準，只能人爲定義了一些比較難的關卡。
是不是該用小程序雲？
一筆一連小遊戲目前遠端的邏輯基本都放在小程序雲上面，但也有部分邏輯需要自己搭建第三方服務器來支援。
小程序云爲遊戲提供了玩家遊戲記錄存儲、排行榜邏輯處理等基礎處理功能，但諸如“生成小程序碼”、“調起微信商戶功能”等需要服務端二次校驗權限的接口，小程序雲目前是不支持的。
以結果來看過程的話，中大型遊戲用小程序雲會有挺大程度的限制，但小型的小遊戲用小程序雲應該綽綽有餘了。
能不能做點只有小遊戲可以實現的功能？
答案肯定的，我做demo有個習慣，總想利用它做點新功能的預研或者做點老接口的綜合應用。一筆一連小遊戲中就有兩個點是爲了好玩或者研究而做的。
第一個是“動態消息”的功能
實際落地點是遊戲中的“集結贏薯條”功能（更多細節可參考這裏）：
第二個是發紅包功能
這可能是個有爭議的功能，花叔只是好奇玩一下，有成型的體驗demo，但目前沒上線，技術上能跑通的。
主要的業務邏輯是：
首次需要構建小遊戲和另一個可以發起企業付款小程序間的openid映射關係，當存儲後，以後的每次領紅包操作，即可根據關係去間接調起商戶接口發起（有規則風險）。
而技術邏輯大概是這樣：
只要玩家首次完成這個交互，把這個關係構建好後，未來的就再也不會有跳轉付款小程序的前端交互了。
當然，如果小遊戲和付款小程序是同主體，他們間的openid理論上能動態互轉，就可以免去“通過前端跳轉來構建兩個openid關係”的繁瑣步驟。
好了，說了聽多了。
結束...