Archive for the ‘程設’ Category.

線上日式文字冒險遊戲平台

在歐美國家,雖然宅人口不比日本,但是宅人達力卻也跟日本不分軒輊,Ren’Py 這個開發已久的 AVG 引擎就是歐美人士開發的。它的製作人最近在網路上寫了篇有關於可下載 vs 網路遊玩的遊戲的文章,讀了以後才發現,最近因為 AJAX 技術的進步,所以歐美出現了好多新的日式文字冒險遊戲網路平台。在這些平台上,無論是創作者要撰寫故事,或者玩家要體驗遊戲,都是透過網頁遊覽器來完成。

BASS AVG 遊戲製作平台 vNovel Interactive NovelStream Datesim.org
創作者費用 免費(需用遊戲貨幣BM才能發表) 目前為展示用 免費遊戲免費
付費遊戲收取作品的 30% 收入
站方免費幫創作者移植既有的遊戲。
玩家費用 免費 免費 免費遊戲免費
付費遊戲按創作者規定收取費用
免費遊戲每個 0.5 美元,
積極參與該站的活動可免費遊玩。
編輯 採文字檔腳本方式編輯 目前為展示用 採用直覺式所見即所得的視覺方式編輯 無編輯環境,由站方移植遊戲
語音 支援 支援
存檔 自動讀取上次進度 支援 支援

將網頁作為遊戲的平台有許多好處,比如說:

  1. 有收費機制的平台可以有效阻礙盜版。
  2. 多人編輯與合作可透過網路完成,減少難度。
  3. 因為只需要上網就能玩,再一步縮短與一般大眾的距離,增加淺在客群。

不過 Ren’Py 的製作人認為,網路遊戲平台的缺點也不少:

  1. 無法下載所以無法備份,要是平台垮了,那麼這些創作就從此消失。
  2. 除非平台很佛心有開放原始碼,不然在未來,也不能經由模擬器等方式讓遊戲能繼續可玩。

不過這些問題也是有些解決之道,比如說開放讓創作者下載備份檔,以及額外開發備份檔的單機播放程式。不過就算是解決了這些問題,最主要的還是在於玩家們的意願。有個創作者 Ayu 舉辦了一個網路投票,結果是絕大多數的人還是比較喜歡能下載的單機板遊戲。也許是因為有個可以保存的實體才讓我們有值得花錢的感覺吧。

在我看來,NovelStream 是裡面最成熟的一個平台,不但外觀好看又專業,而且腳本編輯器也比一般的 AVG 引擎還要友善好多,更別說是許多其他的功能(遊戲腳本版本控制、語音與讀檔功能、友善的討論社群環境)。而 vNovel Interactive 雖然目前只是展示用,但是其遊戲體驗也因流暢的圖片轉換還有語音給我很大的好感。

BASS則是讓我有些遺憾,因為這個平台算是最早出現的(三年前就有了),而且還是台灣人開發的,可惜介面沒有繼續發展,而使用客群也沒有複雜化。

這些平台都不是日本人開發的,也許網路這一塊還是日本海外發展的比較蓬勃。我比較推薦的兩個遊戲,一款是 Narcissu ,是幾年前有名的免費同人電子小說。第二個則是 Ripples,一款英文同人團體製作並配音的電子小說。兩者的完成度都很高,效果也不輸給 Flash。也許這些平台真的是未來同人遊戲的一種可能性。

Uniform Renamer 檔案更名整理器

看著下載資料夾裡的檔案漸漸增加,但是他們的檔名格式又參差不齊,你是否有種衝動想要找天好好把它們分門歸類,但是又覺得寸金難買吋光陰。又或者你辛苦的整理了,最後卻有著浪費時間的空虛感?請試試看這款檔名整理器,本軟體希望能幫助大家省下一半的整理時間。

本軟體的主要功能是整理資料夾與壓縮檔的檔名,而不是為同一套檔案更名編號,這是跟其他更名軟體不一樣的地方。

下載 UniformRenamer(0825更新:提高程式效率)

Photobucket

使用教學

