前暴雪VP復盤:[魔獸爭霸]局域網遊戲設計

【Gamelook專稿,轉載請註明出處】

Gamelook報道/去年11月的時候,我們曾經發過一篇前暴雪VP Patrick Wyatt講述《魔獸爭霸》誕生的博客,他在那篇博文中回顧瞭暴雪最經典遊戲之一的靈感來源以及項目的來龍去脈。可我們都知道,《魔獸爭霸》最最經典的玩法之一就是局域網戰鬥,這種玩法不僅是RTS競技的首次嘗試,也讓DotA等後來的地圖有瞭可以雙方多人對戰的基礎,(有關Wyatt個人信息以及《魔獸爭霸》立項來源可以參考Gamelook之前發佈過的文章)。

出於技術方面的原因,在如今的MOBA遊戲中,這種局域網對戰的做法已經被逐漸拋棄,但在出於‘技術黑暗期’的暴雪,到底是如何做出瞭這種可以帶來緊張刺激體驗的多人對戰玩法呢?在早些時間的另一篇博客中,Patrick Wyatt講述瞭《魔獸爭霸》項目策劃過程、戰鬥單位建造、戰爭迷霧、電腦AI設計的靈感和來源,並講述瞭第一次《魔獸爭霸》多人對戰的設計以及出現的問題和解決過程,以下請看Gamelook編譯的完整譯文:

Warcraft1

《魔獸爭霸》的首次多人遊戲是壓倒性的勝利、一個慘敗,也是一場平局。可能有人會問,這怎麼可能同時發生在一件事上呢?其實,這裡是有故事的,其中包括遊戲AI、遊戲業務經濟、戰爭迷霧以及更多因素,如果有時間的話,你應該認真讀完這篇文章。

經過瞭自1993年9月以來的六個月研發之後,《魔獸爭霸》系列的開山之作《獸人與人類》終於成為瞭一款遊戲,而不是科技Demo。很多個月以來,我一直是該項目唯一的全職員工,因而遊戲的研發節奏是有所限制的。幸運的是,我有其他同時協助,包括Ron Millar、Stu Rose和其他幾個人負責遊戲設計工作,隨後幾名從事其他項目的美術師終於抽空為項目做瞭創意原型的美術工作。



初始團隊的人員數量聽起來很寒酸,因為當時的《魔獸爭霸》是公司自籌資研發,而公司的收入則是給Interplay和Sunsoft這樣的遊戲發行商做外包工作掙來的,所以資金量是很有限的。

當時我們在研發4款16位主機遊戲:一個較好不叫座的橫版解謎遊戲續作《失落的維京人2(The Lost Vikings 2)》、一個橫版奔跑跳躍遊戲《黑色荊棘(Blackthorne)》、一個DC漫畫皮的‘街霸’科隆作品《Justice League Task Force》和一個橫版動作遊戲《Death and Return of Superman》。正是有瞭這幾款遊戲的研發資金和公司其他的一些作品,我們才有瞭最初的研發成本。

遊戲研發經濟學

在遊戲行業歷史的大多數時期,不隸屬於零售遊戲發行商的獨立研發工作室通常的籌資方式是有限的,大多數都是通過與這些發行公司簽外包研發合同獲得資金,因為這些發行商會提前支付一筆遊戲研發費用,除瞭先期研發資金外,發行商還會負責PR、市場營銷、制造、零售、客服支持諸如此類的後續工作。

在上世紀90年代初,那時候的零售遊戲發行商比現在多很多,但持續增長的遊戲研發成本以及遊戲發行成本的增長導致瞭遊戲業公司大量的破產和並購,現在想起零售遊戲發行商,可能大多數人會提到動視暴雪、EA或者育碧,而不是20年前存在的那一大批中型公司。和所有行業一樣,合同的條款是由出資方擬定的,所以規則就是,‘有錢人說瞭算’。雖然理論上來講這種模式是非常有序的,遊戲賣得好可以給研發商帶來不錯的回報,但從歷史角度來看,從來都是發行商拿到最多的利潤,這一點在電影行業同樣適用,開發商們獲得的資金充其量足夠他們活著等到下一個項目,前提是如果足夠幸運的話。

上面提到‘提前預付金’的時候,更為確切的說,是不包括分成在內的預付金,對於開發商們來說相當於一個可免除貸款,隨後開發商可以從遊戲銷售中獲得分成。這個模式其實聽起來非常好:你研發一款遊戲,並且賣出去的每一份遊戲都有分成。但這種模式最後被證明瞭絕大多數研發出來的遊戲銷售額都沒有能夠達到預付金的水平。由於研發工作室通常必須放棄他們對遊戲以及續集的所有權,這種模式通常被認為是雇傭協議模式。

