北京赛车pk10下载ios:經典的死后:星球大戰:帝國的陰影


[這個經典的Mark Haigh-Hutchinson于1997年1月完成的事件,最初印在Game Developer雜志上,在早期任天堂64標題星球大戰:帝國的陰影中落后于幕后。

]帝國的陰影是最初為任天堂64視頻游戲機開發的動作游戲。

它是多媒體星球大戰活動的一部分,包括小說,配樂,玩具系列,漫畫書,交易卡和其他相關商品。< br>
Nintendo 64版本于1996年12月發布,并且已經證明非常受歡迎,迄今為止已經發運了超過一百萬份。

IBM PC版本于1997年9月初發布,并具有增強的剪切場景,紅皮書音頻(音樂和語音)和高分辨率圖形。

它需要使用3D加速卡。

為什么陰影?返回1994年夏天,LucasArts正在探索為新興的“下一代”之一開發新3D標題的可能性平臺。

經過一番討論,Nintendo 64被認為是首選平臺,即使當時沒有可用的硬件。

由于我們與Lucasfilm的密切關系,我們我們知道Lucasfilm Licensing正在策劃帝國陰影事件。

Jon Knoles,任天堂64游戲的首席藝術家兼設計師,積極參與決定Shadows的時間線。
>他建議它發生在帝國反擊和絕地歸來之間。

陰影故事線主要涉及銀河系的黑社會,新時期允許我們探索一些事情“絕地歸來”中沒有解釋過這個問題。

它還開辟了一些與原始故事無關的新角色,這給我們提供了比使用既定數字更多的創作自由。


獎勵是它允許我們利用每個人最喜歡的賞金獵人Boba Fett。

我們是developi作為全新游戲機的首選游戲之一,有意識地決定嘗試延伸并涵蓋多種不同的游戲風格。

我們希望確保玩家擁有盡可能多種多樣,但仍然享受令人滿意的體驗。

現實引擎200美元?到1994年9月初,我們收到了Silicon Graphics工作站,核心團隊正在工作。

最初三位程序員使用Indigo 2 Extremes,200mhz CPU,64MB RAM和24位圖形。

最后,我們必須將程序員的計算機改為INDY(仍然是強大的機器)來安裝Nintendo 64開發系統。

另外,我們很幸運LucasArts允許我們獲得Silicon Graphics ONYX超級計算機。

這款令人印象深刻且有點貴的冰箱大小的計算機擁有Reality Engine 2圖形硬件,四個R4000 CPU和256MB RAM。

它成了一個我們開發設備的重要組成部分,因為它是唯一可以模擬最終Nintendo 64硬件將如何運行的硬件。

確實,Nintendo和SGI為我們提供了模擬大多數功能的軟件。真正的硬件將支持。

9月下旬,程序員前往Silicon Graphics與其首席架構師Tim Van Hook討論Nintendo 64硬件設計。

SGI工程師是他們為自己的設計感到自豪,并承諾將提供與雄心勃勃的規格相匹配的硬件。

九個月后,我們了解到他們確實符合這些規格。

到1994年圣誕節,我們擁有第一級游戲的基礎,Hoth之戰,在ONYX上運行得非常好 - “相當不錯”是高分辨率(1280x1024),32位色,每秒60幀。

到目前為止,我們還收到了任天堂的早期原型64續滾輪。

這包括一個改進的超級任天堂控制器,帶有原始的模擬操縱桿和Z觸發器。

由于我們嚴格的保密協議,我們無法與任何人討論硬件或項目在核心團隊之外。

因此,當我們使用它時,我們會偷偷地將原型控制器隱藏在紙板箱中。

為了回答關于我們正在做什么的不可避免的問題,我們開玩笑地回答它是一種新型的控制器 - 一碗液體通過指尖吸收你的思緒。

當然,你必須用日語思考......。

1995年7月,我們收到我們的第一個實際硬件作為INDY的插件板。

