帕納寧道︰「或許我們不應該太先入為主順著游戲引擎這個思路走，我們應該想想如果我們沒有游戲引擎我們要怎麼開發？」
貝尼托•瓦西里耶維奇說道︰「關于這個我先前已經考慮過了幾種可能。
我覺得涉及到下雨這個情景，最讓人嘖嘖稱奇的其實是三點。
首先，GRAY FOREST設計的‘下雨’很有層次感。
其次，早GRAY FOREST設計的下雨場景中並沒有出現一般游戲里天氣粒子常常呈現的井噴或者斷續。
貝尼托•瓦西里耶維奇接著說道︰「後兩個問題稍微麻煩一些，但涉及到層級感的問題，倒是不難猜測GRAY FOREST是怎麼做到的。
無非就是以2D的形式進行了3D的表現而已，從而實現一種偽3D的效果。」
帕納寧印象中以2D形式進行類似于3D的表現︰
首先要在2D游戲場景中設置3D渲染區域。
在3D渲染區域要放上想要表達的多個2D圖片。
當然2D圖片並不是隨意放置的，要將所述多個2D 圖片渲染成相鄰圖片的兩側邊緣順次連接在一起的折疊冊頁的3D形式。
這樣做的話當程序開始接受到輸入信息（諸如對觸屏上的滑動手勢之類的）做出響應時。
就會將3D渲染區域提前「放置」的折疊冊頁向著程序先前設定的方向展開。
這個過程還要智能地調整相應折疊冊頁中的排布順序及圖片的尺寸以實時地確定各2D圖片的展開位置和展開角度。
這一過程順利實現的話可以將各2D圖片渲染成與其展開位置和展開角度實時對應的偽3D表現形式。
具體怎麼理解這個過程呢？
帕納寧想到了「立體書」，就是一翻開能看到立體畫面的那種書。
某種程度上在2D游戲場景中設置3D渲染區域而後在所述3D渲染區域顯示多個2D圖片這一舉動就很類似于立體書的運作過程。
只不過架構這種「立體書」的過程遠比繪制現實中那種小兒科般的立體書要復雜的多。
這個過程需要涉及到對2D游戲場景進行分層。
要將2D游戲場景中所述折疊冊頁所在的區域設置為采用3D渲染策略的3D渲染層。
所述3D渲染層不光要對應于所述3D渲染區域，同時為了避免一些瑕疵的出現。
還要將2D游戲場景中的背景區域設置為采用2D渲染策略的2D渲染層。
而後要將3D渲染層覆蓋到2D渲染層之上。
通常這個覆蓋的采用的形式是︰
——對所述2D渲染層采用正交投影方式進行投影，對所述3D渲染層采用透視投影方式進行投影。
並不是簡簡單單疊加就完事了。
在游戲中涉及到具體到表現的時候還要繪制2D渲染層到顏色緩沖區。
將2D渲染層的所有像素深度設為最大深度而形成為所述2D游戲場景的背景；
繪制3D渲染層到顏色緩沖區︰
對于3D渲染層的所有像素深度設為小于所述最大深度。
使得3D渲染層投影生成的畫面覆蓋背景所在2D渲染層的相應區域。
如此才能在2D畫面上實現的3D視覺效果。
這個過程听起來就很麻煩。
雖然不明白大道至簡的道理，但帕/納/寧同樣認為而麻煩的事物往往意味著實際運行的時候容易出現這樣那樣的問題。
反正帕/納/寧覺得GRAY FOREST所用的絕對不是這種方法。
在老搭檔面前帕/納/寧自然沒有遮掩。
他將他這個想法毫無保留地說給了貝尼托•瓦西里耶維奇。
貝尼托•瓦西里耶維奇深以為然。
帕/納/寧道︰「我的老伙計，你把我搞糊涂了。
你剛才說GRAY FOREST所做的無非就是以2D的形式進行了3D的表現從而實現3D的視覺效果。
可你也同意了我剛剛的觀點——認為GRAY FOREST采用的不是通過引入3D渲染區域再構建‘折疊冊’的那種做法。
莫非你想說的是除了我剛才說的這種方法之外，還有別的方法可以在2D畫面中進行3D表現？
在電腦游戲中除了我剛才說的那個方法，確實還有很多別的方法在2D畫面中進行3D表現。
但恕我實在想不到在手游里除了構建3D渲染區域之外，還有哪些可以實現在2D畫面中實現3D效果的技術。
哦，我親愛的貝尼托•瓦西里耶維奇，別繞彎子了，快告訴我你究竟是怎麼想的。」
貝尼托•瓦西里耶維奇理了理思路，而後開口說道︰「首先說到你剛才提到的觀點，我和你也是同樣的見解。
如果按照你說得那種方法在實際操作的時候涉及到將3D渲染層覆蓋到2D渲染層之上時。
這個過程需要對2D渲染層采用正交投影方式進行投影，對所述3D渲染層采用透視投影方式進行投影。
而這兩種投影涉及到的計算都極其龐大。
尤其是透視投影是典型的計算密集型投影，這個過程涉及到三角計算。
並不是sin x、cos x那種簡單的三角計算，涉及到這個過程中的三角計算通常伴隨附加有包括矩陣和矢量相乘的運算。
隨著場景中所記錄細節的量的增大時，用來渲染該場景的冗長計算的數量也將增大，這對CPU是個極大的考驗。
常規情況下，涉及到一般物體的投影計算都很吃CPU。
更何況是涉及到下雨這個場景，如果按照你說得這種辦法進行透視投影的話。
實時計算量將隨著雨滴數量的增多而呈現出指數增長。
恕我直言，別說5s中的A7處理器是一枚桌面級處理器。
就是A7處理器的處理效能在此基礎上再翻一番恐怕也只能勉強滿足這種運算需求。
巧婦難為無米之炊，如果真的是采用這種方式的話，現有的CPU水平根本無法提供技術支撐。
假設GRAY FOREST所采用的真是這種方式的話。
那麼在現有的技術水平下，運行這麼一款計算量超級多的游戲時會出現什麼樣的反應呢？
這些額外的計算大概率會要求以移動設備減小的幀速率進行游戲。
這也從側面驗證了我們先前的判斷。
除此之外，我覺得GRAY FOREST所采用的方式也不是傳統意義上的游戲渲染。
一般來說涉及到2D游戲畫面相對應的游戲渲染通常所采取的步驟通常是︰
先獲取2D游戲畫面數據而後分析2D游戲畫面元件的初始坐標；
在獲得初始坐標之後根據所述初始坐標構建所述2D游戲畫面元件的實際坐標系。
接著，基于上面所構築的實際坐標系，將2D游戲畫面映射成3D游戲畫面才具有的視覺效果。
再之後要將映射的3D游戲畫面的數據緩存到緩存器中。
當接收2D游戲的運行指令，只需要根據所述運行指令調取緩存器中已經生成的3D游戲畫面的數據就可以了。
同時為了增強表現形式，還需要對調取的3D游戲畫面進一步渲染。
上述這個過程對GPU的要求很高，GPU必須有強大的實時渲染能力。
這樣的做法雖然理論上行得通，但也僅僅是在越獄後蘋果手機或者ROOT之後的安卓手機上菜行得通。
但在正常狀態的手機中根本不大現實。
畢竟一個應用能調用的GPU大多數情況下都是相當有限的。
帕/納/寧︰「那你認為GRAY FOREST采用的究竟是什麼方式呢？」
貝尼托•瓦西里耶維奇︰「對此我也只能猜測，一個人設計游戲時采用的方式很大程度和其開發風格有很大的關系。
GRAY FOREST雖然崛起的很迅速，像一顆冉冉興起的新星，但此人開發手法是相當老練的。
這些作品都得到了市場的驗證，廣受游戲玩家的喜愛。
能取得這樣的成績的GRAY FOREST也可以說得上是一個極其有經驗的游戲開發者了。
而這樣的人在涉及到具體游戲開發時不可能憑空給自己制造麻煩。
因此我推斷GRAY FOREST所采取的一定是最簡單的方式。
另外不久前GRAY FitHub上上傳了他之前開發《2048》所設計的代碼。
開始的時候我並沒怎麼當回事，因為這段代碼形式並不算很簡潔。
但絕對是在iOS上運行起來效率最高的。
其實像《2048》這種簡單的小游戲，即便是運行效率有點區別，也不會影響太大。
可偏偏GRAY FOREST一定要搞一個效率最高的。
這說明這個人骨子里就追求高效率。
而在2D游戲中最高效的做法絕對不是額外引入3D渲染區。
基于效率方面的分析以及對游戲畫面進行判斷。
我認為GRAY FOREST在下雨場景中雨滴之所以看起來很有層次感是因此采用了一種視覺欺騙。」
帕/納/寧疑惑道︰「視覺欺騙？」
貝尼托•瓦西里耶維奇︰「對的，就是視覺欺騙，一般我們會下意識的認為‘近大遠小’。
因此涉及到雨滴層次感架構的時候，只需要將雨滴表現的大小不一即可。
當然，涉及到如此濃密的雨滴，GRAY FOREST絕對不可能一滴滴地去繪制。
正常來講，2D畫面，就是只有X、Y軸的畫面，不存在Z軸；
而3D畫面，則是有X、Y、Z軸的畫面。
而GRAY FOREST采用的做法應該是在2D游戲中引入了虛擬的Z軸。
我猜測GRAY FOREST具體來說是這樣做的。
因為在游戲中，像雨滴這種東西一般都是由粒子系統進行表示的。
[一般來說粒子系統表示三維計算機圖形學（CG）中模擬一些特定的模糊現象的技術。
之所以將這些現象稱為模糊現象是因為用其它傳統的渲染技術難以實現的真實感的游戲圖形。
經常使用粒子系統模擬的現象有火、爆炸、煙、雨、火花、落葉、雲、霧、發光軌跡這樣的抽象視覺效果等等。
粒子系統的核心是粒子發射器生成的一個個行為獨立的粒子，共同構建出動畫]
在對游戲中引入虛擬的z軸之後。
這樣我們在游戲開發中進行雨滴層次感的構建的時候。
完全可以讓粒子發射器在發射天氣粒子（雨滴）的時候，賦予天氣粒子（雨滴）一個虛擬深度值Z。
在天氣粒子的整個生命周期中，虛擬深度值Z保持不變；
Z值和天氣粒子（雨滴）狀態之間應該存在著一個函數，
這個函數所起到的作用是縮放作用是對雨滴進行縮放。
並且這個函數將賦予深度值不同的天氣粒子以不同的視覺大小和運動狀態。
再之後將縮放變換結果分別發送至粒子大小顯示單元和粒子運動狀態顯示單元
如此一來，理論上應該會使2D游戲中的天氣粒子具備層次感。
當然，這只是我的猜測而已，想要知道問題真正的答案，還需要進一步的分析。
再或者，我們要向GRAY FOREST本人尋求答案。」
（ps︰……天氣粒子分層這個是豬場的技術，原本是14年末出現的）
帕/納/寧听到這個分析，似乎又收獲了一些新的啟發，不過他也有不解之處。
帕/納/寧說道︰「只是這樣嗎？我記得在很多游戲的建築場景都常用到這種類似的近大遠小效應啊。尤其是涉及到一些城堡廊柱之類的游戲這種近大遠小的設置其實是很普遍的。
甚至這樣的設計多多少少有點復古。」