為瞭更好的交易條件,研發工作室通常采用的策略就是自籌資研發遊戲創意原型,然後用它來吸引發行商註資,開發商自籌資投入的時間越久,就可以從最終合同中得到更多的話語權。或許最佳的例子就是Valve Software,Gabe Newell用自己在微軟掙到的資金用於《半條命》的研發,因此他獲得瞭在這個遊戲發佈時間方面的話語權,所以他才可以決定隻有達到高質量要求的時候才發佈遊戲,而不是必須為瞭讓Sierra Entertainment季度財報更好看而按規定時間發佈。更為重要的是,Gabe自己的資金量足以保證這款遊戲的在線分銷權屬於Valve公司所有,而當時並不起眼的在線分銷模式給Valve後來的起飛奠定瞭基礎。

自籌資研發創意原型的不利之處在於,這時候的遊戲是沒有發行商簽的,通常把資金耗光之後就會導致工作室關門。我所在的公司當時的名字還是Silicon & Synapse,我們的《魔獸爭霸》是自籌資的,另一個項目《Games People Play》也是自籌資,後者加入瞭猜詞解謎、Boggle以及很多機場貨架上經常見到的遊戲玩法。

由於需要支持兩款完全不同風格的遊戲研發,當時的公司所有者們希望創造更多的資金來源,希望讓公司的資金狀況更加穩定,而不是去冒公司倒閉的風險。當然,把賭註放到多個遊戲內容本身也是有風險的,因為多數情況下一個公司的產品如果沒有滿足其用戶群的需求,往往也會失敗。暴雪品牌今天的一個巨大優勢就是,即便是沒有看到產品,其忠實用戶也會信任該公司能夠做好,這就是品牌效應。而當時的既做休閑遊戲又做3A遊戲的風格是很難贏得這樣聲譽的,比如當年的Sierra Entertainment,後來由於難以找到用戶群而陷入瞭苦苦掙紮。

在所有的活動中,《Games People Play》都被證明是錯誤的決定,因為做一個休閑娛樂產品對於主程序來說非常的缺乏興趣,所以這個項目從來也沒有成熟過,而且最後還是被取消瞭。或者換個角度來說,這不是一個錯誤,因為正是由於《魔獸爭霸》和《Games People Play》兩款遊戲的存在,才最終說服瞭當時的第二大教育軟件公司Davidson & Associates收購Silicon & Synapse。

我們的新東傢

Davidson & Associates由Jan Davidson創建,後來他的丈夫Bob也加入瞭公司,當時公司有多款教育遊戲,得益於《Math Blaster》的成功,公司增長被一致看好。作為一款教育遊戲,《Math Blaster》如果用的好的話還是有一定價值的,但我覺得它有時候很愚蠢,我高中的新聞課會在電腦房為校報寫文章和醫學教育進行分享,我的新聞學同學們和我一起看到過12年紀的醫學學生們用計算器玩《Math Blaster》的場景。

由於這些小行星包含‘3+5’以及‘2X3’這樣的表達式,所以他們快速的用計算器計算,然後輸入結果破壞這些小行星,毫無疑問的是他們可以學到一些東西,認為他們比教師聰明,但我並不覺得他們這樣用時間是值得的,因為他們很快就可以輸入結果瞭。

有瞭良好的發展和風格激進的領導人,Davidson和Associates開始向遊戲制造業擴張(為零售盒裝遊戲進行制作和打包)、介入瞭遊戲分銷以及學校教材的發放。他們看到瞭向娛樂領域進軍的機會,最後,他們初期創造娛樂體驗的經歷讓他們覺得, 如果從外部買一個有經驗的團隊會更加靠譜。

所以,威脅《魔獸爭霸》研發團隊繼續投入的現金流問題也隨著公司被收購變得迎刃而解瞭。有瞭Davidson的支持,Silicon & Synapse終於有可能專註於研發自己的遊戲,而不是去不斷的尋找低利潤的雇傭模式給其他發行商打工,被收購之後公司改名為暴雪。當時的母公司實力雄厚,在1993年創造瞭2款頂級遊戲,並且被評為任天堂年度開發商,但公司沒有拿到任何分成。

