大約在一年前，我說我會離開 OGRE，現在我要說，我要回到 OGRE 的懷抱了。
在過去的一年間，除了在日間工作外，晚上也在進修，所以比較忙，沒空閒去製作自己想做的遊戲，曾經想在有限的空間裡，嘗試一些 OGRE 以外的 Game Engine，但可惜的是，可能是年齡的問題，在知識和習慣上的束縛，和以前的我不一樣了。近日可以靜一靜地在想，其實我的想法很簡單，只是想做遊戲，而不只是想編寫電腦程式，所以我決定回到 OGRE 的身邊了。
重新的面對著 OGRE，它新的版本是 1.7.4 ( 暫時不會用 1.8.0 RC )，令我想起在拋棄它之前曾經試過，但那時候總是 Compile 不能。這次重新嘗試，不知怎的卻很順利，用了不到兩天的時間便可以用到了一年前的基本功能了。( 但現在卡在了一個地方，就是 Overlay 的 Text Element 看不到字形... )
除了面對新的 OGRE 版本外，一些以前的工具也要更新，雖然只是 OGRE 的更新，但也要作一些配合，工具例如：Actor Editor、Material Editor、Mesh / Animation exporter、Viewer... 等等都要逐一更新，看上去好像很多功夫要做，但仍是值得的，因為「我可以製作遊戲」!
Monday, February 27, 2012
Sunday, August 28, 2011
遊戲製作是甚麼 ?
近來在遊戲製作的過程中，看到了很多失誤，當中牽涉到的，是橫跨了遊戲設計、美術設計和程式設計。認真一點的說（或者是不客氣的說），就是整個遊戲的製作上，由一開始已經是註定成為了 epic fail 的最佳例子。
其實遊戲製作是甚麼一回事？
從遊戲設計上說，遊戲製作其實並不困難，因為困難的並不是遊戲製作過程，而是遊戲設計上，對「創作」上有多少的覺悟，如果有志投身或現職遊戲設計的，應該要有這個覺悟，因為如果沒有這個覺悟的，你所遇到的，只會是失落與沮喪，到最後只是黯然離開。
我所說的覺悟是，不要認為遊戲設計是空想科學而已，請細心想一想；因為遊戲製作並不是「空想」而已，你不能只享受創作時的快感，也不能閉門造車，只有自己才明白整個遊戲的設計，要和 Team 內的組員多溝通，要所有組員明白遊戲的核心，同時也要顧及很多很多的因素及細節，例如遊戲的設計在表達上，和技術上的可行性，又甚至是界面上的實用性...等等，這些看上去都不太關於遊戲設計的範疇，但對遊戲製作上卻是非常重要的。
從美術人員的角度上說，做出遊戲設計上所有視覺效果，是最重要的職務。然而，在美術的表達上，也要和遊戲設計的主題互有交流，才能夠充分表達到遊戲的重點。同時在技術層面上，也要有多一點的認識，始終遊戲製作這個行業，與其他美術設計業不一樣，在創作上會是被科技的框架包圍著，多認識一點技術，多一點創作空間。
到了程式設計上，切忌一些堆砌、不必要的複雜及 hard-coded 的形式，例如：
int _column = _size_col % 3;
int _row = _size_row / 3;
以上的例子簡單地說明了「堆砌 + 複雜 + hard-coded」，這種程式，不便修改，不便除蟲，突顯出那是臨時堆砌出來的。
另外，對遊戲引擎工具的一知半解，也會令以上的問題劇烈化，成為了問題最基本的觸法點。
但到了最後，不得不說的，就是互信的問題，如果遊戲設計人員，美術人員及程式技術員，大家都互不信任，不互補長短的，要製作的遊戲到最後成為了 epic fail 的一員，也是必然的結果了。
在這樣看上去，我好像有點自以為是，只懂批評。
但正如爆漫中說的，成功的三項條件：自大，努力，運氣！（我有點自大，很努力，但沒運氣）
其實遊戲製作是甚麼一回事？
從遊戲設計上說，遊戲製作其實並不困難，因為困難的並不是遊戲製作過程，而是遊戲設計上，對「創作」上有多少的覺悟，如果有志投身或現職遊戲設計的，應該要有這個覺悟，因為如果沒有這個覺悟的，你所遇到的，只會是失落與沮喪，到最後只是黯然離開。
我所說的覺悟是，不要認為遊戲設計是空想科學而已，請細心想一想；因為遊戲製作並不是「空想」而已，你不能只享受創作時的快感，也不能閉門造車，只有自己才明白整個遊戲的設計，要和 Team 內的組員多溝通，要所有組員明白遊戲的核心，同時也要顧及很多很多的因素及細節，例如遊戲的設計在表達上，和技術上的可行性，又甚至是界面上的實用性...等等，這些看上去都不太關於遊戲設計的範疇，但對遊戲製作上卻是非常重要的。
從美術人員的角度上說，做出遊戲設計上所有視覺效果，是最重要的職務。然而，在美術的表達上，也要和遊戲設計的主題互有交流，才能夠充分表達到遊戲的重點。同時在技術層面上，也要有多一點的認識，始終遊戲製作這個行業，與其他美術設計業不一樣，在創作上會是被科技的框架包圍著，多認識一點技術，多一點創作空間。
到了程式設計上，切忌一些堆砌、不必要的複雜及 hard-coded 的形式，例如：
int _column = _size_col % 3;
int _row = _size_row / 3;
以上的例子簡單地說明了「堆砌 + 複雜 + hard-coded」，這種程式，不便修改，不便除蟲，突顯出那是臨時堆砌出來的。
另外，對遊戲引擎工具的一知半解，也會令以上的問題劇烈化，成為了問題最基本的觸法點。
但到了最後，不得不說的，就是互信的問題，如果遊戲設計人員，美術人員及程式技術員，大家都互不信任，不互補長短的，要製作的遊戲到最後成為了 epic fail 的一員，也是必然的結果了。
在這樣看上去，我好像有點自以為是，只懂批評。
但正如爆漫中說的，成功的三項條件：自大，努力，運氣！（我有點自大，很努力，但沒運氣）
Monday, June 27, 2011
Wednesday, June 01, 2011
Wednesday, March 16, 2011
究竟... 有甚麼好玩 ?
以下是一段 Prototype 2 的 trailer，片段中展示了丟人落街，但我不是想說其道德問題，而是，若那是一個要 Promo 的 Gameplay，那麼..... 「有甚麼好玩？」
對不起，我百思不得其解。
對不起，我百思不得其解。
Thursday, March 03, 2011
要放棄的時候就應該放棄
在這些年來，用過不少有關遊戲開發的 Engine，近幾年都在用 OGRE，但相信是時候放棄它了。
自從 OGRE 推出 1.7 以來，我嘗試過幾次將自己的 Ogng3D Engine，從 OGRE 1.6 轉過去 1.7，但係每次都有點小問題令我停滯不前，由它加入 Boost 的小問題，到 .mesh 格式的改變... 等等，這些林林種種的小問題，真是煩瑣得很... 所以，就在此決定，不會再跟進 OGRE 作為我的遊戲開發 Engine 的一環了。
一直以來，OGRE 中的很多功能 ( 例如 Particle System )，都絕對不是一般的難用，只是我自己一直都找不到替代品，才一直硬著頭皮地用著它... 。到了近年，遊戲 Engine 都發展到一個沒法想像的地步了，而且不小 Engine 開始免費化了 ( 當然是有條件的... )，所以其實已經不愁沒有替代品。
最後也要說說，其實在使用 OGRE 配合自己的 Ogng3D 的這幾年間，因為 OGRE 的難以運用，確是從中學習到不少遊戲開發的事，雖然不能使用它來開發一個真正的遊戲 ( 其實曾經用過 Ogng3D 做過幾個遊戲 Prototype 呢... )，但也算是個不錯的經驗。
很多時候，人要在適當的時候放棄一些東西。這次使用 Engine 的事情，也不應再糾纏下去，狠心的切斷和 OGRE 的關係好了。
自從 OGRE 推出 1.7 以來，我嘗試過幾次將自己的 Ogng3D Engine，從 OGRE 1.6 轉過去 1.7，但係每次都有點小問題令我停滯不前，由它加入 Boost 的小問題，到 .mesh 格式的改變... 等等，這些林林種種的小問題，真是煩瑣得很... 所以，就在此決定，不會再跟進 OGRE 作為我的遊戲開發 Engine 的一環了。
一直以來，OGRE 中的很多功能 ( 例如 Particle System )，都絕對不是一般的難用，只是我自己一直都找不到替代品，才一直硬著頭皮地用著它... 。到了近年，遊戲 Engine 都發展到一個沒法想像的地步了，而且不小 Engine 開始免費化了 ( 當然是有條件的... )，所以其實已經不愁沒有替代品。
最後也要說說，其實在使用 OGRE 配合自己的 Ogng3D 的這幾年間，因為 OGRE 的難以運用，確是從中學習到不少遊戲開發的事，雖然不能使用它來開發一個真正的遊戲 ( 其實曾經用過 Ogng3D 做過幾個遊戲 Prototype 呢... )，但也算是個不錯的經驗。
很多時候，人要在適當的時候放棄一些東西。這次使用 Engine 的事情，也不應再糾纏下去，狠心的切斷和 OGRE 的關係好了。
Subscribe to:
Posts (Atom)
