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。也許這些平台真的是未來同人遊戲的一種可能性。

ATOM 格式推廣

常常逛 Blog 的人應該都知道訂閱這種方便的功能。只要訂閱了該 Blog 的 RSS ,就能知道在 Blog 更新的狀況。當你訂閱多個 Blog 的時候,訂閱器就會摘要式的告訴你最近哪個 Blog 有更新了,免去你花時間一一拜訪每個 Blog。不過 RSS 這種格式缺點不少,對於程式設計師來說,已經有更好的替代品,那就是最新發展的 Atom 格式。

RSS 的發展歷史 有些複雜。在開發的過程中, RSS 出現了兩個分支, 2.0 版本是從 0.91 版本來的,但目前被凍結了。1.0 版本則是繼續改進中,是從 0.90 版本來的。不過各版本都有不同程度的相容問題。

ATOM 的設計參考了 RSS 本身的一些缺點:

內文的格式

RSS 並沒有特別訂定內文該用什麼格式,或者是各種格式要怎麼區分。你可以放純文字,也可以放像是 <img> 這種已經編碼過的 html ,又或者是把 html 放在 CDATA 裡面。可是,閱讀器沒有辦法知道你到底是放了哪種東西,而必須自己猜測原文的格式到底是什麼。

而 ATOM 則提供了 type 這個屬性,指定內文到底是 "text", "html" 還是 "xhtml" 。要是使用 xhtml ,不但不用費心地把整段html的 < 改成 &lt; ,而閱讀器也能更加容易地運用內文的資料。要知道,網頁的世界並不是只有 html ,還有像是 Microformat 以及 GData 等種種東西。這些使用 Xhtml 的格式要是得先經過編碼處理,肯定要發揮功用肯定更加困難。

格式本身的完善

RSS 沒有指定一個時間的表示格式,沒有自己的 schema,沒有使用 xml 本身的 lang 作為語言的標示。這些都在 ATOM 中被改進了。其餘的還有 ATOM 可以連結到有 ASCII 以外的字集的 URI 資源。此外 ATOM 也有強制發布者給每個文章定一個獨立 ID ,以便能更簡單地追蹤更新的文章。

總而言之,ATOM在技術面上考量了許多 RSS 的缺點,並加以改進。使用 ATOM 只有好處沒有壞處,請各位 Blogger 以及研發人員有機會就用用看 ATOM 吧。

On RSS and Atom
Six Apart – Blog – Why We Need Echo
Atom vs RSS (ZT) – 王朝網絡 – wangchao.net.cn
东拉西扯:全文还是摘要 – 对牛乱弹琴 | Playin’ with IT – 洪波的偏见 | keso.me

兩個 Web BBS 比較,以及其未來。

最近又發現一個新的 Web BBS ,叫做 DISP.cc。這跟 Gaaan.com 一樣,是使用 AJAX 想用網頁模擬 telnet BBS 的討論區,提供一種鍵盤操作的介面。Gaaan 從 2006 年發展至今,漸漸失去活力,連開發專版也久久沒有新的文章。DISP.cc 則是表現出新軟體頻繁更新的熱血,很有可能搶去 Gaaan 的用戶群(雖然跟ptt來比,數量還是很少)。

以下就是我的比較表:

gaaan.com DISP.cc
重讀已讀文章
(從一篇文章離開後馬上再進入)
沒有延遲,靠本機快取 有延遲
RSS訂閱功能
入版畫面 有,而且比BBS豐富,可用特殊動態效果
可被搜索引擎搜索
精華區/分類/標籤 有(讀者自行標記任意標籤) 有(版主可建立樹狀分類,設定是否讓讀者自己標分類)
其他常見BBS功能 個人信箱
線上傳訊
與其他網站連動 轉收文章到 Hemidemi 以及 Del.icio.us 轉貼至 Plurk 以及 Facebook

GaaaN 從 2006 年發展到現在,一開始十分吸引大家的眼光,可是卻慢慢的失去人潮。原因應該還是在於:

Web BBS 把目標群眾放在喜歡用 BBS 的人上面,可是像是巴哈以及 ptt 已經很好用了,不但極快,有人氣,擁有歷史累積下來的寶貴資料,而且還有名氣。這樣十分完善的網路社群,使用者跳槽到 GaaaN 的好處沒有什麼。而對於不玩 BBS 的人來說, GaaaN 實在是無法使用,單靠滑鼠沒辦法做任何事,要是要上下查看主題或者是發表文章,都必須用鍵盤才行。

與其把操控方式做的完全跟 BBS 一樣,開發者反而應該試著把 BBS 的操作優點整合到一般的討論區軟體內,比如說更簡單大方的視覺風格,又或者加入鍵盤操控功能。還有其中最重要的,讓使用者有種即時互動的錯覺(像是巴哈的洽特版或者 ptt 的黑特版)。只要做出了這種感覺,那麼這個平台的吸引力馬上就會更上一層樓。

