電腦遊戲製作開發設計論壇

[還是零分]

今年開始的專案
http://github.com/ToyAuthor/ToyBox

我一個library寫久了會覺得程式架構有著無藥救的缺陷
此時就會重開一個專案了
這個ToyBox是第三個
因為要重新檢討去支持Unicode才寫的
目前沒什麼實用性可言(什麼也畫不出來)
都在寫一些很基本的小工具

希望可以用這個小專案跟大家做討論
不要再閉門造車

[還是零分]

目前只考量2D繪圖
畢竟2D都搞不好是不可能去碰3D的
現在我對繪圖技術不怎麼感興趣
對於lua、zlib、FreeType等工具比較想學
音效跟網路的建立要延後了
過去寫的東西可能要重學了

繪圖還是靠OpenGL
反正上Linux還是要用它
只是用到的只會是非常基礎的部分(也許連glew都不必用)
不想在上面再多花任何時間了
可能用VC++6.0這老爺車都還編得動吧...

我並不是希望寫出一個真的可用的工具
比較像是提供一個可以討論的範例
有著簡單的工具、簡約的API
用它來探討Unicode該怎麼全面實施、CMake還有什麼密技可用
配合Visual C++、Eclipse、CodeBlocks可以搞出什麼？
繪圖管理或遊戲UI適合什麼設計模式

還請請各位多多指教

[yag]

遊戲引擎製作什麼的，太高大上了，想在台灣找到討論的人可不容易
尤其是現在都轉做手遊了，改用unity的人一堆
想再找個有興趣自製pc遊戲引擎的太難了

[還是零分]

要找到討論的人向來不容易
大家目標都不盡相同

但是總是比我獨自研究來的好
期望能留下一些東西
反正也不會有什麼損失

也不要想成遊戲引擎就好了
這只是幾個小專案湊一起而已

所以這專案並不是筆直朝著遊戲目標前進
而是探討一些大多C++專案都用得到的知識
(還是這專案有用到的東西早就是大家開發環境的基本配備了？)

至於手機遊戲
那個是因為有商機的緣故吧？
只是做好玩的會想挑戰手機嗎？
說不定以後遊戲只要能在Linux上面運行就保證能移到手機上呢

[撲殺兔]

零分大大你的專案我建不起來，我看編譯選項的 -Wall 有開，
這樣所有 void* 到 toy::ptr_t 的轉型都會出錯。

因為我 CMAKE 沒用過，安裝完CMAKE會有附帶的 cmake-gui。
我是用它直接按 configure=>generate 出一個 codeblocks 專案。

但產生出的專案跟平常的 codeblocks 專案比起來在 project build option 那
沒有找到可以設定的編譯選項，所以不知道你的情況是如何呢?

[還是零分]

編譯選項這件事我不會在IDE上面做設定了
-Wall寫在 ToyBox/cmake/ToyTools.cmake 裡面

我是覺得跟-Wall沒關係啦
我放上去Github的是至少編譯OK才上傳的

void* 跟 toy::ptr_t 之間的轉型問題也許是因為你的電腦是64bit?

我目前都只在32bit上面寫程式
64bit上面應該會出問題

專案跟目錄下的development environment.txt寫了我的開發環境

在64bit電腦上應該把
typedef u32 ptr_t;
寫成
typedef unsigned __int64 ptr_t;


不過"__int64"是Visual Studio的
MinGW可能要用<inttypes.h>裡的"uint64_t"

[撲殺兔]

感謝!沒看到原來code裡面有註解，耍蠢了......。
我後來直接用uint64_t來代替就可以了。小弟目前為止還是以了解opengl怎麼實作為主，所以大大的code是我以後才需要碰到的部分。
不過對記憶體管理有興趣的人來說Manager01.hpp這個可以多看一下，如何減少記憶體的fragment。
unicode顯示的部分我在目前的工作它還是用字圖的方法在呈現，不知道是因為PS3平台還是因為code老舊(系列作的關係，架構一直沿用)。但是在PC平台就不是這種做法，所以要另請其他高手幫忙了。
還是希望ToyBox可以有更多人參與啦，畢竟國內這種類型的open source也不多了。