從並購中獲得瞭大筆資金可以用來招聘新員工,並且還可以讓現有的員工轉到該項目上來,所以《魔獸爭霸》的研發進度有瞭大幅提高。

策劃‘過程’

暴雪最初幾年的遊戲設計和研發過程最好的描述方式就是‘自然的’,在正式的設計討論會上我們進行大量的討論,但更是經常在公司走廊或者吃飯時間進行小規模交流。有些功能出自設計文檔,而其他功能則是由單個程序員做出來的。遊戲美術是規劃好並且按照程序執行的,但也有些是因為美術師突然想到瞭好主意而熬夜加班完成的,還有則因為美術師隻是希望做出不同,其他元素也是類似,《魔獸爭霸》的故事和傳說一直到遊戲即將發佈前的幾個月才出現。

雖然過程不可預測,但結果是非常驚人的。因為我們的團隊是由一些遊戲研發大神組成的,在他們研發的過程中,遊戲一步步發展到瞭後來被玩傢們認可的作品。我們的第一款《魔獸爭霸》是為IBM PC機研發的,最佳證明瞭這個過程,最終使這款遊戲成為瞭經典。

《魔獸爭霸》的單位創作系統是如何而來的

生物學傢們都知道,進化過程的一開始就是錯誤的,因為所有的進化樹都被抹掉瞭,而我們的研發也同樣磕磕絆絆。因為我們沒有可以對比的數據,所以隻好反復的嘗試並且去掉不能用的東西,我可以說這是一個謹慎、認真的過程,但很多時候這些想法都是從事故、爭論以及個人沖突得來的。

7

我記憶猶新的一件事是和遊戲單位創造相關的,在研發的初期階段,你需要在主機上輸入cheat指令才能讓單位行動,因為當時沒有別的UI機制可以做,在我們考慮如何最有效創造單位的時候,很多想法出現瞭。為暴雪初期遊戲做瞭大量創意和設計的美術師Ron Millar提議讓玩傢們建造農場房間,和《Populous》裡一樣,這些農場階段性的產出基本的工人單位,也就是(人類的)農民和(獸人的)苦工,玩傢們可以使用這些單位直接挖掘金礦、砍伐樹木並建造設施,但他們不能具備戰士的能力。

這些苦工還可以直接在兵營裡接受軍事訓練,期間他們會從地圖上消失,訓練完成後成為熟練的戰鬥單位,其他的訓練區域可以創造更高等的軍隊單位,比如弩車組和巫師。這個想法最終沒有完全實現,這也是我們設計過程的一個常見失誤,因為設計過程的最終結果缺乏正式的文檔,所以一個被討論過的想法有時候不知道如何被執行,所以這個想法在開始寫代碼之前,在我們的非正式設計組裡討論瞭很多遍。

在開始寫代碼之前,Ron離開去參加瞭一個交易展會(有可能是當時的冬季CES),他是和公司總裁Allen Adham一起去的,在他們離開期間,我們確定瞭《魔獸爭霸》系列的方向,我把它稱之為‘《魔獸爭霸》策劃政變’。

在一個午後,另一個早期加入公司的美術師Stu Rose來到瞭我的辦公室講述不同的做法,Stu認為Ron提出的單位創造機制有太多未能解決的實際困難,更重要的是這種操作方式和我們要給玩傢帶來的實時策略遊戲體驗是相悖的(RTS)。

在他的RTS內容下,玩傢們需要更多的註意力,他們不能把目光放在同一個地方太久,因為遊戲中有太多的競爭,規劃建築/升級樹、推動經濟發展、創造單位、放置建築、偵查地圖、觀看戰鬥並對個體技能進行微控制。在一個RTS遊戲裡,最有限的資源就是玩傢的註意力,所以增加非直接的單位創造機制是給玩傢增加瞭負擔,可能會導致註意力沖突,提高遊戲難度。

為瞭建造最基礎的戰鬥單位獸人步兵,玩傢們必須把農民或者從事低重要性工作的工人參加訓練,在Stu看來這是不必要的增加瞭遊戲難度。我對他的看法非常認同,因為我也有同樣的看法,並且不認為單位創造是需要進行大改的地方。這裡說的大改,參照物是《沙丘魔堡2》,我們的遊戲《魔獸爭霸》靈感就是來自該遊戲,但比該遊戲的單位創造有更為簡單的方法,你隻要在工廠建築界面點擊以下,這個戰鬥單位就可以跳出來為你而戰,這個想法並不是創新,而是借鑒瞭更早的一些遊戲,但卻非常的適用。

