TGDF 2016: 第二天

7/1, 7/2 因緣際會的去了兩天的 2016 台北遊戲開發者論壇 (Taipei Game Developer Forum),雖然現在並沒有在開發遊戲,但兩天下來感覺相較於去技術意味濃厚的 conference ,收獲也是不少。

本系列文以簡單心得的方式做一些紀錄,免得以後忘光光了。一共分為兩天。

Indie MEGABOOTH: Best practices for showing your game to the public

講者: Kelly Wallick &
Christopher Floyd

這場主要就是在介紹 "Indie MEGABOOTH" 這個組織在幹嘛(他們也帶了一些遊戲來參加外面的 indie space),怎麼樣可以幫助獨立遊戲開發者們在遊戲展上認識自己的遊戲,如果有興趣要如何申請,審核的流程又是如何等等的...

創辦人說她一年玩 500 款遊戲 (WTF)

據他們的說法,MEGABOOTH 在大型遊戲展的租攤位大小是比 AAA 廠商還大的,最近一次好像展出了 80 款獨立遊戲 (80個小 booth)。

Cross platform VR development – Building for multiple platforms with Job Simulator

講者: Alex Schwartz

又是 VR 場,而且還是 keynote ~~~~

這場又有提到了昨天提到過的 90hz、Unity 等等,看來 Unity 確實是一時之選,疑似有支援講題中提到目前的三家主力 VR 廠商:

  • HTC Vive
  • Oculus Rift
  • PS VR

這場講題本身有 focus 在多平台之間產生的問題,發現把上面這三家攤在檯面上一比就知道 HTC Vive 看起來真的戰力超群。

感覺 VR 互動是一個重要的課題,然而 Oculus Rift 或 PS VR 在這方面的限制讓它們的遊戲類型可能會有所限制(或著遊戲在此平台被迫限制)。

控制器的部分三個平台都差不多,所以可以透過他們自己加掛的 library (OwlchemyVR) 很好的抽象化掉;然而控制器的位置 tracking 在不同平台的限制卻非常惱人 www

有興趣深入了解一下的話可以看一下這段影片,TGDF 本身應該是沒有錄影,這是之前同主題在別的地方的 talk,篇幅比較短一點的版本。

另外印象比較深的是QA階段有人提問「如果因為效能的問題需要在 90fps 以及 8x MSAA 之間做取捨,你會怎麼選擇?」,講者表示 __當然是會犧牲反鋸齒,不過如果有第三個選項,他寧可減少畫面上的物件數,也要盡可能保持 90fps + 8x MSAA。

相關的 performance 部分可以看這段

Flying by the Seat of Our Pants

講者: Raj Joshi

這場感覺講者之前的經歷非常厲害,待過各種大型遊戲公司,又學了非常多東西。

在過去 15 年間,Raj Joshi 曾從事派拉蒙影業、索尼影業的電影美術,以及遊戲公司動視、美商藝電與 Double Helix 的遊戲監製與製作人等工作

他疑似覺得膩了之後,受到一個之前認識的朋友邀請,賣掉家產(?)加入現在的獨立遊戲工作室,擔任一款新遊戲《GALAK-Z》的總監。

總之,就是談談各種中間碰到的慘事,以及最後如何熬過來,成功讓遊戲發行了。

口條非常之清晰,也偶爾會穿插一些笑點,不愧是總監。

話說他們的工作室預計是要 base 在大阪,似乎是因為創辦人娶了日本太太 www
他們整個 team 好像都是西方人啊~~~

傳遞感動怎麼可以這麼難?─《OPUS 地球計畫》的開發與發行經驗分享

講者: 李思毅

最近比較有名(連我都聽過的意思)的一款台灣製獨立遊戲,這場超滿的!

這款遊戲從構想初期就以傳遞感動為訴求,會選擇天文主題也是由於想要在設定上給予一種浩瀚 vs 渺小的感覺。