這個后來被稱為修訂版1板,但在檢查時它非?!案刪弧?- 沒有電線包裹或其他臨時物品在眼前在三天之內,技術主管Eric Johnston和第二位程序員Mark Blattel將游戲移植到實際的硬盤上當我們第一次看到Hoth戰役在“真正的”機器上運行時,這是一個令人敬畏的時刻。

硬件的第一次修訂非常接近原始規格由SGI提供。

除了RCP(Reality CoProcessor)沒有以最終速度運行,并且其中一個特殊視頻“抖動模式”不可用時,它表現得非常好。
>在接下來的幾周內,我們將再收到兩塊板,以便所有程序員都以類似的方式進行開發。

三個月后,我們將收到Revision 2板,這使得RCP達到全速以及修復一些小錯誤。

另一個令人驚喜的是內存量增加一倍到4MB。

進一步的發展是硬件“抖動模式”執行幾個視頻后端的各種功能 - 主要是為了減少Mach綁定的影響,這在使用16位顏色時很常見。

T技術學埃里克約翰ston和Mark Blattel在SGI平臺上擁有豐富的經驗,我們承諾使用Performer 3D API對游戲進行原型設計。

這是一個非常靈活的基于OpenGL的系統。

最后,我們會在Nintendo 64上編寫我們自己的Performer功能子集。

這使得我們可以在短短三天內將游戲從$ 140,000 SGI ONYX轉移到$ 200任天堂64.

關卡設計師使用Dark Forces的工具集來構建游戲的第一人稱關卡。

這允許在IBM PC上使用實際的Dark Forces引擎進行粗略的預覽。
>這項工作相當不錯,雖然在項目后期,我們可以使用單個SGI供級別設計人員專用。但是,PC解決方案也很有用,因為關卡設計師已經熟悉了涉及的過程。

不幸的是,由于此時游戲引擎沒有在PC上運行,因此開發周期為有點慢。

此外,ONYX計算了每個級別的預先清除可見性樹。

由于Eric和Mark,它的工作方式非常優雅。


世界被細分為“扇區” - 即由幾何或其他標準定義的多邊形區域。

這些扇區控制碰撞檢測,具有與游戲相關的屬性,并執行其他幾個相關功能。 br>
可見性程序遍歷世界,從360度弧形中的每個扇區的中心以及三個高程渲染場景。

對于要在特定場景中渲染的每個多邊形扇區,識別32位值而不是紋理信息,填充幀緩沖區中的適當像素。

這是一個簡單的問題,即讀取幀緩沖區以確定哪個扇區從該位置可見。 br>
這個過程被稱為“淡化”,因為標識符是寫的進入frame緩沖區(實際上是RGBA值)導致場景顯示為純粹的柔和色彩。

Motion在1995年春天,我們決定嘗試使用動作捕捉來控制主角的動畫。作為諸如Stormtroopers之類的敵人。

幸運的是,我們的姐妹公司Industrial Light&Magic(ILM)有一個可供使用的捕獲系統。

這是一個系留系統,使用一個用于確定每個傳感器位置的磁場。

傳感器使用攀爬帶,運動關節支撐,繃帶和魔術貼條組合在11個位置連接到演員。
< br>系統的性質帶來了幾個問題。

首先,演員必須在凸起的木制平臺上演出,因為混凝土地板上的金屬結構支撐會影響捕捉系統。
>其次,由于演員在平臺上以及拴在一起,我們無法獲得“干凈”的跑步周期>
我們的一些雄心勃勃的動作也證明是有問題的。

從積極的方面來說,一旦系統被校準,我們能夠在一天內捕獲超過100個動作,每個動作有兩到三個不同的動作“需要。

”我們在運行Alias 太陽2平臺 PowerAnimator的SGI Indigo 2 Extreme計算機上實時查看了這些動作。

這使我們能夠在繼續執行之前快速確保每次捕獲都是“干凈的”下一步行動。不幸的是,我們發現經過分析后,運動數據被證明無法使用。

這主要是因為關節的角度信息不一致圍繞每個軸的方向的表示。

因此,人物的所有動畫都是手工重做的,這是一項耗時的任務。

Jon Knoles指揮演員Amos Glick想象中的鏡頭。