本軟體的使用步驟如下:

  1. 編寫重新命名的方法(上半邊視窗),或者下載別人的來用。
  2. 選擇要批次大量重新命名的資料夾(下半邊視窗)。
  3. 按按鈕預覽新的命名。
  4. 選擇要修改的檔案後,按「更改選取檔案名稱」批次一起命名。

建立更名規則

更名規則是一連串更改檔名的步驟。檔名整理器依順序執行每個步驟後,就能把舊檔名轉換成新檔名。

舊檔名 –> 步驟1 刪除XXX –> 步驟2 替換 XXX –> 步驟3 複製 XXX –> 新檔名

更名規則的第一行是命名格式,也就是新檔名的格式。在執行步驟的時候,舊檔名的資訊就會轉移到新檔名上。
更名規則的第二行以後每一行都是一個步驟。步驟有三種:刪除、替換以及複製。

範例

在這個範例中,我要把以下左邊的檔名轉換成右邊的檔名。

(一般コミック) (漢化) [田中太郎] 世界末日 第01巻  –> [田中太郎] 世界末日 – 1 [中]

要套用的更名如下

<剩餘檔名> - <集數> <中文>
delete	(一般コミック)
replace	<中文>	[中]	(繁體)	[漢化]
copy	<集數>	* 第0?(\d*)巻
copy	<剩餘檔名>	* (.*)

第一行是新檔名格式。你會發現這裡面的項目對應到之後的步驟,比如說<中文>就對應到第三行。
這些步驟會把資料從舊檔名轉移到新檔名中對應到的位置。

有了新檔名格式後,就要分別指定各個步驟。以下是三種步驟的的用途及欄位說明,欄位與欄位要有 tab 作分隔。

規則表的第二行是「刪除」,能把不要的文字從舊檔名刪除,讓檔名更好處理。欄位說明如下:

delete 要從舊檔名刪除的文字,可用正規式,要多個可用 tab 分隔
delete (一般コミック)

可以在 delete 步驟中設定數個要刪除的文字,只要用 tab 分隔即可。

規則表的第三行是「替代」,欄位說明如下:

replace 名稱
由使用者自行命名
對應到新檔名格式中。
是替換後的文字 要替換的目標,可用正規式,要多個可用 tab 分隔
replace <中文> [中] (繁體) [漢化]

範例中的這項規則能夠偵測有沒有「(漢化)」這個字樣,如果有的話,代表這檔案是中文的。於是「[中]」就會被放在新檔名格式中「<chinese>」的位置。

規則表的第四行是「複製」,通常搭配正規式(regular expression)來搜尋文字。欄位說明如下:

copy 名稱
由使用者自行命名
對應到新檔名格式中。
要複製的目標,可用正規式,要多個可用 tab 分隔
copy <集數> * 第0?(\d*)巻

範例中,我想要搜尋漫畫的集數,但是不想要原本檔名中一些累贅的字(第、0、)。
在這個例子中,我只想要 0 後面的數字,所以就用 (\d*) 把該數字抓出來,放在新檔名格式中「<集數>」的位置。
在本軟體中,正規式的前面要加上 "* ",以便與一般文字作區隔。
之前的刪除與替代中的搜尋目標也能使用正規式。

最後一行也是個複製規則,把所有剩下來的東西放進新檔名格式中「<剩餘檔名>」的位置。在正規式中,
「(.*)」即是代表選取全部的字元(即是剩下來的舊檔名)。

相信透過這三種規則的組合,以及正規式的威力,就能夠做出你想要的各種檔名,節省手動更名的時間。

以下是目前我的規則檔,各位可以複製貼上試試看。

<reg_remain><reg_vol><reg_vol2> <chinese><english>
delete	[comic]	[Comic]	[漫畫]
delete	(一般コミック)
delete	[PNG]
delete	* \[全.冊\]	* \(全\d*集\)
delete	* \[\d*p\]	* \(全\d*集\)

replace	<chinese>	[C]	* (\[中.\])	(繁體)	[BIG5]
replace	<english>	[E]	(英)

copy	<reg_vol>	* 第0?(\d*)巻
copy	<reg_vol2>	* \[?[Vv]ol.0?(\d*)\]?
copy	<reg_delete>	* \[\d*p\]