不過後來根據各種市場調查,感覺重點應該還是要有好的故事 XD

少見的開發時間比較短的遊戲(半年),其他場往往都是不小心就又多做了一年...

最認同的部分是「認真做一款遊戲,帶給玩家 2 小時的感動體驗,而不要求營運/課金」的精神。

《說劍》開發始末

講者: 陳禮國

講者很愛看武俠小說,一直夢想要做一款武俠遊戲,能夠傳達那種武俠的精神,最後在各種精煉下做出了這款《說劍》。

精煉的過程大概是這樣: 武俠 -> 刀劍 -> 手勢體驗

而劇情則是小說式的精煉: 劇情 -> 插圖 + 文字 -> 玩家自行腦補

看完遊戲玩法確實能夠感受到「武俠」的精神在裡面,非常厲害。

有興趣可以看一下介紹影片: https://www.youtube.com/watch?v=tDGEzNMqma8

系列文後記

這兩天都早起,前往會場的路上,一度微微感覺後悔接受友人的邀約(X)。不過事實證明我錯了,覺得兩天下來有充分的感受到「想做遊戲」的能量,有一種神祕的充電感(雖然我不做遊戲啦)。

我想說的是

有對遊戲充滿熱情的各位真是太好了。

那麼最後我們就來聽一首「廁所女神」吧!

TGDF 2016: 第一天

7/1, 7/2 因緣際會的去了兩天的 2016 台北遊戲開發者論壇 (Taipei Game Developer Forum),雖然現在並沒有在開發遊戲,但兩天下來感覺相較於去技術意味濃厚的 conference ,收獲也是不少。

本系列文以簡單心得的方式做一些紀錄,免得以後忘光光了。一共分為兩天。

「矛與盾」-獨立團隊自研與自營運間的拉扯

講者: 吳以尋

講的是「境界之詩」這款遊戲從製作、發行到營運碰到的問題,以及各種的掙扎。

令人眼睛為之一亮的點在,他們營運時選擇了比較細水長流的做法,而不是快速的把玩家榨乾(活動推到某個營業額就不再推活動)。並且也已經上線營運了一年左右的時間,難能可貴!

註: 其實現場大部分的遊戲都不是 in-app purchase 的營運向,所以「境界之詩」算是整個 TGDF 2016 中十分少見

Working with Google Play in an Evolving Ecosystem

講者: Kevin Chiao

看起來是贊助商的 Keynote,主要介紹 Google Play 各種充滿戰力的功能。

整個聽他介紹完覺得 Google Play 還真的是有夠用心,現在的 Google Play console 真是讓我大開眼界。

最有趣的是 A/B test 的功能示範了幾家公司測試 App icon 的成果,下載量實在提升太多了 ww

講者的中文腔調超重,我跟同行友人一致覺得他不如直接講英文,大家聽了比較舒暢。

Design and Emotions of VR Experiences

講者: Eddie Lee

主要是在講如何提升 VR 互動的層次。

講者是獨立遊戲工作室 Funktronic Labs 的創辦人,感覺對 VR 互動非常有研究,不過 VR 也還在發展階段,自然還是有一些尚在研究的問題。

他們最近主打的 VR 塔防遊戲 Cosmic Trip (game play),真的是相當精緻(相較於大部分的 VR demo)。

這場首次提到了之後在 VR 場會常聽到的幾個詞兒

  • 90hz (90fps) <- VR 讓使用者體感無壓力的的 fps 要求是穩定 90
  • Unity (5.4) <- 超多人用 Unity,5.4 好像有了某種非常強勁的 performance 更新

演講中提到在基地間移動是使用 VR 手把帶出一個類似傳送門的裝置再使用,於是在 QA 階段也有人問對於目前如果想要實際步行到某處該如何製作,這種所謂的 local motion 問題,現階段似乎還沒有完美的解決方案。

淺談美術風格統合;《Sdorica》開發經驗分享

講者: TEE

