らんどなテックブログ

エンジニアのいろいろ

スマホゲームの UI について思うこと

ここで書いているのは、特にアウトゲーム(遊び以外の部分・画面)の UI について思うことです。

主題

ネイティブアプリに比べると、スマホゲームの UI 周りは、スマホに特化させた操作性をあまり導入していない印象がある。

背景

自分はもともとネイティブアプリのエンジニアをしており、途中からゲームアプリ開発へ切り替わった。その中で、主題のようなことをちょこちょこと感じる機会がある。

 

例えば Facebook の場合、写真を閉じる UI として上下にスワイプするというのがある。

Facebook は上下にスクロールするのが基本操作であるため、写真を閉じてそのまま次の操作へシームレスにつながるというのが非常に心地よい操作であると思う。

他にもメールアプリでは、左にスワイプすると削除ボタンが表示され、そのままスワイプを振り切ることで削除を確定することができる。これなら一度指を離してから決定ボタンをタップする、といった二度手間がない。

Kyash というアプリでは、送金の際の操作を自分の前方にスワイプすることで確定するため、自分から送り出す、という行為を直感的な操作で実現していると思う。

 

翻ってゲームの操作を考えると、こういった操作性はあまり見かけないと思う。

キャラクタやアイテムの一覧はスクロール操作、タップや長押しで詳細表示、画像を全画面表示した場合はもう一度タップしたり画面端に表示されたバツボタンで閉じる。

もちろん、他でもよく見る UI で統一することでユーザの学習コストを下げ、安心して操作してもらえるという利点はある。必ずしも凝った操作性が優れているわけではないため、現状に問題があるとも思わない。

 

仮説

とは言え、ゲームアプリではなぜ凝った UI の導入がないのか、という点が自分の中ではずっと気になっている。そこで、自分なりに考えをまとめてみたい。

① 既存のゲームが強烈な見本として存在しているため

スマートフォンアプリは、これまでにない存在だったと感じる。そもそもスマートフォンというそれまで無かったデバイスと密接に関わる存在であり、マウスやキーボードを通さず直接操作するという新しい体感をもたらした。

そのためスマートフォンアプリの開発では、PC アプリケーションなど既存の知見に習わず、実在の体感に如何に近づけるか、といった志向で UIUX の開発が行われてきた。

一方、スマホゲームはスマートフォンアプリであるとは言え、コンシューマやアーケードのような「既存のゲーム」という楽しさをいかに取り込むか、というところが主眼だったのではないか。既存の操作性は当然ボタン操作などの堅実なものが多く、それに倣ったことが昨今のゲーム UI のベースになったのではないか。

② ゲームというミスが許されない環境下での操作性検討が影響しているため

これは、先日の勉強会でいただいた意見を元にした考えである。

ゲームでは、誤った操作でキャラクタがやられてしまうなど、ユーザにとって当然のようにミスが許されない環境がある。そのため、開発者も絶対に誤解しないような UI、というものを検討すると考えられる。

これは本来インゲーム(遊びの部分)に導入される文脈ではあるが、その考え方を持ってアプリ全体の UI が検討されるため、凝った UI というものがあまり導入されないのではないか。

③ ゲーム開発者にそのあたりに特化したタイプがいないから

これはやや暴論な気がするが、自分が関わってきた中では割と当てはまっている印象はある。ゲームを開発することに強いモチベーションを持つ開発者(エンジニアに限らず)は、「遊び」を作る部分への興味が強い人が多い。そうでなくても、課金導線やユーザのゲームサイクル構築など、もう少し俯瞰的なレイヤーでチカラを発揮するタイプが多い印象がある。

デザイナも、どちらかと言えばキャラクタやアイテムなど、イラスト作成のタイプが多い印象がある。UI 設計、というもの自体に特化した人材がゲーム業界にそこまでモチベーションを持っていない、少なくとも昨今のネイティブアプリやウェブサービス開発に流れている、というのはあるのではないだろうか。