Stu認為我們應該采取他的建議,不要進行更多爭論而應該立即開始做。所以在接下來的幾天以及多個夜晚中,我匆匆做出瞭遊戲以及單位創造所必需的用戶界面,所以這個設計決定已經成為瞭既定事實。當Ron和Allen回來的時候,我們已經完成瞭簡單的單機模式,不過當時沒有做敵人和電腦AI系統。

所以這個階段的時候,《魔獸爭霸》已經成瞭一個玩起來簡單的遊戲,更重要的是,它還很有趣,所以我們此後再也沒有改過單位創造系統。

《魔獸爭霸》的第一次多人遊戲

在1994年6月,經過瞭10個多月的研發之後,我們的遊戲引擎差不多已經可以用於多人模式瞭。我越來越開心的發現,我加入的一些代碼上的改變使得《魔獸爭霸》終於有可能進行首次多人遊戲瞭。在忙於制作核心遊戲邏輯(事件循環、單位調度、尋路、戰略AI單位、狀態欄、遊戲內UI以及高等級網絡代碼等工作)的時候,其他的程序員們一直在忙著做多人遊戲相關的組件。

一個來自Caltech的大學生Jesse McReynolds完成瞭一個低等級的網絡資源庫,並通過本地局域網發送IPX信息包。這個代碼是基於Quake的源代碼而來,當時是約翰•卡馬克在id Software時候做的,現在已經開源瞭。雖然IPX界面層隻有幾百行的C代碼,但它是網卡驅動代碼界面的一部分,確保瞭一個遊戲客戶端創造的信息可以被發送到另一個玩傢的機器上。

當時還在Cal State Fullerton讀研究生學位的Bob Fitch研發瞭最初的聯網界面,可以讓玩傢們加入多人遊戲,我的辦公室和他挨著,所以交流起來非常的方便,因為我們必須通力合作才能把他的加入遊戲與我的遊戲事件結合起來。在完成瞭所有改變之後,我打包瞭遊戲客戶端並把它復制到一個網絡驅動上,這時候Bob回到瞭自己的辦公室加入這個遊戲。這是一個多麼小的奇跡,我們兩人寫的代碼居然可以用瞭,所以我們倆完成瞭第一次的《魔獸爭霸》多人對戰。

隨著遊戲開始之後,我感覺到瞭玩任何其他遊戲都沒有的激動,其中一部分是因為我參與瞭代碼工作,但更為重要的是,終於可以和真實的人類對手進行遊戲,而不是電腦AI,而且由於戰爭迷霧的緣故,我還不知道他在做什麼。

戰爭迷霧的由來

從早期遊戲借鑒的一個想法就是讓對手看不到敵對單位,遊戲地圖中的隱藏區域由黑色圖片組成,隻有友方單位探索之後玩傢才能看到,因為在真是戰鬥中,如果可以實時看到地方的操作是非常不完美的體驗。

十七年前由Walter Bright研發的一個回合制多人策略遊戲《Empire》當時為瞭同樣的目的使用瞭戰爭迷霧,當一個地圖被發現之後,這片區域就永遠是亮著的,所以這類遊戲最重要的就是盡早探索地圖,這樣在和敵人作戰的時候就擁有更大的優勢,因為瞭解敵人動向才能更好的做應對。

在歷史上,由於不瞭解敵人創造的地形而失敗的將軍太多瞭,把這個因素加入RTS玩法中是增加遊戲樂趣非常重要的方式,所以這個玩法我們要感激Walter以及西木工作室從事《沙丘魔堡2》的人員。

電腦AI

很多玩傢們都知道,策略遊戲中玩傢們遇到的電腦控制AI通常是很弱的,所以玩傢們經常會發現電腦AI是程序化的,擊敗它們很簡單,所以電腦AI方通常會有軍隊、位置或者規則方面的優勢,這樣才能給玩傢們帶來更大的挑戰。

在大多數的《魔獸爭霸》任務中,敵對電腦玩傢通常有完整的城市和軍隊與人類玩傢戰鬥,更為重要的是,《魔獸爭霸》還有一些非對稱規則,讓AI可以與玩傢進行競爭,不過可能大多數的玩傢直接把這些規則稱之為‘作弊’。我們創造的其中一條規則就是幫助AI減少金礦的流失量,比如當一個人類玩傢用工人采礦的時候,每次可以采100個單位的礦,然後往大廳裡運送100金,知道金礦被采光。而當AI占領這個金礦的時候,它的工人隻需要采8個單位的礦就能往大廳運送100金。

