読者です 読者をやめる 読者になる 読者になる

KYな雑記帳

個人的なメモ帳

DGC2016報告会に参加してきました

4月2日(土)に行われたGDC2016報告会に参加してきました。
www.igda.jp


その簡単なまとめと、感想を。
ちなみに、動画を撮っていたし資料は公開されるとのことです。

GDC2016概要&IGDAアップデート(小野憲史)

GDC2016の概要とIGDAの概要の紹介でした。
GDC2016は過去最大規模で2万7千人の参加者がいたそうです。
講演だけでなく、展示エリアも拡大しているようです。
また、AWARDでは、ナラティブブーム旋風が起きていて、多くの賞をナラティブゲームが受賞していたようです。
IDGAとは、ゲーム開発者を対象とした国際NPOで、日本ではすべてがボランティア活動で行われているようです。

自動化ーニバルだよ! GDC16にみる自動化技術とテストのトレンド(竹原涼/セガゲームス)

RiotGameがテスト環境の構築にDockerを導入したという話から、QA(サービス検証・テスト)チームがどのようにプロジェクトに関わっていくかという話。
テスト計画を練る際に、全体の予算、スケジュール管理、リリースする範囲(地域)まで視野に入れる必要がある。
開発の初期段階からQAがチームに参加し、技術的な話だけでなく、長期的な視点が必要。
とのこと。

