1。還沒(méi)有真正的次世代網(wǎng)游，更別指望它能賺錢
好幾次有朋友問(wèn)我，次世代網(wǎng)游到底是什么東西
我說(shuō)，次世代網(wǎng)游就是模型至少上萬(wàn)面，貼圖每張都起碼2048，法線圖，高光圖，多層蒙版一個(gè)都不能少；動(dòng)態(tài)光滿天飄，還都是開(kāi)著陰影的；體積云，體積霧，體積光，全都是立體的，酷；水面的反射，折射，波紋，浪花，樣樣精彩；超大型，超豪華場(chǎng)景，無(wú)限視野。就一個(gè)字：真實(shí)！哦不對(duì)，是兩個(gè)字，超真實(shí)。
這樣的游戲用現(xiàn)在能配到的最好的機(jī)器，跑起來(lái)FPS也一定不允許超過(guò)15，否則那就不能叫次世代了。
說(shuō)白了，次世代就是你用當(dāng)下的機(jī)器完全跑不起來(lái)的游戲，要么怎么能叫“次”世代呢。
這樣的游戲，不是讓大多數(shù)玩家能玩得起來(lái)的，不是拿來(lái)賣錢的，就跟北京的商品房一樣，是給大家去追捧的。最多，會(huì)等Intel，Nvidia來(lái)給開(kāi)發(fā)商返點(diǎn)利。嗯，我是說(shuō)，大概可能估計(jì)會(huì)有的吧。
次世代的游戲其實(shí)已有不少了，比如戰(zhàn)爭(zhēng)機(jī)器，比如戰(zhàn)神，比如彩虹六號(hào)……但次世代的網(wǎng)游還沒(méi)有。
魔獸是次世代嗎？不是，完全不是。
永恒之塔是次世代嗎？也不是，它也還差的遠(yuǎn)。
天下二，劍網(wǎng)三就差的更遠(yuǎn)了。
2。真正賺錢的游戲技術(shù)都很普通
也許你會(huì)說(shuō)，真正的次世代游戲都還沒(méi)有出來(lái)，你怎么就敢預(yù)言他們不能賺錢呢？
是的，我不能，如果我有未卜先知的本領(lǐng)，那我早就不再需要靠做游戲來(lái)養(yǎng)活自己了。
可是，我們卻能夠看到現(xiàn)在賺錢的游戲是什么樣的，這些是明明白白擺在那里的。
魔獸世界：把這個(gè)游戲譽(yù)為國(guó)內(nèi)3D游戲的教程書完全不為過(guò)，不過(guò)你承不承認(rèn)，策劃也好，程序也好，美術(shù)也好，都從這里面學(xué)到了很多東西，模仿了很多東西，在目前國(guó)內(nèi)的游戲里面，到處都能找到魔獸的影子。
可是魔獸又用到了多神奇的技術(shù)？主角模型算上所有部件，3000多面，各部件的貼圖組合在一起，512大小，沒(méi)有法線沒(méi)有高光，絕大多數(shù)還都只是一層貼圖，偶爾有一些多層混合的。地形最簡(jiǎn)單的分塊4層混合，最簡(jiǎn)單的lightmap。水面，把鏡頭拉遠(yuǎn)一點(diǎn)都能看出來(lái)貼圖形狀。天空盒，一個(gè)普通的m2模型。
可是，魔獸所表現(xiàn)出來(lái)的整體場(chǎng)景效果，有哪一個(gè)游戲敢說(shuō)超越呢？
天龍八部，基于開(kāi)源引擎Ogre制作的典范，也因?yàn)樘忑埌瞬抗奈枇藝?guó)內(nèi)好多使用Ogre開(kāi)發(fā)的小團(tuán)隊(duì)。
不得不承認(rèn)，Ogre所使用的技術(shù)是最樸實(shí)的，樸實(shí)到我這樣一個(gè)3D新手都能拿來(lái)修修改改，做點(diǎn)簡(jiǎn)單的demo。
同樣不得不承認(rèn)，天龍的畫面效果確實(shí)很一般，2.5D的場(chǎng)景，固定的視角，輕盈的有些像紙片人的模型，可是，這并不妨礙他每月近兩億的收入。
夢(mèng)幻，大話，DNF，征途，傳奇……
除了這些表面上能看到的技術(shù)以外，背后的技術(shù)是同樣的道理。
早期的單服務(wù)器，分線方式，依然沿用在現(xiàn)在很多主流的游戲服務(wù)器端，并且依然是非常賺錢的項(xiàng)目。而類似于BigWorld的高深架構(gòu)，事實(shí)上也并沒(méi)有成功的項(xiàng)目。如果把天下二的商業(yè)結(jié)果跟其他項(xiàng)目一比較的話。
3。2D游戲比3D游戲賺錢
我一樣很認(rèn)同，未來(lái)的趨勢(shì)是3D，但是，那時(shí)候賺錢的3D項(xiàng)目不應(yīng)該是現(xiàn)在這個(gè)樣子的。
以國(guó)內(nèi)游戲玩家的年齡及文化層次來(lái)看，要讓他們接受“右鍵旋轉(zhuǎn)朝向，左鍵旋轉(zhuǎn)視角”太過(guò)于困難，而即使是一個(gè)很熟悉3D操作模式的老玩家，進(jìn)入到一個(gè)新的場(chǎng)景中，要分辨出“上北下南，左西右東”也是很煩人的一件事。
如何盡可能的使用上3D的表現(xiàn)力，但又避免掉目前3D游戲的復(fù)雜操作模式，這要看未來(lái)誰(shuí)先能走好這一步。
但是，在3D真正應(yīng)用起來(lái)之前，目前還是2D的天下。
國(guó)內(nèi)最賺錢的夢(mèng)幻，還有大話系列，同樣最高在線超過(guò)200萬(wàn)的DNF、征途，還有那不應(yīng)被忘記了傳奇。
不用歷數(shù)這些名字，文化部2009網(wǎng)游行業(yè)發(fā)展報(bào)告上統(tǒng)計(jì)的結(jié)果是，2D游戲收入占整個(gè)游戲行業(yè)收入達(dá)70%多。
這也無(wú)怪乎騰迅到現(xiàn)在還在開(kāi)發(fā)2D新項(xiàng)目，以3D起家的完美也要開(kāi)2D項(xiàng)目，網(wǎng)易的大話到3代了還是2D，把unreal3應(yīng)用得純熟的韓國(guó)人也同樣還在制作2D游戲。
4。游戲開(kāi)發(fā)并沒(méi)有什么高深的技術(shù)
首先需要明確的一點(diǎn)，游戲項(xiàng)目是工程項(xiàng)目，不是科研項(xiàng)目。
工程項(xiàng)目的目的是在有限的人力跟財(cái)力之下實(shí)現(xiàn)出既定的需求，而這個(gè)需求從前面的分析可以知道，要求并不高，所以，需求的實(shí)現(xiàn)過(guò)程也就并沒(méi)有多么高深。
至少在我經(jīng)歷過(guò)的項(xiàng)目里，沒(méi)有什么驚天地泣鬼神似的英雄人物，沒(méi)有創(chuàng)造出多么偉大的算法，我們所做的，只是使用現(xiàn)在的技術(shù)，現(xiàn)有的方法，拼合成一個(gè)軟件產(chǎn)品，一個(gè)融合了程序、美術(shù)、策劃勞動(dòng)力的軟件產(chǎn)品。
游戲開(kāi)發(fā)的過(guò)程里，沒(méi)有，也不需要多厲害的技術(shù)高手，需要的僅僅只是有耐心，有責(zé)任心的普通技術(shù)人員。
5。游戲的賣點(diǎn)在內(nèi)容而不是畫面，但是畫面不夠好卻沒(méi)有機(jī)會(huì)去展現(xiàn)內(nèi)容
說(shuō)這一點(diǎn)不是想強(qiáng)調(diào)到底是程序重要還是美術(shù)重要，或者是策劃更重要。這三者是缺一不可，而且哪一方弱都不行的。
我想說(shuō)的是，游戲真正留住玩家靠的還是內(nèi)容。
一樣是拿現(xiàn)在賺錢的游戲來(lái)說(shuō)，夢(mèng)幻沒(méi)有華麗的3D場(chǎng)景跟畫面，天龍有3D，但沒(méi)人會(huì)說(shuō)那里面有華麗的場(chǎng)景，DNF的2D畫面還是非常粗糙的，唯獨(dú)好一點(diǎn)的魔獸，但他的市場(chǎng)表現(xiàn)在國(guó)內(nèi)游戲里面來(lái)說(shuō)，并不算太強(qiáng)。
但是好的畫面在最開(kāi)始的幾分鐘里卻是相當(dāng)重要的，這就好比是長(zhǎng)的帥的人能夠更吸引女孩子一樣。
也許你能用你的魅力，你的錢袋子來(lái)打動(dòng)女人，但如果你穿著一件破衣服，臉上只有著殘缺美，那你后面那些魅力，那些優(yōu)點(diǎn)永遠(yuǎn)沒(méi)有機(jī)會(huì)展示出來(lái)。游戲也是一樣。
至少，你的新手村一定要做到富麗堂皇。
6。游戲并不需要追求太多的游戲性，提供一個(gè)交流的平臺(tái)就行
這是我最近的感悟。
很多人玩游戲其實(shí)就是為了打發(fā)時(shí)間，我也問(wèn)過(guò)很多沉迷于魔獸，沉迷于偷菜，沉迷于這些那些游戲的人，包括偶爾玩一下的，包括職業(yè)玩家，包括像我這樣，為了游戲而玩一下的人。
游戲靠什么來(lái)留住人，在這一點(diǎn)上達(dá)成共識(shí)并不難，那就是里面的朋友。所以，給玩家營(yíng)造一個(gè)更好的交流氛圍，交流環(huán)境，做到這一點(diǎn)了，游戲玩法可以要多俗有多俗。
又在游戲里面，還有社區(qū)里面接觸了一些新生代的玩家們，似乎家族是一個(gè)很流行的東西。這其實(shí)可以看作是以前游戲里公會(huì)的升級(jí)版。在某個(gè)兒童游戲里，一個(gè)玩家?guī)е胰⒂^他們的家族，帶我一個(gè)個(gè)拜見(jiàn)他們的官員。可我并沒(méi)有看到這些官員的頭銜，于是我問(wèn)，你們這些官員是怎么來(lái)的？答曰：自己封的。
就好像公園里的小道一樣，有時(shí)候，游人們會(huì)按照自己的喜好在草地上走出一些新的路來(lái)，這些路才是最合理的。
為什么不順著這些玩家的路，把這些功能做的更強(qiáng)大一點(diǎn)呢。
其實(shí)，把社群的功能做得更強(qiáng)大，更高級(jí)一點(diǎn)，那就像文明。或者做的更容易，更低齡一點(diǎn)，那就像過(guò)家家。不管是怎樣，應(yīng)該在系統(tǒng)里就增強(qiáng)了交流的便利性，甚至可以在玩家一加入到游戲中，就開(kāi)始引導(dǎo)著他加入社群。只有在社群里，他才能找到家的感覺(jué)，他才會(huì)因?yàn)榕笥褌兌粝聛?lái)。
當(dāng)然，怎么找對(duì)這條路，走好這條路，可不像寫下這幾行字這么簡(jiǎn)單。
根據(jù)文化部2009年游戲行業(yè)發(fā)展白皮書上的數(shù)據(jù)，游戲運(yùn)營(yíng)失敗比例30%左右，游戲開(kāi)發(fā)失敗比例50%左右，當(dāng)然這個(gè)是指登記注冊(cè)了公司的，其實(shí)還有更多小團(tuán)隊(duì)，小工作室，直接死在了起步的路上。
單從這個(gè)比例來(lái)看，似乎創(chuàng)業(yè)的風(fēng)險(xiǎn)還是挺大的，每一個(gè)成功活下來(lái)的公司都踩著一個(gè)或幾個(gè)死去公司的尸體。可是，相比起大家常說(shuō)的，十家創(chuàng)業(yè)公司一家成功，這個(gè)比例也不算高，而且，要是再看看成功的游戲公司獲得的回報(bào)，這個(gè)風(fēng)險(xiǎn)也就真的不大了。
說(shuō)游戲創(chuàng)業(yè)的風(fēng)險(xiǎn)不如說(shuō)小創(chuàng)業(yè)團(tuán)隊(duì)最終的結(jié)局。
幾個(gè)志同道合的朋友走到一起，當(dāng)然是想把事情做成功的，但是美好的期望不能保證全都能實(shí)現(xiàn)，不過(guò)，即使這個(gè)過(guò)程失敗了，也不一定全都失敗，除了最好的結(jié)局之外，也還是有其他幾種可能性的。
從最好到最壞，大致有以下這么六種結(jié)局：
1。游戲在預(yù)期時(shí)間內(nèi)開(kāi)發(fā)成功，并上線運(yùn)營(yíng)
當(dāng)然，這是最理想的結(jié)局，也是團(tuán)隊(duì)組建初期給自己設(shè)定的目標(biāo)。
國(guó)家政策規(guī)定，運(yùn)營(yíng)網(wǎng)絡(luò)游戲的公司注冊(cè)資金必須一千萬(wàn)以上，另外游戲的宣傳推廣費(fèi)用一般都比較高，所以如果沒(méi)有足夠的資金實(shí)力，獨(dú)立運(yùn)營(yíng)的可能性不大。
但是如果一切都進(jìn)展順利，順利的將游戲開(kāi)發(fā)完成，順利的找到了投資人，自己組建運(yùn)營(yíng)團(tuán)隊(duì)其實(shí)是最好的選擇。因?yàn)槎贾溃\(yùn)營(yíng)才是創(chuàng)造利潤(rùn)的地方。
2。游戲開(kāi)發(fā)成功，但不具備獨(dú)立運(yùn)營(yíng)的條件，轉(zhuǎn)做單純的開(kāi)發(fā)商，把產(chǎn)品代理給別人運(yùn)營(yíng)
如果很不幸的，沒(méi)有足夠的資金實(shí)力去運(yùn)營(yíng)自己的游戲，或者，創(chuàng)業(yè)伙伴們對(duì)自己運(yùn)營(yíng)游戲的把握都不大，也找不到一個(gè)放心的人來(lái)做，再或者，投資人不希望由開(kāi)發(fā)團(tuán)隊(duì)自己來(lái)運(yùn)營(yíng)。那么，把產(chǎn)品代理給專業(yè)的運(yùn)營(yíng)公司，獲得利潤(rùn)分成，也是一個(gè)不錯(cuò)的選擇。
其實(shí)很多的創(chuàng)業(yè)小團(tuán)隊(duì)最終選擇的都是這條路，更不用說(shuō)參與18計(jì)劃，贏在巨人計(jì)劃的那些團(tuán)隊(duì)了，本身就是屬于投資公司旗下的。
運(yùn)營(yíng)畢竟不同于開(kāi)發(fā)，游戲開(kāi)發(fā)需要解決是技術(shù)問(wèn)題與團(tuán)隊(duì)內(nèi)成員的合作問(wèn)題，而運(yùn)營(yíng)面對(duì)的競(jìng)爭(zhēng)卻有可能是血淋淋的，商場(chǎng)如戰(zhàn)場(chǎng)，沒(méi)有十足的把握與充分的資金支持，需要慎重對(duì)待。
但是代理給別人最大的一個(gè)問(wèn)題是收入將受制于人，首先這個(gè)分成比例可能會(huì)并不高，另外，如果游戲比較成功了，運(yùn)營(yíng)公司很可能會(huì)山寨一款同樣的游戲，并把用戶引入他自己的游戲，而避免與原來(lái)的開(kāi)發(fā)商分成。這樣的例子在國(guó)內(nèi)已不鮮見(jiàn)。
3。游戲開(kāi)發(fā)過(guò)程中遇到問(wèn)題，團(tuán)隊(duì)加入大公司，以工作室或獨(dú)立部門方式存在
團(tuán)隊(duì)最終加入大公司的情況，也并不一定是自己遇到了問(wèn)題，也有可能是合作的需要。
當(dāng)創(chuàng)業(yè)團(tuán)隊(duì)度過(guò)了最初的一段時(shí)間，游戲基本成形，開(kāi)始大量的內(nèi)容制作的時(shí)間，將可能需要招聘大量開(kāi)發(fā)人員，這時(shí)，人員的管理不像以前幾個(gè)核心人員那樣，完全靠自覺(jué)了。而創(chuàng)業(yè)的伙伴們顯然對(duì)技術(shù)的把控比對(duì)人員的把控能力要強(qiáng)，也許，找一家成熟的公司，由他們來(lái)處理這些人事、財(cái)務(wù)方面的瑣事要容易得多。
另外，也有可能投資人希望開(kāi)發(fā)團(tuán)隊(duì)能夠在自己身邊，能夠經(jīng)常看到開(kāi)發(fā)成果，能夠讓自己更放心。畢竟，投進(jìn)去的錢那是真金白銀，花錢的人不在身邊，心里總會(huì)有些不大放心。
還有可能就是團(tuán)隊(duì)確實(shí)遇到了問(wèn)題，比如資金方面的問(wèn)題，找一家有實(shí)力的公司進(jìn)行合作，整體并入大公司，成立一個(gè)新的部門，或者獨(dú)立工作室，繼續(xù)原來(lái)的工作。
這種一般會(huì)與公司按比例分紅，但因?yàn)楣驹陂_(kāi)發(fā)期就在支持付工資，也承擔(dān)了風(fēng)險(xiǎn)，所以這個(gè)分紅比例不會(huì)比代理分紅高，但對(duì)于當(dāng)初創(chuàng)業(yè)的核心開(kāi)發(fā)人員來(lái)說(shuō)，也絕對(duì)比在公司打工強(qiáng)。
4。開(kāi)發(fā)團(tuán)隊(duì)整體被收購(gòu)，繼續(xù)回到打工狀態(tài)
這種結(jié)局就已經(jīng)是不大愿意看到的了。
當(dāng)然，收購(gòu)的方式也有多種，如果收購(gòu)后在新公司成立部門，繼續(xù)進(jìn)行原來(lái)項(xiàng)目的開(kāi)發(fā)，那與上一種情況其實(shí)相差不多，但因?yàn)槭鞘召?gòu)，支付了費(fèi)用，或者是以股權(quán)方式收購(gòu)的，所以開(kāi)發(fā)團(tuán)隊(duì)的身份會(huì)有改變，說(shuō)白了，就是現(xiàn)在是純粹的打工仔，不能再談更多的條件。
不是，既然是被收購(gòu)，那還是會(huì)有一點(diǎn)收入，讓初創(chuàng)人員有一定的回報(bào)。
5。創(chuàng)業(yè)失敗，團(tuán)隊(duì)整體加入新公司，在新的公司里再繼續(xù)開(kāi)發(fā)新項(xiàng)目
如果很不幸的，團(tuán)隊(duì)最終因資金問(wèn)題，或者合作問(wèn)題，不得不結(jié)束創(chuàng)業(yè)的過(guò)程。
這時(shí)也還是有可能繼續(xù)博一次，比如找一家有實(shí)力的大公司，以團(tuán)隊(duì)方式加盟，可以帶上以前未完成的項(xiàng)目，或者不帶項(xiàng)目。當(dāng)然，進(jìn)入新公司后做什么項(xiàng)目，這很難再由自己決定了，另外團(tuán)隊(duì)成員是否會(huì)被新公司拆散，這也不由自己控制。
但總之，團(tuán)隊(duì)加盟新公司，比單打獨(dú)斗要好。
這只能算是不得已而為之的最后選擇了吧。
6。團(tuán)隊(duì)失敗，解散。各回各家，各找各媽。各自回到自己的打工狀態(tài)
最壞的情況就是，創(chuàng)業(yè)過(guò)程失敗，最終團(tuán)隊(duì)完全解散，或者還沒(méi)有完全解散的人也找不到合適的去處，這時(shí)只能是各回各家，各找各媽了。
進(jìn)入新一輪的打工狀態(tài)。
每一個(gè)創(chuàng)業(yè)的團(tuán)隊(duì)都是帶著對(duì)未來(lái)美好的憧憬開(kāi)始的，并且在開(kāi)始的時(shí)候也是認(rèn)真在做的，但有人的地方就有江湖，也許合作的過(guò)程并不像想象的那么順暢，也許后來(lái)才發(fā)現(xiàn)投資人并不像之前承諾的那樣大方，也許，大家都錯(cuò)誤的估計(jì)了自己的能力。
但是，每一個(gè)勇敢走出第一步的團(tuán)隊(duì)，每一個(gè)敢于走上創(chuàng)業(yè)這條路的個(gè)人都是英雄。
至少，他們的人生有了這段經(jīng)歷而變得精彩起來(lái)，至少，他們向成功的人生方向又邁出了一步。
這比那些只會(huì)贊嘆某某游戲公司有多賺錢的人要強(qiáng)得多，這比那些只敢臨淵羨魚而不敢退而結(jié)網(wǎng)的人要可敬得多。
或者，走向創(chuàng)業(yè)路上第一步的時(shí)候，可以問(wèn)一問(wèn)自己，兩年或者三年以后，希望自己能是個(gè)什么狀態(tài)。再問(wèn)一問(wèn)自己，如果失敗了，最壞將是個(gè)什么狀態(tài)。然后再回身看一看現(xiàn)在的自己，現(xiàn)在是怎樣一個(gè)狀態(tài)。如果今天換到行業(yè)里最好的公司，有同等條件下最好的待遇，兩年或三年后自己將可以是怎樣的狀態(tài)。
或許，你會(huì)覺(jué)得，還是應(yīng)該走出去試一試。
好游戲的標(biāo)準(zhǔn)很難定義，往往商業(yè)上的成功與品質(zhì)上的優(yōu)秀并不是完全一致的。那就不談好游戲，說(shuō)說(shuō)怎么做成一款游戲吧。
做成的意思是指能夠成功上線運(yùn)營(yíng)，至少，保證能有個(gè)兩萬(wàn)人同時(shí)在線吧，這樣，其實(shí)也就是做成了，一年還能有兩千多萬(wàn)的收入，如果只是個(gè)小團(tuán)隊(duì)開(kāi)發(fā)，那足夠收回成本并讓開(kāi)發(fā)人員獲得基本滿意的回報(bào)了。只是，她可能不算好游戲而已。
游戲，雖不是軟件項(xiàng)目里最復(fù)雜的，但也屬于最復(fù)雜的軟件項(xiàng)目之一吧。倒不是說(shuō)游戲程序?qū)懫饋?lái)有多難，而是游戲項(xiàng)目的需求變更太頻繁，游戲項(xiàng)目涉及到的人員配合太復(fù)雜。
策劃的思路始終在變，朝三暮四是常事，繞個(gè)大圈又回到原點(diǎn)也是會(huì)有的；運(yùn)營(yíng)方隨時(shí)也會(huì)跟進(jìn)，提出一些更有利于運(yùn)營(yíng)推廣的想法要求程序去實(shí)現(xiàn)。
程序、策劃、美術(shù)，完全不搭邊的一群人，思維方式跟工作習(xí)慣存大巨大的差異，卻要在一起，把各自的工作揉合起來(lái)，成為最終的游戲產(chǎn)品。
這一切，說(shuō)起來(lái)似乎并不復(fù)雜，但在執(zhí)行過(guò)程中一旦出現(xiàn)點(diǎn)小差錯(cuò)，一般都是人為的一點(diǎn)小問(wèn)題，后果基本上卻會(huì)是災(zāi)難性的，之前所付出的努力都付之東流。
但是我們又不能說(shuō)這些需求的變更不應(yīng)該有。正是因?yàn)榇蠹叶荚跒檫@項(xiàng)目而努力，都希望做好產(chǎn)品，才會(huì)有這樣的反復(fù)。有句話說(shuō)的好，好游戲是改出來(lái)的。
程序、策劃、美術(shù)的配合更是無(wú)法避免的。以前那種靠一兩個(gè)程序員單挑所有事情的時(shí)代已經(jīng)成為歷史，即使今天某個(gè)人確實(shí)有這能力，原畫畫的超級(jí)棒，3D模型做的一流好，程序還寫的讓人刮目相看，可是，時(shí)間總是有限的。今天一個(gè)優(yōu)秀的創(chuàng)意，如果等個(gè)十來(lái)年才能實(shí)現(xiàn)出來(lái)，那等到出來(lái)的那一天，也只能放進(jìn)博物館了。
而且，以目前的小型MMORPG項(xiàng)目來(lái)看，就算是效率比較高的創(chuàng)業(yè)小團(tuán)隊(duì)，就算是在一些既有代碼的基礎(chǔ)上修改來(lái)完成項(xiàng)目，也至少需要20到30人年的開(kāi)發(fā)時(shí)間。
大概這些描述已經(jīng)給你蒙上了一層悲觀的陰影，事實(shí)上做成一款游戲的風(fēng)險(xiǎn)其實(shí)并沒(méi)有想象的那么大。
每一個(gè)在游戲公司呆過(guò)的人都清楚，游戲開(kāi)發(fā)其實(shí)也就那點(diǎn)事。
策劃的需求雖然總在變動(dòng)，但到了今天，沒(méi)有哪個(gè)程序會(huì)硬編碼策劃們的邏輯需求。腳本的引入完全可以讓策劃們自己去配置、調(diào)試、驗(yàn)證一些想法，如果能做的更進(jìn)一步，提供GUI的工具讓他們更方便的去修改這些東西，那策劃們將會(huì)更少來(lái)麻煩程序。
一個(gè)稱手的工具會(huì)讓美術(shù)人員以最高的效率去制作游戲內(nèi)容。有時(shí)候你會(huì)發(fā)現(xiàn)，程序只需要花上半天時(shí)間為編輯器增加一個(gè)很小的功能，卻能讓美術(shù)減少幾天的工作量。而美術(shù)花上幾分鐘時(shí)間檢查所做的東西是否符合程序制定的規(guī)范，也能讓程序兄弟們少花那兩三天的時(shí)間去調(diào)試到底是什么原因讓程序崩潰。
理想的情況下，程序給美術(shù)和策劃們制作好了工具，游戲的一切內(nèi)容，都與程序再無(wú)關(guān)。程序所要關(guān)注的，是如何讓游戲運(yùn)行的更順暢，如何讓策劃配置的自由度更高，如何讓這些工具更好用，如何最大可能的減輕美術(shù)與策劃的工作量。
再加上這些相互的理解與支持，合作會(huì)變得越來(lái)越順暢，大家會(huì)更愿意為對(duì)方多付出那么一點(diǎn)點(diǎn)時(shí)間。我想，真正做到了這一點(diǎn)，在一些團(tuán)隊(duì)里經(jīng)常會(huì)聽(tīng)到的美術(shù)、策劃與程序們相互之間的抱怨也就沒(méi)有了。
當(dāng)然，這樣的情況有些過(guò)于理想化，也許這些不一定都能做到。
實(shí)際上你可能依然會(huì)在團(tuán)隊(duì)里聽(tīng)到程序?qū)γ佬g(shù)不遵守規(guī)范的抱怨，依然會(huì)聽(tīng)到美術(shù)對(duì)工具不能完全滿足使用需求的指責(zé)，依然會(huì)有策劃過(guò)來(lái)要求程序反復(fù)修改或者實(shí)現(xiàn)某個(gè)功能。
本來(lái)嘛，程序、策劃、美術(shù)工作性質(zhì)的差異，思考問(wèn)題方式的差異，使得他們很難完全一致，這時(shí)，我們需要有一兩個(gè)能夠顧全到大局的人，去化解這些問(wèn)題。這一兩個(gè)人的以身作則，還有他們的感染力，也在帶動(dòng)著團(tuán)隊(duì)的合作向著良性的方向發(fā)展。
很多時(shí)候，箭在弦上，只要有人輕撫一下，緊張局勢(shì)便可破解。很多時(shí)候，只是缺少這樣一兩個(gè)愿意主動(dòng)站出來(lái)的人。每一個(gè)團(tuán)隊(duì)都會(huì)有核心，所謂的核心，并不僅僅在于技術(shù)上的主導(dǎo)性，很多時(shí)候，他需要把他當(dāng)作是團(tuán)隊(duì)的領(lǐng)頭人，主動(dòng)承擔(dān)起這些責(zé)任。
只要找對(duì)了兩個(gè)這樣的人，我相信，小團(tuán)隊(duì)要做到和諧融洽還是比較容易的。
如果順利的話，團(tuán)隊(duì)成員每天都能夠看到自己所做的東西一點(diǎn)一點(diǎn)在成型，一點(diǎn)一點(diǎn)在完善，這對(duì)團(tuán)隊(duì)的士氣將是很大的鼓舞，每個(gè)人都看到未來(lái)將會(huì)是怎樣。
小團(tuán)隊(duì)相比大公司，優(yōu)勢(shì)在于行動(dòng)迅速，但劣勢(shì)在于抗風(fēng)險(xiǎn)能力較弱，更需要注意士氣的維持。所以，一個(gè)始終充滿激情的旗手就顯得很重要了。他不應(yīng)該離大家很遠(yuǎn)，更不能高高在上，他就是集體的一份子，每個(gè)人都能看到的一份子。
中國(guó)的國(guó)情使得車庫(kù)文化不大可能產(chǎn)生，即使是對(duì)于小團(tuán)隊(duì)來(lái)說(shuō)，可是，在我們還在成長(zhǎng)的過(guò)程中，每個(gè)人都應(yīng)該坐在一張桌子上。
我也始終認(rèn)為，開(kāi)發(fā)人員本身是并不復(fù)雜的，不管是程序、策劃還是美術(shù)。尤其是一些真正想做好事情的人，在大家認(rèn)同的合作方式下，有共同的利益訴求，每一個(gè)理性人必將選擇通力合作，首先把項(xiàng)目做成功。
每一個(gè)團(tuán)隊(duì)成員，尤其是核心人員，只要心里面陽(yáng)光一些，再陽(yáng)光一些，沒(méi)有那些所謂的辦公室政治，沒(méi)有那些所謂的圈子圈套。小團(tuán)隊(duì)十來(lái)號(hào)人，只有一個(gè)圈子，就是這個(gè)集體。那么，做事情其實(shí)是應(yīng)該很順暢的。
只要找對(duì)了人，做成一款游戲，其實(shí)并不難。
游戲有多賺錢，看一下上市游戲公司的財(cái)報(bào)就知道了。http://tech.163.com/caibao，這里有國(guó)內(nèi)互聯(lián)網(wǎng)公司財(cái)報(bào)匯總，摘錄09年第四季度幾家公司的游戲業(yè)務(wù)贏利情況，見(jiàn)下表：
| 公司 | 游戲營(yíng)收(萬(wàn)元) | 毛利潤(rùn)(萬(wàn)元) | 毛利率 |
| 盛大 | 133600 | 80200 | 60% |
| 完美 | 54000 | 52600 | 86.60% |
| 暢游 | 48250 | 28800 | 92% |
| 巨人 | 27300 | 23200 | 83.90% |
當(dāng)然，這是占據(jù)了國(guó)內(nèi)游戲行業(yè)收入一大半的幾家大公司，不過(guò)就算是小公司，只要能成功讓產(chǎn)品上線，利潤(rùn)率也是一樣的。
從上市公司的財(cái)報(bào)里可以看到，一般MMORPG的每活躍付費(fèi)用戶平均每月貢獻(xiàn)收入大致在60元左右，有些游戲會(huì)高很多，有些稍低一些。也就是說(shuō)，只要有2萬(wàn)活躍付費(fèi)用戶，以85%的利潤(rùn)率來(lái)計(jì)算，扣除運(yùn)營(yíng)成本后的月利潤(rùn)就能達(dá)到100萬(wàn)。
不過(guò)，目前游戲的類型基本上都是道具收費(fèi)，這樣不是每個(gè)玩游戲的人都會(huì)掏錢。按照暢游財(cái)報(bào)中披露的信息，非付費(fèi)用戶向付費(fèi)用戶的轉(zhuǎn)化比例為18%，其他游戲的這個(gè)比例應(yīng)該也不會(huì)相差太多，2 * 18%，月收入100萬(wàn)就需要有11萬(wàn)的活躍用戶。
活躍用戶的統(tǒng)計(jì)方法一般是如果該賬號(hào)在一天內(nèi)累計(jì)在線時(shí)間超過(guò)2小時(shí)，剛該玩家的活躍天數(shù)就加1，如果在線時(shí)間在半小時(shí)到2小時(shí)之間，則活躍天數(shù)加0.5，在線時(shí)間小于半小時(shí)的不算活躍天數(shù)。當(dāng)然，這是每日活躍用戶數(shù)的統(tǒng)計(jì)方法。
我們以2小時(shí)為單位，只要在每個(gè)時(shí)間單位內(nèi)有11 / 12萬(wàn)用戶在線，則就達(dá)到了10萬(wàn)活躍用戶。也就是說(shuō)，平均在線只要不到一萬(wàn)人就達(dá)到了月入100萬(wàn)的目標(biāo)。
這個(gè)數(shù)字基本上是可信的。可以再看一看完美的財(cái)報(bào)，完美Q4財(cái)報(bào)顯示，平均同時(shí)在線（ACU）為115.7萬(wàn)人，網(wǎng)游收入為5.4億元，平均每月為1.8億，這樣每1萬(wàn)平均在線貢獻(xiàn)的收入為 18000 / 115.7 = 155萬(wàn)，這個(gè)數(shù)字比前面計(jì)算的不到一萬(wàn)同時(shí)在線貢獻(xiàn)收入100萬(wàn)還要高，這是因?yàn)橥昝赖腁RPU值比暢游高，為每月74元。
所以，每當(dāng)跟別人介紹我是做游戲時(shí)，別人都會(huì)感嘆一下，游戲啊，挺賺錢的，我也笑笑，確實(shí)是挺賺錢的。可是，如此賺錢的產(chǎn)品，開(kāi)發(fā)人員的回報(bào)又有多少呢？
再來(lái)看一下上市公司的財(cái)報(bào)。依然是暢游的，“非美國(guó)通用會(huì)計(jì)準(zhǔn)則產(chǎn)品開(kāi)發(fā)費(fèi)用為510萬(wàn)美元，環(huán)比增長(zhǎng)5%，同比減少12%。環(huán)比增長(zhǎng)主要是由于聘用了更多的游戲研發(fā)人員而導(dǎo)致員工薪酬與福利費(fèi)用的增加。同比減少主要是由于公司管理層獎(jiǎng)金方案的調(diào)整——之前授予的股權(quán)激勵(lì)在IPO后價(jià)值提高，因而公司減少其現(xiàn)金獎(jiǎng)勵(lì)。”
從這句話上可以看出來(lái)，這個(gè)研發(fā)費(fèi)用不僅僅只是開(kāi)發(fā)人員的工資，還包括了由于員工的相關(guān)福利，也包含了為員工所繳納的保險(xiǎn)，公積金等費(fèi)用。另外也還包括了獎(jiǎng)金，以及股權(quán)獎(jiǎng)勵(lì)等等。就這520萬(wàn)，也只占到了營(yíng)收的7%。
在公司管理層解讀財(cái)報(bào)的時(shí)候有另外一句話，“截止到2009年12月31日，共有520位工程師。地面推廣團(tuán)隊(duì)中正式員工有50人，另外還有臨時(shí)雇員大約還有600人。”不知道這510萬(wàn)的研發(fā)費(fèi)用是否包括了上面提到的地面推廣人員和臨時(shí)雇員，暫時(shí)認(rèn)為其不包含吧，假定這些錢都花在了520位開(kāi)發(fā)人員身上。
另外也不知道這510萬(wàn)是否包含研發(fā)相差的辦公室租金等費(fèi)用，這個(gè)估計(jì)應(yīng)該包含吧。
公司為員工繳納的保險(xiǎn)，公積金跟我們交的一樣，會(huì)占工資的20%多，辦公開(kāi)支不大好算，另外福利也不好說(shuō)，比如聚餐，組織出去玩等，這些不好統(tǒng)計(jì)，還不排除有一些無(wú)法統(tǒng)計(jì)到的灰色內(nèi)容。簡(jiǎn)單一點(diǎn)，就算這510萬(wàn)有50%最后以money的形式發(fā)到了開(kāi)發(fā)人員手上吧，包括每月固定工資與獎(jiǎng)金。這樣，平均每人每月是1600美元。
因?yàn)榇蟛糠止镜莫?jiǎng)金都是以多發(fā)一個(gè)或者幾個(gè)月的工資形式來(lái)發(fā)放的，據(jù)說(shuō)暢游每年相當(dāng)于能發(fā)16個(gè)月工資，1600 * 12 / 16 = 1200美元。平均8000元的月薪，可能大部分人會(huì)感覺(jué)到自己并沒(méi)有這么多。當(dāng)然，因?yàn)橛幸恍〔糠秩擞泄蓹?quán)的獎(jiǎng)勵(lì)，他們的收入遠(yuǎn)超過(guò)了8000 * 16，所謂20%的精英獲得了80%的利益 :) 其實(shí)也是差不多的。
如此高利潤(rùn)率的游戲產(chǎn)品，到頭來(lái)生產(chǎn)者們的回報(bào)卻也還是一樣。所以，再聽(tīng)到人說(shuō)游戲很賺錢時(shí)，有必要好好對(duì)其解釋一番 :) 游戲確實(shí)是賺錢，可錢并不在我們這些人的口袋里。
再來(lái)看近期網(wǎng)易的大話二團(tuán)隊(duì)集體離職，大明龍權(quán)開(kāi)發(fā)團(tuán)隊(duì)集體跳槽完美，還有華義成都差不多整個(gè)公司跳到騰訊，金山的團(tuán)隊(duì)到網(wǎng)易去開(kāi)發(fā)大唐，盛大的英雄年代團(tuán)隊(duì)出走征途等等，這不能說(shuō)是員工不夠忠誠(chéng)，實(shí)在是利益分配的不合理。新的老板只要肯多拿出一個(gè)甚至半個(gè)百分點(diǎn)，分到開(kāi)發(fā)人員的手中就是沉甸甸的誘惑了。
而且還有另外一條很重要的因素，游戲的成功與否很大程度上來(lái)自于那幾個(gè)開(kāi)發(fā)人員。縱觀國(guó)內(nèi)游戲廠商，基本上都是只靠著開(kāi)發(fā)團(tuán)隊(duì)做的一款游戲就撐起了整個(gè)公司，讓公司擠進(jìn)二線、一線游戲廠商行列，甚至靠著這一款游戲去賺美國(guó)股民的錢。當(dāng)然這種成功也有很大的偶然性。
就像一個(gè)正在創(chuàng)業(yè)路上的朋友所說(shuō)，游戲是能讓你迅速?gòu)臈畎讋谧兂牲S世仁的最好選擇。當(dāng)前，前提是你不是在為別人打工。
Ogre正在開(kāi)發(fā)中的版本，1.7版，引入了新的Terrain Component與Paging Component，Ogre終于開(kāi)始對(duì)地形渲染進(jìn)行官方的支持了。Ogre官方論壇上sinbad也提到了這個(gè)新的Terrain Component的特性及目前的進(jìn)展，不過(guò)他自己也說(shuō)，雖然他很希望1.7版能在今年發(fā)布，但是結(jié)果卻也很難預(yù)測(cè) :(
曾幾何時(shí)，在Ogre中尋求更加完善的地形渲染支持是多少人都在做的事，Ogre源代碼庫(kù)中的Terrain Scene Mananger只能實(shí)現(xiàn)最基本的高度圖渲染功能，搭配一張普通texture和一張detail texture，根本無(wú)法實(shí)現(xiàn)出我們想要的真實(shí)地形效果。于是，Addon論壇上不少人也開(kāi)始了為Ogre擴(kuò)展地形渲染支持的工作，比較有名的是PLSM，這部分代碼經(jīng)過(guò)不少的修改，之后也被納入了Ogre的Octree Scene Manager代碼庫(kù)，不過(guò)其依然還是相當(dāng)?shù)暮?jiǎn)陋。另外還有一個(gè)就是Myrddin，這里是論壇上的介紹頁(yè)面，在1.7版出來(lái)之前，這應(yīng)該是最好的地形渲染選擇了。
所以，之前使用Ogre的游戲要么自己來(lái)寫地形渲染這一塊，要么干脆就不要地形，一切皆mesh，比如最近挺火的火炬之光(Torchlight)。
其實(shí)，一切皆Mesh也并不是不可以，相反，用Mesh能夠表現(xiàn)出更加細(xì)膩真實(shí)的效果，比如場(chǎng)景本來(lái)就是由大師的地下城或者陡峭的山脈構(gòu)成時(shí)。就像前幾年玩過(guò)的“地牢圍攻2”。當(dāng)然，全Mesh場(chǎng)景的問(wèn)題也是很明顯的，其需要渲染的面數(shù)太多，所以，這樣的游戲也只好采用固定的斜視角，并且打上很近的霧來(lái)減少需要渲染的對(duì)象數(shù)，就如同前面提到過(guò)的兩個(gè)例子，“地牢圍攻”和“火炬之光”那樣。
從OgreSVN上checkout出來(lái)代碼，簡(jiǎn)單看了下相關(guān)的代碼注釋，其特性還是挺讓人期待的。
首先，地形資源有了自己的文件格式，不再是以前的terrain.cfg和terrain.png或terrain.raw了，
另外，terrain和paging以Component的形式實(shí)現(xiàn)，不再依賴于Scene Manager的實(shí)現(xiàn)。
然后，貼圖的混合也已基本實(shí)現(xiàn)。目前地形渲染的一個(gè)pass最多支持6層貼圖，地形渲染常用的normal map, light map, colour map，specular map都已經(jīng)支持，從其提供的幾張?jiān)囼?yàn)用的截圖來(lái)看，多層混合、法線以及高光實(shí)現(xiàn)的都已經(jīng)沒(méi)有問(wèn)題了。
另外還有一個(gè)額外的特性是支持運(yùn)行時(shí)對(duì)地形的修改，并能在后臺(tái)線程中對(duì)地形數(shù)據(jù)進(jìn)行加載和保存。
雖然這個(gè)特性在目前的游戲中都不需要，因?yàn)榈匦尉庉嬕话闶窃趫?chǎng)景制作的時(shí)候完成，也就是由美術(shù)人員在制作地圖時(shí)就已確定好了，在游戲中只需要將地圖文件讀出來(lái)并渲染到屏幕，游戲進(jìn)行過(guò)程中也不允許對(duì)地形數(shù)據(jù)進(jìn)行任何破壞和修改。
其實(shí)，從技術(shù)上來(lái)說(shuō)，這并不是絕對(duì)的限制，地形及場(chǎng)景完全是可以破壞的，可以重建的，比如，可以讓一顆炸彈落過(guò)的地方永久的留下一個(gè)彈坑，讓火燒過(guò)的地方只留下一片殘骸，樹木及雜草都被燒毀，另外，城鎮(zhèn)與村落也不需要是美術(shù)預(yù)先編輯好的，玩家完全可以在一塊空曠的地方建起一座城來(lái)，當(dāng)然也可以把別人的一座城燒毀掉，等等。
只是，當(dāng)?shù)匦渭皥?chǎng)景改變后服務(wù)器需要同步大量的數(shù)據(jù)給客戶端，并且，如何保證這些數(shù)據(jù)的完整性和一致性。這最主要的還是受限于網(wǎng)速的原因，如果網(wǎng)絡(luò)速度足夠快，我們完全可以把游戲做成瘦客戶端，甚至無(wú)客戶端，就像現(xiàn)在的flash web game一樣，客戶端總是去服務(wù)器上取最新的場(chǎng)景數(shù)據(jù)，這樣就不再有問(wèn)題了。
但是，另外一個(gè)問(wèn)題可能會(huì)稍麻煩一些。當(dāng)?shù)匦魏蛨?chǎng)景改變后，服務(wù)器端的AI相關(guān)數(shù)據(jù)會(huì)受到很大的影響，比如尋路數(shù)據(jù)，不論是用nav mesh還是用waypoint，這些數(shù)據(jù)都要重新構(gòu)造，而這個(gè)構(gòu)造過(guò)程一般來(lái)說(shuō)將會(huì)是漫長(zhǎng)的，但是地形的重建卻可能會(huì)是相當(dāng)頻繁的。。。還有AI對(duì)象的出生數(shù)據(jù)，等等，這都需要我們花一些精力去思考。
當(dāng)然，一切能夠想得到的問(wèn)題都不會(huì)是大問(wèn)題，總會(huì)有方法去解決它們。今天覺(jué)得不可能做到的事，隨著明天硬件環(huán)境的提升，新的算法的實(shí)現(xiàn)，這也將成為我們?cè)谟螒蛑心軌蛴H眼看到的事實(shí)。
最近在我的關(guān)注領(lǐng)域內(nèi)的消息還真不少
1。Unity2.6發(fā)布，并且將indie版免費(fèi)。(當(dāng)然，之前也有30天的試用版)Unity的制作人說(shuō)過(guò)一句話：如果做web，2D就用flash，3D就用Unity。雖然這是一句宣傳詞，不過(guò)，Unity也確實(shí)挺不錯(cuò)。
2。Android 2.0 SDK發(fā)布，可惡的GFW，好在Android Setup Tools非常體諒我們這些墻里的人，升級(jí)工具里有個(gè)選項(xiàng)叫https，當(dāng)然，這是通過(guò)犧牲速度來(lái)?yè)Q取的。真不明白GFW封堵sourceforge, developer.android這樣的開(kāi)發(fā)者網(wǎng)站是何用意，怕國(guó)外的先進(jìn)技術(shù)毒害了我們這群求知的人們？
另外，摩托的支持Android 2.0的新手機(jī)也即將發(fā)布，售價(jià)是誘人的199刀，不知道國(guó)內(nèi)有沒(méi)有渠道能夠買到。當(dāng)然，這199刀不會(huì)是跟之前的iPhone售價(jià)一樣吧。
3。一款叫做Torchlight的游戲發(fā)布，其制作人以前在北方暴雪呆過(guò)，所以，這游戲怎么玩怎么像是暗黑卡通版。另外，據(jù)說(shuō)其網(wǎng)絡(luò)版在一年半后發(fā)布，國(guó)內(nèi)由完美時(shí)空代理。不過(guò)，我更加關(guān)注的是它使用Ogre渲染引擎。
4。Qt4.6正式發(fā)布，新特性確實(shí)添加的很快，想拿它來(lái)做工具試試。
這篇文章所使用的方法來(lái)源于 CuteQt博客 上的一篇文章：http://www.cuteqt.com/blog/?p=868
生成對(duì)象內(nèi)存布局所使用的方法來(lái)自于vc8編譯器一個(gè)未公開(kāi)的參數(shù)，即 /d1 reportSingleClassLayoutXXX或者 /d1 reportAllClassLayout，MSDN上關(guān)于這個(gè)的簡(jiǎn)單說(shuō)明及示例可以見(jiàn)這里：http://blogs.msdn.com/vcblog/archive/2007/05/17/diagnosing-hidden-odr-violations-in-visual-c-and-fixing-lnk2022.aspx
一般來(lái)說(shuō)用reportSingleClassLayout，因?yàn)閞eportAllClassLayout會(huì)生成許多中間類的結(jié)果，干擾我們的分析。
按照上面博客中介紹的方法，一步步來(lái)跟蹤各種虛函數(shù)使用情況下的對(duì)象內(nèi)存布局，可以很直觀的看到虛函數(shù)是怎樣分布的，各種繼承情況下虛函數(shù)是又是怎樣生成的，等等。
一點(diǎn)簡(jiǎn)單的總結(jié)：
1。以前常說(shuō)的，因?yàn)樘摵瘮?shù)的使用，使得類多了一個(gè)vtable指針，大小增加了4字節(jié)，其實(shí)是不完全正確的。因?yàn)橐粋€(gè)class內(nèi)可能會(huì)有多個(gè)虛表的存在，比如當(dāng)有多個(gè)帶虛函數(shù)的父類時(shí)。
2。多個(gè)虛函數(shù)在虛表里的順序由其定義順序決定。如果是從多個(gè)父類派生來(lái)的，則這多個(gè)虛表的順序由父類的申明順序而定。
3。多繼承情況下的同名虛函數(shù)處理使用了一種叫做thunk的技術(shù)，這樣通過(guò)不同的基類調(diào)用同名的虛函數(shù)時(shí)，都會(huì)調(diào)用到相同的函數(shù)體內(nèi)。
4。虛基類的實(shí)現(xiàn)多了一個(gè)vbi表，記錄的是虛基類中的虛函數(shù)表地址信息。同時(shí)在派生類中計(jì)算好了到這個(gè)vbi表的偏移，這樣虛基類里的虛函數(shù)在菱形繼承關(guān)系的派生類中就只有了一份實(shí)現(xiàn)。
5。使用的時(shí)候其實(shí)不必要意這些細(xì)節(jié)問(wèn)題，編譯器在生成函數(shù)調(diào)用代碼時(shí)已經(jīng)幫我們處理好了，即這個(gè)函數(shù)在哪個(gè)虛表中，是第幾個(gè)虛函數(shù)，最終也就是要做多少個(gè)字節(jié)的偏移。
不得不承認(rèn)，QT在Nokia的懷抱中越活越滋潤(rùn)，如長(zhǎng)成的少女一般越來(lái)越漂亮。
程序速度越來(lái)越快，Nokia QT推出的第一個(gè)版本運(yùn)行速度比原來(lái)快了近一半，而即將推出的4.6版還將把圖形渲染底層重寫，以進(jìn)一步提升運(yùn)行速度。
平臺(tái)支持范圍也越來(lái)越廣：S60手機(jī)平臺(tái)的支持，當(dāng)然，這是Nokia收購(gòu)QT的最主要目標(biāo)吧，最新的Windows7和Max OS X以及更多的Unix平臺(tái)的支持，讓QT無(wú)孔不入。
完全獨(dú)立的IDE：QT Creator，雖然說(shuō)用慣了VS IDE之后在剛接觸這個(gè)Creator時(shí)有很多的不習(xí)慣，但QT要做到更大可能的跨平臺(tái)支持，有一個(gè)統(tǒng)一的IDE和編譯環(huán)境也是必要的，另外，Nokia也提供了Addons以以VS或者Eclipse IDE集成。并且，在新的1.3版Creator上還將使用一個(gè)叫做jom的程序來(lái)代替VS默認(rèn)使用的nmake程序，最終應(yīng)該將會(huì)完全擺脫VS吧。
使用硬件加速的OpenVG實(shí)現(xiàn)以達(dá)到高速的矢量圖形繪制，Nokia打算無(wú)視Flash的存在？當(dāng)然，這與“實(shí)現(xiàn)自己的Creator”，“使用自己的jom代替nmake”一樣，所有的技術(shù)都要自己來(lái)DIY。或許，只有把所有的技術(shù)都掌握在自己手上才是最可靠的。
對(duì)觸控系統(tǒng)的支持是未來(lái)所有操作系統(tǒng)都必須要具備的，包括Windows7，包括iPhone，包括Android，QT4.6在這一塊上也不甘落后。
QT的野心從其博客上的一篇文章似乎能夠看出點(diǎn)端倪。做游戲，這個(gè)跟QT以前所專注的GUI開(kāi)發(fā)八桿子也打不著的領(lǐng)域也要囊括進(jìn)來(lái)，那還有什么東西的出現(xiàn)是你所不敢想象的呢？
也許，這就是未來(lái)的軟件開(kāi)發(fā)大平臺(tái)。
或者，正如QT的一個(gè)博客站名一樣：QT Everywhere!
DXSAS : DirectX Standard Annotations and Semantics，DirectX引入的一項(xiàng)在Shader代碼與應(yīng)用程序之間進(jìn)行數(shù)據(jù)綁定的規(guī)范，當(dāng)出到0.8時(shí)被廣泛用于各種應(yīng)用程序中，后來(lái)從MS的產(chǎn)品線中神秘消失，有關(guān)DXSAS的規(guī)范文檔被從MSDN中移除，只留下幾頁(yè)引用說(shuō)明。。。
簡(jiǎn)單來(lái)說(shuō)，當(dāng)我們?cè)贒X中使用Shader的時(shí)候，我們會(huì)使用一個(gè)常量表來(lái)設(shè)置各種參數(shù)值，其中最重要的當(dāng)屬世界變換矩陣了。這在用DX寫游戲程序時(shí)沒(méi)有問(wèn)題，但是在其他一些Shader編輯工具中問(wèn)題就出來(lái)了，如何設(shè)置這些變量？當(dāng)然，每種工具可以提供自己的方法，比如現(xiàn)在Max，Maya都提供了自己的方法在Shader中綁定世界變換矩陣，但問(wèn)題是每種工具提供的方法都不一樣，這樣寫出來(lái)的Shader文件就麻煩了。。。
于是，MS這時(shí)站出來(lái)，提出了一個(gè)標(biāo)準(zhǔn)：DXSAS。這是目前還能找到的DXSAS的一段描述：
Standard annotations and semantics (DXSAS) provide a method of using shaders in a standard way that enables shaders to be used with tools, applications, and game engines. DXSAS defines a set of semantics and annotations that are attached to host application values and effect parameters for the purpose of sharing effects.
地址：http://msdn.microsoft.com/en-us/library/bb173004(VS.85).aspx
有標(biāo)準(zhǔn)是好事，而且我們也能看到，大量的Shader工具及游戲引擎也使用到了SAS，比如FXComposer，比如RenderMonkey，比如CryEngine。。。當(dāng)然，各工具可能對(duì)SAS都會(huì)有自己的擴(kuò)展，但大部分還都是按照標(biāo)準(zhǔn)來(lái)的。
可是，為什么MS突然就將這標(biāo)準(zhǔn)移除了。。。而且，沒(méi)有任何理由的。。。以至于FXComposer1.8版本以前的文檔中附帶的SAS描述章節(jié)也跟著一并刪除，我在FXComposer2.5上找遍了整個(gè)手冊(cè)也沒(méi)找到這個(gè) WorldViewProjection 從哪里來(lái)，翻遍了MSDN上HLSL有關(guān)的內(nèi)容也沒(méi)有看到這幾個(gè)關(guān)鍵字。無(wú)奈Google之，原來(lái)受此困惑的人還真不少。
好在，Nvidia推出了一份新的文檔，描述SAS的使用方法，或許Nvidia也很困惑，“which came from DirectX 9, and are sometimes hard to find”。。。但是新的FXComposer手冊(cè)中對(duì)這些只字未提卻是我仍然很困惑的，對(duì)于像我這樣的一個(gè)新手來(lái)說(shuō)，完全不可能知道這些東西是如何來(lái)的，如何去找這些Semantics的定義。
Nvidia網(wǎng)站上的SAS說(shuō)明文檔：http://developer.nvidia.com/object/using_sas.html
以及FXComposor官方論壇上置頂?shù)年P(guān)于SAS文檔的說(shuō)明貼，當(dāng)時(shí)我竟然沒(méi)看到這個(gè)置頂貼 :( http://developer.nvidia.com/forums/index.php?showtopic=1358
其他人提出的一些相關(guān)疑問(wèn)：
http://developer.nvidia.com/forums/index.php?showtopic=750
http://developer.nvidia.com/forums/index.php?showtopic=31
http://developer.nvidia.com/forums/index.php?showtopic=1061
http://developer.nvidia.com/forums/index.php?showtopic=1347
http://developer.nvidia.com/forums/index.php?showtopic=1394
留下這些記錄，也許有跟我一樣的初哥們，少點(diǎn)困惑 :)
看到CppBlog上翻譯的一篇游戲主循環(huán)，想起之前也看到過(guò)一篇類似的文章，因?yàn)楣P記本上第一篇記錄就是這個(gè)主循環(huán)的簡(jiǎn)短翻譯，對(duì)比了一下，發(fā)現(xiàn)這篇文章對(duì)實(shí)現(xiàn)細(xì)節(jié)的描述更多一些，也發(fā)上來(lái)與大家共享。
這篇文章最早是出現(xiàn)在flipcode的論壇上，地址在這里，后來(lái)有人整理了一下，并添加了更多的描述，也就是下面的內(nèi)容。原貼地址在這里。
文章中關(guān)于網(wǎng)絡(luò)的描述是指局域網(wǎng)環(huán)境下的情況，另外這個(gè)主循環(huán)也沒(méi)有考慮到windows環(huán)境下與Windows Message Loop的結(jié)合，如果是應(yīng)用在windows環(huán)境下，可以再參考下這里，把兩者結(jié)合基本上就差不多了。
翻譯并未嚴(yán)格遵照原文，為了讀起來(lái)流暢，很多句子都是按照我個(gè)人的理解來(lái)描述。
This article is about a way of structuring a game's main loop. It includes techniques for handling view drawing with interpolation for smooth animation matched to the frame-rate with fixed-step game logic updating for deterministic game logic. A lot of this is still pretty much a work-in-progress as I muddle my way through, learning better ways of doing things or new tricks to add to my bag, so please bear with me.
這篇文章描述的是如何組織游戲主循環(huán)的一種方法。內(nèi)容包括了如何處理平滑的動(dòng)畫繪制，并且能夠根據(jù)當(dāng)前幀率做正確的動(dòng)畫插值，另外還要保證固定的游戲邏輯更新幀率，以確保游戲邏輯的計(jì)算結(jié)果是確定的。
這些內(nèi)容的實(shí)現(xiàn)有很多都還在進(jìn)行中，我也在不斷地學(xué)習(xí)更好的方法，以及將一些新的技巧添加進(jìn)來(lái)，所以，希望能夠給我一些耐心與寬容。
The heart of a game, any game, is the game loop. This is where the action takes place, where the guns fire and the fireball spells fly. In some games, the concept of the game loop may be diffused among different components or game states, which implement their own version of the game loop to be exectued at the proper time, but the idea is still there.
任何游戲的核心都是游戲主循環(huán)。游戲的動(dòng)作執(zhí)行、子彈的射擊以及火球魔法的飛行等等都是在這里實(shí)現(xiàn)。
在一些游戲中，你可能會(huì)找不到一個(gè)唯一的游戲主循環(huán)，取而代之的是，你會(huì)在一些組件及狀態(tài)機(jī)中找到各個(gè)不同版本的主循環(huán)。
其實(shí)這個(gè)原理也是一樣的，只不過(guò)是把原來(lái)的一個(gè)主循環(huán)拆分成了多個(gè)，這樣可以控制游戲在不同的時(shí)間及狀態(tài)下執(zhí)行不同的循環(huán)過(guò)程。
The game loop is just that: a loop. It is a repeating sequence of steps or actions which are executed in a timely and (hopefully) efficient manner, parceling out CPU time to all of the myriad tasks the game engine is required to perform: logic, physics, animation, rendering, handling of input. It must be constructed in a deterministic, predictable fashion so as to give expected behavior on a wide array of hardware configurations. Classic failures in this regard include old pre-Pentium DOS-based games that were synchronized to run well on old hardware, but which did not have the controls in place to control the speed on newer hardware, and consequently ran so rapidly that they became unplayable on new hardware. With such a broad diversity of hardware as now exists, there must be tighter controls on the game loop to keep it running at a consistent speed, while still taking advantage of more powerful hardware to render smoother animation at higher framerates.
簡(jiǎn)單來(lái)說(shuō)，游戲主循環(huán)就是一個(gè)循環(huán)過(guò)程。
在這個(gè)不斷重復(fù)執(zhí)行的過(guò)程中，我們需要把CPU時(shí)間按照一定的規(guī)則分配到不同的任務(wù)上，這些任務(wù)包括：邏輯、物理、動(dòng)畫、渲染、輸入處理等等。
游戲的主循環(huán)必須保證是以一種確定的、可預(yù)測(cè)的方式來(lái)執(zhí)行，這樣才能在大量的不同硬件配置環(huán)境下都得到我們所期望的相同行為。
以前的DOS游戲曾經(jīng)出現(xiàn)過(guò)這樣的問(wèn)題，它們?cè)谂f的硬件上運(yùn)行的很好，但是放到新的硬件上以后就失去控制了，游戲的運(yùn)行速度變的如此之快，以至于根本無(wú)法去玩它。
現(xiàn)在市場(chǎng)上存在這么多的硬件種類，所以就必須要緊緊地控制住游戲的主循環(huán)，保證他們以一個(gè)固定的速度運(yùn)行，但同時(shí)又能獲得這些強(qiáng)大的硬件所帶來(lái)的好處：以盡可能高的幀率來(lái)渲染出更平滑的動(dòng)畫。
Older games frequently tied the rendering of the view very closely to the game loop, drawing the view exactly once per logic update and waiting for a signal from the display system indicating a vertical retrace period, when the electron gun in the CRT monitor was resetting after drawing the screen. This synchronized loops to a predictable rate based on the refresh rate of the monitor, but with the advent of customizable refresh settings this leads again to unpredictable loop behavior. Retrace synchronization is still useful, especially to avoid visual artifacts when rendering the view, but is less useful as a means for synchronizing the game logic updating, which may require finer control.
以前的游戲經(jīng)常將渲染過(guò)程與游戲循環(huán)緊密地綁在一起，首先執(zhí)行一次邏輯更新，然后繪制畫面，接著等待顯示系統(tǒng)觸發(fā)一個(gè)垂直同步信號(hào)，之后就是下一輪循環(huán)周期：邏輯更新、渲染、等待……周而復(fù)始。
這種同步的循環(huán)方法在顯示器的刷新率可預(yù)測(cè)的情況下是有效的，但是當(dāng)可以自定義刷新率以后，這種行為又變得不可預(yù)測(cè)了。
垂直同步仍然是有用的，尤其是在避免畫面的渲染出現(xiàn)撕裂的情況下，但是用來(lái)同步游戲的邏輯更新就沒(méi)多大用了，這時(shí)可能需要更好的控制方法。
The trick, then, is to separate game logic from rendering, and perform them in two separate sub-systems only marginally tied to each other. The game logic updates at it's own pace, and the rendering code draws the screen as fast as it possibly with the most accurate, up-to-date data the logic component can provide.
這種方法就是將游戲邏輯更新與屏幕渲染過(guò)程分離開(kāi)，將他們放到兩個(gè)分離的子系統(tǒng)中去處理，只是在需要的時(shí)候才與另一個(gè)打交道。
游戲的邏輯更新嚴(yán)格按照計(jì)劃來(lái)執(zhí)行，但是屏幕渲染則以它所能達(dá)到的最大速率來(lái)進(jìn)行。
The system I am accustomed to using is based on a Tip of the Day ( http://www.flipcode.com/cgi-bin/msg.cgi?showThread=Tip-MainLoopTimeSteps&forum=totd&id=-1 ) posted to http://www.flipcode.com by Javier Arevalo. It implements a loop wherein the game logic is set to update a fixed number of times per second, while the rendering code is allowed to draw as rapidly as possible, using interpolation to smooth the transition from one visual frame to the next.
這里描述的方法基于Javier Arevalo發(fā)表在flipcode Tip of the Day 上的代碼來(lái)實(shí)現(xiàn)。
在這個(gè)游戲主循環(huán)里，游戲邏輯更新被設(shè)置為每秒執(zhí)行固定次數(shù)，但同時(shí)渲染代碼被允許執(zhí)行盡可能多次，并且還使用了插值來(lái)使得兩個(gè)渲染幀之間的動(dòng)畫變化盡可能的平滑。
Briefly, here is the code. I will then attempt in my own crude fashion to explain the workings, though I suggest you check out the original tip at the above link to read Javier's explanation, as well as the forum posts accompanying it which offer up insights and suggestions on how the performance of the loop may be improved.
閑話少說(shuō)，下面首先是代碼，然后我會(huì)簡(jiǎn)單的按我的方式描述一下代碼的工作原理，同時(shí)我建議你閱讀一下上面鏈接地址所給出的內(nèi)容，其中有Javier的解釋，并且論壇上的回貼也有一些不錯(cuò)的內(nèi)容，包括別人的評(píng)論和一些關(guān)于如何提高效率的建議。
(注：flipcode論壇早就已經(jīng)關(guān)閉，上面的鏈接地址已經(jīng)失效，flipcode上只保留有一些優(yōu)秀內(nèi)容的archives，在這里能找到這篇原文，其中包括Javier的解釋)
time0 = getTickCount();
do
{
time1 = getTickCount();
frameTime = 0;
int numLoops = 0;
while ((time1 - time0) > TICK_TIME && numLoops < MAX_LOOPS)
{
GameTickRun();
time0 += TICK_TIME;
frameTime += TICK_TIME;
numLoops++;
}
IndependentTickRun(frameTime);
// If playing solo and game logic takes way too long, discard pending time.
if (!bNetworkGame && (time1 - time0) > TICK_TIME)
time0 = time1 - TICK_TIME;
if (canRender)
{
// Account for numLoops overflow causing percent > 1.
float percentWithinTick = Min(1.f, float(time1 - time0)/TICK_TIME);
GameDrawWithInterpolation(percentWithinTick);
}
}
while (!bGameDone);
Structurally, the loop is very simple. The above snippet of code can encapsulate the entire workings of your game.
從結(jié)構(gòu)上來(lái)說(shuō)，這個(gè)主循環(huán)非常簡(jiǎn)單。上面的代碼片段基本上能夠囊括你的游戲的整個(gè)工作過(guò)程。
First of all, the main loop portion is embodied as the do{} while(!bGameDone); block. This causes the loop to run endlessly, until some game condition indicates that it is finished and it is time to exit the program, at which point the loop ends and the game can be properly shut down. Each time through the loop, we perform game logic updates, input updating and handling, and rendering. Now, for a breakdown of the sections of the loop.
首先，主循環(huán)的執(zhí)行過(guò)程被包在do…while循環(huán)塊中，這使得游戲主循環(huán)將永不結(jié)束地運(yùn)行，直到游戲明確地被告知需要結(jié)束并且退出程序時(shí)為止。
在每次進(jìn)入循環(huán)的時(shí)候，我們會(huì)執(zhí)行游戲邏輯的更新，輸入更新與處理，還有渲染。接下來(lái)，把循環(huán)分為幾個(gè)片段來(lái)描述。
time1 = getTickCount();
frameTime = 0;
int numLoops = 0;
while ((time1 - time0) > TICK_TIME && numLoops < MAX_LOOPS)
{
GameTickRun();
time0 += TICK_TIME;
frameTime += TICK_TIME;
numLoops++;
}
This portion is the game logic update sequence that forces the game logic (physics updates, object motion, animation cycling, etc...) to update a set number of times per second. This rate is controlled by the TICK_TIME constant, which specifies the number of milliseconds the logic update is supposed to represent in real time. It probably won't take that long to perform, in which case the update won't be performed again until enough time has passed. For example, with TICK_TIME=40, each logic represents 40 milliseconds, thus forcing the code to update game objects at a rate of 25 times per second.
這部分代碼處理游戲邏輯的更新，并且強(qiáng)制要求游戲邏輯每秒執(zhí)行固定次數(shù)。
游戲的邏輯處理包括物理更新、對(duì)象行為、動(dòng)畫循環(huán)等等。更新速率通過(guò)TICK_TIME常量指定，其含義為兩次邏輯更新的時(shí)間間隔，即經(jīng)過(guò)TICK_TIME后應(yīng)該再次進(jìn)行更新，而不是說(shuō)一次邏輯更新要持續(xù)這么長(zhǎng)時(shí)間。
例如，TICK_TIME = 40，其含義為每次游戲邏輯更新后表現(xiàn)40毫秒，這將使得每秒游戲?qū)ο髸?huì)被更新25次。
The logic is encapsulated in it's own while loop. It is possible during a given frame that game logic will take too long. If a logic update cycle goes overtime, we can delay rendering for a bit to give ourselves a little extra time to catch up. The while loop will continue to process game logic updates until we are no longer overtime, at which point we can go ahead and continue on with drawing the view. This is good for handling the occasional burp in logic updating, smoothing out the updates and keeping them consistent and deterministic; but in the case that the logic repeatedly goes overtime, it is possible to accumulate more time-debt than the loop can handle. Thus, the MAX_LOOPS constant is in place to dictate a maximum number of times the loop can repeat to try to catch up. It will force the loop to dump out periodically to handle other tasks such as input handling and rendering. A loop that is constantly running at the MAX_LOOPS limit runs like hell and is about as responsive as a tractor with four flat tires, but at least it keeps the loop operating, allowing the user to pass input to terminate the program. Without the MAX_LOOPS failsafe, it would be entirely possible for a slow computer to lock up with no way to exit as it chokes on the loop, trying to catch up but getting further and further behind.
邏輯更新的代碼被包在他自己的while循環(huán)中。
可能在某一幀里游戲邏輯的處理時(shí)間會(huì)非常長(zhǎng)，甚至?xí)瑫r(shí)，這時(shí)我們可以稍稍暫停一下屏幕的渲染，使得游戲邏輯更新能夠在這段時(shí)間里趕上來(lái)。
這個(gè)while循環(huán)就是用來(lái)讓游戲邏輯繼續(xù)更新，直到我們不再超時(shí)，之后我們繼續(xù)游戲的主循環(huán)并且進(jìn)行屏幕渲染。這可以很好地處理突發(fā)的邏輯更新超時(shí)，使得我們的更新更加平滑，并保證邏輯的一致性和可預(yù)測(cè)性。
但是如果游戲邏輯處理持續(xù)地超時(shí)，甚至使得我們的主循環(huán)無(wú)法處理過(guò)來(lái)，這時(shí)MAX_LOOPS將會(huì)起到作用，他將使游戲控制權(quán)從邏輯更新中跳出來(lái)，去執(zhí)行如輸入處理和屏幕渲染等其他任務(wù)。
MAX_LOOP常量限制了這里的while循環(huán)用來(lái)追趕邏輯處理時(shí)間時(shí)最多能重復(fù)的次數(shù)。這樣當(dāng)游戲真的出現(xiàn)完全無(wú)法處理完邏輯更新的時(shí)候，用戶也有機(jī)會(huì)結(jié)束程序。
如果沒(méi)有MAX_LOOP的檢測(cè)，很有可能會(huì)出現(xiàn)一臺(tái)很慢的電腦試圖追上邏輯處理時(shí)間，但是卻越追越遠(yuǎn)，而又沒(méi)有機(jī)會(huì)退出這個(gè)過(guò)程，最后陷在了這個(gè)死循環(huán)中……
IndependentTickRun(frameTime);
This section is where input is gathered, events are pumped from the event queue, interface elements such as life bars are updated, and so forth. Javier allows for passing how much time the logic updates took, which can be used for updating on-screen clock or timer displays and the like if necessary. I've never found occasion to use it, but I regularly pass it anyway on the off-chance I'll need it someday. frameTime basically gives the amount of time that was spent in the logic loop performing updates.
這部分代碼用來(lái)處理用戶輸入的捕獲，事件會(huì)從事件隊(duì)列中被取出來(lái)處理，界面元素，如血條等，會(huì)在這里被更新，還有其他類似的處理。
Javier在這里留了一個(gè)frameTime參數(shù)，用來(lái)指明邏輯更新所花的時(shí)間。可以用這個(gè)值來(lái)更新游戲屏幕上的時(shí)鐘或定時(shí)器等類似信息。
雖然我目前還沒(méi)有找到機(jī)會(huì)用它，但我還是習(xí)慣性地把它帶上了，也許某天我會(huì)需要。
In order for the game loop to run predictably, you should not modify anything in this step that will affect the game logic. This portion of the loop does not run at a predictable rate, so changes made here can throw off the timing. Only things that are not time-critical should be updated here.
為了使游戲循環(huán)的運(yùn)行是可預(yù)測(cè)的，你不應(yīng)該在這里修改任何可能影響游戲邏輯的東西，因?yàn)榇瞬糠衷谟螒蛑餮h(huán)中的執(zhí)行次數(shù)是不可預(yù)測(cè)的，所以在這里只能做一些時(shí)間無(wú)關(guān)的更新。
// If playing solo and game logic takes way too long, discard pending time.
if (!bNetworkGame && (time1 - time0) > TICK_TIME) time0 = time1 - TICK_TIME;
This is where we can shave off our time debt if MAX_LOOPS causes us to dump out of the logic loop, and get things square again--as long as we are not running in a network game. If it is a single-player game, the occasional error in the timing of the game is not that big of a deal, so sometimes it might be simpler when the game logic overruns it's alloted time to just discard the extra time debt and start fresh. Technically, this makes the game "fall behind" where it should be in real time, but in a single player game this has no real effect. In a network game, however, all computers must be kept in synchronization, so we can't just cavalierly discard the pending time. Instead, it sticks around until the next time we enter the logic update loop, where the loop has to repeat itself that many more times to try to catch up. If the time burp is an isolated instance, this is no big deal, as with one or two cycle overruns the loop can catch up. But, again, if the logic is consistently running overtime, the performance of the game will be poor and will lag farther and farther behind. In a networked game, you might want to check for repeated bad performance and logic loop overruns here, to pinpoint slow computers that may be bogging the game down and possibly kick them from the game.
當(dāng)由于滿足了MAX_LOOP條件而跳出邏輯循環(huán)時(shí)，可以在這里減掉多加的上TICK_TIME時(shí)間，并且只在單機(jī)游戲時(shí)才這樣做。
如果是在單機(jī)游戲中，偶爾出現(xiàn)時(shí)間上的錯(cuò)誤是不會(huì)有什么大問(wèn)題的，所以當(dāng)游戲邏輯執(zhí)行超時(shí)后也沒(méi)有多大關(guān)系，我們簡(jiǎn)單的把多花的時(shí)間減掉，然后重新開(kāi)始。從技術(shù)上來(lái)說(shuō)，這會(huì)使得游戲有一點(diǎn)點(diǎn)時(shí)間上的落后，但在單機(jī)游戲里這不會(huì)有什么實(shí)際的影響。
但是在網(wǎng)絡(luò)游戲中這樣做卻不行，所有連網(wǎng)的電腦都必須要保持時(shí)間上的同步。
在網(wǎng)絡(luò)游戲中，如果某臺(tái)電腦落后了，他應(yīng)該保持其落后的狀態(tài)，然后在下一次進(jìn)入邏輯更新循環(huán)時(shí)，自己讓自己多重復(fù)幾次，以便追趕上來(lái)。
如果時(shí)間延遲只是個(gè)孤立事件，這將不會(huì)有多大問(wèn)題，經(jīng)過(guò)一兩次超速就會(huì)追趕上來(lái)，但是如果游戲邏輯更新總是超時(shí)，游戲的表現(xiàn)將會(huì)非常糟糕，并且最終將會(huì)越來(lái)越滯后。
在網(wǎng)絡(luò)游戲中，你可能需要檢查出這些持續(xù)超時(shí)，表現(xiàn)總是很差的電腦，并將這些可能拖慢整個(gè)游戲環(huán)境的電腦踢出去。
// Account for numLoops overflow causing percent > 1.
float percentWithinTick = Min(1.f, float(time1 - time0)/TICK_TIME);
GameDrawWithInterpolation(percentWithinTick);
This is where the real magic happens, in my opinion. This section performs the rendering of the view. In the case of a loop where TICK_TIME=40, the logic is updating at 25 FPS. However, most video cards today are capable of far greater framerates, so it makes no sense to cripple the visual framerate by locking it to 25 FPS. Instead, we can structure our code so that we can smoothly interpolate from one logic state to the next. percentWithinTick is calculated as a floating point value in the range of [0,1], representing how far conceptually we are into the next game logic tick.
在這里我們將進(jìn)行屏幕繪制。
當(dāng)TICK_TIME = 40時(shí)，邏輯更新幀率為25FPS，但是現(xiàn)在大多數(shù)顯卡都能支持更高的渲染幀率，所以我們沒(méi)必要反而鎖定渲染幀率為25FPS。
我們可以組織我們的代碼，讓我們能夠平滑的從一個(gè)邏輯狀態(tài)到下一個(gè)狀態(tài)做插值。percentWithinTick為一個(gè)0到1之間的浮點(diǎn)數(shù)，表示我們應(yīng)該向下一個(gè)邏輯幀走多遠(yuǎn)。
Every object in the game has certain state regarding LastTick and NextTick. Each object that can move will have a LastPosition and a NextPosition. When the logic section updates the object, then the objects LastPosition is set to it's currentNextPostion and a new NextPosition is calculated based on how far it can move in one logic frame. Then, when the rendering portion executes, percentWithinTick is used to interpolate between these Last and Next positions:
每個(gè)可移動(dòng)的對(duì)象都有LastPosition和NextPosition。邏輯更新部分的代碼在執(zhí)行時(shí)會(huì)將對(duì)象的LastPosition設(shè)置為當(dāng)前的NextPosition，再根據(jù)它每一幀所能移動(dòng)的距離來(lái)計(jì)算出NextPosition。
然后，在渲染對(duì)象的時(shí)候，可以再用percentWithTick來(lái)在Last和Next位置之間進(jìn)行插值。
譯注：
time0為最后一個(gè)邏輯幀所在的時(shí)間點(diǎn)，time1為當(dāng)前實(shí)際時(shí)間，(time1 – time0) / TICK_TIME表示當(dāng)前時(shí)間比最后一個(gè)邏輯幀所在時(shí)間超出了多少百分比，用這個(gè)百分比來(lái)向下一邏輯幀做插值。
如果機(jī)器比較快，在兩個(gè)邏輯更新時(shí)間點(diǎn)之間執(zhí)行了多次屏幕渲染，這樣插值就有效了。此時(shí)time0不變，time1一直在增長(zhǎng)，可以根據(jù)增長(zhǎng)的百分比來(lái)計(jì)算動(dòng)畫應(yīng)該從最后一次執(zhí)行邏輯更新的位置向下一次邏輯更新所在的位置走多遠(yuǎn)。
也就是上文所說(shuō)的，在Last和Next位置之間進(jìn)行插值。插值后的實(shí)際位置，即DrawPosition的計(jì)算方法如下：
動(dòng)畫播放的插值也是類似。
DrawPosition = LastPosition + percentWithinTick * (NextPosition - LastPosition);
The main loop executes over and over as fast as the computer is able to run it, and for a lot of the time we will not be performing logic updates. During these loop cycles when no logic is performed, we can still draw, and as the loop progresses closer to the time of our next logic update, percentWithinTick will increase toward 1. The closer percentWithinTick gets to 1, the closer the a ctual DrawPosition of the object will get to NextPosition. The effect is that the object smoothly moves from Last to Next on the screen, the animation as smooth as the hardware framerate will allow. Without this smooth interpolation, the object would move in a jerk from LastPosition to NextPosition, each time the logic updates at 25FPS. So a lot of drawing cycles would be wasted repeatedly drawing the same exact image over and over, and the animation would be locked to a 25FPS rate that would look bad.
游戲的主循環(huán)以電腦所能夠達(dá)到的最大速度不停地運(yùn)行，在大多數(shù)時(shí)間里，我們將不需要執(zhí)行邏輯更新。
但是在這些不執(zhí)行邏輯更新的周期里，我們?nèi)匀豢梢詧?zhí)行屏幕渲染。當(dāng)循環(huán)的進(jìn)程越接近我們的下一次邏輯更新時(shí)間，percentWithinTick就接近1；percentWithinTick越接近1，DrawPosition的位置就越接近NextPosition。
最后的效果就是游戲?qū)ο笤谄聊簧下摹⑵交貜腖ast位置移動(dòng)到Next位置，動(dòng)作將以硬件幀率所能允許的程度盡可能的平滑。
如果沒(méi)有這個(gè)平滑插值過(guò)程，對(duì)象位置將會(huì)從上一幀所在的LastPosition直接跳到下一幀所在的位置NextPosition。大量的渲染周期都被浪費(fèi)在把對(duì)象反復(fù)渲染到相同的位置上，并且動(dòng)畫也只能被鎖定在25FPS，使得看起來(lái)效果非常差。
With this technique, logic and drawing are separated. It is possible to perform updates as infrequently as 14 or 15 times per second, far below the threshold necessary for smooth, decent looking visual framerate, yet still maintain the smooth framerate due to interpolation. Low logic update rates such as this are common in games such as real-time strategy games, where logic can eat up a lot of time in pathfinding and AI calculations that would choke a higher rate. Yet, the game will still animate smoothly from logic state to logic state, without the annoying visual hitches of a 15FPS visual framerate. Pretty danged nifty, I must say.
使用了這項(xiàng)技術(shù)之后，邏輯更新與屏幕渲染被分離開(kāi)了。
這將允許我們把邏輯更新幀率降低到14或15FPS，這遠(yuǎn)遠(yuǎn)低于平滑的動(dòng)畫渲染所需要的幀率，但是在使用動(dòng)畫插值之后卻仍然能維持平滑的渲染幀率。
在實(shí)時(shí)策略類游戲中可能會(huì)使用這樣低的邏輯更新幀率，這里邏輯更新會(huì)因?qū)ぢ泛虯I計(jì)算而占用大量的時(shí)間，在這種情況下使用高的邏輯更新幀率顯然不行。
但是，游戲卻仍然能夠在不同的邏輯狀態(tài)之間做平滑的動(dòng)畫過(guò)渡，不會(huì)因?yàn)橹挥?5FPS的渲染幀率而出現(xiàn)那些令人生厭的動(dòng)畫跳躍現(xiàn)象。
非常的漂亮，我不得不說(shuō)。
I've created a simple program in C to demonstrate this loop structure. It requires SDL ( http://www.libsdl.org ) and OpenGL. It's a basic bouncy ball program. The controls are simple: Press q to exit the program or press SPACE to toggle interpolation on and off. With interpolation on, the loop executes exactly as described to smooth out the movement from one logic update to the next. With interpolation off, the interpolation factor percentWithinTick is always set to 1 to simulate drawing without interpolation, in essence locking the visual framerate to the 25FPS of the logic update section. In both cases, the ball moves at exactly the same speed (16 units per update, 25 updates per second), but with interpolation the motion is much smoother and easier on the eyes. Compile and link with SDL and OpenGL to see it in action: http://legion.gibbering.net/golem/files/interp_demo.c