這種非對稱規則實際上讓遊戲更加好玩,比如以下兩個方面:它可以阻止玩傢使用堡壘策略,比如利用強大的策略技巧建造無懈可擊的防禦,所以‘堡壘策略’對於AI來說是沒有用的,因為人類玩傢的金礦會比電腦AI更早消耗光。

第二,當人類玩傢最後破壞瞭電腦的基地之後,他們還可以有金礦可以采集,這樣也讓遊戲變得更快,比使用有限的資源獲得碾壓性的勝利更為有趣。

大多數的玩傢可能會意識到AI設計最不公平的是,他們可以看穿戰爭迷霧,AI隨時知道玩傢們在做什麼。在實際遊戲中,這個優勢其實對於電腦來說並不大,仍然不能阻止它在人類玩傢面前看起來非常愚蠢。有趣的是,在《星際爭霸》推出十多年之後,一些AI程序員們開始嘗試非作弊性AI的設計,得益於BWAPI資源庫的幫助,這些程序員們可以直接為《星際爭霸》引擎輸入指令玩遊戲。程序員們進入這些AI進行相互競爭,這些BWAPI產生的AI是非常優秀的,有時候可以擊敗非常優秀的人類玩傢。

與人鬥其樂無窮

作為一個在開始研發《魔獸爭霸》之前就玩過很多策略遊戲的人來說,我對於當時的電腦AI限制是非常瞭解的,雖然我也和很多的電腦AI戰鬥過,有時候可能還會輸,但大多數時候是贏的,我從來都不怕和AI戰鬥,即便是玩Eastern Front的時候同樣如此,當時我在朋友的Atari 800遊戲機上體驗過Chris Crawford創造的遊戲,後來我的卡帶實在太久而不能讀瞭。

這些遊戲都很有趣、讓人激動,最重要的是具有挑戰性,但並不讓人覺得可怕。但是,當我第一次玩瞭《魔獸爭霸》的多人模式之後,我的看法有所改觀。

我知道自己在和真實的人類玩傢對戰,不隻是技術和策略,還需要考慮指揮速度,由於戰爭迷霧的原因還不能看到對方在做什麼,這樣的感覺既緊張又刺激。在我的職業生涯中,從來沒有一款遊戲可以讓我像玩《魔獸爭霸》多人模式這樣激動,因為你不知道戰鬥的結果是贏還是輸。

在這種激動情緒的推動下,我盡可能有效的獲得金幣和木材,建造農場和兵營,研發攻擊能力,探索地圖,最重要的是,在他可以攻擊我之前擊敗Bob的軍隊。當時沒有測試遊戲來驗證引擎的功能,我知道他也同樣覺得誰贏得首個《魔獸爭霸》多人戰鬥意義重大。更重要的是,當我們在暴雪一起玩《毀滅戰士》的時候,我基本上在辦公室出名瞭,Bob因為我頻繁的殺掉他而發怒,他發誓再也不跟我玩瞭,我知道他一定在等著有機會報仇。

在戰鬥中我們的軍隊相遇瞭,我們都盡瞭最大努力創造更多的單位參戰,當我發現他的營地並攻擊之後,我就覺得更有希望瞭。Bob的策略似乎沒有章法,似乎我可以擊敗他的軍隊,但我希望不給他留任何機會,然後隻要看到他的單位和建築我都會進行攻擊。

而突然之間,遊戲崩潰瞭。

8b1

隻要是個程序員都會明白,新代碼首次完美工作的可能性為0,所以遊戲崩潰是很正常的,遊戲屏幕回到瞭遊戲崩潰界面,讓人很容易想起Windows之前的時代。而現在我們的Windows錯誤報告其實更復雜瞭,玩傢們還可以每一次都提交錯誤報告,不過通常玩傢們偶爾會看到藍屏界面。

遊戲崩潰之後,我離開辦公室去找Bob,並且說‘太棒瞭,我把你打的落花流水’,所以當我聽到Bob說他把我打敗瞭之後讓我很驚訝。我們爭執瞭幾句就回到瞭正常話題,不過在更短的時間裡我們發現,遊戲不僅出現瞭bug,還出現瞭實時同步的問題,我把它稱之為‘同步bug’,我們兩個人的電腦完全在上演不同的戰鬥,本是同一個遊戲卻發生瞭完全不同的結果。