Mark Haigh-Hutchinson對電纜進行了爭吵并提供了支撐手。

MIDI MusicOur init接近的方法該游戲的音樂類似于我們的一些PC游戲 - 即基于MIDI的解決方案。

然而,我們遇到的第一個問題是我們的音樂家使用的MIDI鍵盤之間的硬件不兼容性用于開發游戲的Silicon Graphics計算機。

理論上可以直接在Nintendo 64硬件上預覽作品,因為音樂家在鍵盤上播放它們。

當然,這個將為音樂家提供最好的反饋。

不幸的是,由于一些未知的原因,音符開/關對丟失,導致和弦發出一個音符。

另外,注意事項有時會完全錯過。

不久之后,其他不受歡迎的行為浮出水面。

我們通過讓音樂家捕捉樣本集并僅在他們的鍵盤上播放來解決這些謎團。 >
經過一些實驗,我們覺得MIDI音樂很好,但沒有捕捉到es約翰·威廉姆斯的管弦樂配樂與“星球大戰”密切相關。

此外,每個額外的樂器頻道都需要比我們想要分配更多的CPU時間。

此時,我們嘗試使用星球大戰主題的未壓縮數字樣本進行實驗。

即使在使用任天堂提供的ADPCM編碼器進行后續壓縮后,質量也非常好。
太陽2娛樂
經過一番勸說后,Nintendo慷慨地同意將墨盒空間從8MB增加到12MB。

這使我們能夠包含大約15分鐘的16位,11khz單聲道音樂,聽起來非常好。

考慮到這一點大多數用戶會通過電視(而不是復雜的音頻系統)收聽音樂,結果接近音頻CD的結果,從而證明所需的額外磁帶空間是合理的。

藝術路徑一直存在的問題陰影的發展是inabili ty to在我們使用的各種3D軟件包之間導入和導出數據。

最終,我們設法通過一些翻譯實用程序以及使用Alias Power Animator作為我們的中心“集線器”格式來規避這些問題。

但是,尺度,模型層次結構和動畫數據仍然存在問題。