copy	<reg_remain>	* (.*)

結尾

本程式目前沒有經過嚴密測試,如有出錯請多多包涵,謝謝使用也請多多提供意見,不管是說明檔(我覺得這份就寫得很爛),規則的建立方法,甚至你想要更改程式(還蠻想試試看多人的Open Source的感覺)等等都行。

謝謝大家提供的名字,最後我決定使用 Uniform Renamer 這個很保守的名字 :)

目前我想不出好的程式名稱,所以在此徵求程式命名。目前募集到的名字有:

  • Re2
  • Magic Renamer
  • Renamer Renamer
  • Renamer Zombie
  • iRenamer
  • Renaman
  • Chat Renamer
  • Standardize Renamer
  • Unify Renamer / uRenamer
  • Reg Renamer
  • AutoChange ComicNamer
剩下

程式設計師對於人名的錯誤認知

在這一篇文章 Falsehoods Programmers Believe About Names: MicroISV on a Shoestring 提到了程式設計師對於名字所保持的錯誤認知,我覺得很有趣,簡單的翻譯了各點。這張清單有些玩笑,也有些項目是使用西歐語系的人們才會有的問題。

  1. 每個人都只有一個正式的名字
  2. 每個人都只使用一個名字
  3. 每個人,在這個時間點,只有一個正式的名字
  4. 每個人,在這個時間點,只有使用一個名字
  5. 每個人有正好 N 個名字(N可以是任何數量)
  6. 每個人的名字都能放進某個訂定數量的空位中
  7. 每個人的名字都不會改變
  8. 每個人的名字雖然會變,但是只會在特別的一些時候時會變。
  9. 每個人的名字都是用 ASCII 編碼寫的。
  10. 每個人的名字都是只由一個編碼寫的。
  11. 每個人的名字都能對應到 Unicode 字元
  12. 人名是有區分(英文)大小寫。
  13. 人名沒有區分(英文)大小寫。
  14. 有些人的名字有前綴或後綴,但是你能夠安全地忽略這些。
  15. 人名不會含有數目字
  16. 人名不會全都是(英文)大寫
  17. 人名不會全都是(英文)小寫
  18. 人名可以排序。所有系統只要使用一樣的排序方法排同批名字,就會得到相同的排序結果。
  19. 每個人的姓跟名必須是不同的。
  20. 每個人與親戚都使用一樣姓氏。
  21. 每個人的人名都是獨一無二的。
  22. 每個人的人名幾乎都是獨一無二的。
  23. 好吧但是人名應該夠多元,所以不會有百萬個人同用一個名字。
  24. 我的系統永遠不用管中國來的名字。
  25. 或者是日本名字。
  26. 或是韓國名字。
  27. 或者是愛爾蘭,英國,美國,西班牙,墨西哥,巴西,秘魯,俄國,瑞典,波札那,南非,千里達,海地,法國,或者是克林貢帝國。這些都有常見卻奇特的命名方式。
  28. 那個克林貢帝國只是個玩笑對吧?
  29. 你那該死的文化相對論!在我的社會中,人們至少同意了一套名命標準。
  30. 世界上有個能夠無損地把名字轉換後再反轉回來的演算法。(對,只要你的演算法能傳回輸入值。你得一顆星星。)
  31. 我可以安全地假設這本髒話字典中不包涵任何人的名字。
  32. 每個人的名字都是出生時拿到的。
  33. OK,也許不是出生時,但至少很接近出生時。
  34. 好啦,好啦,在出生後一年內。
  35. 五年內?
  36. 你在開玩笑,對吧?
  37. 當兩個不同的系統有同一人的資料時,會用這個人的同一個名字。
  38. 在一個設計優良的系統中,兩個不同的資料輸入端拿到一個人的名字時,一定會輸入在位元上都相同的字串。
  39. 那些名字能把我系統弄壞的人是奇怪的異類。他們應該有個像是「田中太郎」一樣可接受的名字。(譯註:這是在英文句子裡插入日文的常用名字,反而變得不常用)
  40. 每個人都有名字。