對於從來沒有接觸過網絡編程的童鞋們來說,他們可能會認為《魔獸爭霸》客戶端會不斷的發送整個遊戲的狀態,也就是說,每個回合電腦都會發送位置和每個遊戲單位的動作。在一個隻有少數位置的慢節奏遊戲中,比如象棋或者跳棋是可以這麼做的。但在一個像《魔獸爭霸》這樣的遊戲中,一次性可能有600個單位在行動,所以你不可能通過網絡傳遞這麼大的信息量。

我們認為很多玩傢可能會使用2400波特率的調制調解器,這樣每秒鐘隻能傳輸幾百個字符,從來沒有用過調節器的年輕玩傢們應該花時間看看這個技術,基本上沒有比煙幕信號少太多東西,而且隻是比滴水穿石的做法先進瞭那麼一點點。但你們要知道,那時候還沒有Amazon、谷歌以及Netflix,我們當時所處的時代太落後瞭。

由於此前曾經把戰鬥想起從DOS移植到Windows平臺過,所以我對於多人遊戲使用調節器交流是非常熟悉的,我知道這是因為通過調節器的帶寬有限,所以通過網絡發送所有的遊戲狀態是不可能的,所以我的解決方法就是隻發送每個玩傢的命令,並且讓雙方同時執行這些操作。

我知道這個方法是可行的,因為電腦對於執行命令是非常在行的。然而不幸的是,很多時候研發遊戲的人類往往不善於告訴電腦應該去怎麼做,所以才會產生如此之多的BUG。當兩個電腦被認為應該做同樣事情的時候,但通常會因為bug而出錯,這的確是個問題。

當兩臺電腦同步各自遊戲數據的時候,他們對於同樣的問題給出瞭不同的答案,這個問題會隨著遊戲進展越積越深,就像很多穿越電影那樣,你在過去隻要改動一點點,未來就會發生巨大的改變,《魔獸爭霸》遊戲也是一樣,在我的電腦上,我看到瞭Elvish弓箭手可以看到你的Orcish苦工並攻擊,而在你的電腦上,苦工可能完全沒有看到過我的單位,由於無法對這些數據不一致進行識別,我們兩人進行的對戰遊戲就成瞭兩個遊戲。

所以這就是《魔獸爭霸》的第一個多人遊戲,但同時對於研發團隊來說是個巨大的勝利,因為它實在是太有趣瞭,其他的團隊成員很快也嘗試瞭多人遊戲,一旦人們體驗瞭多人模式之後,再沒有其他更具吸引力的東西瞭,即便當時經常出現遊戲崩潰,我們團隊一致認為我們在做偉大的遊戲。

而當時我們所有要做的,就隻是把遊戲做完。

悲劇的是,我們很快發現瞭更糟糕的事情,我們不僅有很多的同步BUG,還發現瞭不同的BUG原因,如果所有的bug都出於同一個原因,那麼我們解決起來會很容易,但結果是同樣的bug有很多的原因導致,所以每一個BUG都要分不同情況解決。

為什麼會發生同步BUG?

在研發《魔獸爭霸》的時候,我設計瞭一個解決方案對需要網絡傳輸的數據進行最小化控制,隻發送每個玩傢最初的指令,比如‘選擇單位5’、‘移動到65.,1224位置’以及‘攻擊單位53’等等,很多程序員獨自設計瞭同樣的系統,這樣可以不用發送整個遊戲數據就可以在單個遊戲回合進行兩臺電腦之間的同步。

如今,這種做法可能會有人嘗試為這種方法申請專利,但我認為這個軟件不應該申請專利,基本上軟件中的大多數想法都是一個資深的程序員可以做到的,而Nuff表示專利的定義是必須是非明顯性(non-obvious)的。

我從來沒有使用任何方法來檢查兩個電腦之間的同步是否有問題,所以遊戲代碼中的任何BUG都可能導致遊戲崩潰,所以有時候遊戲可能會在雙方電腦上各自運行,隻不過差異會越來越大。所以為瞭讓遊戲發佈,我的下一個問題就是設計一個可以檢測同步問題的系統。

匆匆結束的故事

你們都知道瞭故事的結局:《魔獸爭霸》最終還是在五個月之後發佈瞭,這看起來像是永遠那麼久,因為我們每天都投入很多個小時,遇到瞭很多的困難,克服瞭太多的挑戰,而且創造瞭一些讓我們非常有熱情的遊戲。未來我可能會探索更多的事情,但寫到這裡也該結束瞭,這篇博客已經太長瞭。

Comments are closed.