余談

ここまでゲームに凝った UI が一切ないような書き方をしてきたが、そんなことはないとは思っている。

自分が知っている中では、デスティニーチャイルドが当てはまる。

トップ画面に設置された UI は引っ張り出すような操作が可能であり、そのまま次の画面に遷移することが可能である。

f:id:ryu_rand:20190321182459p:plain

他にもドラガリアロストは画面切り替わりが極めてシームレスになっており、操作性は普通でも新しい体感を提供していると感じる。

おわりに

繰り返しになるが、自分は必ずしも凝った UI が良いとは思っていない。ゲームアプリはあくまでインゲームが主役であり、ソシャゲであればそれに加えてユーザが興味を持つのはガチャ画面あたりではないだろうか。

メニュー画面やキャラクタ強化画面などはあくまでサブの位置づけだと思うし、わかりやすさが最優先なのも正しいと思う。それでも、スマートフォンというデバイスに沿った新しい操作性がゲームから生み出されれば、それもまた新しいゲーム性の発明につながるのではないかと思う。

ryu-rand.hatenablog.com

 

「【TECH×GAME COLLEGE#16】ゲームに学ぶUXデザイン」に参加しました

勉強会に参加してきました。 techxgamecollege.connpass.com

自分が UIUX に興味があることもあり、非常に刺激を受けられてよかったです。

考察

UX が捉える範囲が、サービスを使う前から、サービスを繰り返し使うことによって受ける影響まで含む、というのは考えが及んでいなかった。 他にも、感覚で理解していたもののうまく言語化できていなかった点で気付きが多かった。

  • ゲームはサービスとコンテンツが混在していること
  • ゲームはあえて苦痛を作る必要性があること
  • ゲームならユーザの状況を設計することができること
  • 共感を得る、説得力のあるキャラクタの重要性

その他

懇親会の最後で直接質問させていただいたゲームと非ゲームの UI の違いについては、以前から自分が気になっていることでもある。 この点はまた別の機会に考えをまとめてみたいと思う。

講中のメモ

UX とは