當然上面說的是個十分大的改變,要是只想在 Web BBS 本身做簡單的改進,我覺得可以:

  • 讓介面風格更像友善,比如說改變深色系的配色,或者不要用單獨一個登入畫面作為首頁。
    更好的就是偽裝的類似一般的討論區系統。
  • 讓各版有像是廣告活動,投票等等的機制炒熱氣氛。比如說可以在首頁放最新的活動等等。
  • 讓版主設定每個版的風格,像是背景圖案,字型,入版畫面等等。
    這樣才能讓每個版自己成為入口,拉進新人朝。
  • 讓不登入的人也能留言。
  • 讓人只靠滑鼠也能遊覽整個網站。
  • 分散式的架構,讓一般人也能在其他伺服器架設版面,不過這會需要開放程式碼就是了。

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.

Highlight table row in Firefox

When we surf the web, sometimes highlighting table rows on mouse hover makes life so much easier. I used to use GreaseMonkey to do the job, but recently I discovered the CSS’s equilvalent, which in theory should be a fraction of a second faster. The steps are simple but is only for Firefox.

Firstly install Stylish, which to CSS is like GreaseMonkey to Javascript. Then add the following style:

tr:hover{background-color:#FFFACD}

That’s about it. Configure further if you need to. I really hope the day when :hover is supported universally and I won’t have to touch Javascript for that (stop using IE6 dammit).

有時候如果能依靠滑鼠的位置把游標底下的表格列給反光起來,會讓使用更便利。原本我是使用 GreaseMonkey 來達成這個任務,不過最近我學到了使用一個感覺更加好的辦法。

首先,先下載 Stylish 。 Stylish 之於 CSS 就像是 GreaseMonkey 之於 Javascript 。然後加了以下這個樣式就好了。

tr:hover{background-color:#FFFACD}

就是這樣。希望有一天 :hover 會成為所有遊覽器都支援的樣式。請支持用比 IE6 要新的遊覽器。

分類與標籤、category & tag ,你迷惑了嗎?

這個週末把 WordPress 更新到 2.7 後,感覺動力大增,就搬了許多篇舊文章並把把不用的分類合併或是整理。

在 WordPress 上我能同時使用標籤以及類別。這兩種整理資料的方法其實有許多相近之處,所以從以前就常常會煩惱是不是用錯了。這個週末多花了幾天好好的想了想,歸納出一些粗略的法則。

在共同上,類別跟標籤其實都是用來讓客人能更容易搜尋想要看的文章的。一篇講關於動畫的文章可能裡面沒有「動畫」兩個字,所以要靠外部的標籤或是分類來讓客人容易搜尋。

其實因為同一篇文章能夠歸類在好幾個群組,所以群組跟標籤的差異就只剩下群組間能有子類別這種關係。這種類別關係最容易套用在時間上(2009新番–>秋季)。有子類別的好處是,客人來找文章的時候,選大群組就會自動包含小群組。所以要是你想要這樣子就可以套用類別。

傳統上類別不會分的太細,讓人能很容易瞭解整個網站內容的分類。要是太多列別,那麼放在選單上不但擁擠,也會因為眼花撩亂而降低實際的功效。說到這,我想順便提提自己對於 tag cloud (標籤雲)的感受。首先它很眼花撩亂,標籤數量多不提,要是不分行依照筆劃排列,又使用字體大小的分別,反而讓眼睛不知道該注意哪裡。第二、因為 blog 是給單一作者的使用平台,所以文章都是作者自己貼上標籤的,很多 tag 系統在多人網站上顯現的優點就沒有用武之地(像是統計分析之類)。最後,tag 由於十分隨性,所以許多 tag 可能讀者永遠都沒有興趣點選來看。

標籤在感覺上因為隨性,所以從以上的三點反向思考,怎樣都讓人有種 keyword 的感覺。我想把標籤當作關鍵詞系統用,算是個不錯的選擇吧。

所以目前暫時的結論是,類別應該注重於介紹讀者該網誌的內容好讓他們有個起始點能逛網站。而標籤該用於幫助讀者搜索(無論是站內或是搜索引擎)的結果更加精確。

其實,我們大可把類別當標籤使用,創造出幾百個類別一樣會變成另一個 tag cloud。這兩個功能真的十分近似,除了運用類別的父子關係之外,兩者都能互換使用。真正要作,這兩種東西應該就要結合在一起,更加 generalise ,並用一種新的方式呈現。舉例來說,除了父子關係以外,應該讓作者能夠自由地自訂新的關係。然後只呈現前幾大項或是有歸類的項目,也許能讓整個分類的功能更加自由易用。

延伸閱讀:
使用wordpress初步心得 + 分類與tag之間的異同