2、C++

C++語言是具有面向物件特性的C語言的繼承者。面向物件編程，或稱OOP是結構化編程的下一步。OO程式由物件組成，其中的物件是資料和函數離散集合。有許多可用的物件庫存在，這使得編程簡單得只需要將一些程式〝建築材料〞堆在一起（至少理論上是這樣）。比如說，有很多的GUI和資料庫的庫實現物件的集合。

C++總是辯論的主題，尤其是在遊戲開發論壇裏。有幾項C++的功能，比如虛擬函數，函數呼叫的決策制定增加了一個額外層次，批評家很快指出C++程式將變得比相同功能的C程式來得大和慢。C++的擁護者則認，用C寫出與虛擬函數等價的代碼同樣會增加開支。這將是一個還在進行，而且不可能很快得出結論的爭論。

我認，C++的額外開支只是使用更好的語言的小付出。同樣的爭論發生在六十年代高級程式語言如COBOL和FORTRAN開始取代彙編成語言所選的時候。批評家正確的指出使用高階語言編寫的程式天生就比手寫的組合語言來得慢，而且必然如此。而高階語言支持者認這點小小的性能損失是值得的，因COBOL和FORTRAN程式更容易編寫和維護。


優點：組織大型程式時比C語言好得多。很好的支援面向物件機制。通用資料結構，如鏈表和可增長的陣列組成的庫減輕了由於處理低層細節的負擔。

缺點：非常大而複雜。與C語言一樣存在語法濫用問題。比C慢。大多數編譯器沒有把整個語言正確的實現。

移植性：比C語言好多了，但依然不是很樂觀。因它具有與C語言相同的缺點，大多數可攜性用戶介面庫都使用C++物件實現。

使用C++編寫的遊戲：非常非常多。大多數的商業遊戲是使用C或C++編寫的。

資料：最新版的《The C++ Programming Language》非常好。作教程，有兩個陣營，一個假定你知道C，另外一個假定你不知道。到目前止，最好的C++教程是《Who''s Afraid of C++》，如果你已經熟知C，那試一下《Teach Yourself C++》。

3、我該學習C++或是該從C開始

我不喜歡這種說法，但它是繼〝我該使用哪門語言〞之後最經常被問及的問題。很不幸，不存在標準答案。你可以自學C並使用它來寫程式，從而節省一大堆的時間，不過使用這種方法有兩個弊端：

‧你將錯過那些在遊戲中可能是更有效的資料建模方式。
‧不用馬上開始學習 OO 編程，但可能要強制你改掉最終必須忘掉的編程壞習慣，這一點請相信我。

最大的商業遊戲，包括第一人稱射擊遊戲很多並沒有使用C++。但是，這些程式的作者即使使用老的C的格式，他們通常堅持使用面向物件編程技術。如果你只想學C，至少要自學OO（面向物件）編程技術。OO是仿真（遊戲）的完美方法，如果你不學習OO，你將不得不〝辛苦〞的工作。

4、組合語言

顯然，彙編是第一個電腦語言。組合語言實際上是你電腦處理器實際運行的指令的命令形式表示法。這意味著你將與處理器的底層打交道，比如暫存器和堆疊。如果你要找的是類英語且有相關的自我說明的語言，這不是你想要的。

確切的說，任何你能在其他語言裏做到的事情，彙編都能做，只是不那簡單 - 這是當然，就像說你既可以開車到某個地方，也可以走路去，只是難易之分。話雖不錯，但是新技術讓東西變得更易於使用。

總的來說，組合語言不會在遊戲中單獨應用。遊戲使用彙編主要是使用它那些能提高性能的零零碎碎的部分。比如說，毀滅戰士整體使用C來編寫，有幾段繪圖程式使用彙編。這些程式每秒鐘要調用數千次，因此，盡可能的簡潔將有助於提高遊戲的性能。而從C裏調用彙編寫的函數是相當簡單的，因此同時使用兩種語言不成問題。

特別注意：語言的名字叫〝彙編〞。把組合語言翻譯成真實的機器碼的工具叫〝組合語言程式〞。把這門語言叫做〝組合語言程式〞這種用詞不當相當普遍，因此，請從這門語言的正確稱呼作起點出發。


優點：最小、最快的語言。彙編高手能編寫出比任何其他語言能實現的快得多的程式。你將是利用處理器最新功能的第一人，因你能直接使用它們。

缺點：難學、語法晦澀、堅持效率，造成大量額外代碼 - 不適於心臟虛弱者。

移植性：接近零。因這門語言是一種單獨的處理器設計的，根本沒移植性可言。如果使用了某個特殊處理器的擴展功能，你的代碼甚至無法移植到其他同類型的處理器上（比如，AMD的3DNow指令是無法移植到其他奔騰系列的處理器上的）。