人工知能の行方 -ゲームエンジンとVRの間で-(三宅陽一郎/スクウェア・エニックス

スライドや話が駆け足で、目でスライドを追うのに精一杯で、あんまりメモを取れなかった。
ゲームAIという分野は成熟し、大型ゲームへの対応のフェーズになっている。
しかし、VR空間におけるAI,アニメーションは技術論理を再構築する必要があるらしい。
ゲームエンジン開発という分野はの最終ブラッシュアップ状態。
ゲームエンジンでも、データ解析という点ではまだまだ開拓できる。
とのこと。

GDC Play 小林丸(徳留和人/スマイルブーム)

GDC PlayにSimile Game Builderという3DゲームのRPGを簡単に作れるツールを持って行った体験談。
周りが欧米人の中、日本人が固まっていても向こうから話にくることは少ないので、英語話せるアピール、気軽に話せる雰囲気づくり、目立つ格好で客引きなどが必要だった。
興味のある人は、その場でコンタクト先を渡してくれるので、欧米を視野にいれた製品があるのなら、GDC Playでターゲット層の生の声を聴くことができる。
また、海外展開に関して、コンサルティング企業とも話すことができた。
とのこと。

生産性と繁栄を(佐野浩章/ツェナネットワークス)

日本では働ける人口(生産人口)が減少しているので、人を増やすことで生産量を上げることはやりにくくなっている。
そんな状況では、個人が生産性を上げるしかない。
個人の生産性を上げるためには、残業を減らす・人数規模にあったチームの動き方・生産をアシストできるツールの導入などが方法としてある。
ただルーチンワークをするだけの人間は仕事ができない(就職できない)だろう。
やみくもに仕事をするのではない。
とのこと。

世界を変えるかもしれない!?インディ開発者が挑戦するゲームを通した社会変革の一歩(後藤誠/マッチロック)

とある、インディーズゲーム、We Are Chicago 開発者のセッションを受けた感想。
インタビューによって集められた実際の体験談に基づいてストーリーを作っており、ゲームを通して共感を高めることにより、地域に住んでいる人の実際を知ってもらい、教育することを目的にしている。
これは、ゲームを通して、現実世界を変えることが目的になっている、ソーシャル・インパクトを持つゲームだった。
ゲームは影響を与える。それはいい影響も悪い影響も両方がふくまれている。
ゲームは世界をよりよい世界に変えることができる。
企業では、お金を稼ぐことが目的なので、売れるゲーム・やって気持ちの良いゲームを作らなければならない。
インディだからこそできるのではないか?
とのこと。

GDCラウンドテーブル2016(小林太郎/ポリゴンマジック)

ラウンドテーブルとは、机を並べて円卓上になって、ディスカッションを行う形式。
現場トップレベルの方がたによるディスカッションが行われる。
ラウンドテーブルでは、持って帰れる情報が多く刺激的で、様々な観点でのアドバイスがもらえる。
やって成功したこと、悩んでいること、失敗した事例の情報共有の場となっており、現場からジューシーなトレンド情報を得られ宇r。
継続してくることに意義があるとのこと。
今回は参加したラウンドテーブルと、話されていたことの紹介だった。

被って試した。VRシステムビッグ3体感比較+α(佐藤カフジ/ゲームジャーナリスト)

VRを体験して三つのデバイス(Oculus, Vive, PSVR)の比較だった。
性能的にはVive, 話題的にはPSVR、トータルバランス的にはOculusとのこと。
詳しくは記事参照。
【佐藤カフジのVR GAMING TODAY!】かぶった!試した! Rift・Vive・PSVR“体感”比較 - GAME Watch
また、ベクションマスク(仮)というVR酔いを防ぐ新しいテクニックについてもふれていて、高速に動く近景をわざと見せなくすることでVR酔いを防ぐ工夫をしているとのこと。

VR… そこは最後のフロンティア(南治一徳/ビサイド

VRコンテンツを作るための、心がけてきな話。
プレゼンス(存在感)が重要であり、ゲームでそれを壊してはならない。
壊さないために、VR酔い、操作方法、しょぼい反応、やりすぎな演出、非現実的な音、身体感覚と視覚情報の断絶、ちょかん的でない操作と反応、の7点に注意する必要がある。
また、ゲームデザインが悪いと不快感が生じるので、VRの素敵体験を作り出すようなゲームデザインにする必要がある。
でも、基本的なゲームデザインは今までとあまり変わらない。
とのこと。

感想

ルーチンワークをするだけの人間ではこの先仕事にありつけないという話と、
ゲームによって現実社会を変えるという話が印象的だった。
あと、これからは、やっていてプレイヤーに大きなフィードバックを与えるだけでなく、プレイヤーにストーリーを体感させるナラティブなゲームが主流になっていくのかなと楽しみになっている。
VRはどうだろう?OculusやViveが発売されたことで、例えばイベントスペースやアトラクションでVRコンテンツが増えそうではあるけれど、家庭にまで普及するのかな。
PSVRがそれに一役かって、家庭でもVRを(個人的にはサマーレッスン的なVRコンテンツ)を遊べる時代になればいいなぁと思いました。

DroidKaigi2016に参加した感想

2月18日19日に行われたDroidKaigi2016に参加してきました。
こういったカンファレンスはブログを書いて終わるものなので、ブログに感想を書いておこうと思います。

DroidKaigiについて

droidkaigi.github.io


公式ホームページはこちら。
DroidKaigiはAndroidの技術カンファレンスです。
Android技術情報の共有とコミュニケーションを目的に開催されています。
各講演は録画されてたので、後程公開されると思います。

資料

各資料も公開されています。
unsolublesugar.com

unsolublesugar.com

感想

今回のDroidKaigiは有給を使って参加していたので、ゆっくりとした気分で見たいものだけを見るスタイルで参加しましたが、これが良かったと思いました。
気分的にゆっくりできますし、全部の講演を網羅しなきゃという強迫観念にも陥ることはありませんでした。
基調講演は逃してしまいましたが、朝ゆっくりできたのもグッドです。

講演に関してもいろいろな技術的なことから、どうやって学んでいったかという初心者にもありがたい講演までありました。
個人的には、Android-Lintの講演が一番糧になったと思います。

終わった後でハッシュタグを見ていて気付いたのですが、ペアプロもやっていたようで、それに参加したかったというのが少し心残りです。
あと、みんなドーナッツを食べていたのだけれど、あれどこで配っていたのだろう…食べたかった…

ネイティブのコードレビューをしてもらった話

最近アプリ開発のタスクも行うようになりました。
そのために、Android Studioを使って練習用のTodoアプリを作りました。
それを社内のネイティブアプリチームのメンバーにコードレビューしてもらったので、そこででた指摘を忘れないようにまとめておきます。

importを整理しよう

  • 自動インポート便利
    • Ctr + option + o
  • 使っていないインポートはAndroidStudioが色を変えてくれるので消す

外部から使われていないものは基本privateで

Activtyを増やさずにフラグメントを増やす

  • Activtyに全部書こうとしない
  • 処理を外だし出来る
  • UIパーツとかはフラグメントに切り出した方が使い回しができる
  • AndroidStudioのテンプレートでフラグメントのテンプレがある

フォーマッタを使いましょう

  • option + command + l
  • インデントや改行などの細かいことをAndroidStudioに任せることでチームのコードを統一できる

テストは書きましょう

  • ユニットテストは書く癖をつける
  • UIのテストは書かない
  • UIの各処理を外だししてそのテストを書く

DB操作関連

  • 文字列生成はやめましょう
  • CursorLoader使いましょう
  • StringBuilderを使いましょう

名前空間

values使えるのGood

  • レイアウトで使ってる文字列など
  • レイアウトで使っている色など

文字の書き方は統一しよう

  • snakecase
  • camelcase

スレッドを考えましょう

  • uiを扱っているスレッドでdb操作はしない
    • 描画が遅くなる
  • ライブラリを使うとDB操作のスレッド分けを考慮してくれる
  • AsyncTackで重い処理をやってあげる
    • AsyncTackはあいているスレッドを探してそのスレッドで処理する

AndroidStudioの指摘を直しましょう

  • never userd
  • 使われていないimport

レイアウトについて

  • レイアウト作る際は浅く広く。ネストはあんまりしないように。

勉強会備忘録:リアルタイム通信技術の基礎知識

Macのトラックパッドは羨ましいなと最近思い始めました。
さて、この記事は 1/21(木)に行われた勉強会に参加した備忘録です。

参加した勉強会は下記リンクの、ネイティブアプリエンジニアが知っておくべきリアルタイム通信技術の基礎です。
atnd.org

モバイルにおける通信特性

  • キャリアにおける通信制限がある
    • 128kbps
  • 混雑するとさばききれない
  • この辺りを考慮する必要がある

伝送方式

  • サーバ・クライアント方式
    • リモート通信
    • 今回の話のメインがこの方式

モバイルの通信プロトコル

双方向通信

  • 双方向通信とは?
    • サーバーからもクライアントからも通信データのやりとり
    • サーバープッシュが手軽にできる
  • 手法
    • Server Sent Event
    • WebSocket
    • RUDP

HTTPにおける双方向通信

  • ワンリクエスト・ワンレスポンスが前提
  • 疑似的な双方向通信にしかならない
  • パケットの肥大化

Websocket通信

  • 純粋な双方向通信を行うためのプロトコルTCP上で動作
  • コネクションは張りっぱなし
  • メリット
    • ヘッダが軽量
    • リアルタイム性が高い
    • サーバ負荷も低い
    • バイナリデータのやりとり

通信データの軽量化

  • MessagePack
    • 高速
    • 多くの言語に対応
      • サーバークライアントの技術選択の幅が広がる

通信データ量が小さいことのメリット

  • キャリアにおける通信制限をすりぬける
    • ダウンロードが走らなければ
    • 画面遷移などは通信制限にかかっていてもスムーズに

リアルタイム通信での同期種類

  • 完全同期型
  • 非同期型
    • 画面レベルが多少ずれていてもOK
    • MMOとか
    • 今回のメイン
  • サーバー集中処理
  • クライアント集中処理

非同期型 サーバー集中処理

  • 1, クライアントでユーザ入力
  • 2. サーバーで入力を解釈
  • 3. サーバーでデータ更新
  • 4. クライアントで結果表示
  • ※クライアント側での不正ができない

クライアント設計

  • クライアントはViewer
  • MVC
  • 例:キャラクターオブジェクト
    • 画面タッチ
    • Controller : 移動命令
    • Model : データで更新
    • View : 通知に応じてキャラクターを動かす
    • サーバー・ユーザ両方の入力に対しても挙動が変わらない

非同期型 クライアント分散処理

  • 1. ユーザー入力
  • 2. クライアント:計算処理、データ表示
  • 3. サーバー:データ更新
  • ユーザーの不正対策が必要
    • 通信の暗号化など

同期種類

サーバー集中

  • 通信切断
    • ゲーム進行は停止しない
  • ゲーム進行
    • 常に通信が必要
  • 処理負荷
    • サーバー

クライアント分散

ホストゲスト方式

  • ホスト端末
  • ゲスト端末
  • サーバー
  • 通信頻度が高い
  • ホスト端末がゲスト端末の入力を解釈して結果を各ゲスト端末に送る
    • ホスト端末の処理負荷が高い
  • ホスト端末がネットワークから切れた時の対処が必要

全ホスト方式

  • 全端末がホスト
  • サーバー
  • ゲームの結果は同期せずに入力を各端末に送り、各端末で入力の解釈・処理を行う
  • 通信頻度が低い
  • 1ホストに環境が依存しない
  • 結果の同期ずれは??
    • 入力に対して常に同じ結果が生じるようにする
      • 乱数シード値を共有する

感想

  • 全ホスト方式というのは初めて聞いた。
  • ホストゲスト方式と全ホスト方式はユーザーからしたらどっちが安全に働くのだろうか、という疑問

もう年変わってだいぶたったけど今年の目標を考えた

みなさんは今年の抱負決まりましたでしょうか?
2016年が始まってすでに半月以上たちましたけど、今年の目標を考えたので、あとから見返せるように書いておきます。

抱負会議

今年の目標を決めるにあたって、会社のチームで抱負会議というのをやったので、抱負会議について書いておこうと思います。
抱負会議とは、その名の通り今年の抱負を決める会議です。
集まったメンバーで順番にその人に今年の抱負を付箋に書いていくという会議です。
自分がやりたいことだけでなく、他人が自分に求めていることも分かり、思ったよりも盛り上がりました。

今年の抱負

では、さっそく今年の抱負を書いていきます。

linkis.com


この記事によれば、多くの目標を立て、目標が大きすぎると、達成率がさがり、さらに目標を失敗したことで自分自身を傷つけるということなので、小さい目標を数個程度たてます。

目標

  • ゲームを最低1本リリース&100ダウンロード
  • ゲームジャム部に毎月参加
  • kotlinやswiftでアプリを完成

今回の目標は定量的に評価できて、大きすぎない目標をたてました。
まぁ、こんな感じで。
抱負会議で上がっていたのは、「ゲームを最低1本リリース&1000ダウンロード」でしたが、今年はリリースすることを目標にしたかったので、ダウンロード数は減らしました。

その他の候補と却下理由

  • ゲームを月一本リリース
    • まだリリースしたことないので、今年は最低1本リリースを目標に。
  • 先輩を超えるネイティブ力
  • 所属チームのネイティブマスター
  • たよれるAndroid/iOSお兄さんになる
  • フルスタックエンジニアになる
  • 先輩の仕事を全部奪う
  • Post○○先輩
    • 今年の目標は定量的に評価できるものにしたかったので、数字で評価できず、人によって感覚が違いそうなので、却下しました。
  • Nativeチームのここが悪いよ会
    • ネガティブな事をやる必要があるのかな?と思ったので。
  • 学びをブログ・Qiitaに書く
    • ブログの記事数で評価できそうだったけど、一旦保留にしました。
  • 1チケット1ガチャ
  • ガチャは1月1万円まで
    • 三が日で1万円以上つかっていたのでwあと、自分は欲しいのがでたら出すまで回すので。。。
  • OSSチャレンジ
    • 正直に言ってあまり興味がなかったので。
  • cordva検証
  • 既存サービスにwebGL
    • これは、個人の目標というよりは会社のタスクに入れて欲しい。
  • UnityPro買う
    • 18万かぁ・・・

おまけ

そいうえば、去年はカードゲームで人と対戦することが少なかったので、月一以上でショップ大会にでるようにもしたいな。
あと、オリハルコンリーグもふみたい。

ソシャゲのガチャの確率について考えてみた

本当にほしいものは出るまで回してしまう人コスッキーです。

さて、最近ソシャゲのガチャが炎上しているし、自分でもちょっとガチャにお金を使いすぎている感があるので、ガチャの確率などについてもう一度考え直してみることにしました。

それは間違いである

ひとまず、例を出して考えてみるとしましょう。
SSRの確率が3%のガチャ」という例で考えてみます。
この確率をみて、「まぁ、3%なら33回ぐらいひけば一枚はSSRが引けるだろう」と考えた方もいるのではないでしょうか。
しかし、それは間違っている!
では、SSR3%のガチャで33回引いた後でSSRを持っていない確率を考えてみます。
計算式は (SSRを引けない確率)^(試行回数)で求められるので、
(1-3/100)^33 = 0.365
約37%です。
33回引いてもSSRを持っていない確率は37%とかなり大きいですね。
あと、引いている確率は、引いていない事象の排反なので、約63%です。
ほしい奴の一点狙いならば持っていない確率はさらに大きくなるでしょう。
ちなみに、この確率設定で100回ほど引けば持っていない確率は約5%になるので一枚くらいはひけるのではないでしょうか。
確率なので、絶対というのはありませんが。。。

他の例でも考えてみる

他の例でも考えてみるとしましょう

SSR確率が1.5%の場合

このガチャを100回引けば1枚くらい出そうな感覚なので、
100回引いた後でSSRを持っていないのは、(1-1.5/100)^100=0.220 約22%です。
これも結構でかいですね。。。
200回ほど引けば持っていない確率は約5%程度になるようです。

SSR確率が1%の場合

もうすでに、計算するのもつらくなってきましたが、最後にこの確率を例にとって考えてみるとしましょう。
このガチャも100回引けば1枚くらい出そうな感覚なので、
100回引いた後でSSRを持っていないのは、(1-1/100)^100=366 約37%です。
かなり大きいですね。。
200回引いても持っていない確率は約13%もあります。
この確率のガチャを引くときはけっこうな覚悟を持って引く必要がありそうです。

期待値を考えてみる

では期待値を考えてみます。
ここでいう期待値というのは、「カードを入手するのにかかる金額」という考えで使われるものです。
絶対にこの金額で手に入るという金額ではないですよ。しょせんは確率ですからね。
その計算方法は、 (ガチャ1回の金額)*(1 / (カードの確率)) で求められます。

SSR確率が3%で、1回300円の場合

期待値は、 300 * (1 / 0.03) = 9999.9 約1万円です。

SSR確率が1.5%で、1回300円の場合

期待値は、300 * (1 / 0.015) = 20000.0 約2万円です。

SSR確率が1%で、1回300円の場合

期待値は、300 * (1 / 0.01) = 30000 3万円です。

この期待値の計算結果をみて、「高いな」と思ったらガチャを引かない方がいいです。
経験上、これより多くの値段がかかりますし、
SSRの種類は何種類もあるので、お目当てのものが出るまでこの金額の何倍もかかる事が考えられるからです。

まとめ

さて、いろいろとガチャの確率について改めて考え直してみました。
率直な感想を言うと、計算しなおしてみると、自分の感覚よりはるかに出にくいなというのが感想ですw

これらの計算結果を見て、否定的な印象を持った人はソシャゲでガチャを引くのをやめた方がいいでしょう。
なぜなら、ガチャを引き終わった後、あるいは、引いている途中で後悔するからです。

いくら使ってでも欲しいものがある、これが出るならいくら使っても構わない、という覚悟を持ってガチャは引いた方がよさそうです。
もちろん、自分で稼いだお金を使ってね。

カタログIPゲームジャムまでにやっておきたいこと

11月6日(金)にカタログIPゲームジャムというものがあるのですが、先日その参加者向けにUnityの講習会があったので、それのざっきです。
講習会では、当日利用できるアセットの説明などもあったのですが、ここではゲームジャムまでにやっておいた方がいい事をまとめます。

カタログIPゲームジャムについては以下参照open.channel.or.jp


そもそもゲームジャムとは?

48時間で即席のチームを作ってテーマに基づいたゲームを作るお祭りです。
しかし、「ゲームジャムは実践であって、遊びじゃない」とのことです。
「当日勉強しながら作ろう」では完成しないから、準備をしっかりとしておきましょうとのことでした。

突飛な発想でゲームを作るヒント

ゲームの企画のヒントをいくつか挙げられていました。

  • 別ジャンルのゲームにする
  • ワンアイディアに絞る
  • キーワードの掛け算をする
    • 元のゲームのイメージと違うものをかけると発送しやすい
  • 何分ぐらいで遊べるゲームを目指すかきめる
    • 3から5分程度で楽しく遊んでもらえるゲームを作ったら成功
    • 要素を増やすより3分間楽しく遊べることを考える

もちもの攻略

  • ヘッドホン、耳栓、ポストイット、サインペン、ノート、アイマスク、歯ブラシ、タオル、着替えなど
    • 泊りじゃないけど、寝る場所の確保
    • マウス持っていたほうが効率的
    • サブで使えるネットワーク環境もあると○

ゲームジャムの鉄則1:体調を万全に

48時間の開発は思ったより過酷です。
冷暖房にやられないように、服装に気を配ったほうがいいとのことでした。
また、会場でよくあるトラブルとして、以下の事があるので事前に準備しておきましょうとのことでした。

  • Unityをインストールしていない
  • Unityをアクティベートしていない
  • Unityのバージョンが違う

ゲームジャムの鉄則2:会場のネットワーク回線を当てにしない

狭い会場に80人くらい集まるとのことなので、お察し。

ゲームジャムの鉄則3:前もってできないことは当日出来るようになると思わない

  • 自分ができるきることを棚卸
  • できないことを練習
  • 使いたいアセットの練習

これらは最低限やっておくべきとのことです。

また、さらに追加して以下の事をやっておくといいことらしいです。

  • 周辺のレストラン、コンビニの下見
  • 役割の決定

チーム作業のススメ

今回は基本的に4人になるとのことですが、たいていのゲームジャムでも数人~6人くらいになると思います。
即席のチームで作業を進めるためにタスク管理はしっかりしておきましょうとのことでした。
ここでは、ポストイットGoogleスプレッドシートでのタスク管理がいいと紹介されていました。

バージョン管理

必須です。
当日までにBitBucketを使ったバージョン管理を練習しておきましょう。bitbucket.org

  • BitBucketの登録
    • 無料で使える
    • プライベートリポジトリが使える
  • Unity側の注意点
    • ファイルの移動はUnity上で行い、エクスプローラーなどを使わない
      • Unity上で行わないとメタデータなどの更新も行われないため
    • Asset Serializationを「Force Text」にする
      • Unityのツールバーで、「Edit」→「Project Settings」→「Editor」から
  • リモートリポジトリにプッシュする
    • Macならコマンドライン上で良さそう
    • WindowsならGUI使ったほうがよさそうだった(SourceTreeとか)
    • すべてをバージョン管理するわけでなく、Asset, ProjectSettingなどを管理する
    • Library, Tmpといった一時ファイルはgitignoreでバージョン管理しない

クラウドビルド

Landing : Unity Cloud Build : build.cloud.unity3d.com : Unity

Unityのアカウントをもっていたらただで使えます。
サーバーにアップしたプロジェクトを勝手に引っ張ってきてビルドしてくれるサービスです
無料プランだと1時間に1回ビルドですが、ジャムの終盤になったら自分でビルドすればいいので問題ではなさそうです。

チームプレイとディレクション

  • 人に任せる、できないことをしない
  • 上がってきたものをリテイクしない
  • 5秒で決断する
  • 三日目の朝にできないことはバッサリ切る
  • 時間内にクロージングするためにできることをする

まとめ

Unityの最新版のセットアップから、クラウドビルドまでは一通り練習しておいたほうがよさげです。
できれば、アセットの使い方の練習もできれば吉な感じでした。
ゲームジャムの本番では練習などできない、する時間がないので、それまでにどれだけ準備できるかで完成度が分かれそうと感じました。