學校要的作品集，結果我只是用文字去重新描述一次而已…。(這樣是認真還不認真啊？)
很多檔案現在不是放在這台電腦上，很懶得去找，結果就變這樣了。(明明就說要找的…)
不然其實前面幾個不放張 screen-shot 還真說不太過去。
但我不管了。學校愛不愛，隨便他吧。
連結不做了，反正印出來也看不到，裡面又一堆是舊東西。
==
godfat 真常 作品集
由於我的作品多是電子檔，不易以紙本呈現，且數量眾多、四散各處、統整不易，是故
僅僅節錄部份，盼能以小見大，以偏見全。這裡將條列出幾個比較具有份量的項目，
再依照其項目稍微說明內容或是連帶提起其他相關小著作。
1. 逃離轟炸雞
這是大一上學期基礎程式設計的期末作品，完成度很低，不過已經可以概略看到其內容。
大抵上是一個轟炸超人（Bomberman）的模仿作，輔以一個網路上可以下載到的一個
小遊戲叫《N》，取 Ninja 的 N, 是一個橫向動作遊戲，有一點點解謎的味道，可能
有點早期紅白機（Famicom）上《七寶奇謀》的味道，以這個遊戲做參考增加一些變化。
與轟炸超人最大的差異在於，轟炸超人的地圖都是網狀的，奇數橫排全空，偶數橫排
第一格空，第二格障礙物，以此交錯著。在此種地圖下，爆炸的紋路一定會是十字的。
不過在本遊戲中，地圖不全然是這種模式，也有全空的。在這種地圖下，爆炸將會以
擴散的方式，形成一個全方向的爆炸紋路。除此之外，越接近爆炸中心點傷害力越高。
轟炸超人的設定是只要被炸到，就算是陣亡。但在《逃離轟炸雞》中，由於此種爆炸
模式並不容易閃躲，所以有生命力的設定，爆炸邊緣的傷害力是非常低，而中心則是
非常高。
本遊戲最困難的演算法就是在這個爆炸波紋的計算與產生的過程。轟炸超人的十字爆炸
是瞬間的，本遊戲中卻是依照時間逐漸往外擴散。這部份的演算法其實並不困難，但
本遊戲中最難搞定的部份應該也是在這了。另一部份則是關卡使用 XML 檔設定，而
Flash 讀入 XML 的方式有點繁瑣，這部份則是我花最多時間的地方。
至於背景設定，簡單來說就是有個每次都會到「雞村」抓一堆雞的大魔王，先是把
所有的雞關起來，然後依照某個順序一隻一隻宰來烹調。有一天，有一隻母雞終於
從地牢中逃了出來…。這隻母雞就是主角，主要武器是下蛋，蛋爆炸時會產生荷包蛋，
荷包蛋的蛋黃數量越多表示威力越大。最邊緣的荷包蛋是沒有蛋黃的。迷宮中會遭遇
到的敵人，一開始是打火機，碰到母雞時會不斷噴火，生命歸零時就會燒焦變成一道菜。
本遊戲除了動作外，也有一定的戰術意味，因為敵人有一定的行為模式，先算好的話，
可以不受到任何傷害輕易地過關。未來需要的是增加更多武器與敵人和地圖。
p.s. 後來因為多媒體設計概論這堂課的緣故，為此遊戲加做了一個片頭動畫。大致上
就是在描繪上面提到的背景設定。由於個人的美術能力極弱，所以此動畫可參考的部份
僅有腳本與分鏡等部份。詳細這裡就不多說明了。
2. Roly Poly
這是大二上學期多媒體程式設計的期末作品。雖然課堂上是講 Director, 不過事實上
Roly Poly 完全是由 Flash 寫成的，因為 Flash 很明顯比較好用。這東西不是遊戲，
只是一個像是螢幕保護裝置的畫面展示。用色彩不斷變化，且漸層的同心圓在畫面正
中央繞著一個軸心不斷轉動。另一方面，畫面邊緣則不斷有綠色與灰色的球（that's
Roly & Poly）噴出，一個會順著同心圓的轉動逐漸變小且落到螢幕正中央而消失，
另一個則會不斷追著滑鼠跑，同樣也是逐漸變小且越來越慢。碰到滑鼠則「波」一聲
消失。
背景音樂用 Falcom 的 Sound Team JDK 替 Gurumin 製作的 BGM,
TO MAKE THE END OF DIGGING（原文 digging 少一個 g, 為符合英文原則我補上了）
整首音樂風格也是不斷轉啊轉啊轉，藉由強大的節奏感與不斷起伏的旋律。
此外，還有一個小趣味，就是滑鼠點一下會大量放出 Roly & Poly, 滑鼠連點的話…
FPS 很容易會跟不上，某方面而言具有十足的快感（不斷撞到滑鼠而消失，波波聲不斷）
3. Java programming
大二下學期因 Java 程式設計課堂而接觸 Java language. 比較值得一提的是一個完全
依照 MVC 架構製作的生命遊戲（game of life），這是一個很有名的細胞自動機題目
（Cellular Automata），這裡就不描述這東西是什麼了。這個程式比較大的問題是，
由於我的細胞全部是用 swing 的 JButton 做的，所以執行效率非常非常之爛，爛到
幾乎可以說是完全沒辦法用，只能稍微看看感覺而已。但由於 MVC 切得相當不錯(自認),
所以這部份的效能要改進是沒有問題的，不需要動到太多東西。但想當然爾沒繼續做。
另一個則是跟別人合作的一個大系統，我負責的部份是由 applet 組成的 editor,
可以做文字與圖片的編排，支援 layer 與 layer compose.（不只是 merge）
大 bug 沒有，小問題其實不少。不過這是個最後宣告失敗的案子，所以小 bug 我也
沒有繼續修完。花了不少時間，可惜沒什麼成果，變成經驗值吸收掉了。
後來陸陸續續還有一些 Java 的小東西，不過沒什麼值得一提的。Java 不好玩，
玩到這裡大概就可以結束了。剩下的只有工作的部份，自我研究已經不用了。
4. codename: shooting cubes
這是大三上學期互動媒體系統概論與虛擬空間設計的期末作業。這不是個人作品，是
跟同學組小隊做出來的東西。現在將會擴展為畢製內容，所以實際上這東西的內容是
很多的。不過基本上，我負責的部份只有 C++ virtools SDK, 這是個極為難用的垃圾，
在上面吃到的苦頭已經太多了。由於內容設計本身不是我負責的，所以這部份就不談了。
整個程式的主要架構是我構思的，最早是寫在 Flash 中當一個 prototype. 後來把架構
移植到 C++ 中，這部份也沒有太多問題。只是一旦接上 virtools SDK, 情況就會變得
有點慘。其實也沒有太多好提的。另一方面，為了有更好的執行效能，我利用 boost 與
Loki 製作了一個 lib sw（尚未公開）, 目前主要的組件是 ObjectPool, 用來快速且
大量地產生 object 用的。後來也開發出幾種變形，像是利用執行效能去換取 gc 的能力
lib sw 中，還有各種 object pool 實作的效能比較，和 boost 本身的 object_pool 某
方面而言各有優劣。（但其實綜合比較下來，還是 boost 的強大得多，這點我承認）
接下來的部份都跟學校作業無關。
5. 網站 與 文章
雖然我對於 web programming 不熟，但我自己弄過的網站其實也還不少，雖然都是
很小的，或是臨時性的，大部份也沒什麼值得一提。比較值得一提的，恐怕都是以
內容為取向，跟整個網站設計的關係倒是不大。例如以 phpBB2 經營的討論社群，
還有現在相當流行的 weblog. 前者是一直有在玩，後者則是最近才開始在碰，恐怕
是因為還是對 forum 有很大的不捨吧。也因此，個人想要做一種網站，目標就是
forum + weblog + wiki 的形式。暫定使用 Ruby on Rails 實作，等到哪天心血來潮
時就會去試著做吧。
主要的概念是以 forum 為骨幹，加上 weblog 的表現形式與整理方式，還有 wiki 的
索引、搜尋、呈現模式。不是什麼了不起的東西，只是如果大部份的東西都能自己掌控，
能玩的方向是可以很多的。早期本來是想用 XOOPS 去改，我該說幸好沒去做嗎？以現在
的眼光來看，用 XOOPS 肯定是個極端愚蠢的行為。
至於前面提到的 phpBB2 與 weblog, 前者現在已經沒有太多公開的意義了。後者的話，
眼見被 google 收購的 blogspot/blogger 似乎滿好用的，於是在前一陣子開了一個
來玩，放置一些個人在各討論板發表過的文章。沒多久後，又受 thegiive 之邀進駐
他所經營的 Lighty RoR, 替 Ruby 或 Rails 撰文。現已發表過數篇文章。
星之一角 2.0
http://blog.godfat.idv.tw/
Lighty RoR 最簡潔有力的網頁框架
http://lightyror.thegiive.net/
前者的一些來由，可以參考這篇文章：
2007.03.02 開場白
http://blog.godfat.idv.tw/2007/03/only-test.html
還有這篇：
2007.03.03 why 2.0?
http://blog.godfat.idv.tw/2007/03/why-20.html
還有很多已發表和未發表的文章，就不轉貼到這裡了。
6. spellbook
這是一個設計到一半的格子戰略遊戲。相關文件網路上很多，這裡就不詳細說明，
只簡單轉貼一篇談地非常淺的簡單介紹：
what's spellbook?
簡單地說，這只不過是一個代號而已，一個在決定這款遊戲正式名稱前的代號。
就像是 Vista 的 code name 為 longhorn 一樣，Vista 這個名稱出來後，
longhorn 就有如功成身退般，成為一個歷史名詞。
回到起點，不過也不要太起點，我可不想從我三歲時開始講起，
那是一段漫長的故事…。所以就從 VM + MtG 開始說起吧。
何謂 VM + MtG? 簡單地說，他是這個遊戲最早的代號。
由於我個人喜歡戰略遊戲，又有那麼一點格子控，愛好自由組合、個人風格、
等等因素，所以我喜歡 VM 形式的遊戲，戰略與格子。
（嗯，當然，還有一點奇幻的風味，這也是重點之一，是吧？）
卡片遊戲，富含最小基本單位的組合風味，MtG 的自由牌組與戰略性搭配，
這兩者都成為我很喜歡的遊戲。
（嗯，當然，還有一點奇幻的風味，這也是重點之一，是吧？）
那麼，如果這兩者合併起來會是什麼樣子？其實我一開始並不是這樣想的。
只是，這樣說起來，似乎會比較容易讓人理解，呵呵。不過事實上呢，
spellbook 還是比較偏向 VM. 整個遊戲模式還是以 VM 為主，
只是加上一點 MtG 的味道在裡面。
會是這個樣子的理由是，我本來就只是想要改善 VM, 而非真正做出一個
VM + MtG 的東西。我覺得 VM 是個好遊戲，但他有太多不足了。
最讓人詬病的就是…地圖編輯器、群戰、replay, 等…嗯，不要在這裡發散怨念。
而既然要做了，當然是要做徹底一點，把所有我個人覺得「也許」會更有趣的東西，
都一併弄進去。
結果，就是 spellbook 了。雖然在還沒有這個名詞前，其實我也只有朦朧的概念。
在被慫恿之下，才漸漸把這整個概念完善（其實很多概念都是瞬間決定沒有經過
仔細思考的），並取個 code name, 希望能慢慢的把這樣東西做起來。
那麼，設計理念是什麼呢？其實就只是「組合與變化」。spellbook 裡所有東西的
設計原則，都是組合與變化。所以我將整個遊戲規則劃分為兩個部分，
一個叫核心規則 Core Rule, 另一個則叫擴充規則 Extension Rule. 核心規則
表示著不變的基本定律，就像是萬有引力一般。擴充規則則表示著可變動的玩法，
就像圓周運動是一種藉由基本力學，產生出的很特別的行為一樣。
玩家可以有很自由的搭配。不同的牌組（在 spellbook 中，就叫做魔法書）、
不同的幻魔使（精靈主、Master、Wizards）。而這些，全部可以由玩家自由設定。
比方說你喜歡一個高生命的主角，於是你可以利用剩餘的點數，讓生命力點高一點。
這些，是算在擴充規則中。而魔法書製作委員會會預先釋出一組核心設定 Core Set,
替玩家們定義出一組預設的擴充規則。這個 Core Set 會由魔法書製作委員會維護，
維護其正確性、平衡性、趣味性等。至於其他的擴充規則，可由玩家自行去定義，
放到網路上任由其他玩家自行下載，達到絕對的變化性。
最後，我個人也希望能夠釋出一組魔法書製作委員會所製作的劇本 Scenario.
這個劇本會描繪出 spellbook 本身的世界設定，也由淺入深教導玩家 spellbook
可以怎麼去玩。當然，劇本同時也屬於擴充規則的一部分，所以玩家也能夠自由
建造屬於自己的劇本…。
至於多人連線、群戰（預設劇本中就會出現）、replay、編輯器、
等這些一般玩家就能想到的東西，可能的話全部都會一併放在排程中製作。
以上，就是整個 spellbook 所希望達到的目標。也許有點過於理想化，
不過…這部份就保留吧 ^_^
2006.07.20 godfat 幻滅.真常
一些詳細資料可以參考：（我用 Ruby cgi 寫的簡單網站，借放在朋友空間）
http://ymcom.ym.edu.tw/~godfat/
更多詳細資料參考：（這在我電腦上，所以關機、沒網路或是離家時無法連上）
http://www.godfat.idv.tw/index.php?c=4
6. emuflickr
這是今年參加 Taiwan Hackathon 2007 時，我所參與的 RoR 組所做的東西。
主要的設計與構思是超級大師 lukhnos 提出的，大致上而言就是模擬 flickr 的
server, 做出一個 portable flickr emulation layer. 個人自然是幫不太上忙，
只稍微試出了 flickr 的 response 可能無法單以 json 的形式儲存，還是得存成 xml
形式的 data, 否則在回傳 rest 格式的 response 時，會發生某種程度的失真。
我的一些詳細敘述可以參考：
http://blog.godfat.idv.tw/2007/04/blog-post_21.html
專案首頁是：
http://code.google.com/p/emuflickr/
7. ludy project
這是最近的事。Ruby 確實是我很愛的程式語言，雖然我在 C++ 上所花的功夫比之 Ruby
實在多太多了，所以一開始是比較想寫 C++ library, 這也是上面提到的 lib sw 計劃。
可惜不可諱言的是，C++ 寫起來真的是很累，我也沒那麼多時間和精神慢慢去寫 lib.
這是 ludy 產生的原因之一。Ruby 程式寫起來，又快又簡潔，沒辦法寫 C++ lib 的怨念
就可以快速發散到 Ruby 身上。
所以這個 ludy project 繼承 lib sw 的精神－壹群的小組件－。在 emuflickr 中發現
svn 的好用，於是就到 rubyforge 申請了一個帳號，開了一個專案，使用 rubyforge 的
svn 協助開發。
首頁（還沒空寫一個漂亮的頁面）
http://ludy.rubyforge.org/
專案首頁
http://rubyforge.org/projects/ludy/
目前大概的目標是實作 functional programming 的 tool, 應該會照著 Haskell 的
programming style 來做，因為我覺得 Haskell 寫起來確實是很好玩的一件事。
不過 Haskell 的 type inference 和 type check 可能就有點勉強了，畢竟 Ruby 本來
就是 dynamic typing 的，硬要做成 static typing 應該很沒意義吧。這部份就再看看.
以上就大概提了七大項目，請明鑒。
2007.04.28 godfat 真常