使用彙編編寫的遊戲：我不知道有什商業遊戲是完全用彙編開發的。不過有些遊戲使用彙編完成多數對時間要求苛刻的部分。
資料：如果你正在找一門組合語言的文檔，你主要要找晶片的文檔。網路上如Intel、AMD、Motorola等有一些關於它們的處理器的資料。對於書籍而言，《Assembly Language: Step-By-Step》是很值得學習的。

5、Pascal語言

Pascal語言是由Nicolas Wirth在七十年代早期設計的，因他對於FORTRAN和COBOL沒有強制訓練學生的結構化編程感到很失望，〝空心粉式代碼〞變成了規範，而當時的語言又不反對它。Pascal被設計來強行使用結構化編程。最初的Pascal被嚴格設計成教學之用，最終，大量的擁護者促使它闖入了商業編程中。當Borland發佈IBM PC上的 Turbo Pascal時，Pascal輝煌一時。集成的編輯器，閃電般的編譯器加上低廉的價格使之變得不可抵抗，Pascal編程了MS-DOS編寫小程式的首選語言。

然而時日不久，C編譯器變得更快，並具有優秀的內置編輯器和調試器。Pascal在1990年Windows開始流行時走到了盡頭，Borland放棄了Pascal而把目光轉向了Windows 編寫程式的C++。Turbo Pascal很快被人遺忘。

最後，在1996年，Borland發佈了它的〝Visual Basic殺手〞- Delphi。它是一種快速的帶華麗用戶介面的 Pascal編譯器。由於不懈努力，它很快贏得了一大群愛好者。

基本上，Pascal比C簡單。雖然語法類似，它缺乏很多C有的簡潔操作符。這既是好事又是壞事。雖然很難寫出難以理解的〝聰明〞代碼，它同時也使得一些低級操作，如位操作變得困難起來。

優點：易學、平臺相關的運行（Dephi）非常好。

缺點：〝世界潮流〞面向物件的Pascal繼承者（Modula、Oberon）尚未成功。語言標準不被編譯器開發者認同。專利權。

移植性：很差。語言的功能由於平臺的轉變而轉變，沒有移植性工具包來處理平臺相關的功能。

使用Pascal編寫的遊戲：幾個。DirectX的Delphi元件使得遊戲場所變大了。

資料：查找跟Delphi有關的資料，請訪問：Inprise Delphi page。

6、Visual Basic

哈，BASIC。回到八十年代的石器時代，它是程式初學者的第一個語言。最初的BASIC形式，雖然易於學習，卻是可怕的無組織化，它義無返顧的使用了GOTO充斥的〝空心粉式代碼〞。當回憶起BASIC的行號和GOSUB命令，沒有幾個人能止住眼角的淚水。

快速前進到九十年代早期，雖然不是蘋果公司所希望的巨人，HyperCard仍然是一個在Windows下無法比擬的吸引人的小型編程環境。Windows下的HyperCard克隆品如ToolBook又慢又笨又昂貴。了與HyperCard一決高下，微軟取得了一個小巧的名Thunder編程環境的許可權，並把它作Visual Basci 1.0發佈，其用戶介面在當時非常具有新意。這門語言雖然還叫做Basic（不再是全部大寫），但更加結構化了，行號也被去除。實際上，這門語言與那些內置於TRS-80、Apple II及Atari裏的舊的ROM BASIC相比，更像是帶Basic風格動詞的Pascal。

經過六個版本，Visual Basic變得非常漂亮。用戶介面發生了許多變化，但依然保留著〝把代碼關聯到用戶介面〞的主旨。這使得它在與即時編譯結合時變成了一個快速原型的優異環境。

優點：整潔的編輯環境。易學、即時編譯導致簡單、迅速的原型。大量可用的插件。雖然有第三方的DirectX插件，DirectX 7已準備提供Visual Basic的支援。

缺點：程式很大，而且運行時需要幾個巨大的運行時動態連接庫。雖然表單型和對話方塊型的程式很容易完成，要編寫好的圖形程式卻比較難。調用Windows的API程式非常笨拙，因VB的資料結構沒能很好的映射到C中。有OO功能，但卻不是完全的面向物件。專利權。

移植性：非常差。因Visual Basic是微軟的品，你自然就被局限在他們實現它的平臺上。也就是說，你能得到的選擇是：Windows，Windows或Widnows。當然，有一些工具能將VB程式轉變成Java。

使用Visual Basic編寫的遊戲：一些。有很多使用VB編寫的共用遊戲，還有一些是商業性的。

資料：微軟的VB頁面有一些資訊。

7、Java 編輯醒目~