之後的回應還加了幾條:

  • 人名不會含有標點符號
  • 人名不會含有除了單引號外的標點符號
  • 每個人在不同國家的名字都一樣
  • 每個人只能有一個社會地位稱謂(在德國,有兩個學位的人會用兩個 Dr 表示)
  • 每個人都有姓跟名
  • 名字一定有兩個字母以上

還有一些奇怪名字的人

在 Slashdot 上的討論中,有幾個人提到了解決的方法:不要把名字特別區分為姓跟名分開來儲存,而是讓使用者直接輸入完整的姓名,存在一個 Unicode 的文字欄位中。此外也提供另一個文字欄位,讓使用者輸入他的日常生活常用名。而系統可以在法律需要時使用完整姓名,而在一般問候時使用常用名稱。

雖然這張清單有很多都是極端的例子,不過我覺得最重要的,還是「人名不會含有除了單引號外的標點符號」這條。有像是 O’Raily 之類名字的人,常常會因為 SQL injection 的因故,而不能在網站上使用自己正確的名字。程式設計師在處理姓名時,還是應該使用正確的方式好好處理標點符號,而不是直接把他們拒絕掉。

山窮水盡疑無路

這幾天,我一直在嘗試著寫一個簡單的程式,能夠在解壓縮 7Zip 中的 BMP 時順便將之轉成 JPG。在記憶體中作轉換可以有效節省硬碟讀取次數跟所需的硬碟空間。在各種嘗試下的抵達了終點,可是才發現有個很重要的問題無法解決,所有心血算是白費了。

我首先是想直接修改 7Zip 本身,不過自己身為 C++ 的新手,實在無法瞭解要怎樣才能修改。而想嘗試使用 7z.dll ,卻無法理解 dll 要怎樣使用。最後連 LZMA 的 source 都看過了,還是覺得霧煞煞。幸好偶然發現有個叫做 C# (.NET) Interface for 7-Zip Archive DLLs ,之後更發現了繼承其精神的 SevenZipSharp ,讓工程大有突破。

在研究 SevenZipSharp 以後,我決定還是使用 C# 來當開發的工具。C#就像是 Java ,提供了很完整的資料庫,開發小型的圖形化程式十分方便。終於,克服了重重 bugs ,終於開發出了能夠解壓縮 bmp 又順便轉換成 jpg 的程式。

可惜的是,當我測試某個有 1000 張 bmp 的 7z 檔案時,發現解壓縮需要好幾個小時。這才發現,原來我使用的這個 ExtractFile 函式,因為一次只會解壓縮一個檔案,而因為 7Z 是種 solid 壓縮檔,所以解壓縮一個檔案就必須把這個檔案之前的所有檔案都算一遍。原本解壓縮時 7Zip 有最佳化,會依序解壓縮並保持計算過的進度,所以時間上不會很緩慢,但是這個 SevenZipSharp 的 API 沒有作到這麼完善,等於說解壓縮這個測試檔就要花 500 倍的時間。而要修改 API 本身對我來說還是太困難,所以自己的心血算是白費了。

唉,實在是山窮水盡疑無路,目前的柳暗花明又一村還遙遙無期。

Speex – 一個專門為語音設計的檔案格式

Speex 是一種專門設計來紀錄語音的檔案格式,在壓縮語音這方面,會比 Ogg Vorbis 還要好上二到四倍,所以 Speex 非常適合用在遊戲的語音上。它是一種開源的自由軟體,所以不用付授權費即可使用。

Speex 的官方網站在 http://www.speex.org/ ,上面有提供命令列的編碼與解碼器。不過 http://www.rarewares.org/others.php 有提供一個叫做 Speexdrop 的視窗程式,能讓一般的使用者也能直接把 wave 檔案拖到這個程式視窗中來進行轉換。

雖然 Speex 是設計接受 8kHz 16kHz 還有 32 kHz 的輸入檔案的,但是我發覺一般的語音要是變成 32kHz 會讓很多高音的感覺消失,感覺變得鈍鈍的。所以我還是不做任何處理就把 Wav 丟給 Speex 處理。目前能用 Foobar2000 直接播放 Speex 檔案。