意:サービスを使って得られる体験

  • 使用前、使用中、使用後すべて含まれる
  • @使用中
  • 知覚と反応のサイクルを繰り返す
  • 反応:感情、思考、行動
  • @使用後
  • 体験全体を内省して記憶に残す(いいね、など
  • 誘発された次の行動もこれに含む
  • @繰り返し使用後
  • 経験、記憶が累積していく

これらすべてが UX に含まれる

  • 使用前:価値を期待させる
  • 使用中:使いやすさ、心地よさを提供する
  • 使用後:次の行動を誘発する(行動のコントロール
  • 繰り返し使用後:ブランド価値を高める

ペルソナ・シナリオ・カスタマージャーニーマップ&ユーザ工学

  • 要求定義・要件定義のためのもの、ではある
  • 本来は使用前から繰り返し使用まですべてを網羅するべきもの

行動経済学/ナッジ

  • 行動を誘発する

CX デザイン

UX デザイナの仕事

  • ターゲット決定・インタビュー・観察
  • 分析・アンケートで検証
  • ペルソナの作成

↑でカスタマージャーニーマップができる

  • ペルソナ:個人
  • これ:行動
  • 状況・行動・心理
  • タッチポイント(ユーザとの接点

理想シナリオから要求/要件を定義する

施策・UX 評価

ユーザの協力を得て良否を評価する

  • 専門家の判断に安心せず、当事者からの情報を得る

ゲームの特異性

  • 楽しさをデザインする
  • 苦痛をデザインする
  • 状況(ゲーム内ルール)をデザインする
  • 状況(キャラクタ)をデザインする

楽しさ

  • web にとってはサービスは手段である(楽しいのはコンテンツ
  • ゲームはコンテンツと手段が一体化している

楽しさとは厳密には方法論では語れない(語った人はいる

解釈

  • ゲームではない娯楽もある
  • 使いやすさは楽しさに影響する
  • ゲームの雰囲気は楽しさに影響する

事例(ボタン

  • web: わかりやすさ優先のシンプル
  • game: 雰囲気演出を優先

事例(演出

  • twitter: 上部が最新であることを暗に伝える演出
  • game: 雰囲気作り(実用的な意味はない演出

ゲーム外でも雰囲気を演出する

  • 世界観に沿ったツイートとか PUSH 通知とか

苦痛をデザイン

  • web: 使いづらさは排除
  • 挑戦する楽しさのために敵キャラや障害物を提供
  • 現代:課金させるために苦痛を与える(ゲーム以外でもあり得る)
  • カスタマージャーニーを把握して課金を促す
  • 課金してでも解決したい気持ちが最大化するタイミング

カスタマージャーニー

  • 画面フロー図にプレイヤー心理と施策を追記するとできる
  • サブゲーム:時間は有限だからこそそれを消費させる
  • ここ自体が楽しいのはインゲームと融合しているからか?
  • 他人のコレクションを見せて羨ましがらせるためにソーシャル感がある

ゲーム内ルールをデザインする

  • ゲーム内の状況は設計できる
  • これは web ではあまりできない
  • 手段じゃないからか
  • 基本的に状況は行動を縛る

状況の事例

  • 弾に当たると死ぬ緊張感(COD
  • バリアで無敵になれる爽快感(HALO

  • 理由なく嫌われる緊張感(納得できない

  • 理由なくモテる爽快感(納得できる
  • ゲームのシステムとしてはヒロインの好感度の違いだけ
  • 些細なパラメータの違いだけで印象や展開を変える

キャラクタをデザインする

  • ユーザの周囲にいる人物も状況の一つ
  • ゲームキャラはユーザの周囲にいる人物になりうる
  • シンデレラが結婚してハッピーエンドなのは、本人が幸せだと納得したから
  • 無理ゲーでもチャレンジするのは、(誰かを助けるというストーリを持った)キャラに共感するから
  • 説明文で促すのではなくキャラがユーザに頼む、とかいい例
  • キャラのセリフで説明の読み飛ばしを防ぐ

ユーザの共感を得るには?

  • 人格があると錯誤させる:aibo とか
  • 言動を理解の範囲内に抑える
  • ナラティブを共有する

ナラティブ:原意:当事者の語る体験談

  • 自分ごととして認識できる押し付け感のないストーリ
  • 擬人化も擬人化対象が与えていたナラティブを元ネタにできる手法

Question

ゲームにしかできないことってありそう?

  • 無いと思っている。今はできてないだけ。

ナラティブ

  • 平たく言えば同人誌が作りやすいかどうか
  • キャラの関係性に想像の余地があると作りやすい

懇親会メモ(うろ覚えです

製品開発以外を含めて俯瞰できる UX デザイナーいない?

  • そういう人材はいるが、あまりデザイナーと呼ばれてないのでは?
  • Apple などは広告含めてユーザと製品の出会いを作るという考え方がある

昔は攻略本などのメディアミックスも盛んだった印象

  • 流行ってお互いにやりすぎて廃れた印象もある

ガチャをひくユーザであっても、追加ストーリーいくらで購入、みたいのはヘイト多い印象

  • コンシューマゲームではなくソシャゲを中心としているユーザにとっては無料で遊べることが大前提
  • これまでと異なる背景をもったユーザが増えてきてるのではないか

最近サブスクリプション増えたね

  • 他業種でも増えている
  • おそらくビジネスモデルは今でも模索中

そもそもお金周り見れる開発者っているの?

  • ゲーム学校の生徒にはあまり見かけない

ゲームより非ゲームのアプリの方が UI が洗練されているのでは?

  • その傾向はあると思う
  • ゲームは操作ミスによって失うものが大きいから、誤解されうる操作性を使いにくいのではないか

Android back キーと演出スキップについての考察

 これについて考えていた。

 

多分スキップすべきではない

結論としては、少なくともいきなりスキップさせるべきではないのだろうなと思う。

developers-jp.googleblog.com

ここでの Back キーの基本的な期待値は、前の画面に戻る、トップ画面であればアプリを閉じる(その確認ダイアログを開く)と書かれている。

前の画面に戻るのが適切な場合であれば、という記述もあるが、じゃあスキップさせますはまぁちがうだろうなと。

developers-jp.googleblog.com

ちょっと古いが、こちらのページにも以下の記載がある。

> システム アイコン(「Back」キーなど)に期待される機能の定義を変えないこと。

 

じゃあどうするか

上述の標準的挙動の定義の中に、ポーズ(ダイアログ)を表示するという挙動が例として挙げられている。Back キーの期待値としてややずれている気もするが、これであればユーザの意図でなければキャンセルも可能である。

 

ポーズを出さない仕様のときはどうするか

> Back キーが押された際には何かアクションが起きるようにしてください。何もアクションが起きないとユーザーの混乱を招いてしまう可能性があります。

こういう記載があるので、無視するのはまずいだろうと思われる。Android 標準のトーストや、アプリの UI でなんらかのフィードバックを返す必要がある。

作業見積もりのやり方

仕事における作業見積もりについて、自分がしていることをまとめてみる。

 

やっていることは大きく3点。

  • 自分がしたすべての作業を時間とともに記録する
  • 自分がするすべての作業を見積り時間と共に記録する
  • 自分が活動できるすべての作業時間を書き出す

 

背景

見積もりとは、「必要な時間」-「使える時間」> 0 であることを確認するためのものである。どうしてもこれが満たせない場合は、助っ人を頼むなり期日をずらすなり別途対応が必要になる。

早期にこれができるのなら、別段大した問題はない(と思う)。一番やっかいなのはギリギリになってこういう話をしなければならない場合だ。それを回避するために見積もり、すなわち「必要な時間」と「使える時間」をできる限り正確に算出する必要がある。

 

作業時間の記録について

自分はすべての作業時間を記録している。これの目的は、①使える時間を最大化すること、②必要な時間算出の精度を上げること、の二点である。

作業時間の記録 - Google スプレッドシート

具体的には上記のようなまとめ方をしている。これを始めたきっかけは、自分が使えるすべての時間を可視化すれば、そこから見積もり精度を上げる何かが見つかると考えたからである。

実際の気付きとして以下のものがあった。

  • 作業の区切りを意識しやすい
  • ドハマリに気づきやすい
  • 作業分割が的確だったか振り返りやすい

毎回作業に名前をつけることになるので、何をどこまでやるかということを考えながら作業する習慣がつく。また、定期的に時間を確認するため、自分の想像以上に作業に時間がかかっている際にも気付きやすく、効率的に時間を使える。

また作業見積もりの際にも、今までの作業にどれだけ時間がかかったかが記録されているため、当てずっぽうではない見積もりができるようになる。

 

必要作業と作業可能時間の書き出しについて

この2点は一つの資料にしているため、まとめて記載する。

特に大型機能開発の際には、設計よりも前にすべての機能を書き出すようにしている。また、その時点で見えている MTG などの予定もここで一元化してしまう。

これを始めたきっかけは、「必要な時間」とはすべての機能開発にかかる時間の総和であり、「使える時間」とは期日までに自分が実際に作業できる時間であると考え、ならばそれらをすべて可視化すれば算出ができると考えたからである。

タスクリスト - Google スプレッドシート

具体的には上記のようなまとめ方をしている。

実際の気付きとして以下のものがあった。

  • このリストが片付けば完了であるという安心感がある
  • この通りに進めば期日通りに完了できるという安心感がある
  • 作業完了日がひと目で分かる
  • なんの見積もりがずれているかひと目で分かる

このリストには全タスクと作業できる時間がまとまっているため、作業完了日が明確に見える。また、見積もりと実際の作業時間を並べているため、振り返りをする際に必要な情報もまとまっている。

予想外の成果だったのは、安心感を持って作業できることによるメリットである。

間に合うのかどうかヤキモキすることが減り、不安だから見積もりをもう一度考えよう、といった開発以外の作業を抑えることにつながった。

この資料を運用する際には、以下の点に留意している。

  • 増えたタスクはすぐに追記する
  • 変更のあったスケジュールもすぐに反映する
  • 見積もりの指針を揃える(ゆるいかキツいか)

ここに一元化されているという点が安心感につながるため、他のメモやカレンダーにタスクが分散しているのは望ましくない。また、差し込みスケジュールもある程度は避けられないため、それも随時反映していくことで、資料と実際の状態を等しくすることができる。 

最後は振り返りの際に重要な点で、見積もりの指針がぶれていると正しく見直すことができない。キツめに見積もって遅れたなら誤差だが、ゆるめに見積もってなお遅れたなら、それは作業の重さや自分のスキルに誤認識があるかもしれない。

 

やってみたが合わなかったこと

下記のやり方も試したが、自分には合わなかった。

  • 1.5倍の見積もり
  • 2点見積もり

 1時間と見積もったものを1.5倍として考え、が実際に1.5時間で完了した場合、確かに遅れは発生しない。ただし、なぜ1時間と考えたのにズレが起きたのかを発見しにくくなる。そのため、この方法は基本的に用いていない。

2点見積もりとはキツめの最小見積もりと余裕を持った最大見積もりの2点を予め置くことで、大きなズレを回避することができる手法のことを指す。悪い方法ではないが、自分の場合は初期の見積もりを1番精度高く行い、中盤以降は微調整をしながら進めていく。そのため、見積もりを2重でやるような形になってしまい、自分には合わなかった。

 

まとめ

自分のやり方を整理したものをまとめてみた。

やっていることは大きく3点。

  • 自分がしたすべての作業を時間とともに記録する
  • 自分がするすべての作業を見積り時間と共に記録する
  • 自分が活動できるすべての作業時間を書き出す

やってみた上での気付きとしては以下の点がある。

  • やること、所要時間、作業できる時間などすべての因子を可視化することで、大規模開発であっても一つ一つ分割して考えられる
  • 情報が一元化されていることで作業途中の様々なストレスを軽減し、開発に集中することができる

「ゲーム開発マネジメント勉強会 vol.2」に行ってきました

「ゲーム開発マネジメント勉強会 vol.2」に行ってきました。

management-for-game-development.connpass.com

 

場所は目黒のアカツキです。

最近は業務でチームで開発を意識することが増えてきたため、勉強させてもらいました。

 

前半は登壇発表、後半はトークセッションという構成でした。

いきなり感想

具体的な話が多く聞けたので、非常に参考になりました。

登壇発表では、実際にアサインされたチームでの事例が話されました。チームごとに抱える課題、そしてそれをどう解決するのか、という内容が方針と手段をそれぞれ具体的に示されており、非常にイメージしやすかったです。

トークセッションでは各社ごとの違いが示されたのが興味深かったです。たとえばチームで用いているツール、用いることをやめたツール、最初にやること、定期的にやること、やらないこと、といった内容がありました。特にツールは各人思うことが多いようで、非常に面白かったです。

考察

マネジメントを「ゴールを示し」「安心できる環境を作り続ける」と定義しているのは、自分がまだ曖昧にしか見えていない PM のミッションを非常に明確化している印象を受けた。

また、多くの課題がある状況下での対処法として、無理矢理にでもシンプルな課題へと落とし込み、しっかりと進捗を実感できるようにすることでチームのモチベーションを下げずに進む、というのは非常に参考になる考え方だった。

トークセッションの中では、特にチームビルドの重要性と、そのために必要なマネジメントを感じることができた。自分ができるからみんなもできるだろう、ではなく、全員ができるような環境をいかに作っていくか、自分が環境づくりができるような関係性をどう作っていくか、ということが、マネジメントをする者にとって非常に重要な課題であると認識できた。

 

発表メモ

開発マネジメントとは

スピーカーにとってのマネジメントとは

  • 開発を統括しゴールを目指すこと
  • 仕事の話なので収益化は当然必要
  • 「価値向上」を「計画」し、「実行」し、そこに「責任をもつ」こと

なのですが...

  • 特にゲーム開発では普遍的なマネジメントモデルがない
  • PM いない場合もある
  • P 兼任のディレクターがいたりする
  • P がいっぱいいる場合もある
  • 立場と裁量が噛み合わっていないこともある

メンバーがマネジメントへの意識が希薄な場合が結構ある

  • メンバー全員がマネジメントの意味を理解できているケースは少ない
  • PM チームへの啓蒙も必要
  • そうするといざというとき協力を頼めるようになっていく

事例1

  • PM にゲーム作る(ディレクター業務)以外をやってほしい的な事例
  • 実行のリスクをどう管理するか
  • 見守ることは管理ではない
  • リスクとは:コスト、スケジュールなど様々ん危険性をまとめた言葉
  • リスクの把握をすることがマネジメント
  • 把握とは:想定外の事態で何が起こるのかを予測しておく
  • 想定外事象は影響度と発生率で評価する
  • 例:インゲーム部分が決まらないと他のとこ作れないから影響度デカイ、みたいな
  • わかりにくい事象でも各メンバーが報告しやすい関係性をいかに作っていくか
  • 厳しく、優しく、上から、仲良く、混ざっていく、などやり方は様々
  • PM もメンバーの一人(あくまでスピーカーが用いている考え方)
  • あまり評価のやり方は固定しない方が良い
  • 具体的な手法:視点を増やして精度を上げる、執念深く対策しまくる

事例2

  • 売上悪いから助っ人して、的な
  • 期待値:PDCA 回して KPI を改善する
  • やること:ゴールへの道筋を示す
  • 答えが簡単ならそもそも PM の増員とかいらないはず
  • 複雑な事象をシンプルな問題に見せかける(これだけだと詭弁ぽい)
  • もうちょっとちゃんと言うと...
  • やることが多すぎるとリスク管理も困難、結果メンバーのモチベーションも下がる
  • シンプルな大目標中目標を作って進捗を見えるようにする
  • シンプルなゴールに向かうストーリーを用意し、進捗している実感を得られるようにする

疑問

  • Q. シンプルなゴールとは、1番大きい課題や、近いものをまとめてしまう感じ?
  • 本質に近いものを抽出する
  • 事例:格ゲーなら格闘部分が楽しめるならチュートリアル改善は後回しでいいだろ、みたいな
  • それらを現場主導で発見し、いかにスムーズに導くか、がマネジメント

事例3

  • 炎上してるからなんとかして、的な
  • リスク管理できるところまでスリム化する
  • それができてから、作業遅延解決とか改善の話を始める
  • やっちゃいけないのは、このまま頑張れ、的な放置
  • ↑安心できる環境を作る、というマネジメントができていない

まとめ

  • マネジメントとは
    • 道筋を示すこと
    • リスク把握、対策を継続的にやること
    • 安心して開発できる環境を作り、改善を続けていくこと

 

トークセッション

トーカー

湯前 慶大 : 株式会社アカツキ VP of Engineering/認定スクラムマスター/認定LeSS実践者
山浦 大輔:株式会社ディー・エヌ・エー ゲームコンテンツ事業部 第一開発部 エンジニアグループ マネージャー
山田 元基:株式会社QualiArts 技術責任者/プロジェクトマネージャー
開 哲一:ワンダープラネット株式会社 執行役員 VP of Engineering

BTS/ITS

  • JIRA は BTS としては有用(タスク量の可視化が容易なため)
  • Wrike よかった
  • Trello っぽい使い方もできる
  • カンバンもガントもできる
  • ゴチャゴチャしてない
  • 管理が得意な人がやるとすごく高速にできる
  • 欠点:高価
  • EP は年間100万円
  • 他のツールは?
  • asana
  • shotgun
  • 物理カンバンの欠点はトラッキングできないこと
  • とはいえ、そもそもタスクに対するトラッキングしない

CI

  • jenkins の用途は?
  • 静的解析とか
  • プランナのデータ反映とか
  • ガチャのシミュレーション(設定と合ってるか検証)とか

プロジェクト初期にやること

  • ミッションの共有
  • 何を届けるか
  • 誰を相手にするのか
  • 何を作るか
  • 優先度の低いことを出すのが大事
  • みんなで「やらないこと」の共通認識をつくる

スプリント

  • 初期で設計もやってしまう(オレオレ設計を避ける)
  • プレイ会ベースで振り返りをしている
  • 朝会で良かったこと報告してチームビルドにつなげたりしている

ふりかえり

  • 同じことをやってるような人たちでふりかえる
  • KPT の量をチーム間で共有する
  • K を多くすることが目標だったりもする
  • サンクスカードとか
  • スプレッドシートはみんな同時に書けるから良い
  • 一斉に書くと、促されてみんな書くようになる

PM の悩み

どこまでチームメンバーに自己管理を任せるか

  • 管理は個人の話
  • ただし仕事はチームのものなので発信はしてほしい
  • 発信の仕方は訓練次第
  • タスクをちゃんと聞き取るのは発信者ではなくチームの課題
  • プロトのときは個人で管理しないとやれないものも多い
  • チームによりけりではある
  • @まとめ
  • 基本個人に任せたい
  • ただし個人のスキルに依存してしまう
  • なのでそれらを拾う動きは必要

Q. マイクロマネジメントは悪か?

  • 最終的には悪だと思う
  • ただし必要なタイミングはあると思う
  • 最初とか
  • 上から言われるのではなく、自分でタスク管理できたほうがモチベーションにもなるはず

上層部とのすれ違い

  • そんなにあるか?
  • 上から余計なこと言われても自分だけで止めたりとか
  • 報告頻度とかコミュニケーションをいかにしていくか
  • 数値ですぐ報告できるような準備はしておく
  • でもまあ普段からコミュニケーションしているのでそんなに問題にならない

Gotanda.unity #8 行ってきた

Gotanda.unity という勉強会に行ってきた。

gotanda-unity.connpass.com

といっても先月ですが(汗)。

だいぶ遅くなったけど、復習も兼ねて印象深かったものの感想書く。

 

シンプルStateMachine

この粒度で実際に試して何がうまく行かなかったかを聞けたのは参考になった。

仮にこういう設計とプロダクトの齟齬を早期に発見するとしたらなにができるだろう、プロトで複数画面作って複数人数での開発を試して、とかになるのか。

 

シェーダー芸・入門から1ヶ月の道のり

ナニモワカラン状態から一歩一歩進んでいった話が聞けて心強かった。

写経大事写経大事。

 

Tilemapのアップデートについて(仮)

Unite でも聞いて気になってた!

発表中でも言ってたけど、自分がプレイしてたゲームを作れる、というのはゲームに関わっててよかったと思える。

 

その他

懇親会でも自作シェーダを見せてもらって興奮した。

エンジニア懇親会ならではって感じ。

 

感想

あまり勉強会行き過ぎないようにしてるけど(行くだけで成長した気になっちゃうから)、時々行くことでまた色々やってみよって気になれるのは良い。

あとインプットは継続してるつもりだけど、アウトプットできてないなってチクチク実感。これも勉強会の良いところ(震え声)