Java是由Sun最初設計用於嵌入程式的可攜性〝小C++〞。在網頁上運行小程式的想法著實吸引了不少人的目光，於是，這門語言迅速崛起。事實證明，Java不僅僅適於在網頁上內嵌動畫 - 它是一門極好的完全的軟體編程的小語言。〝虛擬機〞機制、垃圾回收以及沒有指標等使它很容易實現不易崩潰且不會泄漏資源的可靠程式。

雖然不是C++的正式續篇，Java從C++ 中借用了大量的語法。它丟棄了很多C++的複雜功能，從而形成一門緊湊而易學的語言。不像C++，Java強制面向物件編程，要在Java裏寫非面向物件的程式就像要在Pascal裏寫〝空心粉式代碼〞一樣困難。


優點：二進位碼可移植到其他平臺。程式可以在網頁中運行。內含的類庫非常標準且極其健壯。自動分配合垃圾回收避免程式中資源泄漏。網上數量巨大的代碼常式。

缺點：使用一個〝虛擬機〞來運行可移植的位元組碼而非本地機器碼，程式將比真正編譯器慢。有很多技術（例如〝即時〞編譯器）很大的提高了Java的速度，不過速度永遠比不過機器碼方案。早期的功能，如AWT沒經過慎重考慮，雖然被正式廢除，但了保持向後相容不得不保留。越高級的技術，造成處理低級的機器功能越困難，Sun這門語言增加新的〝受祝福〞功能的速度實在太慢。

移植性：最好的，但仍未達到它本應達到的水平。低級代碼具有非常高的可攜性，但是，很多UI及新功能在某些平臺上不穩定。

使用Java編寫的遊戲：網頁上有大量小的Applet，但僅有一些是商業性的。有幾個商業遊戲使用Java作內部腳本語言。

資料：Sun的官方Java頁面有一些好的資訊。IBM也有一個非常好的Java頁面。JavaLobby是一個關於Java新聞的最好去處。

8、創作工具

上面所提及的編程語言涵蓋了大多數的商業遊戲。但是也有一個例外，這個大遊戲由於它的缺席而變得突出。

"神秘島"。

沒錯，賣得最好的商業遊戲不是使用以上任何一門語言編的，雖然有人說〝神秘島〞99%是使用 3D建模工具製作的，其根本的編程邏輯是在 HyperCard 裏完成的。

多數創作工具有點像Visual Basic，只是它們工作在更高的層次上。大多數工具使用一些拖拉式的流程圖來類比流程控制。很多內置解釋的程式語言，但是這些語言都無法像上面所說的單獨的語言那樣健壯。

優點：快速原型 - 如果你的遊戲符合工具製作的主旨，你或許能使你的遊戲跑得比使用其他語言快。在很多情況下，你可以創造一個不需要任何代碼的簡單遊戲。使用插件程式，如Shockware及IconAuthor播放器，你可以在網頁上發佈很多創作工具生成的程式。

缺點：專利權，至於將增加什功能，你將受到工具製造者的支配。你必須考慮這些工具是否能滿足你遊戲的需要，因有很多事情是那些創作工具無法完成的。某些工具會生臃腫得可怕的程式。

移植性：因創作工具是具有專利權的，你的移植性以他們提供的功能息息相關。有些系統，如Director可以在幾種平臺上創作和運行，有些工具則在某一平臺上創作，在多種平臺上運行，還有的是僅能在單一平臺上創作和運行。

使用創作工具編寫的遊戲：〝神秘島〞和其他一些同類型的探險遊戲。所有的Shockwave遊戲都在網路上。

資料：Director、HyperCard、SuperCard、IconAuthor、Authorware

9、結論
你可能希望得到一個關於〝我該使用哪種語言〞這個問題的更標準的結論。非常不幸，沒有一個對所有應用程式都最佳的解決方案。C適於快而小的程式，但不支援面向物件的編程。C++完全支援面向物件，但是非常複雜。Visual Basic與Delphi易學，但不可移植且有專利權。Java有很多簡潔的功能，但是慢。創作工具可以以最快的速度生你的程式，但是僅對某一些類型的程式起作用。最好的方法是決定你要寫什樣的遊戲，並選擇對你的遊戲支援最好的語言。〝試用三十天〞的做法成工業標準是件好事情。

作者簡介

John Hattan 是位於德克薩斯州的 Watauga 裏最大的軟體公司——Code Zone 的主要負責人。如果你對他的文章有什看法，請寫信給他。

轉來滴...


原連結http://www.programmer-club.com/pc2020v5/forum/Show...ard_pc2020=exp&id=11929




>做什麼事配什麼語言是很重要的

這一篇的重點就是要讓人知道你說的這句話，
做什麼事用什麼語言。


感觸良多....~~

把來龍去脈都交代了
但是還是要自己實際用過的比較有感覺