[MakeDream]

我是覺得可以往Ogre3D發展，它的討論資源目前是OpenSource界最多的，也跨所有平台，幾乎所有的疑難顇症，都可以在這裡http://www.ogre3d.org/forums/找到答案。我算是台灣Ogre引擎的推廣者之一吧XD，這是我研發遊戲引擎的網誌https://www.blogger.com/home，最近因為轉換工作，而公司又是用Cocos2d，所以更新有點慢，觀迎對研發遊戲引擎有興趣的人來指教，希望能有更多的同好加入研發跨平台遊戲引擎的行列。

[還是零分]

在我剛到這裡註冊時就有試著去學Ogre了，然後立刻被它的範例難倒了，現在的話會覺得這些遊戲引擎的範例都算和藹可親了，因為在工作上看到的程式碼大多很亂沒有頭緒。

站長說的沒錯，現在沒什麼人想寫引擎了，Ogre是把繪圖部分搞定了，但是跟現在檯面上的方便工具相比，使用Ogre依然像個苦行僧一般(寫Direct3D的則是差不多該圓寂了)。

前陣子我在努力試著用純C++來寫android程式，想要讓ndk融入CMake體系中，始終沒能搞定，感覺只差一點點了，但就是障礙重重，結果剛剛用新認識的corona玩看看...

沒道理啊!用這寫遊戲居然這麼簡單!!!

使用者寫lua程式碼就好，跨平台小case，編譯器在雲端，開發環境沒什麼特別需要準備的，居然簡單成這樣，看著手機上的範例程式正常的運作，不知道該怎麼講，我還是專心把我的小玩具寫好吧，別將時間花在跟開發環境的周旋上面了，也不想追工作上用不到的新技術了。

[MakeDream]

我覺得引擎分成遊戲引擎及成像引擎，Unity及UDK則是兩者合而為一，但我個人認為，遊戲引擎是不容易被統一架構的，如果硬要說可以，那只能說它適合一種類型的遊戲（比方udk要做fps很容易，架構都剛好允合，而unity則適合直接拿來寫第三人稱的動作遊戲，其他的就不一定適合）。比方我之前有拿udk做動作遊戲，很快，而且是鍵盤操作及滑鼠，更快，但如拿來做麻將的話，就麻煩了，因為udk只讓你寫script，而且io事件都包好了，如果要拿來直接用的話，你就必須寫在onfire這個事件，如果你要custom自己的事件的話，我覺得還不如直接hand direct input事件更快，因為弄懂他的事件分派流程及還要按照他的步驟處理，更花時間。我覺得unity就算script的部份比較自由，但你如果有任何客製化的需求，就麻煩了，follow它的步驟往往比直接touch原生來得更麻煩，比方要客製化它的plugin，流程及步驟就不知道要多多少。

我個人覺得Ogre的問題，在於工具這個部份，對我來說開發工具不是什麼問題（BCG+MFC可以快速開發很多不輸專商業品質的工具），重點是這個成像引擎的架構、彈性、效能，更重要的是它有廣大的討論資源。

使用Ogre也許起步比較慢，但等到能掌握之後，我覺得開發速度不一定會比unity之類的引擎慢，原因是當專案最後整合的時候，往往會有需要調整架構及對應市場的變化需求，而follow已經定得比較死的框架，就麻煩了（比方gles的shader code很容易就可以自己客製化一個，但在unity就得follow它所訂義使用shader的流程…），除非你想你的遊戲都不改，就算你能從store上找到覺得適合的套件，但仍需付出是否能良好整合其他系統的成本。

總之我覺得遊戲引擎還是自己做比較適合，因為它是跟專案的架構走，不容易被標準化。

[還是零分]

@MakeDream
這些工具向來都是這麼回事
越方便簡單就越死板
自由度越高就越難駕馭

你則是因為需要高自由度才對Ogre特別青睞
Ogre擁有廣大的討論人數的確是重要的優勢
當我不想碰底層繪圖時就會找Ogre了