雷亞未推出的新作 RPG 《Sdorica》的美術總籌來分享 Sdorica 是如何嘗試定下現在的風格

  • 目標是東西方通吃
  • 決定韓系
  • Q版特色

現場有展示了一些場景畫面還有戰鬥人物動畫等等,真的是非常精緻/生動。

QA 時間有人問到戰鬥人物動畫是採用什麼方式製作的,TEE 表示是用 spine + sprite animation。

遊戲藝術的戰場前線─「概念設計」

講者: 陳以樂

講者負責的是團隊中製作遊戲概念設計,總之就是把需求轉為各種可能,並且對於發出需求方也有一些回饋,進而為遊戲發展出更多創意。

主要以他口中所謂的某款「武器娘」遊戲作為範例,有展示了許多發想階段的手稿,還算是有趣;不過因為這場接在 Sdorica 後面,武器娘的美術風格跟平常外面看到的遊戲也就是差不多的感覺,不像 Sdorica 有種眼睛一亮的 fu。

Mutation Mechanics: Mushroom 11 Tech

講者: Itay Keren

在我第一次 survey 議程表之前沒有聽過 Mushroom 11 這款遊戲,本來想說如果確定要聽這場的話應該先去 Steam 上買來玩一下,結果最後沒時間就作罷。

Mushroom 11 是一款相當特別的 platformer 遊戲,透過你的滑鼠可以消除真菌集合體的部分來達到各種神奇的效果,進而通關。

可以先看一下 gameplay

這場比較注重技術實作的部分,雖然沒有特別提是用什麼做的,但看來(又)是 Unity

  • mushroom physics
  • groups
  • background
  • camera
  • stage generation

這場聽完的感想完全就是這遊戲還真是有夠難做... 可能近期會買來膜拜一下 ww

Optimization 相關的部分,基本上載入關卡(隨流程動態)之後所有畫面上的東西都是 pool 住的,所以不會有 memory 的變動;接著會趁使用者 idle 的時候做 "replenish" 的動作,總之就是 idle 的時候就算小掉 fps 也還是沒有人會發現的。

神奇的是這款遊戲看起來就像是為了觸控而設計的遊戲,但它直到今日還沒有推出行動版遊戲,作者表示還在製作中。我想行動裝置上的種種硬體限制應該給它造成了相當的困境吧!

其他

  • 會議區外面的 Indie Space 獨立遊戲區 蠻有趣的
  • 沒有提供午餐只好去吃老朋友甜不辣
  • 下午茶看起來戰力超群
  • 感覺參加者大學生好多
  • 其實台北文創六樓這個空間還不錯
  • 這天九樓剛好是周杰倫的電競隊辦公室開幕

jquery-css-mahoro: 新嘗試的集合

這篇文章並不是特別用來介紹 jquery-css-mahoro,主要在這次的開源過程中,我嘗試加入了一些之前沒有使用過的工具/流程。

本文將會概述一下這次 jquery-css-mahoro 中的新嘗試有哪些,而日後可能會有一些文章稍微深入介紹本次的新嘗試(也可能沒有,我就是懶),請大家拭目以待。

jquery-css-mahoro

不過還是要先來簡介一下這次的開源小物。

jquery-css-mahoro
https://github.com/pc035860/jquery-css-mahoro

是我覺得每次操作 CSS animation 的 class 都很麻煩,進而寫出的小小 jQuery plugin (真心覺得 ngAnimate 超方便)。

它能做的事情就 如 README 裡面所寫

  1. 加上 CSS animation class
  2. CSS animation 開始跑
  3. 移除 CSS animation class

本來我只是把它丟在 某個 gist 裡面,後來發覺這樣要使用還是不太方便,還是需要丟上 NPM;既然要丟上 NPM,不如就找時間來認真的開源一下。

關於命名

現在與 CSS animation 有關的 jQuery plugin 實在太多,大家的名字也都差不多沒什麼識別度,既然這樣我還不如選一個特立獨行一點的,好好地做 SEO 應該還還是會有可見度的啦(吧)。

