台湾 例大祭の一般参加した時のメモ
第二回博麗神社例大祭 in 台湾に一般参加してきました。 日本国外である台湾での開催ということで、なかなかハードルが高いと思われがちですが、 案外アッサリ行ってこれたので、どんな準備をしたかを書こうと思います。
画像は台湾例大祭で購入した公式グッズ(おみやげ?) であるところのパイナップルケーキです。
パスポートを取得する。
これは自分は既にパスポートを取得してたので、今回は特になにもしてませんでした。 ググれば、パスポートの取得の仕方はノウハウが見つかるので、そちらを参照頂ければと思います。
Visa は不要
日本のパスポートがあれば、台湾への渡航に Visa は不要です。
飛行機のチケットの取得
LCC(格安航空券)を使うと安いと思います。 私は行こうと決めた時期が遅く、LCCがほぼ売り切れだったので、 China Airlines でチケットを購入しました。往復 6万円くらい。 LCCであれば、3万円くらいで行けると思います。
ホテルの予約
楽天トラベル(http://travel.rakuten.co.jp/)を利用して、現地のホテルを予約。 例大祭の会場が、台北市大同区だったので、"大同区"で検索して、 なるべく会場に近いホテルを予約した。 予約したホテルはビジネスホテルで、1泊 6000円くらいでした。
持ち物
パスポート、クレジットカード、現金、PC、スマホ、充電器、着替えだけ持っていった。 最悪、パスポート・クレカ・スマホさえあればなんとかなるので、 それらだけは絶対に忘れずに。
充電器は日本のものがそのまま使えるので、変圧器などは不要。
空港
関空から台湾 桃園国際空港まで飛行機でだいたい片道3時間くらい。 搭乗手続きに時間がかかるので、離陸時刻の1時間前には、 空港のカウンターでチェックインするくらいの時間感覚で、空港に来ること。 空港での手続きまでは、日本語が通じる。大丈夫。
両替
空港にて、日本円を台湾ドルに両替。空港が一番交換レートが良いと聞いた。 交換手数料が 30台湾ドル(約120円くらい)かかる。
僕は 7万円両替して 18000台湾ドル手に入れたが、結局 現地では 7000台湾ドル(約26000円)くらいしか使わなかった。
空港からホテルへの移動
桃園国際空港から台北市まで距離があるので、電車あるいはタクシーで移動することになります。 私はタクシーを使ったので、タクシーの話をします。 だいたい空港から台北市まで、タクシーでだいたい40分くらい。料金は約1000台湾ドル(約4000円)。
タクシーのおっちゃんは、日本語も英語も通じないことが多いので、 スマホとかに、行き先の住所をメモして見せると良い。
ホテルからイベント会場への移動
これもタクシー。市内であれば、100〜200台湾ドル(500円~1000円くらい)で移動できる。 大きな通りであれば、タクシーはめちゃ流れてるので、簡単に捕まえられる。 日本のタクシーと違って、台湾のタクシーは自動でドアが開かないので、自分で開けること。
イベント会場
今年の会場は以下でした。
会場名:卡市達創新基地(圓山店) 住所:台北市大同區承德路三段232號B2
以降の開催も同じ場所である保証はないので、今後の台湾例大祭がどこで開催されるかは、 公式サイトを必ずご確認ください。
基本的にはイベント会場での注意事項は日本と同様です。
列形成のイベントスタッフは台湾語の人ばかりで、そこだけ面食らうかもしれません。 10時半開催のところ、私は10時に来たのですが、だいぶ列が出来てました。
列で並んでるとスタッフが参加者の手にスタンプを押し始めます。 カタログを事前購入していない人は、ここで100台湾ドル払って、スタッフにスタンプを手に押してもらいます。 入場は、カタログあるいは手のスタンプを会場スタッフに見せることで入場できます。
カタログは200台湾ドルですが、会場でカタログを購入する場合に、 手のスタンプを見せると、100台湾ドルでカタログが購入できます。
会場は人も多いし、熱気が凄かった。
FAQ
台湾って日本語は通じるの?
あまり通じないって聞いてます。ホテルは高いホテルだと通じるかも。 イベント会場では、台湾のサークル主の方は、簡単な日本語であれば通じる人もいました。
台湾って英語は通じるの?
タクシーはほぼ通じない。 ホテルは簡単な英語なら通じるといった感じでした。
Wi-Fi状況は?
ホテル/空港はほぼほぼFree Wi-Fi。 さすがに道端とかで フリー Wi-Fi は飛んでいないので、 お店とかに入る必要がある。
会場での同人誌のお値段
漫画本だと、100台湾ドル(約400円)〜150台湾ドル(約600円)くらい。 イラスト本だと 300台湾ドル (約1200円)とかが多かった。
Electron で手動GCを行う
さいです。
JavaScript と Electron でPC向けの弾幕シューティングゲームを作っています。
C++ と違って JavaScript はGarbage Collection (以降GCと呼称)がある言語なので、
ゲームプレイ中に不定期にGCが発生して、ゲームのパフォーマンスが悪化することがあります。
Object pooling を使って、GCの回数は減らす努力はしているのですが、
それでも(恐らく)GCの発生によって、古いPC等では露骨に画面が止まることが
あるので、Electron上で GCのタイミングを調整したいなぁと思いました。
Electron は Chromium ベースのプラットフォームであり、
Chromium は v8 エンジンを使用しています。
v8 エンジンのGCは Mark-Sweep 方式でのGCです。
v8 エンジンが自分で判断して行うGCを止める方法は
調べたのですが、無さそうです。
よって仮説として、メモリが潤沢にある環境であれば、オブジェクトが必要なくなってもすぐにオブジェクトへの参照を切らずにしておき、リザルト画面などのタイミングで不要なオブジェクトへの参照を切って、それからすぐに手動でGCを発生させることで、ゲームプレイに支障が出る場面でのGCをなくせそうです。
というわけでやっとこの記事の本題に入りますが、Electron 上で
手動GCを行う方法を書きたいと思います。
–expose-gc フラグを立てる
const electron = require('electron'); const app = electron.app; app.commandLine.appendSwitch('js-flags', '--expose-gc'); app.on('ready', () => { // Your code here })
app.commandLine.appendSwitch('js-flags', '--expose-gc');
を実行することで、Electron のレンダラプロセス上で global.gc()
関数を実行することができるようになります。
メインプロセス上のコードで app
に対して、ready イベントが発火するまえに、app.commandLine.appendSwitch()
を実行することで、
js-flags
に引数を渡すことで、Electron の v8 エンジンに対して--expose-gc
フラグを渡すことができます。
この辺は、公式の docs に記載されている。
global.gc() の実行
上記の方法で、v8 エンジンに --expose-gc
フラグを渡すことで、
Electron のレンダラプロセス上で、global.gc()
が実行できるようになります。
// 手動GCの実行 if (global.gc) { global.gc(); }
サンプルコード
サンプルコードを書いて、GCが行われているか確認してみます。
メインプロセス
// electron エントリポイント 'use strict'; const electron = require('electron'); const app = electron.app; const dialog = electron.dialog; const BrowserWindow = electron.BrowserWindow; const globalShortcut = electron.globalShortcut; app.commandLine.appendSwitch('js-flags', '--expose-gc'); let mainWindow; function createWindow () { mainWindow = new BrowserWindow({ "width": 640, "height": 480, }); mainWindow.loadURL(`file://${__dirname}/index.html`); // Open the DevTools. mainWindow.webContents.openDevTools(); mainWindow.on('closed', function () { mainWindow = null; }); } app.on('ready', createWindow); app.on('will-quit', () => { // Unregister all shortcuts. globalShortcut.unregisterAll(); }); app.on('window-all-closed', function () { if (process.platform !== 'darwin') { app.quit(); } }); app.on('activate', function () { if (mainWindow === null) { createWindow(); } });
レンダラプロセス
'use strict'; var Game = function() { this.frame_count = 0; this.bullets = []; }; Game.prototype.run = function() { requestAnimationFrame(this.run.bind(this)); this.frame_count++; // create for (var i = 0; i < 100000; i++) { this.bullets.push(new Bullet()); } // run for (var j = 0; j < this.bullets.length; j++) { this.bullets[j].run(); } // reset this.bullets = []; if (this.frame_count % 600 === 0) { if (global.gc) { console.log("done gc"); global.gc(); } console.log(process.memoryUsage().heapUsed); } }; var id = 0; var Bullet = function() { this.id = id++; this.frame_count = 0; }; Bullet.prototype.run = function (){ this.frame_count++; }; window.onload = function() { var game = new Game(); game.run(); };
レンダラプロセスは、1フレーム毎に、Bullet オブジェクトを10万個生成しては、その場で破棄しています。
また10秒に1度、GC を実行して、それからヒープ領域の使用量を console.log
で出力しています。
上記が実行結果です。10秒ごとに GC が実行されているため、
そしてGC 実行後のヒープ領域は常に最小になっています。
こちらが、js-flags
を追加しなかった場合です。
追加しなかった場合、レンダラプロセスには global.gc()
関数は存在しないので、
GC は実行されずに、ヒープ領域の使用量も不定(レンダラプロセス側の v8 エンジン任せ) となっています。
最後に
この記事を書いていて思ったのですが、メモリ解放対象のオブジェクトがなくとも、
GC時のルートオブジェクトからマーク済みオブジェクトを探索していく処理が、
ゲームに影響を与えるレベルの処理だと上述の方法は意味ないですね…
v8 エンジンが何を持ってGCを走らせてるのか知りたいなと思いました。
告知ツイートをするときに気をつけていること/考えていること
【告知】5/7 例大祭「B37a」にて東方二次創作同人ゲーム「紫と霊夢の終わらない夏」の体験版を頒布します。霊夢と紫が協力してステージ上のアイテムを集めるゲームだよ。無料で配ってるよ。当日はサークルスペースでプレイもできる予定。 pic.twitter.com/2Qcjgnapzh
— さい@例大祭 B37a (@saigyojiyu) April 30, 2017
こういった同人誌即売会において、 Twitter 告知をする際に、僕が気をつけていること/考えていることを 言語化して文章にまとめておきます。
僕は同人ゲームを作る人なので、同人ゲームの頒布の際の告知という前提があります。
メッセージ
入れなくちゃいけないもの
- いつ頒布するの?
- どのイベントで頒布するの?
- スペース番号
- 作品名
- 体験版 or 完成版?
- ゲームを一言で表す紹介文
なるべく入れた方がいいもの
- 委託があるかどうか
- (あれば)特設サイトURL
やるべきこと
- 関わってくれた人の名前を上げる
イラストはシノバ様(@shinonova_ra)です。ゲームタイトルのイラストは、シノバ様が例大祭で頒布されるイラスト本にも収録予定です!
— さい@例大祭 B37a (@saigyojiyu) April 30, 2017
イラストや音楽を他の人に依頼したならば、その旨を、告知へのリプライなどで書きます。 作ってくださった方および、その方達のファンへの敬意を込めて。
告知時間
18~23時くらいに告知ツイートするのが、一番人がTwitterを見ている時間だと思うので、効果的だと思います。
ただ、休日はみんな外出しているからか、その時間はあまり皆Twitterを見ていないイメージ。
また、平日の12時も案外効果的(お昼休みで皆Twitterを見る)
というわけで告知時間は、平日の12時と、18~23時くらいが良さそう。
最初の告知日
イベント開催日からあんまり事前に始めても、みんなまだサークルチェックを行っていないので、 RTとかしてもらえないイメージ。
例大祭(東方Projectオンリー同人誌即売会)であれば、イベント日の3週間前から ちらほらと告知ツイートを見始め、2週間前〜1週間前くらいが告知ツイートの ピークのように見えます。
というわけで、イベント日の2週間前〜1週間前くらいには、 告知ができるようなスケジュールで制作を進められるといいですね。
告知頻度
あまりうっとおしくならないよう、1日1度、告知ツイートをセルフRTする。
サンプル画像
表紙 or パッケージに使うタイトル画像1枚 + ゲームのサンプル画像3枚。
同人ゲームは「中身のわからないものは買いたくない」というのが顕著なコンテンツなので、ゲーム内容についてはネタバレを極力恐れず、惜しみなく画像を提供する。
観点として、 1. どういうプレイをするゲームなのか? 2. どういう点が魅力なのか?
がわかるように画像を選定します。
RT先の反応を見る
僕は、RTされたら、その人のホームを見に行っています。 何かしら告知ツイートに言及がされてるとスゴク嬉しいです。
RTやfavの反応があると、もっと反応が欲しいなあと思うし、 反面、ガッカリされないように頑張ります。
人からの反応を確かめるのは、こうしたコンテンツ制作における 心の栄養だと思います。
一方で、こうした承認は麻薬にも近く、 告知ってツイートしてからその日中、ちょくちょくRTやfavの反応があるので、 ついついTwitterを見てしまって作業が止まりがち・・・。これは反省。
告知は所詮告知
結局告知がどうだろうがゲーム本体の魅力がちゃんとないと、 ゲームは手にとってもらえません(当たり前ですが)。
他の人にもシェアしたくなるコンテンツというのは、 単純なクオリティの高さも一つの指標だと思いますし、 今のトレンドに沿っているとか、あるいは今までに無かった斬新さもあるでしょう。
告知は所詮告知。
最後に
これらは全て僕の所感であり、僕がただやってることに過ぎません。 もしもっとよりよい方法や知見があれば、教えて頂けますと幸いです。
ストレングスファインダーをやってみた
こんにちは、さいです。
ストレングスファインダーというツールがあります。
「あなたの強みを分析しましょう!」というツールです。
皆さんの中にも就職活動の際に、「あなたの強み分析」「適職診断」とかで
そういうのをやった人もいるかと思います。
ストレングスファインダーは、ああいったツールの、
もうちょいいい感じのアドバイスなり情報をくれるツールです。
さあ、才能(じぶん)に目覚めよう―あなたの5つの強みを見出し、活かす
- 作者: マーカスバッキンガム,ドナルド・O.クリフトン,田口俊樹
- 出版社/メーカー: 日本経済新聞出版社
- 発売日: 2001/12/01
- メディア: 単行本
- 購入: 160人 クリック: 3,045回
- この商品を含むブログ (462件) を見る
上記の本を購入するとアクセスコードを手に言れることができて、
34の強みからあなたの強みTOP5を分析しますという診断が行える(アクセスコードは1度しか使えないので中古じゃダメだよ)。
さらに8000円ほど払うと、34の強みランキング全部見られる。
僕の診断結果は以下でした。
- 指令性
- 競争性
- 内省
- 収集心
- 達成欲
指令性
「指令性」という資質によって、あなたは主導権を握ります。ほかの人と違い、あなたは自分の考えを他人に強く主張することを苦痛とは感じません。それどころか、ひとたび考えが固まると、あなたはそれをほかの人に伝えずにはいられません。そしてひとたび目標が定まると、あなたはほかの人をそれに同調させるまで安心できません。あなたは対立に怯えることはありません。むしろ、対立は解決策をみつけるための第一歩であることを知っています。ほかの人は不愉快な状況に立ち向かうことを避けようとするかもしれません。ところが、「事実」や「真実」がどれだけ不愉快なことであろうとも、それを示さなければならないと感じます。あなたは、課題が人々の間で明確に理解されていることを求めます。従って、あなたは人に、偏った考えを持たず正直であることを要求します。あなたは彼らにリスクに挑戦することを迫ります。彼らを怖がらせることすらあるかもしれません。これを嫌って、あなたのことを頑固と呼ぶ人もいるかもしれませんが、一方で、進んであなたに主導権を握らせることもしばしばあります。人々は、立場をはっきりと示し、周りの人にもある特定の方向に向けて行動するように求める人に魅力を感じます。だから、人々はあなたに惹きつけられるでしょう。あなたには強い存在感があります。あなたは「指令性」を備えた人です。
おぉ、すごい、自分で自覚してたパーソナリティとピッタリ!
僕は周囲の人間より自分が一番確度の高いことを知ってる/決められるとかいう
だいぶ傲慢なことを思ってる人間なので、この「指令性」が高いというのは納得。
診断結果から、各強みの詳細な情報が見られるんだけれど、
そこで「指令性」について以下のように述べられてる。
指令性という資質を持つ人には、強い存在感があります。状況の主導権を握り、決断を下します。 危険に遭遇したときにも対処できる才能を持っていることを知っています
あーそうそう。現在/未来が不確定でも、確度を高く「決め」と「行動」が出来るのは 指令性が高い人の強みの一つだと思います。実は世の中の人の多くは、わからないことに対して、 「自分が決定を下して責任を追いたくない」「確実でないことに不安になる」といった思いを持っています。 そういった人たちに対して「こうすればうまく行くよ!」と、方針を立てて導けるのは「指令性」の高い人の強みの一つだと思います。
言った内容や言い方によっては、他の人を怖がらせることがあります。おそらくこの効果を利用して、他の人を動かして自分の要求を通しているでしょう。
そうそう。自分の言うことを相手に正しいと思わせるために、自分の影響力を高めようとするんですけど、 それは時として相手を萎縮させてしまうんですよね。正しいことは頭でわかってるんだけれど、身体で実行できないという心情が人間は往々にしてあるので、それに対する共感とか尊重は必要です。
自ら進んで障害を解消してください。他の人は物事を進めるために、あなたの自然な決断力に頼ります。 あなたが障害物を取り除くと、あなたなしではありえなかった新しい機運と成功を生み出すことも珍しくありません。
これは今まで自分は出来てなかったことだなって思います。「決定」が出来て、人をその方向に向かせることができること、そして「決定」を実行するに当たって邪魔な障害を取り除くことは大切にしていきたい。
大義を掲げ、それを貫きます。 抵抗勢力の中で大義を守り抜くという場面で優れた能力を発揮するでしょう。
これも自分は出来てなかったこと。大義を掲げるに当たって、人々が共感できる大義を作ることはとても大切なのですが、自分は出来ていないので、大義を掲げていきたい。
「指令性」に関するいくつかの文章を抜粋しましたが、まだまだたくさんあります。
読みながら、自分が出来ていること/出来てないことが明確になっていきます。
ちなみに、私の強みTOP5のうち、「指令性」以外の、4つですが、
「競争性」は人と切磋琢磨すること、「内省」は考えたり議論したりすること、「収集心」は、知識を求めること、「達成欲」は、多忙で生産的であることですね。
ソフトウェアエンジニアなので、「内省」「収集心」が高いことは納得なのですが、
「競争性」「達成欲」は、どちらかと言えば営業職とかそういうタイプっぽいのが面白いです。
というわけで、ストレングスファインダーの紹介でした。
全ての能力において万能な人はいません。自分の弱い部分は他人に補ってもらって、
自分の強い部分をより伸ばしていくことが、結果的に社会全体の効用最大化に繋がるのではないでしょうか。
2016年振り返り
お仕事
既存サービスに対して、割りと大型の新規機能追加とかやってました。 プランナー1名、デザイナー1名、エンジニア2名で、期間6ヶ月くらいの案件です。
要件的にフロントエンドをしっかりとやらないといけない感じだったので、 WebSocket による常時接続と、JavaScript フレームワーク Mithril を導入しました。
サーバーサイドについては、DDD(ドメイン駆動設計)に基いて設計しました。
新技術の導入であったり、6ヶ月という弊チームではあまり知見のない期間での開発でしたが、 スケジュール的な遅延もなく、また大きな障害もなくリリースすることができました。
一方で、新規機能についてのユーザーは評価が悪く、売り上げが伸び悩みました。 ソフトウェアエンジニアとしての私の能力として、「どう作るか」については、 割りと知見ができてきたのですが、「何を作るか」については、まだまだ稚拙であり、 そうした弱点が露骨に出てしまった結果だと思います。
登壇
カンファレンスや勉強会などで登壇して発表する機会を頂けました。
GameServerDevelopers
Grand Frontend Osaka 2016
JavaScript Performance
ichi-pixel
Mithril
SPA(Single Page Application) 作りたくて、一方 React とか Angular とかがピンと来てなかったのですが、 Mithril に出会い、あっという間に手に馴染んでしまいました。
MVCフレームワークかつ仮想DOMかつ最小限のAPI数で、サーバーサイドアプリケーションの開発と ほぼ同じ概念で学習できるので、何度も言いますが、あっという間に手に馴染んでしまいました。
個人プロダクトや、社内向けプロダクトで色々使ったり、また仕事でも導入したりしました。 代表作は今のところ yukkuri talker という 俗に言うゆっくりボイスをweb上で作成できるサービスです。
同人シューティングゲーム
2月くらいに toho-like-js という JavaScript 製のシューティングゲームを見つけて、ソースコードを読んでました。 3月いっぱい、読んだコードを踏まえて、自分で一度再実装してみたりとかしてました。
それはそれで HTML5 におけるゲームの創り方及びシューティングゲームの創り方がわかってよかったねという話でしたが、 6月くらいに「全ゲ連 交流会」というのに参加し、 そこで、東方Projectオンリーイベント「博麗神社秋季例大祭」にて東方2次創作ゲームの合同試遊コーナー『博麗電脳試遊会』の存在を知りました。
そこで、主催の方に色々教えて頂き、試遊コーナーにてシューティングゲームの体験版を出す話になりました。 (この時点で私は一度もゲームを作ったことがなかったので、今でも自分で驚いています)
結果、UIデザインやイラスト、ドット絵、音楽など、色々な人の手を借りて、 10月の秋季例大祭で体験版の頒布、及び12月のC91冬コミで完成版を頒布することができました。
ここ最近チクチクと個人でシューティングゲームを作っておりました。完成版を C91 冬コミ 1日目 東レ07b で頒布しますので、もしコミケ参加される方いらっしゃいましたら、遊びに来て頂けますと嬉しいです。よろしくお願いします。 pic.twitter.com/s8qQQ8147R
— さい (@sairoutine) December 27, 2016
NES エミュ
3月くらいから NES エミュレータを作ってました。 コンピュータ・アーキテクチャの勉強になりました。
これはブログ記事もバズって、とても楽しかったです。
OSSコントリビュート
大きなOSSでは、Mithril と Electron にコントリビュートしてました。 自分が使用していて遭遇したバグのfixとか、ほしいと思った機能の追加が主にコントリビュートの仕方でした。
自分がどう変わったか
今までの自分の行動(技術の勉強とか)って成長意欲に基づく手段的な善だったわけです。 それが、NESエミュレータを作ったり、toho-like-js のコードを読んだりすることで、 それらの行為自体が純粋に楽しいという、手段的善から内在的善に変わるブレイクスルーがありました。
こうなるともう強いもので、コンピュータに関わることを、楽しいという理由だけで インプットやアウトプットを継続できるようになるわけです。
そして、そういったコンピュータに関わることは、自分が楽しいだけのただの自己満足であり、 それを人々に向けて活かす方向性が見えました。
僕の人生はオタクカルチャー/コンピュータエンジニアリングの2つで構成されているわけですが、 この2つが、ゲーム作りという行動によってようやく交差し結びついて一つのシナリオになってきた気がします。
今は作りたいものがたくさんあります。きっと作ることで、技術的なチャレンジも多々できるし、 それは元々僕が所属していた Web エンジニアコミュニティにも何かしら還元できるでしょう。多分。
これから
ゲームエンジン・アーキテクチャの勉強
元々コンピュータの低レイヤに興味があって、 OSとかメモリとかCPU周りの情報収集はしておりましたが、 いまいちどういうアウトプットをすればいいのかわからずピンと来てませんでした。
最近、ゲームエンジン・アーキテクチャに触れて、そういう低レイヤの知識とか興味を 活かしつつ、アウトプットする(ゲームエンジンを作る/既存のゲームエンジンを改修する)という道が あることを知ったので、やっていきたいと思います。
2D に関しては一通りやった気がするので、次は、3D と物理エンジンをやりたいです。
ブログ記事書く
自分はブログ記事を書くのが苦手(全然バズらない)と思って、あまりやらなかったのですが、 下記のように自分の知見を書いたところ結構たくさんの人に見てもらえたので、 もっと継続して人に見てもらえるような記事をたくさん書いていけたらなと思います。
ゲーム作る
やっていきます。オタクカルチャー大好き。 1本作ってみてちょっと思ったのが、僕のゲーム観って下記らしいので、 それに基いて作っていけたらなと思います。
・初心者でも簡単にできるゲーム
・同人誌みたいなゲーム
・ゲームは所詮音楽とイラストのプラットフォームでしかない
何か Web 関連のプロダクトを作りたい
一応 Web の人間なので1個くらいは年内に Web サービス的なものを作りたいなと。 一応サーバーサイドの人間なので、サーバーサイドアプリケーションとか、 サーバー構築/運用周りはやっておきたい。
TechLead
お仕事の話ですね。最近下記のような記事を読んで影響を受けました。
http://d.hatena.ne.jp/higepon/20150806/1438844046
同人サークルをよくしていきたい
同人ゲーム作るにあたって、同人サークルというのもやっているのですけれど、 これをよくしていきたいですね。色々考えてます。
「とにかく数を作ってリリースし、制作ノウハウを貯める」
「ゲームは最終的に規模とクオリティ勝負になってくるので人を増やす」
「ゲームを作りたいけど作れない人に、作れる場を提供する」
「属人化しないゲーム制作体制を目指す。究極的には僕がいなくてもサークルのリソースを使ってメンバーがゲームを作れるようになる」
とりあえず思う所を挙げてみたら、スケールさせることばかり考えてて笑った。 ゲーム制作って、最低でもイラスト/プログラム/音楽の三職種居ないといけないし、 欲を言えばシナリオライターとかディレクターとかスクリプターとか色々居て欲しいので、 どうしてもスケールすることを考えてしまいます。
技術採択のときにやるべきこと
初めに
新規プロジェクト/既存プロジェクトで、新しく使う ライブラリだったり、フレームワークだったり、ミドルウェアを選定してきた経験を通して、 採択する段階でこれはしておいた方がいいなという知見が溜まったので、 メモ書き程度に記述します。
前提として、技術採択についてある程度メンバーに裁量が任せられている風土があり、 かつミッションクリティカルでないシステムに導入する、また自社で事業を行っており、 顧客=ユーザーであるというのがあります。
(この辺の前提条件が違う場合、採択に当たってまた別の観点が必要になってくると思います)
システム要件を満たしているかどうか
なんだかフワっとした言い方になりましたが、例えば Web システムに JavaScript のライブラリを 導入する場合に、Web システムが IE8 に対応するという要件ならば、 そのライブラリが、IE8 でも動くか調査するということです。
これをやらないと、開発期間の後半になって、システム要件を満たさないことが発覚して、ライブラリの変更及び実装したコードの破棄をするとかいう地獄になります
私の場合、例えば JavaScript のライブラリを導入する際は、Github の issue を見て、 ブラウザ依存のバグレポートを検索したりとか、ライブラリを使って簡単なアプリを作ってみて、 社内の検証用端末すべてで一通り動くかどうかチェックしたりします。
採択理由のドキュメント化
ライブラリの採択理由について、きちんと文字に起こして社内のwikiなりなんなりに みんなの見えるところに置いておきます。採択に当たっての関係者説得のために 書かざるを得ないのが大抵でしょうが、求められなくてもきちんと書いておきます。
ドキュメントを書く際の観点は以下です。
なぜ導入するのか?
→どういう課題を解決するために導入するのか、あるいはどういう効果を見込んで導入するのか書きます類似のライブラリ/フレームワーク/ミドルウェアの調査
→例えば JavaScript のフレームワークなら、 Backbone とか Angular とか React とか、 色々な種類があります。それぞれのフレームワークについて、特徴やプロジェクト導入に当たってのメリット/デメリットを調査します。選定の観点
→自チームに導入する際のより細かい要件について洗います。「1. なぜ導入するのか?」にて、 大まかな要件については洗えていると思うので、「類似のライブラリ/フレームワーク/ミドルウェアの調査」にて調査した もののうち、どれか一つを選べるレベルには細かい要件を洗います。結論
「3. 選定の観点」で記載した観点に従って、「2. 類似のライブラリ/フレームワーク/ミドルウェアの調査」のもののうち、 どれを選定したのか結論を書きます。
これをやらないとプロジェクトが終わった後、導入して良かったのか/悪かったのかが振り返れません
採択したいものを使ったプロダクトを1つ作る
社内向けシステムでも、個人プロダクトでも良いので、採択したいライブラリ/フレームワーク/ミドルウェアを使って、 プロダクトを一つ作ります。ToDoアプリレベルではなくて、できれば人に使ってもらえるレベルのプロダクトを作りたいところ。
これをやらないと導入してみたもののよくわからなくて作りきれないというのが発生します
いやご冗談をと思うかもしれませんが、他の人の話を聞くと、たまにあるねん……
その他"必ず"ではないけど"できれば"導入に際してやっといたほうがいいこと
上記3つは、必ずやっておいた方がいいことです。 以下2つは"必ず"必要なのかちょっとまだ判断しかねていることです
フレームワーク/ミドルウェア/ライブラリ自体の実装の理解
フレームワーク/ミドルウェア/ライブラリ自体のバグを踏んだ際に、原因の特定に時間をかけずに済んだり、 フレームワークにパッチを当てるあるいは、フレームワーク自身にバグfix のプルリクを送る等の対処が可能になります。
導入を手伝ってくれるメンバーを自分以外に2名作る
TED Talk に「How to start a movement」というのがあります。 ムーブメントとは3人揃うとそこから加速的に賛同する人が増えるよって感じの話です。
技術導入は、常に「本当にやる必要があるのか?」「やっぱり止めたほうがいいのでは」という周囲の目線に晒されます。 一人で導入を進めていると、そういう目線に負けやすいので、そういう時に一緒に戦ってくれる仲間がいると、導入が進めやすいです。
Live2D + Electron でデスクトップマスコット作って同人誌即売会で頒布してきました
標題の通りです。まずはこちらをご覧ください。
10/30 の 京都秘封で頒布予定の、宇佐見蓮子さんデスクトップアプリのモデルを動かしてみました。 pic.twitter.com/Y1F0ykMDXG
— さい@京都秘封 倶04 (@saigyojiyu) 2016年10月2日
宇佐見蓮子さんのデスクトップマスコットアプリできた。クリックでランダムに5種類の反応してくれる。Mac/Windows 両対応。10/30 の京都秘封オンリーで頒布予定。 pic.twitter.com/5E1ZUJqrTT
— さい@京都秘封 倶04 (@saigyojiyu) 2016年10月9日
東方Project という同人ゲームに登場する「宇佐見蓮子」さんの
デスクトップマスコットアプリを作りました。デスクトップ上で動きます。
クリックすると、何かしらの色々な反応をしてくれます。
2016/10/30 の科学世紀のカフェテラスという同人誌即売会で頒布してきました。
Live2D
Live2D WebGLとNW.jsでデスクトップマスコット
Live2D については上記の記事を参考に実装させていただきました。
公式サイトで WebGL 用 SDK が提供されているのでそれを使用しました。
Live2D Cubism SDK 2
Live2D WebGL SDK の解説については下記のスライドがわかりやすいと思います。
Electron
デスクトップマスコット用に、ウィンドウ表示を無くし、
背景を透過して、常に最前面に表示する方法ですが、
mainWindow = new BrowserWindow({ "transparent": true, // ウィンドウの背景を透過 "frame": false, // 枠の無いウィンドウ "resizable": false, // ウィンドウのリサイズを禁止 "hasShadow": false, // 残像が残らないようにする(Mac only option) "alwaysOnTop": true, // 常に最前面 });
BrowserWindow 作成時に、上記のオプションを設定することで、
簡単に実現することができます。
なお、hasShadow
オプションですが、Mac ではデフォルトで、
ウィンドウに影が付くようになっており、このオプションがオンのままだと、
Live2D モデルのモーションに残像のようなものが残ってしまいます。
オフにしましょう。
上記 Qiita の記事では、NW.js を使ってデスクトップアプリ化しているため、
XMLHttpRequest でなく、fs を使ってモデルファイルをロードしていますが、
Electron においては XMLHttpRequest でロードできます。
このため、Electron のメインプロセスのAPIを使用する必要がなく、
レンダラプロセスのみで完結するため、開発中はブラウザ上でマスコットを表示し、
完成後に Electron で build して完成としました。
ライセンス
Live2D のライセンスは結構ややこしいです。下記の内容は 2016/10/30 時点のものです。
最新の内容は、公式サイトをご確認ください。
本デスクトップマスコットアプリは、同人サークルとして頒布したものです。
直近売上高が1000万未満の同人サークルであるため、「一般ユーザー」として
使用することになります。
一般ユーザーであれば「iOS, Android, Flash, DirectX, Unity, Cocos2d-x, WebGL」のSDKを、
商用/非商用問わず利用することができます。
インディークリエーター向けにLive2D Cubismを無償提供。商用利用も可能
DLカード
同人誌即売会での頒布は、DLカード(ダウンロードカード)を
作成して頒布する方法を取りました。
対面電書という Webサービスにて、
ファイルのアップロード及びシリアルコードの発行を無料で行うことができます。
こうして発行したシリアルコードを、バリアブル印刷対応の印刷所(印刷のウェーブ様等)にてカードの印刷を発注しました。
ポストカード(オンデマンド、両面フルカラー)+バリアブルテキスト印字オプションで、
200部だいたい8000円くらいのお値段です。
メール便に対応しているので、注文から手元に届くまで
だいたい4営業日くらいというスピード感です。
きゃーい。DLカードも届いたぞー!(これはおまけでもらったシリアルコードがついてないやつ) pic.twitter.com/EC18qC7J7S
— さい@京都秘封 倶04 (@saigyojiyu) 2016年10月29日
感想
Mac を会場に持ち込んで、実際に動いてる様を展示していたのですが、
「すごい」「こんなことができるんだ」といった反応をたくさん頂けました。
(エンジニア冥利につきます)
Live2D を使った作品を作る上での課題は、
やはり元のイラストをどう用意するか、
そしてそのイラストをどうやってモデル化するかだと思います。
今回はそのどちらもを他の人にお願いしてしまったので、
私はモデルとモーションを組み合わせただけなのですが、
逆に言うと、モデルさえ用意してしまえば、このような
デスクトップマスコットアプリを作ることは結構サックリとできます。