藝術家有時很難看到他們的藝術作品真正的樣子,直到它通過手我們的多邊形爭吵者(感謝Tom?。?。

最初,我們的紋理藝術家很難想象出硬件所需的紋理大小限制以及顏色減少問題。

新硬件在開發游戲時我們還有許多其他問題需要處理,其中最重要的是在項目的前九個月,我們沒有任何真正的硬件來運行游戲。

這種缺陷無論如何都不是不可克服的,但它限制了我們的選擇ces以某種方式,特別是在關卡設計方面。

我們被迫做出一些假設,尤其是關于性能的假設。

幸運的是,這并不是我們預期的錯誤。 >
眾所周知,那些處于技術前沿的人往往會犧牲它們。

其他問題在1996年圣誕節截止日期前及時完成比賽的壓力很大。

這個現實意味著很多很多深夜,一些團隊成員每周定期工作超過100小時,一年中最好的時間。

希望在未來的項目中可以避免這種工作量。

時間壓力當然是電腦游戲行業的常見問題 - 我們當然不會對這種現象感到陌生。

但是,因為我們不得不在發布后不久發布我們的游戲對于機器,我們承受的壓力比通常遇到的壓力要大。

游戲測試也成了一個問題,因為我們很少實際測試游戲的機器。

太陽2 Game Play Variety我們能夠在Shadows中包含各種各樣的游戲風格。

回想起來,這意味著我們無法調整每種類型的游戲玩法都和我們想要的一樣多。

這也意味著在嘗試編寫和調試五種不同游戲引擎的過程中幾乎是一項艱巨的編程任務。

這些任務包括:地形低空飛行,空間射擊行動,步行第一/第三人或帶噴氣背包(包括行駛中的火車序列),超速自行車高速追逐以及全程360度太空飛行。
>盡管如此,結果是大多數玩家對游戲的體驗總是很有趣,代價是讓一些更加核心的游戲玩家感到不悅。

各種游戲玩法對于一款游戲來說非常重要。許多玩家,將是他們在完全3D環境中的第一次體驗之一。

硬件性能如前所述,對于t在前九個月的Shadows中,我們沒有真正的硬件來衡量游戲的性能 - 除了相當不錯的Silicon Graphics ONYX。但是,當我們終于收到真正的硬件時,我們很高興發現SGI給我們的性能估計證明是非常準確的。

事實上,在很大程度上由于圖形硬件的并行性,我們能夠在整個Shadows中使用浮點數學對于性能沒有顯著影響。

另外,Shadows完全使用C語言進行編程 - 我們沒有必要使用匯編程序(就我而言是第一個,并且即使雖然令人驚喜我是一個長期的鐵桿裝配扇。)

由于我們的場景復雜度相對較高(通常保持在大約3,000個多邊形左右,但根據級別類型和設計而變化),圖形任務占用了執行時間比程序代碼長(也就是說,我們是graphics-b ound)。結果
因此,對程序代碼的優化并沒有顯著提高整體性能。

NTSC到PAL轉換完成美國和日本版本的游戲后,我的任務是轉換游戲以便它可以運行關于歐洲PAL電視標準。

作為英國人,我有一種既得利益,確保轉換是一個好的。

這意味著兩件事:第一,游戲使用的PAL顯示器的整個垂直分辨率(625線與NTSC的525線);第二,我想確保PAL游戲的速度與NTSC相同,即使PAL刷新率是50hz而不是60hz。

幸運的是,當我們開始研究Shadows時,我們意識到要考慮的最重要的事情之一是它必須是基于時間的游戲,而不是基于幀的游戲。

這將允許根據場景復雜性而變化很大的更新速率,以及我們沒有任何真正的硬件來測量性能特征的簡單事實。

本質上,程序會跟蹤每次更新游戲之間的絕對時間。
>這個值,我們稱之為delta時間,成為任何移動或其他基于時間的數量的被乘數。

通過這種方法,游戲獨立于視頻刷新率運行,所有對象都在移動和響應正確的頻率。

另一個問題與人類常見的“信箱”效應有關y NTSC到PAL轉換。??

在大多數情況下,垂直幀緩沖區大小沒有額外的渲染或增加,在可見游戲區域的上方和下方留下難看的黑色條帶。

垂直分辨率現在大于原始NTSC顯示,寬高比也會改變,導致圖形水平拉伸。

雖然我不愿意接受這個,但我猜想我不能負擔得分ra渲染較大的幀緩沖區所需的CPU時間,即使由于50hz的視頻刷新率而有額外的時間可用。

還有一個問題是我們的幀緩沖區的三重緩沖需要額外的RAM使用量因此,我的第一次嘗試只是改變3D引擎的視野和縱橫比。

這個簡單的解決方案很好地解決了“伸展”問題,盡管當然,顯示仍然是字母框。

不幸的是,這也意味著任何2D覆蓋狀態信息仍然“拉伸。

”游戲可能會受到影響,因為根據定義,視野會影響玩家對3D世界的看法。

同樣,這還不夠好。

我需要的是一個不需要的解決方案額外的渲染,但會解決縱橫比問題。

經過一番研究后,我意識到我之前已經發現過可以在顯示硬件的輸出級上更改最終可見顯示區域的大小。

實際上,可以水平和垂直縮小或放大顯示。


為了補償信箱,我所要做的就是將垂直顯示尺寸改變625/525或1倍。



一旦我做了這個,我立即做了一個全屏PAL版。

或者我認為......。

關于Shadows的一個問題是我們必須壓縮游戲中的所有內容以適應可用的盒式磁帶空間。 >
這包括SGI作為開發系統的一部分提供的瘦操作系統。

因此,在機器重置時,有必要解壓縮此OS以運行游戲。

To執行這個解壓縮,我們寫了一個小的bootstrap程序,它在初始化的硬件和OS啟動之間引入了少量的時間。

這種滯后引入了一次性故障在屏幕上作為視頻硬件啟動。

除了我以外,不是很明顯。

經過很多深夜,我發現了一種通過直接訪問Nintendo 64視頻硬件寄存器來消除故障的方法。

Bad Idea我們隨后發現,因為我們直接訪問了硬件,所以它造成了一個不常見的錯誤。

如果在特定的情況下按下重置按鈕,很少(50次中有1次)Nintendo 64會崩潰在游戲中指出。

不僅如此,我無法重復我的硬件上的錯誤(當發生這種情況時我討厭它。)

經過一些很晚的夜晚(在圣誕假期),在Nintendo of America的技術人員的幫助下(感謝Mark和Jim),我們終于解決了這個問題:首先,通過刪除直接訪問視頻寄存器的代碼,其次,通過恢復控制縮放的寄存器復位時垂直軸的輸出。

有時,最簡單的解決方案是最好的。

SGI和Ninte的支持我們非常幸運能夠在游戲制作過程中獲得SGI和任天堂的大力支持。

SGI工程師(特別感謝“Acorn”)非常有幫助,通?;嶧卮鷂頤塹奈侍庖惶熘?,有時是在一小時內。

我要感謝任天堂在游戲制作方面提供的幫助。

Nintendo of America的技術支持和質量保證部門也證明是非常寶貴的。 br>
此外,日本任天堂的三名員工花了一些時間在我們的辦公室直接與我們合作。

1996年8月在日本京都的晚餐。

(從左到右:Don James,Hiro Yamada,Mark Haigh-Hutchinson,Shigeru Miyamoto,Kenji Miki。

)我也很幸運地訪問任天堂在日本京都的總部,與Mario的創造者Shiyru Miyamoto討論Shadows 64.

他的見解既迷人又極具相關性。

他只是一個本能的天才理解視頻游戲。

Wampas和Men當開發一個Shadows規模的項目時,總會有一些事情沒有像他們那樣順利進行...... 1)動作捕捉過程被證明是對我們來說是一個紅色的鯡魚。