這裡可以下載語音測試檔,有 Wav, Ogg Vorbis 還有 Speex 檔案,我把設定調到讓產生的 Ogg Vorbis 跟 Speex 檔案大小大約一樣,各位可以自己聽聽看有何不同。

使用 Speex ,製作少於 200MB 的語音 AVG 再也不成問題。

My guidelines for using tags/categories, and a proposal to a new tag system

I often become confused when I publish a post on WordPress, because it offers both the tagging and categorising. Some of the confusion are caused by the two functionalities having overlapping areas, and some related to the lack of functionality. Overtime I came up with a few guielines to avoid some of these confusion, but not all of them. I want to list those rules first, and then I want to talk about a new system and explain how it can solve the rest of the problems.

First, both categories and tags offer the reader an easier way to search your writings. A review about a particular episode of an animation series may not have the word ‘animation’ in it, but tagging / categorising allows the users to search for all writing related to this topic.

Since one article can belong to multiple categories, the distinction between the current tags and categories is only that categories can have parent-child relationships. This relationship is best applied to chronological ordering (2009 series -> autumn series). A good thing about this relationship is that selecting a parent category will show all the entries in the child categories. This offers a control of granularity for the grouping of posts. Usually I won’t have too many layers of categories. Keeping it at the minimum makes the site map easier to digest, and the category section on the side bar will not be cluttered (which in term decreases the usability).

Tagging is less restrictive to users, which means it can vary greatly to the same writer even in different period of time. I am not a believer in tag clouds. because I loses my focus when I see a sea of links, most of which are seldom used/ less meaningful. I think tagging is more suited for adding keywords. I use it as the source for generating keyword meta tags.

In essence, category gives the reader a general idea of your blog (what kind of writing there are, what is the site structure). It makes it easier for one to navigate through your site. Tags on the otherhand allows users to access your article using external search engines.

However, these guidelines sill cannot fully resolve the following questions. For example:

  • Deciding if one label is more appropriate as a tag or as a category
  • Worrying if the synonyms should be included as a tag
  • Worrying if the category section becomes bloated when adding new sections.

I thought about these question for a while, and came up with a solution. The new system I am proposing will have the table structure like the following (this is only a prototype):

Tag table:
tag(pk)

TagRelation table:
subjectTag(pk fk)
objectTag(pk fk)
relationship(pk)

Category table:
category(pk)

TagCategory
category(pk fk)
tag(pk)

First, even when I use the guidelines I mentioned above, at times it can still be difficult to decide what should be a tag, what should be a category. This can be eliminated by only allow users to enter the tags. You may want to ask: "then how can I categorise posts?" The answer is, the software will do it for you. For example, one can associate the tag "Gundam" with the category "Animation I watched". In another word, category now is dependent on tags. This means the user no longer chooses the category for each writing directly, but when tags are applied the writing will also be categorised automatically. A few good thing about this are: categories can be associate with multiple tags; the user can have a more personalised category name like "My Jukebox".

This model allows relationships other than the parent-child relationship. This is good for future extension. For example, why not add a "part of" relationship which is more flexible than the parent-child relationship (the ability to have more than one parent so to say)? We can say "Final Fantasy" is part of "SqureEnix" company, but is also part of "RPG".

Often I am feel that one particular key word is not adequate, and its synonyms are needed as well. For example I add "Final Fantasy", "FF" and even the title in Japanese as the tags, because even I use these as search terms interchangeably as well. Adding those one by one everytime can be tiring, and having those all listed in the post is messy. But if we allow the "synonym" relationship, we can just choose "FF", and the post will still be automatically be linked to the "Final Fantasy" tag.

More freedom should be given to the user on organising the categories. In this system the user can set up rules to link categories to the tags. Other than that, I think it will be useful to allow users to choose which categories to display on the side menu. This way the user will not fear that a new category will make the side menu more bloated, but instead only list out the important sections. Additional functionalities can also be offered for the visitors to drill down to see further sub categories. The same goes to tags. The user should be able to set which tags can appear in the tag cloud. Having too many items in the tag cloud can never be a good thing.