游戲人生

Author: Fox

在MMORPG中，存在大量的數(shù)據(jù)文件和腳本文件，這些文件涉及很多變量，當(dāng)玩家信息需要存取時(shí)（上線、下線、保存、服務(wù)器交互），即伴隨著大量的讀寫操作。隨著游戲中游戲任務(wù)的增加，每一個(gè)玩家對應(yīng)的需要數(shù)據(jù)庫存取的腳本變量的數(shù)據(jù)量也隨之線性增長，隨著玩家數(shù)量的增加，在服務(wù)器保存玩家角色信息的時(shí)候，通信量的大小是相當(dāng)可觀的，使用多線程讀寫，可以使服務(wù)器的處理能力大幅增強(qiáng)，但網(wǎng)絡(luò)和數(shù)據(jù)庫承受的壓力也會(huì)大幅增加。

當(dāng)然現(xiàn)在有很多的腳本語言為我們設(shè)計(jì)任務(wù)系統(tǒng)提供了便利，像Lua、Python、Ruby這些動(dòng)態(tài)語言的功能越來越強(qiáng)，而且可以肯定的是，會(huì)有越來越多的產(chǎn)品采用這些優(yōu)秀的語言。但我今天要談的不是如何使用動(dòng)態(tài)語言，也不是討論動(dòng)態(tài)語言孰優(yōu)孰劣的問題，而是對于大量的腳本變量的存取優(yōu)化。說白了，這對于使用自定義腳本語言的游戲開發(fā)人員才更有參考價(jià)值。而且我要說的問題很小，小到我只是講一點(diǎn)點(diǎn)內(nèi)容，只是我今天下午的一點(diǎn)活，總結(jié)下來更多只是為了讓自己記住，并不是教育別人。

假設(shè)在整個(gè)腳本系統(tǒng)中，存在500個(gè)與玩家相關(guān)而且需要數(shù)據(jù)庫存取的腳本變量，如果一個(gè)游戲世界中擁有3000個(gè)在線玩家，平均每個(gè)玩家的腳本變量大小為10KB，如果服務(wù)器同時(shí)保存這3000個(gè)玩家的數(shù)據(jù)（那可不僅僅是腳本變量，當(dāng)然腳本變量所占的分量比較大就是了），3000×10KB，哦……與此同時(shí)，服務(wù)器還要進(jìn)行其實(shí)正常的網(wǎng)絡(luò)通信和邏輯處理（雖然不可能是同一個(gè)線程），但服務(wù)器承受的壓力已經(jīng)不小了吧，為了減少這種壓力，腳本變量成為了一種稀缺資源。
為了對腳本變量的存取進(jìn)行優(yōu)化，我想到了一個(gè)最容易實(shí)現(xiàn)的方法。通過對數(shù)據(jù)庫的觀察（其實(shí)想也想也想得到:)），我發(fā)現(xiàn)玩家數(shù)據(jù)中大量的腳本變量的值都是0或者空字符串，這就為優(yōu)化提供了很大的一個(gè)空間。

服務(wù)器一般都保存有一個(gè)腳本變量的配置文件，在這個(gè)文件中列出了所有的腳本變量及其默認(rèn)值。當(dāng)玩家登錄時(shí)，服務(wù)器將為其依據(jù)這個(gè)文件為其建立一份拷貝，并從數(shù)據(jù)庫讀取這些變量的真實(shí)值填充之。因?yàn)榇罅康淖兞恐刀际悄J(rèn)值，所以在往數(shù)據(jù)庫保存的時(shí)候，是沒有必要全部保存的，而只需保存那些不同于默認(rèn)值的變量名和變量值以及該變量對應(yīng)的下標(biāo)即可。下一次從數(shù)據(jù)庫讀入的時(shí)候根據(jù)下標(biāo)確定哪些變量值需要從數(shù)據(jù)庫中讀取就可以了。

很簡單的一個(gè)操作，雖然做到了這一點(diǎn)優(yōu)化，但是對于500個(gè)變量的線性讀取和其他操作，依然不是一個(gè)好的處理方法。

幾點(diǎn)改進(jìn)的方向，目前只是有個(gè)想法：

1、將玩家與其腳本變量解耦

并不是所有的玩家都需要500個(gè)腳本變量的，不同等級(jí)的玩家可以參與的任務(wù)和活動(dòng)是完全不同的，我們顯然沒有必要為每一個(gè)玩家從生到死都保持這500個(gè)變量。這樣考慮下來，估計(jì)一個(gè)玩家的腳本變量數(shù)可以減少300-400個(gè)，從而實(shí)現(xiàn)了“垃圾”回收再利用。OMG！

想法是非常具有誘惑力的，但這一優(yōu)化同時(shí)涉及到腳本策劃和程序，而且稍有不慎（對某一變量重復(fù)使用），全盤皆輸，在“穩(wěn)定壓倒一切”的大方針下，這樣的優(yōu)化需要給出一個(gè)系統(tǒng)的策略，玩家等級(jí)、職業(yè)因素的影響都要考慮進(jìn)去。

2、對玩家腳本變量實(shí)現(xiàn)壓縮存儲(chǔ)

未經(jīng)壓縮的腳本變量，每個(gè)大概有幾十Bytes，如果采用一個(gè)好的壓縮算法，能不能減少到10Bytes呢？什么又是一個(gè)好的壓縮算法呢？壓縮解壓縮的成本和直接存取成本比起來哪個(gè)更高呢？想想這些的確也都是問題呢。

/*****************************************************************************
? 這只是我工作中的一個(gè)總結(jié)，問題很簡單，也很瑣碎，正如我前面所提的，僅僅是提供一個(gè)參考。
*****************************************************************************/