雖然最初承諾一個更加逼真的動畫解決方案,但在我們的案例中數據證明無法使用。但是,我仍然相信它具有巨大的潛力,值得進一步研究即使我們沒有達到處理與角色環境等動作相匹配的潛在問題的程度。





2)嘗試使用MIDI這個游戲的基礎音樂解決方案也被證明是錯誤的。

雖然它承諾在內存方面是一個有效的解決方案(基于盒式游戲的一個重要考慮因素),但它根本不適合管弦樂電影配樂如星球大戰。

3)當我們開始研究陰影時,一個主要問題(繼續d,在整個項目期間)各種3D軟件包無法導入和導出數據。

雖然我們能夠在大多數情況下編寫自己的轉換實用程序,但它仍然證明是絆腳石并阻止我們擁有一條高效的藝術道路。

幸運的是,提供這些工具的公司現在認識到需要將數據導入和導出到其他軟件包,并正在采取措施來糾正這種情況-VRML,事實證明,這是一種有用的格式。

4)時間是制作游戲的最大敵人。

這不是什么新鮮事,但是因為我們是在一臺不存在的機器上工作九個月。

盡管如此,盡管這在很大程度上是我們無法控制的,但我們仍能夠制作出高質量的游戲。


5)事后看來,可能從游戲開發中學到的最重要的一課就是關注焦點。

做一兩件事和d他們極端好吧。

雖然我們的野心很好,試圖為玩家提供盡可能多的多樣性,但我們實際上必須編寫五種不同的游戲引擎。

另外,我們也可以使用了第四個程序員,專門用于游戲前端的各個方面;也就是說,級別選擇,控制器選項等等。

這將會給主程序員帶來一些壓力,直到項目結束。

走出陰影......由于Shadows團隊的才能,奉獻精神和經驗,在開發過程中很多事情進展順利。

1)通過使用功能強大的SGI計算機(1994年在游戲行業中相當罕見)進行原型制作,結合我們程序員對3D技術的了解,我們能夠快速開發游戲,并在性能要求方面保持靈活性。

2)我們重用早期黑暗部隊標題工具的能力為我們節省了時間和資源,因為我們不需要構建所有新工具,盡管需要大量的數據轉換實用程序。