至於為什麼叫 Mahoro,我想我高中的朋友們比較清楚 w

Read on

React 碎碎念: 我只是想寫個 CSS

是說上次的碎碎念好像有點莫名地在我不知道的地方流傳,我根本沒宣傳那篇文章才對...

總之歡迎關注 React碎碎念 系列文章

碎碎念大部分是個人意見,客觀部分敘述有錯誤歡迎指證。

有一天

這天在 ReactJS.tw 看到了人家轉貼的 新工具介紹文章 — React Storybook,點過去看完之後順道看了一下作者還有寫些什麼文章,於是發現了這篇,也就是本文的主角

State of React and CSS

推薦讀完再繼續看下去。

想想上次發的 React 碎碎念: 艱困的新手之路 也是因為被一些看到的東西點燃了(X)

你原本怎麼寫 CSS?

其實原本有在寫 CSS 到一定程度的人(不管是前端工程師還是網頁設計師),一般會碰到一個轉捩點就是 — 習得 CSS 心法 (WTF)。

寫 CSS 的人,隨著碰過的網頁跟經驗增加,漸漸碰到頁面趨向複雜或是網站越來越巨大,然後 CSS 寫一寫就崩潰了。

於是坊間就有各種拯救你的心法出現,是經過時間淬鍊的成果,你可以選擇 follow 一種,或著結合眾家精隨融會貫通。(或著像我只學了皮毛就一直亂寫)

比較有名的心法這邊列三個:

還有一則很容易不小心就搜尋到的投影片 — 漫談 CSS 架構方法 - 以 OOCSS, SMACSS, BEM 為例

歡迎來到 React 的世界

然而,就是這個然而

在 React 崛起之後,因應它用力的 component 化,帶動了嶄新的 CSS 風潮。上面的 Medium 文章中列出搭配 React 使用的方式有:

  • 使用現成的 CSS framework
  • 寫 (good old) CSS
  • 用別人寫的 React-based UI
  • 用 CSS Modules
  • 在 JS 裡面寫 CSS

上面就 React 出現之後才崛起的其實又大體上可以分成兩類:

  • 在 JS 裡面寫 CSS
  • 用 CSS Modules
Read on

Blink 系瀏覽器 History API scroll restoration 的 bug

Update 2016/04/02 15:30
Opera 36(.0.2130.46) 跟 Chrome 49 同步了,所以這個問題也消失了。此文章正式壽終正寢(?)

Update 2016/03/06 14:00
更新到 Chrome 49(.0.2623.75) 以後這個問題已經修正(bug & commit);而同樣是 Blink 系的 Opera 更新比較慢,在 Opera 35(.0.2066.92) 上還是可以重現問題。


最近寫的東西幾個主要的 view 都跟捲動位置有關,而捲動位置對網站瀏覽者的體驗事關重大。

本文內容針對桌面瀏覽器。

我覺得良好的捲動位置體驗是

  1. 在同頁面重新整理後會回到一樣的位置 (在內容物不變的前提之下)
  2. 承 (1),如果內容物在重新整理後會改變 (ex: Facebook),重新整理後可以乾脆回到頂端
  3. 使用瀏覽器的「上一頁」、「下一頁」進入頁面時會保持之前瀏覽的位置
  4. 曾經瀏覽過的頁面再次透過連結點擊進去後可以重置捲動位置(不需要有 3. 的行為)

上面這幾點基本上完全在現在瀏覽器的掌握之中,然而最近發現的 Blink 系瀏覽器(Chrome、Opera)在使用 History API 時的 scroll restoration 有點奇怪

  • 程式操作後的 scroll 並不會被記錄
  • 預設的捲軸 restoration 不適合一般 single page app

這兩點發生的一個重要前提 - 「在操作之後,使用者沒有再動過捲軸(拉動 scrollbar 或是用滾輪)」

Read on