GLSLシェーダスクール2017を通して気づいたこと
はじめに
昨年の話になるのですが、フロントエンドの表現スキルをあげたいと思い、GLSLシェーダースクール2017に参加いたしました。
前回のブログで使っている技術である、シェーダの基礎を勉強するというもので、時系列としては逆になってしまいかつ期間も空いてしまいましたが、ここでの内容をかいつまみつつ自身の振り返りを整理しようと思いました。
GLSLシェーダスクール2017の内容
GLSLシェーダスクールのページにも記載されていたりしますが内容を整理すると、
WebGL開発支援サイト wgld.org, WebGL総本山の管理者doxasさんが主催の勉強会
2017では10月下旬から隔週で計5回実施(5回目は年末年始を挟んで1月下旬に実施)
シェーダの基本文法からシェーダでできる表現の解説(なので、JSに関する解説はシェーダへの受け渡しをメインに1割くらい?)
doxasさん作のエディタ、webgl_editronを使って解説
講義前半はdoxasさんが行い、後半の1時間を外部講師によるプラスワン講義の構成
5回目では、受講生がシェーダを使って作品を作り、その発表会(WebGLに限らず、シェーダが使える環境ならOFでもTouch DesignerでもUnityでも可)
というものでした。
doxasさんは以前からWebGLやシェーダを研究し、WebGL総本山では国内海外のシェーダを使った事例の解説もされているパイオニア的存在です。
今回のゲストは、WebGLフレームワークGrimoire.jsの開発者で「独立行政法人情報処理推進機構の 2016 年度 未踏プロジェクト」にも採択された石井 翔さん、シェーダによる祭典Tokyo Demo Festのオーガナイザーを務めている佐々木 正樹さん、はてな所属のフロントエンドエンジニアでAtomのパッケージVEDAの開発をしたりVJもされている天城 孝義さんの4名でした。
実のところ、前回のシェーダスクールにも参加させていただいたのですが、理論がわかったつもりになっており、手を動かしてシェーダを操るレベルに至らなかったのです。受講生が作品を提出し発表会をするというのが今回初の試みでもあり、もう一度シェーダに理解と実践両面から関わりたいという思いと発表というアウトプット機会を作れると感じ再度参加することにいたしました。
以下、前半講義を中心に要所をかいつまんで残してみました。
第1回 GLSL とはなにかを知ろう
初回は、まずシェーダやWebGLの概論から、描画されるまでの処理フローをメインに学びました。シェーダは「GPUを利用し高速なグラフィック描画を行う技術・概念の総称」であり、シェーダを扱うには、DirectXやOpenGLといったGPUを利用できるAPIが必要になります。
WebGLはOpenGL ES 2.0を踏襲しており、OpenGL系でブラウザから制御できるようにしたものです。
処理フローも、シェーダのソースコードをコンパイルし、それをGPUにアクセスできるプログラムオブジェクトとリンクづけることで動かすことができます。
かなり端折ってしまいましたが、詳細は WebGL開発支援サイト wgld.orgに詳しく解説されているのでそれを参考にすると良いと思います。
なので、この回はこうした用語や概念の説明と仕組みのお話、実サンプルでは板ポリを作って色をつけたり、マウスに応じて変形するものを扱いました。プラスワンではdoxasさんが担当し、光のオーブを表現したり、ラインを描く際の実装を解説頂きました。
第2回 頂点シェーダの基本と使い方を知ろう
第2回では、WebGLで扱える2種類のシェーダの一つ、「頂点シェーダ」にフォーカスした講義でした。頂点といっても、3次元空間上の点をディスプレイのような2次元で描画することから「座標変換」を行う必要があり、その処理の過程で行列を用います。そうしてディスプレイに投影した頂点を三角関数を使って動かしたり、画像(テクスチャ)を読み込み頂点や頂点で構成した板ポリに貼り付けるところをやりました。
第2回プラスワン講義では、前述の石井 翔さんが担当されました。GPUと行列をテーマに話され、GPUはSIMD命令が使えかつCPUに比べコア数が多いことからグラフィック処理に使える点、行列は演算処理を便利にしたものに過ぎない点とあまり意識出来てなかった点を掘り下げた話題で興味深かったです。
第3回 フラグメントシェーダを使いこなそう
第3回は「フラグメントシェーダ」をテーマにした内容でした。特に、頂点・フラグメントで描画した結果を一時的に保持しそのテクスチャをもとにフラグメントシェーダで加工する「ポストプロセス(ポストエフェクト)」の話題が主でした。ちょっとイメージつきにくいかもですが、インスラグラムにあるようなフィルタ機能のようなものと考えれば良いかと。
ポストプロセスの概要から、具体的にどういう表現ができるのか、乱数を使ったノイズ処理やナイトスコープ(緑色の色調でTVのような走査線が走るエフェクト)、モザイクを題材に実装の解説をいただきました。
プラスワン講義は佐々木 正樹さんが担当で、この回のテーマであるフラグメントシェーダに絡めて、組み込み関数を理解しリファレンスをよく読んでおくこと、絵が出なかったり他者からのシェーダソースを使ったがうまく表示されない時のトラブル対処法、エフェクトを組み合わせる時の考え方だったりと、JSと違ってデバッグがしづらいシェーダで陥りがちなポイントや、一歩進めた表現のアプローチとこと細かく解説がなされていて勉強になりました。
第4回 ハイレベルなシェーダテクニック
この回では全体的に特殊で高度な内容でした。まず、「擬似ディスプレースメント」について。3DCGではテクスチャに応じて頂点の座標を動かし凸凹の質感を作る「ディスプレースメントマッピング」と言うものがありますが、doxasさんが呼んでいる擬似ディスプレースメントは、頂点座標を動かさずテクスチャの色味を係数として捉えテクスチャ座標をずらすことで立体的に見える手法を解説しました。次に、パノラマ画像を極座標変換させてTHETAのような全天球画像にしてみたり、GPUをグラフィック用途だけでなく汎用的な演算にも活用し座標移動をGPUで行わせる「GPGPU」の概念や仕組みの解説もありました。正直GPGPUは今も自分にとって扱える代物ではないですが、いつか挑戦したい領域でもありどうやって実現しているのか中身のロジックを理解することができただけでも貴重な経験でした。それから、レイ(光線)を飛ばして閾値に入るものを塗りつぶす処理のレイトレーシングの解説もあったりと、シェーダ表現でも一歩踏み込んだ説明が聞けました。
最後のプラスワン講義は、天城 孝義さん。天城さんはwgld.orgからシェーダについて覚え、シェーダを使ってライブコーディングVJをしたいということで前述のパッケージまで作ったお人です。講義ではVEDAのインストールから操作方法をレクチャーいただきました。かなり機能が盛り込まれていて、標準でそのままVJに持っていけそうな感じでしたし、こちらもゆくゆく触って覚えていこうと思います。
第5回 作品発表
最終回は、事前にdoxasさんに作った作品をファイル添付あるいはURLで送付し、それをdoxasさんのマシンで投影し各人発表してもらう形式でした。
最初はフラグメントシェーダのみで作ったものをdoxasさんに提出しましたが、改めて本スクールを通してチャレンジしてみたかったことに挑戦することにしました。
以下、提出した作品になります。
https://qeita.github.io/motion/js/001/
やってみたかったのは、頂点シェーダで3Dの物体のあるべき形状を歪ませたりできないかというものでした。生のWebGLだとオブジェクトを作るのに多数のポリゴン作って組み合わせたりと骨が折れるため、Three.jsを使うことにしました。
THREE.FontLoaderで日本語・英語の2種フォントを読み込み、メッシュを作っています(初期表示は日本語)。左右矢印キーあるいはメッシュ自体をクリックすると、文字が切り替わって行き、上下矢印キーで日英フォントを切り替えることができます。
文字のメッシュを歪ませている処理は、以下頂点シェーダのところで行っています。
元の位置であるposition.x, position.y, position.zを基準に、乱数(rand(xxx))と原点からの距離(len(xxx))と時間を三角関数でラップしたものとuniform変数sizeを掛け合わせたものを加算しています。
x, y, z軸にそれぞれ同じ値を加算すると、x/y/z軸方向に単純な平行移動になってしまうため、各頂点の座標に応じて加算する度合いを変える必要がありました。
ちなみに、uniform変数sizeは、文字が切り替わるタイミングでJS側でランダムに可変値をセットし、それに応じて変わったタイミングで頂点をグニャグニャ動かす度合いも変化させています。
uniform float time;
uniform float size;
varying float vTime;
float rand(vec2 co){
return fract(sin(dot(co.xy ,vec2(12.9898,78.233))) * 43758.5453);
}
float len(vec2 posiiton){
float len = length(position);
return 200.0/len;
}
void main(){
vTime = time;
gl_Position = projectionMatrix * modelViewMatrix * vec4(
position.x + rand(vec2(sin(time)) * position.xy) * len(position.xy) * cos(time) * size,
position.y + rand(vec2(cos(time))) * len(position.xy) * sin(time) * size,
position.z + 0.1 * len(position.xy) ,
1.0
);
}
メッシュのフラグメントシェーダは、シンプルに時間に三角関数に入れ込んで動的に色が変わるように、背景の平面も乱数を使ってざらついた見栄えにしました。
感想・振り返り
今回参加したことで以下4つの気づきを得ることができました。
最後のは個人的見解が強いのですが、自身の振り返りということで乗せてみました。
シェーダはコードベースなので直感的でない
意図した通りの動きになるものでもないのでトライ&エラーの繰り返し(偶然を楽しむ)
生のWebGLを書く利点(処理フローの理解、ファイルサイズ、ライブラリの記述・バグ)
シェーダ単体だと「表現のクセ」が出るので、複合的な組み合わせで違う角度からの演出・表現を狙う
まず1点目はシェーダのソースを見たことや書いたことがある方ならいわずもがなかもしれません。JSと違って、三角関数やベクトル、組み込み変数を多用して作るものによって何をやっているのかわからなかったりします。 ただ、その複雑性と高度性が表現系エンジニアとしてのアドバンテージや領域になるのではないかと感じました(一方で、クリエイティブからのリクエストとシェーダの複雑性に苛まれる可能性もあります)。
2点目は、第3回プラスワン講義の佐々木さんが仰っていた点とも同じになるのですが、先の複雑性からちょっと数値が変わるだけで全く違う見た目になることもあります。それにより、完全に意図した通りの見た目・動きにならなかったりするので試行錯誤の連続になる感じです。一方で、パラメータによって変わる偶然性を楽しんだりしてモチベーションの維持やアレンジの創出につなげる必要があります。
3点目は、本スクールではThree.jsは一切扱わず、WebGLで一から書かれたサンプルをベースに進めました。抽象化され多機能なThree.jsに頼りがちなところですが、逆に生で書くことの利点もいくつかあります。
まずは、一から書くことでどういう仕組みでGPUにデータを渡しているのか理解につながりやすいかと思います。Three.jsはそこまで意識せずに作れるところがありますが、WebGLの根幹を把握しておくと今後のWebGL自体のバージョンアップでも応用が利きそうではあります。
次に、Three.jsは色々できる反面ファイルサイズが大きくなりがちなところが挙げられます。本体だけでなくモデルデータを読み込んだりポストプロセス用のファイルを読み込んだりするとチリも積もって数MBになることもあります。スクラッチでWebGLを書くと、余計な処理を除くことで軽量化が望めると思われます。実際講義で使ったポストプロセスのサンプルも50KB足らずだったりしました。ただ大量のテクスチャや多様なオブジェクトを扱うとその限りではありませんが、板ポリで表現するようなものであればThree.jsを使わない方がパフォーマンス的にも優しいかと考えます。逆に、沢山の3Dオブジェクトや文字を扱ったりと言ったものだと、多機能なThree.jsがいいでしょうし、そこはスクラッチとThree.jsの両方をフレキシブルに扱えるようになると強いかなという印象です。
それから、Three.jsに限らず、ライブラリはバージョンアップに伴いこれまで使えたAPIが使えなくなったり、記述が変わったりします。また、特定のブラウザでのバグが出ることもあり、ライブラリに左右されない書き方をするなら生でWebGLを書くと良いように思われます。デメリットとしては、Three.jsで調べるよりもWebGLで調べる方が思った記事に行き着かないかもですので、佐々木さんの講義にもあったようにkhronosが公開している組み込み変数やリファレンスを見ておくのが良さそうです。
4点目は、GLSL Sandbox を見て思ったことですが、シェーダだけだとかつてBootstrapで作ったサイトのように「表現のクセ」が出やすいように見受けられました。勿論パーティクルをギュルギュル動かしたインパクトある表現もあるのですが、単一のGUIや表現に絡む技術だけ扱うと、多少なり「クセ」は出てしまうものかなと。。多分Three.js単体で使ってもプリミティブなオブジェクトがバラバラでてるだけでThree.jsのクセが出てしまいそうではあります。ある種既視感に似たものでしょうか。
なので、Three.jsなりフォントなり違う領域のものと組み合わせることで、演出や表現に変化をつけることでオリジナリティにもつながりそうではないでしょうか。そういう意味でも、第5回発表会で発表された寺田 佳央さんのサイトがそういうアレンジ性がすごかったなと感じました。
Three.jsベースですが、テクスチャを貼り付けたり、ポストプロセスで歪ませたりとアーティステックな表現が興味深かったです。
長々となってしまいましたが、以上シェーダスクールで行ってきたことの振り返りです。
これから毎日...は難しいでしょうが、シェーダをガシガシ書いていこうと思います。
WebGLの熱量でカイロにもなるスマホコンテンツを作った
こんばんわ。最近寒波続きで寒くなってきましたね。
今回、「寒中見舞い」をテーマにちょっとしたコンテンツを作ってみました。
経緯
まず本コンテンツを作るきっかけの1つに、昨年10月から通い始めたdoxasさん主催 「GLSL シェーダースクール2017」 があります。これは、GLSL(OpenGL Shading Language)というブラウザ上でGPUを駆使し高速な演算・描画処理を行えるシェーダー言語を学ぶというもので、近年3Dインタラクティブコンテンツ制作に用いられるWebGLと併せて注目されつつある領域です。
スクールでの内容は後日改めて書き留めるつもりですが、これを機に今年は自主的にWebGL・GLSLを扱う機会を作ろうと考えました。
また、私の職種がフロントエンドエンジニアで、日頃クリエイティブから上がったアイデアやデザインを形にする仕事をしていますが、今後は自主制作からでもアイデアからアウトプットまで一貫したものをやっていきたいと思ったのもあります。
さて、冒頭にも触れましたが、最近寒くなってきたことと寒中見舞いの時期に合わせて何かアウトプットをしたいと考えたのが発端でした。仕事柄デジタルクラフトに絡めたものにしたいことと、寒中見舞いの葉書に合わせるならQRコード付けて、そこからアクセスするスマホターゲットにしたコンテンツにしようという漠然とした方向性からはじめました。
アイディア編
アイディアのヒントになったものとして、1つにBlue Paddleの佐藤ねじさんが考案した HOT LETTER があります。使い捨てカイロを手紙にするというアナログながら手紙の「暖かみ」をテーマにしています。
2つ目は、WebGL・GLSLに関連して時折出てくる 「暖をとる」 というキーワードです。GPUで高速な処理を行うためPCだとファンが唸ったりPC・スマホが熱くなったりします。
では、WebGL・GLSLを使って「熱」をインタラクティブ・メイン要素にしたコンテンツを作れないかを考えました。
寒空の中、スマホの熱で温まる状況から「マッチ売りの少女」を連想し、物語のキーになる「火 (≒ マッチの火)」をビジュアルの軸にして、「マッチ売りの少女」のストーリーを読み進めるコンテンツを作ることにしました。
実装編
火をWebGLで再現するにあたり、比留間さんの記事 [GLSL] WebGLで炎の揺らぎ を参考にさせていただきました m(_ _)m。どうやって揺らぐような見え方になっているのかはまだまだ力及ばずなところなので、じっくり研究したいと思います。
次に、タップ・クリックし続けると火の勢いが大きくなる部分を作ってみました。こちらは、タップ・クリックイベントによって、GLSL側のuniformで定義したsize変数の値を加算し、頂点をコントロールするVertex Shaderでsize変数とそれぞれの頂点のx・z座標で計算しています(以下式)。
gl_Position = projectionMatrix * modelViewMatrix * vec4( position.x * size, position.y, position.z * size, 1.0 );
この場合、size変数は最初0でタップ・クリックし続けるとsize変数の値は徐々に上がってきます。すると、上記計算で頂点のx・z座標の値が大きくなり、火の形が徐々に横と奥行き方向に向かって大きくなっていきます。
それから、Three.jsのポストプロセスを使って 熱量を上げる 火の周りの雰囲気を調整してみました。Three.jsのプラグインで、シーンの明るい部分をより明るくするブルームエフェクト(BloomPass)を少々、画面の四隅を暗くするビネット効果(Vignette Shader)を組み合わせて、火の周りが明るく見えるようにして火の勢いに応じてビネット効果を弱め火の明るさが広がるようにしています。
ただ、このままだとさっと見て終わってしまうため、WebGLの熱量を維持する上でゲーム性を持たせることにしました。具体的には以下のルールを設けて、コンテンツの滞留性をつけるようにしました。
- タップ・クリックし続けると火の勢いが大きくなる
- 上下にスワイプ・ドラッグすると、テキストがスクロールする
- 火の勢いがなくなる、または大きすぎるとゲームオーバーになる
デモ
こちらにコンテンツをアップしました。 画面左上の「?」アイコンをクリックすると先述した操作説明が表示されます。
https://qeita.github.io/SeasonsGreetings_2018/
Gitリポジトリ：
https://github.com/qeita/SeasonsGreetings_2018
振り返り
作っている中でも実感していましたが、火の勢いを維持しつつ物語を読むのはUI的にちょっと大変だなという印象を受けました。
また、「マッチ売りの少女」を作品のモチーフにするなら文字情報よりも画像が良いかもと思いましたが、今回画像の選定が定まらないことから対応しませんでした(画像検索APIを使ってランダムに画像表示もありかと思いましたが、APIの制限やAPI keyを晒す点から却下することにしました)。
今回自分で企画し作ったものの経験としては、インスタレーションに比べてWebコンテンツはWebGLのようなリッチ表現だけで成立させるのはなかなか少なく、文字情報等のコンテンツとのバランスが大事なのだなと再認識しました。
追記：
スマホケース越しにやってたり、スペックによっては思ったより熱くならないかもですが、火を見てるとうーん心理的に温かく感じるのかも。。
参考
Bonfire Next #1を通じて感じる、次世代インターフェースの行く末
2018年最初の勉強会、Yahooさんが主催の「Bonfire Next」というイベントに行ってまいりました。タイトルの"Bonfire Next"ですが、
Bonfire ... かがり火(新しいトレンドや技術分野)
Next ... それをもとにどういうことを話し合うか
という意味だそうです。
様々な会社の人が登壇し多様な観点のお話が聞けるところと、今回のテーマ「多様化するインターフェースの活用」の2点が気になりました。
Yahooのオープンコラボレーションスペース、 LODGE が会場です。
カジュアルでお洒落な空間になっています。
実例から見る VUIアプリの企画から分析まで
最初の登壇者は、株式会社WHITE のプランナー/UXデザイナーの伊東 春菜さんです。WHITEは広告系の企画・開発を軸にExperience Deignを手がけるUXデザインカンパニーで、博報堂グループであるスパイスボックスの子会社でもあります。
WHITEは企画からマーケティングまで担当領域とし、恋人の手の上にプロジェクションマッピングを行うTIFFANYの"Hand meets hand"、世界初触れるVRゴーグルの MilBox Touch、ドライブレコーダーのデータを使い運転技術を診断する DRIVING! を事例に挙げていました。
2017年AIスピーカー元年という背景から、WHITEはいち早く音声インターフェースのUXデザイン専門組織を設立し、Google Home発売に合わせて2つアプリをリリースしたとのこと。今回は、作られたアプリの一つである、「日本史語呂合わせ」の開発の過程を紹介してくれました。
まず企画段階では、Simple(誰にでもわかりやすい・短い)であることをコアにしていました。スマートスピーカーとは長時間話すのでなく小時間という性質も考慮し、大人から子供まで・家族や友達・お茶の間で ・GoogleHome/スマホでも使えるアプリをユースケースとして設定されました。
次にペルソナ設定として、VUIという音声でやりとりする性質上、アプリの人格を備えるという独特のデザインがあります。ユニークで一貫性がある人格を設定しトンマナを統一するという目的があり、今回の語呂アプリでは戦国武将の「語呂丸くん」というキャラクターを作られました。
それから、シナリオ作成(会話例などのパスを書くこと)、機械らしさを減らすよう会話にバリエーションを持たせる、Actions on google Dialogflow で開発し、テストでは社内で実際にスマートスピーカーで触れて出たフィードバックの修正を繰り返したそうです。アプリ審査では、ユーザが迷子にならないか・アプリを終了したいときに終了できるようになっているかという項目にもクリアをして行きました。
アプリの分析においては、dashbot という海外のツールを使用したそうです。その詳細分析によると、1回の利用あたり平均会話数18回と、きちんとゲームをこなしているユーザが多かったそうです。その一方、ユーザが語呂丸に問題を出してくるケースがありそれにうまく切り返せていない点や、ユーザの「良いぞ」や「はーい」を、[Yes]の意味で認識していない(表記揺れ)点もわかり、それらに対する対応も進めているそうです。
最後に、VUIはまだ新しい領域でもあり、UI・UXデザイナーに限らず、コピーライターやエンジニアなど様々な職種が活躍できるところがあるので、挑戦して武器を増やしてもらいたいということで締めくくられました。
テクノロジーの目的を明確化するためのデザイナーのアクティビティ
www.slideshare.net
次の登壇者は、NEC 事業イノベーション戦略本部ビジネスデザインセンターの安 浩子さんです。今回、NECの事業である顔認証とAIをメインにお話をされました。
NEC は国産コンピュータで有名でありますが、現在はLenovoにPC事業が移っており、一方でNECは社会価値創造型企業、社会ソリューション事業に移行しているのだそうです。例えば、セブンイレブンに設置されたセブン銀行にNECが関わっていたり、成田空港の指紋認証や指紋照合、ATM・金融システム、交通情報案内と、PCに関わらず様々な分野の課題解決を手がけていることが伺えました。
本テーマでは、イベント会場の本人確認や出入国審査を例に、運転免許証等の顔写真付き身分証明を人の目で照合するこれまでの作業に着目されました。
確かに、人手を使った照合作業は、確認項目やフローがマニュアル化されていれば、比較的導入やアサインも簡易になるでしょうが、捌く量次第で識別精度が落ちていったり人件コストがかかる面が懸念されます。
そこをNECは、パブリックセーフティ - 顔認識システムでスムーズな本人確認を行えることを実践していきました。
特にイベントでは本人確認が大変なところでもあり、顔認識により東京オリンピックへの実用に向けて検証を進めているそうです。また、顔認識を活用して無人店舗への実現も視野に入れているとのこと。
NECでは、「正しい未来になるかどうかを考察する」ことをデザイナーの立ち位置としているようでした。デザイナーというと、見た目のグラフィックを作り上げる人を想像するかと思いますが、そもそも"Design"が"設計"や"ある方向に向ける"ことを示唆することから、それを大局化したポジションなのかもしれません。
社会や顧客のインサイトを探索し、ステークホルダーとともにワークショップを開く。そして、どういう対象者にどんなものを作るのかをインターフェースに落とし込む、という一連の工程をデザイナーが担っており、幅広く立ち回れる裁量と同時に責任の大きさを感じました。
Google Cloudが提供する機械学習API
グーグル合同会社 Google Cloud デベロッパーアドボケイトの佐藤 一憲さんは、Googleが目指す「誰でもできる機械学習」をテーマに、いくつかの機械学習のデモを発表されました。
例えば、りんごとみかんを識別しようとするとこれまでは色や形状と各々の特徴を定義して区別させていたようですが、ニューラルネットワークという技術により高い精度で認識できるようになったそうです。Googleサービスはそうした機械学習を利用しており、最近Gmailでも返信の12%を自動返信できる「スマートリプライ」という機能が導入されました。
次に、Googleが学習済みモデルを提供する「Cloud ML API」にフォーカスを置いて説明されました。
こちらの動画が、Googleで具体的に何ができるのかを分かりやすく紹介しています。例として、カメラから撮った画像をクラウドAPIで結果を取得し、顔検知・感情分析・物体認識といったことができるそうです。
また、Vision Explorer というコンテンツからも、GoogleのCloud Vision APIによってクラスタ分析で3D空間上に似た画像を分類して可視化することもできるので、機械学習を一から始めようとすると敷居が高い部分をGoogleのサービスを活用することで作りたいコンテンツに集中できるのがイイですね。
Yahoo!カーナビ 多様化するインターフェイスの活用
最後は、ヤフー株式会社 Yahoo!カーナビ サービス責任者である上永 徹さんの発表です。
www.slideshare.net
これまでカーナビは車載の据え置き型が一般でしたが、近年スマホで自由自在に表現、操作できるデバイスでカーナビを提供するようになってきました。そうした中で、2017年12月時点でYahoo!カーナビは1200万DLもされており、広く使われているように見受けられました。
一方で、「スマホアプリはドライバーの命をお預かりする以上、独自の安心安全ガイドラインを定め、安心安全を第一に考える必要がある」と上永さんは仰っていました。道路交通法でも運転中にスマホを手に持って操作、注視することは禁止であり、運転する側としてはその使い方、提供側もそれが適した機能であるかが強く問われていると言えそうです。ユーザ側のニーズとして経由地の追加ができないことを例に挙げられ、ただ実際運転の集中を妨げないようスマホを操作させたくないことから、使い勝手を追求できない場合どうすれば良いかが検討事項であるそうです。
また、地図のインターフェースについても諸説ありますが男女で読み取り方の傾向に違いがあるそうです。男だとサーベイマップ的知識(俯瞰して道を理解する)に長けており、女性はルートマップ的知識(自分視点の景色で道を理解する)に強いということで、アプリでもどういう見せ方が最適かが難しそうではあります。
他に検討したこととして、音声操作も挙げられました。確かにタップ操作に比べ運転の集中を欠くことは少なくなりそうであるものの、音楽、空調、会話、走行音等の環境音により音声認識が難しくなる、マイクは音声起動か手動起動か、音声対話だとシナリオ作成が複雑と、様々な課題も出てくることから、扱いやすい機能になるかどうかはもう少し先になりそうな気がしました。
今後コネクテッドカーの実用化によっては、運転する必要がない自動運転の可能性も出てくるかと思います。が、導入される車も限定的であることからカーナビの需要は依然残るわけですし、ただ普段スマホを使う状況よりも制約を受けている中でどういう答えを出していくかが今後の課題と言えそうです。
振り返り
VUI(Voice User Interface)でいうと、一般的なものだとAppleのSiriやGoogleの音声アシスタントがスマホに搭載されこれまでのアクセスポイントでした。アニメだと「東のエデン」のジュイス、映画なら「アイアンマン」のジャーヴィスでしょうか。
昨年から、 Google Home やLINEの Clova が家電量販店などの店頭にも並ぶようになり、スマートスピーカーが一気に取り上げられるようになりました。
私の会社でも実験的にGoogle HomeやClovaの展示会が催されましたが、「今日の天気は？」「音楽聞かせて」 のやりとりを拾い上げてレスポンスしてくれる精度面が思っていたよりも良かったのが印象的である一方、他にどういう使い方ができるのかがイメージしづらいところでした(天気を聞くだけの一方向的な使い方だと次第に使われず置き物化してしまいそうで...)。
そうした意味で、最初の発表に上がったWHITEは先行して音声インターフェースのUXデザイン専門組織を立ち上げ、アプリまでリリースする実績を残したのはすごいと思いました。
据え置き型VUIが今後どれだけ普及し伸びていくのか、多少の予測はできるでしょうが作り手として可能性を考察し実践したケースは稀少ですし先行者であればその盛り上がりをリードすることもできますし。
Googleの機械学習を扱いやすくしたアプローチも、その先行事例の一つと言えるでしょう。普段扱っていない領域であり敷居・学習コストの高い機械学習という分野をAPIを使って誰にでも扱えるようにしたのはさすがGoogleさんですし、一つのビジネスモデルになっていくのだろうと感じました。
Yahoo!カーナビは、ユーザからの需要とサービス側の供給のせめぎ合いを考えさせられました。スマホをカーナビ代わりにできたのは大きい一方、法的な制約下の下スマホを注視しすぎずユーザがやりたいことをいかに達成するかという課題の大変さを感じました。音声が難しいようなら、脳波でなんとかならないかと思いつつ、カーライフを担う役割としてこれからも頑張ってもらいたいなと思いました。
NECが顔認識を扱っているというのは今回初めて知りました。これもまた一つのインターフェースでしょうし、個別認証からもっと広い使い方ができないかなぁと想像しつつ、私もより良いインターフェースのあり方を少しでも考察し形にしていきたいなと考えさせられました。
「思いつく」を考える展で感じた、クリエイティビティのきっかけ
2018年になりました!
個人的には、今まで腰の重かった個人制作等のアウトプットにもチャレンジしていこうと思いつつ、インプットかつ気分転換として展示を見に行こうと思いました。
昨年末に アドミュージアム東京 がリニューアルしたものの休館日と重なったりしてそのまま年を越してしまいましたが、やっと見に行くことができました。
リニューアル後の常設展
これまで2階から降りながら作品を見ていく流れでしたが、リニューアル後は1階が展示スペースになり2階がライブラリになっているようです。以前に比べて開放的なスペースになっており、壁面にはプロジェクターにコピーが投影されたり、サイネージで広告の歴史を紹介したりと、全体的にはデジタルな展示手法になっています。
ローポリの3Dキャラクターを使い時代によって移り変わり行く広告の説明をしています。こういった可愛らしいキャラクターがあるだけで、説明調の展示にも温かみが出るような気がします。
テーブル状のディスプレイが幾つか設置され、そこには過去の広告作品を一覧化されていて、タッチするとその作品の情報や動画を見ることができます。
リニューアル後のイメージで気になっていたのが、雲のような白いオブジェクトが天井からぶら下がっているものです。これは中に入ると広告のCMを見られるようになっています。リニューアル前や他の展示でもそうですが、小さいディスプレイ型で見せるものは展示空間の環境音を配慮してかヘッドフォンを据え付けて、来場者はそれをかけて聞くという流れになっていましたが、わざわざそれをしなくても良いというのは新しいです。外観的にも一つの展示オブジェクトにも見えるので、展示スペースを占有しそうなもののこれもまた一つの展示アプローチと言えそうです。
「思いつく」を考える展
今回の目当ての一つが、「思いつく」を考える展 になります。話題のヒット作や優れたアイディアの裏側にある、「思いつく」に至る過程や思考方法を紹介するというものです。
見に行った理由としては、普段エンジニアでロジック立てて考えることから、自分ではどちらかというと論理的思考に強いと思う反面、クリエイティビティや発想がなかなかでないこともあり、デザイナーが次々とアイディアを出していく発想の引き出しには憧れを持っていたりしました。今後アウトプットをしていきたい私としては、「思いつく」スキルも身に付けたいところです。
最初に、脳科学者の茂木健一郎さんが、脳科学の見地で「思いつく」に至るシチュエーションを紹介していました。例えば、集中して考えた後にリラックスするとひらめきが生まれるとか、脳の整理整頓を促すためにデバイスから切り離れた環境を作ることを挙げていました。
その上で、「思いつく」を考える手法として以下の9つがあるとのこと。
- かくしてみた
- ふやしてみた
- シンボルつくってみた
- くっつけてみた
- ばらしてみた
- くらべてみた
- やめてみた
- やばくしてみた
- いれかえてみた
展示では、それらの手法ごとに照らし合わせた事例とアウトプットに至るプロセスの紹介がありました。
「かくしてみた」なら、盛岡のさわや書店フェザン店に置かれて注目された文庫Xが取り上げられていました。可視化される要素を隠すことで先入観を取り除きPOPの文字情報で想像し購入喚起を促すもので、福袋といいビジュアルに左右されない販促アプローチでは興味深いものではあります。
他にも、「ふやしてみた」なら多数の品揃えを誇るドンキホーテ、「シンボルつくってみた」は多様な生き方を尊重するLGBTを象徴する「レインボーフラッグ」、「くっつけてみた」だと教育 × エンターテインメント で昨年注目を浴びた「うんこ漢字ドリル」を、関係者のインタビューを交えて紹介されていました。
余談ですが、この9つの手法を見て、つい数学やプログラムに関連する用語と照らし合わせて連想しました。もっと良い表現はあると思いますが、こんな感じで。。
- かくしてみた -> 隠蔽化(カプセル化)
- ふやしてみた -> 加算
- シンボルつくってみた -> 抽象化(クラス)
- くっつけてみた -> ベクトルの加算?
- ばらしてみた -> 因数分解
- くらべてみた -> 比較
- やめてみた -> 減算?(要素を除外する意味で)
- やばくしてみた -> ベクトル(方向・力)
- いれかえてみた -> 置換
振り返り
「思いつく」ことは、これまで広告業界で強く求められるスキルでもありました。クライアントの要件からコンセプト・具体的アプローチ・アウトプットまでを日々模索するものでしたが、今回の展示では広告だけに限らずプロダクトやサービスといった事例も多く紹介されていました。電通CDCの古川 裕也さんの著書 「すべての仕事はクリエイティブディレクションである。」 でも、クリエイティブは広告だけの領域に止まらないことを示唆しており、それを再認識する展示でした。古川さんの著書では、アウトプットに至る一連のフローと事例を紹介していましたが、今回の展示はその中でも具体的なアプローチの考えるヒントを、わかりやすくブレイクダウンした形に見受けられます。
本展示にて、「思いつく」ことはプランナー等の一部の人が備えているものではなく、すべての人が扱えるスキルです。それをスキルとして生かすには、筋肉を鍛えるように(これも書籍からの受け売りですが)日々「思いつく」ことを習慣づけることにあるのだなと感じました。
JSでMVCパターンを使ったデモを作った - jQuery編 -
背景
私は、デジタルハリウッドである程度フロントエンド系のスキルを身につけて卒業しその後なんやかんやあってWeb系の制作会社に入りました。
デジハリにいた頃が2011-2012年の辺りで、それから制作会社に入ったのが2015年と結構な開きがあり、そして、その間scssを使ったコンパイル、browserifyといったJSビルドツールや、果てはフロントエンド全体での開発環境等様々なトピックがありました。そもそも2011年頃から現場レベルでも意識していたところなのかもしれませんが、専門学校上がりで実務レベルがなかった自分にとっては大量の情報量を受ける良い洗礼でもありました。
そして現在、開発環境とかビルドツールの知識も得たものの、分かったつもりになっていたり、名前だけ聞いてそのままだったりする事柄もあるため、以下の点を踏まえてブログに書き止めようと思いました。
1. JSの基礎領域をターゲットに自身の振り返りを行う
2. 最近取り上げられている or 今後注目される技術分野を調べてみる
1.は、普段のJS開発だと、アニメーションはTweenMax、AjaxならjQuery、とライブラリ頼りで進めているところがありました。
コアな部分の実装にフォーカスするために他の事柄にはライブラリで捌く判断も大切ですし、車輪の再発明的なものにするつもりでもないのですが、やはりどういうロジックで動かすのかを自分の中でも落とし込んでいかないと、そこで止まってしまう気がして。
なので、こういったJSの基礎的な領域をまずは自分なりにロジック立てて作ってみつつ既存ライブラリのコードから理解し、ひいてはベストな実装方法につなげていけるといいなと思ったりしています。
2.については、最早フロントエンドなら常識なのであろうReactのような仮想DOMを扱うライブラリやら、WebVR・AR、今着目されつつあるProgressive Web Appsといった新し目の技術領域を調べて得たことをメモなりまとめていこうと思います。
こちらは汎用的な1.に比べ固有なケースで使われ用途も限られてくるでしょうが、フロントエンドとしては放ってはおけない新しい分野なので逐次勉強してみようと考えています。また、フロントエンドに限らずUnityなりインタラクティブ系のツールに関する事柄もターゲットに据えていくつもりです。
今回は、1.の領域で「MVCパターン」の事柄を整理しようと思います。とはいえ、現時点では現場で学んだ点の整理にフォーカスをおいてメモしたものになります。書籍やサイトで得た事柄も追って追加していこうと思います。
MVCとは
O'REILLY の JavaScriptデザインパターン によると、
「MVC(モデル・ビュー・コントローラ)と、役割を分離させることで良いアプリケーションの構成を目指すアーキテクチャデザインパターン」のことを指します。1979年のSmallTalk-80の作業中に考案され、デスクトップアプリケーションやサーバサイドアプリケーションに活用され、JavaScriptにも適用されるようになりました。今では、MVCから派生してMVP(モデル・ビュー・プレゼンター)やMVVM(モデル・ビュー・ビューモデル)等のようなMV*系といったバリエーションが増えていきました。
MVCのそれぞれの役割を説明すると、以下のようになります。
モデル・・・アプリケーションのデータを管理
ビュー・・・モデルを視覚的に表現してその瞬間の状態を示すもの
コントローラ・・・モデルとビューの中間に位置し、ユーザがビューを操作した時にモデルを更新する
大まかな流れとしては、
- ビューを操作してコントローラがモデル更新を実行する
- モデル更新を監視していたビューが更新を受けて状態を反映する
になります。ちなみにこのとき注意するのは、
「モデルの更新処理はモデル側で行うものであり、ビューやコントローラはモデルのデータを参照できても直接更新をかけにいってはいけない 」
です。以前Javaを触ったときにカプセル化というのを習いましたが、モデルにはsetterがあり、ビュー・コントローラはgetterしかないというイメージでしょうか(違うかなぁ)。
ちなみに、はじめてMVCパターンの説明を受けた時、モデルというのはデータベースと同義と思っていました。
ただ、ここではフロントエンド領域でのMVCパターンであり、サーバからAPIで取得したデータをモデルに管理するという方が正しいのかもしれません。
関わった案件でいうと、ブラウザサイズだったり、サウンドを有効になっているかどうかといったものをモデルに管理させていましたが、これは作り物の要件によって変わってきます。モデルにどういうデータを管理させるかで、他のビューやコントローラの設計にも関わってくるように捉えています。
デモ
堅苦しい内容になってしまったので、実際に作ってみたいと思います。
シンプルではありますが、ToDoアプリです。
使用したものはjQueryと見た目の調整にMaterial Design Liteを使用しました。
https://qeita.github.io/js/mvc/jquery/todo/
Github Rep:
https://github.com/qeita/js/tree/master/mvc/jquery/todo
jQueryで作るにあたって
本サンプルでは、大きくModel・View・Controllerの3つのオブジェクトを用意しました。
ViewとControllerはnewしてインスタンス化しています。
最後にそれらをラップしたMain関数を実行させています。
https://github.com/qeita/js/blob/master/mvc/jquery/todo/assets/js/app.js
const Model = {
...
};
const View = function(o){
this.o = o;
this.init();
};
~~~
const Controller = function(){
this.init();
};
~~~
function Main(){
new Controller();
new View(document.querySelector('.js-list__box'));
...
}
Main();
まず、ToDoアプリを作るにあたりモデルにどのようなデータを管理するかを考えてみました。
サーバからAPIでデータベースのタスク情報を取得する想定で、itemData.jsonをAjaxで取得するとします。
なので、取得したタスク情報を管理することにしました。todosプロパティを作りここはシンプルに配列形式で進めます。
const Model = {
todos: [],
...
}
次に、コントローラ側にビューの要素をクリックした際、Model.seeTask(_n)のように、モデル側のメソッドを叩くようにしています(この場合、モデルの値を直接更新かけずメソッドを参照しているだけ)。
メソッドを受けて、モデル側でデータの更新をしてから変更したということを通知する必要があります。ここは、jQueryのtriggerメソッドを使ってカスタムイベントを発火することにしました(triggerメソッドは自分で作ったカスタムイベントを発火させることができます)。
カスタムメソッドとは、クリックやマウスホバーのような組み込み定義されているイベントに対し、独自で定義したイベントです。ToDoアプリだと、タスクの読み込み・タスクの詳細表示・タスク追加・タスク削除を以下のようにモデル側に定義しました(今回は余分にモーダルの開閉イベントも定義しています)。
/**
* イベント
*/
events: {
LOAD_TASK: 'LOAD_TASK',
ADD_TASK: 'ADD_TASK',
SEE_TASK: 'SEE_TASK',
OPEN_MODAL: 'OPEN_MODAL',
CLOSE_MODAL: 'CLOSE_MODAL',
REMOVE_TASK: 'REMOVE_TASK',
},
最後に、ビューはどのようにしてモデル更新を受け取るのか。これは、Model変数を$(...)でラップしてjQueryオブジェクトとして扱います。それをonメソッドでカスタムイベントを受け取り、以降ビュー内のメソッドで状態を更新するようにしています。
$(Model).on(Model.events.LOAD_TASK, function(ev){
me.render(me.o);
});
振り返り
デジタルハリウッドにいた時は、jQueryを多用して見た目の処理にとらわれていたため全体の設計が意識できていなかったのですが、こうしてモデル・ビュー・コントローラを分けることで、UIにフォーカスした記述より行数的には膨れ上がってはいるものの、見通しとメンテナンスに良いコード作りになります。
今回はシンプルに1ファイルで完結しましたが、制作規模が大きくなったり多機能に及ぶ場合はモジュール毎にファイルを分けて管理しrequireやimportで結合する形になります。ビューも幾つかのUIがあるならそれに応じて分けて管理すべきところですし、モデルも今回はオブジェクトで作りましたが、複数のUIで参照されるようになるならシングルトンで管理し複数インスタンスを作らないようにしたりという方法もあります。
こういう手法を取り入れることで、大規模なサービスやサイト制作でも分業体制で進めやすくなります。逆に、ランディングページのような小規模で機能もそこまでないようなら使わなくても良いところで。
個人的には、コントローラ内のビュー操作がビューと分けられているのが気になり、やるならビュー内で操作も含めて管理してしまいたいという気持ちでいます。
Unity Developer's Delight に行ってきたよ(後編)
Unity Developer's Delight に行ってきて、前編 では最初の登壇者5名の内容を整理しました。引き続き残り5名の方々の内容にも振り返ってみようと思います。
MuRoさんの「MakeItFilm」
Muro さんは、もともと3DCGデザイナーで現在は株式会社エクシヴィのVRディレクターをされています。今回、3DCG制作現場の課題から作った「Make It Film」をご紹介いただきました。
まず、3DCGの制作は細かな作業の積み重ねでできているところが大きく、マウスで物体やカメラを回転してテクスチャを調整して移動して...と、CGの専門知識はもちろんのこと、マウスやキーボード操作、モニター越しの空間把握を要求される作業です。
そこでMuroさんは、VRで映画を作るクリエイティブツールとして「Make It Film」を作られました。直感的なカメラワークや自分の動きを役者(3Dモデル)に投影できるリアルタイム演技と、VRをコンテンツでなくツールとして昇華させたところが素晴らしいと感じました。
現在もアップデートをしている最中で、オンラインでの共同制作や表現のシェアリングも検討しているそうです。別途最初の操作にかかる学習コストはありそうですが、これが実用化し制作現場でも取り入れらえるようになったら、制作効率の向上・制作現場環境の改善に繋がりそうな気がします。
西村 太雅さんの「Draw Near」
西村 太雅さんは、現役高校生でUnityインターハイ二連覇、U-22プログラミング・コンテスト経済産業大臣賞受賞を果たした、将棋の藤井四段のような将来が期待溢れるクリエイターです。もともとは中学生の頃、Life is Tech というプログラミングスクールでAndroidアプリを作ったことがプログラミングを始めたきっかけだったそうです。それから、Unityを使い始めたようですが、AndroidアプリでJavaを習得していたことからUnityのC#もスムーズに扱えるようになったというから、柔軟性の高さを伺えました。
Unityインターハイに応募した「Draw Near」 は、宇宙に漂流しながらも生き延びて地球に帰還するSFサバイバルシミュレーションゲームになっています。例えば、漂流したステーションとドッキングして拡張したり、漂流者を助けて仲間にする等のゲームシナリオとシステムは大人顔負けのものでした。また、各プラットフォームでのパフォーマンス差異がありそれを最適化するプログラムを作ったり、音楽や3Dモデルにおいても全て自作しているそうで、友人と2人で夏休み返上で作り上げたという学生の本気度の高さに感銘を受けました。
ところにょりさんの「あめのふるほし」
ところにょり さんは、「ひとりぼっち惑星」や 「あめのふるほし」という、独自性ある世界観を作り出しているクリエイターです。
前段が西村さんということもあり、どうやったら才ある若者の芽を潰せるかという冗談から始まり、ご自身のゲームの方向性を紹介してくださいました。
ところにょりさんの作品は「得るゲーム」「失うゲーム」の方向で、自分が作るものは失う要素のゲームが多いと話されました。通常のゲームはリスク・リターンのさじ加減である一方、このお方は記憶を失ってできることが少なくなってくることをやっていたりします。
話は変わりますが、以前田中圭一さんがゲームクリエイターにインタビューする「若ゲのいたり」で、星のカービィを作った桜井政博が「面白いゲームはリスクに見合ったリターンを得られる」と仰っていました(参考)。一見ところにょりさんの作品はそのルールと違うようでありますが、世界観に通じた失う要素がゲームの個性を強めている、そしてその個性がリターンなのではと思いました。
ご自身も売れるためのゲームを作ろうとは思っておらず、高校生の自分が楽しめるようなものを作りたいと仰っていましたし、自分が作りたいものを作るインディーズマインドの強さを感じました。
勅使河原 一雅さんの「スイスでの展示で作ったもの」
勅使河原 一雅 さんも元FlashクリエイターでWeb業界でも有名な方ですが、最近Unityを触りだしたことと今スイスのMuDaで行われている展示について紹介いただきました。
ゴロゴロと横に転がっては異性とキスを交わして水に落ちては転生するINDIA 。父が病気でなくなったことを契機に作った、時間をかけて蓄積される後ろめたさを汚れのようにひたすら洗い流そうとするMUNDA。口の動きを連動させ相互で何か会話なのかやり取りする間を表現しているDiagolus。勅使河原さんの作品は、テクニカルスキルの高さ(MUNDAは人の形状がぬるぬる手足を滑り込ませた動きになっていますが、粒子状のものを使って人型にしているのだとか)もありますが作るもののアート性や世界観が独創的なものばかりでした。
モデレータの方も「勅使河原さんが作るものは、勅使河原らしい仕上がりになる」と評していたように、Unityで作ったとは思えないようなアーティステックな仕上がりがすごいなと安易な感想ではありながらそう感じましました。
山 健太郎さんの「HUMANITY」
山 健太郎 さんは、前編のksymさんと同じくthaに勤めているテクニカルディレクターです。もともとthaにはUnityで作るナレッジが少ないことからksymさんにレクチャーを頂いた経緯があるそうです。
そのthaが最近、開発中ながら動画公開した作品「HUMANITY」 でやった工夫を話されました。私もイベント前に動画で見たことがありますが、あれだけの人物の3Dモデルを滑らかに動かせるのかと驚きました。以前からも鳥を使ったゲームコンテンツ「GUNTAI」では500羽、METAFIVEのライブVJでも魚を100000匹動かしていたというから、大量の物体を使った群衆アニメーションのナレッジ・実績はあるようです。
今回は人物が飛んだり落ちたり武器を使って構えて相手狙って打ったりとモーションが多岐にわたるため、それを管理しつつFPSを高い水準で維持するかが検討課題だったとのことで、Unityも調整次第で物量もコントロールした実装ができるのだなと、まだ自分でも理解が追いついていないながらも感じました。
どういうゲームルールにするのか、現在検討中らしく公開が待ち遠しいところです。
と、濃いネタ続きの10人LTでした。
自分がこれから必要なところに、Unityの基本スキルと応用(シェーダーあたりまで扱えるようになりたい)がありましたが、今回の登壇者のお話を聞いてまずは自分が何を表現したいのかを決めることが大きいと感じました。
これまで技術スキルを磨きそこから作りたいものを作るというものでしたが、Unityはゲーム等のコンテンツを作るツールがすでに揃っているわけであり、「作りたいもの」->「それを作るにはどうやってやるか」と逆算的に考えた方が良いと思いました(もちろん基本操作は先に身に付けるところです)。
そこから技術スキルも追いついてくるわけですし、ちょっとマインド変えてUnityと向き合いたいと思います。そして、Unity Developer's Delightに登壇できるようなゲームやネタも次回までにこさえときたいですね。
Unity Developer's Delight に行ってきたよ(前編)
12月16日、忘年会のシーズンですが勉強も兼ねまして Unity Developer's Delight に行って参りました。クリエイター10名が10分ライトニングトークを繰り広げるというもので、そうそうたる面子と貴重なお話が聞けました。
私自身、Unityは基本操作と簡単なミニゲームを作ってみた程度でしたが、先日行われたdotFes 2017 でも大半の展示でUnityが使われていたことから、本腰入れて扱えるようにしたいと思っておりました。その上で、自身のモチベアップも兼ねていってみたかったというのもあり。そこで聞いた内容を自分なりの考えも添えつつ整理してみました。
大貫 真史さんの「カニノケンカ」
大貫 真史 さんは個人でやっているディベロッパーで、「ACE OF SEAFOOD」をヒットさせたというインディーズゲームのすごい人。最近作ったゲーム 「カニノケンカ」 を作った経緯と、機能周りの話を聞くことができました。
ゲーム機のコントローラが人の動きと連動するような形状になっていない -> カニの形状に近いからカニを使ったゲームにしようと思ったというのは、思いよらなかった角度の発想でした。「作りたいものがあって作る」と言うより「今あるもので作る」という料理の発想に近いのか(?)、ともあれ相手のカニをひっくり返したら勝ちとシンプルなルール性であり、そこに水中なのにぶつかった時に火花が散るエフェクト、カニに武器をもたせる(デモではカニにモーニングスターを持たせてました)、一対多の対決ができたりと異常なくらい(賞賛の意味です)の凝り方をしていて技術レベルの高さを伺えました。
ksymさんの「Unityで作るクソコンテンツ」
ksym さんは、インタラクティブ領域で知らないものはいない中村勇吾 さんが代表のtha(http://tha.jp/)に在籍していたクリエイターです。
ksymさんはこれまでに作ったアプリとそれを考えるに至った経緯を説明してくださいました。痛々しくもひたすら階段から落ち続けるKarateStairs(現在はComing Soonの模様)や、空手と占いと掛け合わせたKARATE URANAI、Unityの WebCamTexture とポストエフェクトで撮ったものをピクセルアートにするカメラアプリUTUや、ワードパズルを簡易化したPX+を紹介されました。
ksymさんのすごいところは、アイディアは〇〇と△△を組み合わせるところの〇〇と△△のチョイスとギャップが色濃く出ていたと思います。例えば、ひたすら階段から落ちるだけではつまらないため、女性が好きなアボカドを階段に配置させたり、KARATE URANAIでも男に人気のある空手と女性に人気のある占いを掛け合わせたら売れるんじゃないか(そしてこれにもアボカドが出てくるw)といった、組み合わせされるもの同士と出来上がった時のギャップ感にインパクトがあり、そこがクリエイター色の強い作品になっていると思いました。
藤岡 裕吾さんの「COLOR GRADINGのススメ」
藤岡 裕吾 さんは、「アカとブルー」という、大量の弾をスマホでも実現させたいわゆる弾幕シューティングゲームの開発者。Made with Unityで記事にされたり、Unityマニアックスを著作した人の一人です。
藤岡さんは、「ゲーム作りは恋愛と同じ」という会社の社訓から、相手に気に入ってもらうためのおしゃれ(ゲームでいう画面映え)をどう工夫するかを説明されました。ポストエフェクトは服で言うところのアウターであるが使い方を誤るとかえってやりすぎ感が出てしまう。それに対し無難におしゃれにできるカラーグレーディングを活用しようという話でした。
確かに、独自性あるゲームを作ろうという思いはあってもデザイナーでないとなかなかに色の加減調整は難しいところ。それなら、SNSの写真にあるような現代のトレンド(一般的な格好いい絵面)を探れば、安定感もあり最大公約的に親和性のあるゲームになりそうな印象を受けました。
ちなみに、藤岡さんのオススメプラグインは Amplify Color と Amplify LUT Pack。
阿部 貴弘さんの「成功の定義 - インディーズ作品はどうして「失敗」してしまうのか」
阿部 貴弘 さんは、かつてFlashディベロッパーとして「Progression」フレームワークを作ったお人。今は脱FlashしてUnityエンジニアになっているそうです。
その方が、今は新感覚テキストシネマMONOTO-SITUATION という作品でアニメーション監督もされているから驚きです。今回は、ご自身の経験も交えつつインディーズ作品の「成功」とは何かを話されました。
まず、「100万本の大ヒット」と聞くとわかりやすいヒットの指標を示しているといえますが、正確には「目標本数」と「実売本数」によって評価されます(例えば、50万本を目標にして100万本なら成功でしょうし、200万本目標で100万本ならそれは失敗)。辞書の通り、「成功」とは物事を目的どおりに成し遂げることを言うが、それは過去の自分の実績から試算するしかない訳です(同ジャンルの市場規模で見ると宣伝力その他差異が大きいため参考にならないとのこと)。
インディーズタイトルでは販売本数の目標を立てられない、であればどう解決するかを阿部さんは2通り提示しました。一つは、「趣味にして完成を目標とする」。二つは、「作ってどうしたいかを考える」。後者は、例えば企画を売り込みたい・世界観を売り込みたい・就職活動に使いたいとかをあげていました。それが目標になると具体的なアクションが明確になるし、周りの人も協力しやすくなるという話でした(阿部さん自身も応援しがいのある人になることを心がけているそうです)。
これは、インディーズタイトルに限らず日常生活での目標設定にも通じるところがありそうです。目標を据えるにしても、他者との相対比較というよりは今の自分を対象にした相対比較を意識するところは人生訓とも言えそうですし、Unityネタによらず周りにも紹介してみたい魅力的な話でした。
chiepommeさんの「今年Unityで作ったものの紹介」
chiepomme さんは、ハシラス のかわいいものが大好きVRエンジニアで、今年VRコンテンツを10個も作ったというからスゴイかつ羨ましい。そのうちの幾つかを紹介していただきました。
「VR音声認識脱出ゲーム」は流行の脱出ゲームとVRを掛け合わせたもので、VRはヘッドマウントディスプレイだけだとコントローラがないため音声認識で進めるゲームコンテンツになっているそうです。具体的には、Julius と呼ばれる音声認識エンジンを使って音声認識で場所を指示するというもの。ただ、音声認識の精度や普段扱ってないことからコマンドがわからない等色々と反省点があったようです。
他には、「Twitter用MV生成ツール」。音声ファイルと画像から動画を生成するという使ってみたいツールです。作ったオーディオデータのみだとTwitterにあげられない点に着目して作ったそうです。ツールを作ったところリツイートをたくさんされたというから、楽曲を作るクリエイターにも有用なツールですね。
最後は「ハッピーおしゃれタイム」という、女児のアバターを使って、アイドルになったり衣装を選んだり、音ゲーをやったりと「なりきりVRコンテンツ」を紹介しました。通常、VRコンテンツは一人称視点でVR空間の外観を見渡し進むのが一般的ですが、別の何かになりたい潜在的欲求を没入感を活用して実現させたのは興味深い試みでした。
別の性別や種族を選んだりと、違う人生を構築するところは、ネットのオンラインゲームにもあったものですし、今後こういうゲームが増えてきそうな気がします。まさに、「VRは可愛いが不足している」(by chiepommeさん)
と、計10名なので前後編に分けましたが、各人濃ゆいネタが多く果たしてどこまで書けるやら(記憶力的に) 。。頑張って整理して後編につなげたいと思います。