此外,通過重用熟悉的工具,我們的關卡設計人員可以在項目早期提高工作效率可能已經預料到了。

3)我們決定使用數字化音樂被證明是一個至關重要的音樂。

因為大多數用戶會通過他們的電視聽音樂,所以質量接近音頻CD的質量,就像許多客戶所關注的那樣。

單獨證明所需的額外盒式磁帶空間是合理的,并且令許多玩家感到驚訝,這些玩家不期望從盒式磁帶游戲中獲得高質量水平。

4)PAL電視標準游戲的轉換非常順利,非常感謝這些國家的客戶。

可以公平地說,Shadows已經設定了標準,因為它可以全屏和全速運行。

沒有理由為什么所有的游戲都來自這個點上不應該只是運行PAL系統以及它們在NTSC上也是如此。

5)鑒于我們正在研究全新的硬件,并且大部分必須發現我們自己需要知道的一切,SGI的支持在整個項目中,任天堂對我們來說都是非常寶貴的。

Varying Shadows雖然我們無法花費太多時間來調整游戲,但Shadows確實成功地為玩家提供了各種游戲 - 游戲風格。

它的受歡迎程度證明了我有幸成為其中一員的團隊的創造力和才能。

核心團隊核心團隊從開始到完成開發Shadows主要由六個人組成,雖然有20個人在不同程度的時間和不同程度上為比賽做出了貢獻。

盡管如此,每個人在比賽的制作中都發揮了至關重要的作用。


完整的游戲積分列表如下:游戲設計師/首席藝術家 - Jon Knoles項目負責人/高級P rogrammer - Mark Haigh-Hutchinson技術主管 - Eric Johnston程序員/ Lycanthrope - Mark BlattelPolygon牧馬人 - Tom HarperLevel設計師 - Jim CurrentLevel設計師 - Matthew Tateishi和Ingar Shu3D藝術家 - Paul Zinnes,Andrew Holdun和Garry M.

Gaber3D Animator - Eric Ingerson紋理藝術家 - Chris Hockabout3D /背景藝術家 - Bill StonehamStoryboard藝術家 - Paul Topolos音樂編輯 - Peter McConnellSound設計師 - Larry the O和Clint BajakianLead Tester - Darren Johnson制作經理 - Brett TostiBack Row(從左到右):Steve Dauterman,Peter McConnell, Jon Knoles,Andrew Holdun,Paul Topolos先生,

B.

Fett; Middle Row(從左到右):Jim Current,Matthew Tateishi,Bill Stoneham,Brett Tosti,Ingar Shu,Tom Harper,Chris Hockabout; Front Row(從左到右):Garry Gaber,Mark Blattel,Eric Johnston,Mark Haigh-Hutchinson;沒有顯示:Paul Zinnes,O,Larry,Clint Bajakian,Eric Ingerson和Darren Johnson。

非常感謝Don James,Henry Sterchi,Hiro Yamada,Kensuke Tanabe和Shigeru Miyamoto。

特別感謝LucasArts的工作人員,特別是George Lucas的星球大戰宇宙禮物。

[Mark Haigh-Hutchinson在撰寫本文時是LucasArts的項目負責人和高級程序員。

他后來將參與星球大戰:Rogue Squadron,Star Wars:Episode I - Racer,和銀河戰士Prime系列。

2008年1月,他去世,享年43歲。


北京赛车pk10报警后果 www.jtcaq.icu 鄭重聲明:本文版權歸原作者所有,轉載文章僅為傳播更多信息之目的,如作者信息標記有誤,請第一時間聯系我們修改或刪除,多謝。

11选5有没有稳赚不赔的方法 高频彩彩票计划自动模拟器 双色球买篮球保本买法 捕鱼手机游戏下载 黑龙江时时技巧 时彩玩法技巧之稳赚 非凡炸金花手机版提现 极速时时在哪里开的 幸运飞艇买3码怎么倍投 百人现金炸金花手机版 北京pk10倍投能赢吗 对刷套利稳赚不赔图片 斗牛棋牌游戏 老时时杀号网站 幸运飞艇七码怎么倍投 重庆时时彩开奖