1. 程式人生 > >SNS遊戲開發的感想

SNS遊戲開發的感想

  目前SNS相當熱門,因此也有想做SNS遊戲的想法,畢竟從校內網和及開心網的運營來看,第三方的SNS遊戲製作公司盈利還是相當大的。可以說2009年是SNS遊戲是興起的一年,而10年則會是百花齊放的一年,這是一塊大蛋糕,雖然有人勸我說這類遊戲已經氾濫,但我覺得蛋糕大也說明市場大。下面說說做一個SNS遊戲所需要做的一些事情。

 

1、Flash素材庫的建立

這個需要美工來做,首先做成一個包括許多遊戲中要用的的元件的庫檔案,元件的建立可以用別人的素材,也可以自己手繪,這個要看美工的能力,最後編譯成SWF檔案來供AS程式設計師來呼叫。

 

2、遊戲主程式的建立。最好用FLEX來完成,因為flex builder不管是對專案的控制還是面向物件的管理都比用Flash 來做好很多。專案要建成ActionScript,因為你既然是做遊戲就不會用到FLEX的控制元件,因為所有的遊戲裡面的控制元件都不是普通程式裡面的控鈕或是標籤控制元件。

 

3、後臺WEB語言的選擇。其實一開始想使用Ruby On Railsr,但是最終還是放棄了。後來又考察過JSP,因為JAVA是一門支援多執行緒的語言,不像ROR或是PHP之類的單執行緒語言,而且JSP又可以用執行緒池,在WEB伺服器和資料庫的併發效能上肯定會好些。但是JAVA的執行緒同步也會隨著應用的複雜出現一些陌名其妙的事情,這也是我最終決定放棄JSP的原因,再後來我看了一篇JSP和PHP關於資料庫效能評測的文章後我就完全拋棄了JSP,因為JSP和PHP分別用普通方式和連線池(jsp)和長連線(php)的的方式評測結果來看,幾乎是一樣,雖然連線池或是長連線的效率相比普通方式的資料庫評測提高了將進三倍,但卻未必適合像SNS遊戲這樣有些巨大同時上線使用者的程式。傳統方式的資料庫操作是當需要從資料庫取資料的時候連線資料庫,取到資料後,則關閉資料庫連線,這樣的方式雖然在頻繁的連線與斷開中損失了一些效率,但是從資料庫的負載來看卻比較好的。試想一下,一同資料庫伺服器同時有1萬人連線,並且進行著select、update、insert等操作的時候,會是什麼樣的場景。因為JSP看起來是真的適合做B/s的軟體,而不應該是網站,雖然效能優異,但是決不那麼容易駕馭,或許牛人可以寫出多執行緒支援完美,且高負載的WEB後臺程式,但是對於SNS遊戲這種短平快的專案,顯然是不適合的。這樣看起來PHP是最合適不過的選擇了,簡潔的語言、靈活的程式設計方式,以及豐富的類庫,以及全球300萬PHP程式設計師的資源共享,決定了這門語言的生命力。我這裡不推薦用PHP的框架,因為畢竟不是用PHP做網站,我們要做的只是一個能與as程式互動的WEB後臺程式,用框架必定也會損失一些效能,而且最主要的還是下面要說到的通訊協議庫AMFPHP的存在。

 

4、說到通訊協議最開始的想法是採用JSON,通過PHP的JSON庫將資料庫中的資料通過JSON的方式返回給AS程式,然後解析處理,因為比XML格式來說JSON的包會小一點,但是從本質上來說XML和JSON都是文字型別的資料包,效率來說肯定比不上使用二進位制的AMF格式,而PHP有大名鼎鼎的AMFPHP包,可以提供使AS程式與PHP進行通訊,當然AMF3也有自身的缺點,雖然是二進位制的資料包,但是本身有過多的描述資訊,且並未進行過壓縮,據我觀察描述資訊佔到500多個位元組左右,哪怕是一個只有一個英文字母的資料包,因此對AMF3進行壓縮是相當必要的,雖然當資料返回量大過5K時,可以基本忽略500多個位元組的冗餘資訊,但是對於SNS遊戲來說,往往有時使用者伺服器上取到的資料就是很短小的資料包,比如說使用者點選的某一塊地上的種物成熟剩餘時間(這裡以開主農場遊戲為背景),這樣的一個包,如果用純JSON包來構建,相信不會超過100個位元組,但是返回的AMF3包足足會有600多個位元組,於是當遊戲使用者達到一定的數量級別,加之此類操作的頻繁程度,相應這其中的總體效率會降低很多,因此在伺服器端的壓縮資料應該說是必須的。當然我們可以用ZLIB庫來進行壓縮,但是壓縮也有一個隱患,就是要消耗伺服器的CPU佔用率,當這種壓縮的操作很頻繁的時候伺服器的CPU勢必會保持在一個比較高的百分比上,因此在選擇壓縮比例的時候要總體來權衡。

 

5、一個團隊要將這些技術整合在一起,並加以實際應用做成SNS遊戲可不是一件容易的事情,程式開發完成後,還要進行遊戲本身的BUG測試,之後就是壓力測試,再下面就是伺服器的構建以及寬頻的選擇,產品上線前要做一一的宣傳工作,上線以後還要做推廣,以及維護、更新工作。

 

總結:雖然說SNS遊戲做起來門檻不高,但是要真正做好一個SNS的應用我覺得並不是一件很簡單的事情,首先遊戲的創意其實決定了遊戲本身的盈利,如果沒有好的創意,做出來的遊戲沒有什麼可玩性,使用者既使在你一定的推廣下會來註冊你的遊戲,但是你絕對不會擁有一定數量的活躍使用者。然後就是技術支援,你的團隊中要有精通flash的美工人員(如果只是會用flash而不具備鼠繪能力的美工,那麼你的遊戲將不會帶給使用者多少的衝擊視覺),還要有能積極響應並處理AS的高階程式設計師(如果程式設計師經驗不很豐富,無法及時去改正程式中的BUG以及無法滿足使用者的一些改進BUG的要求,而導致論壇裡罵聲一片)。再者就是要有一個WEB語言的高手(新手是無法駕馭好後臺通訊協議的)以及一個可以靈活使用SQL命令的資料庫工程師,通常PHP程式設計師都是會直接採用SQL命令來操作資料庫的,我覺得這是一個好習慣,我不太喜歡框架中的封裝好的資料庫類,我覺得這是高階程式設計師做給低階程式設計師使用的一種在降低效能提高通用性的情況下產物。因為一個胸懷大志的程式設計師,應該很少用人家的框架,而應該在自己的專案中總結一些重構以及複用的方法。當然還要有一個伺服器配置、運營的高手,因為做SNS遊戲肯定是需要自己有伺服器,虛擬主機也好,VPS也罷,都是支撐不起如果大的訪問量的,伺服器的優化、叢集以及分佈管理都是需要認真考慮的東西,這關係到整個應用的最終命運。最後還要有一個CTO,會運籌為握的人,把握SNS的方向才能真的走向成功,希望中國的SNS第三方開發商們能懷著一顆熱切的心投入SNS應用的開發,卻迎接2010這個山雨欲來風滿樓的年度!