この記事はアピリッツの技術ブログ「DoRuby」から移行した記事です。情報が古い可能性がありますのでご注意ください。

今年の東京ゲームショー2017について、日本ゲーム大賞を受賞した作品たちをいくつか取り上げて、筆者なりに人気が出た理由を分析してみたいと思います。

みなさんお久しぶりです！Lionです。
前回の記事いかがだったでしょうか？
少しでもゼルダの伝説 時のオカリナの魅力が伝わったのならうれしいです！
さて、本日は「TGSで日本ゲーム大賞に選ばれた作品たち！」」について話させていただきます。
今年はどんな神ゲーが僕らを待っているのか(੭ु´･ω･`)੭ु⁾⁾
受賞した作品を2つほど紹介していきたいと思います。

「やっぱり今年はあのゲームが受賞！」

今年の「年間作品部門 大賞」を受賞したタイトルは「ゼルダの伝説 ブレス オブ ワイルド」でした！
ファンからは「ゼルダの伝説 時のオカリナ」を超えたといわれ、海外ユーザーのレビューでは☆10評価で☆9以下にならないという現象も起こっているくらい素晴らしいゲームです。
ちなみにNintendo Switchのソフトになりますが、なんとNintendo Switchの出荷台数よりソフトが売れている！
らしいです（笑）
また、ゼルダの伝説シリーズ初のオープンワールドを採用。フィールドを際限なく「歩いたり、走ったり、キャンプをしたり、崖や木に登ったり…etc」ほとんど我々の世界でできるようなことはゲーム内でできるようになっています。
※料理だって作れちゃう！
ちなみに選考理由ですが、

・謎解きとバトルの爽快感が最高
・冒険が驚きと発見の連続で楽しい
・やりたいことがすべてできた
・歩いているだけでも楽しい
・シリーズ最高傑作
・まさに大賞にふさわしい

と絶賛の声しかなかったらしいです。
一般投票では、性別・世代を問わず、なんと「5歳から74歳」までの圧倒的な支持を獲得したということもゲーム業界を震撼しました。
ここで、選考理由の「歩いているだけでも楽しい」について少し深堀してみましょう。

「オープンワールドだからできる新しいゼルダの伝説」

　　　　　　　　　　　　　
　　　　　　　　　　Copyright © 2017 CESA, All Rights Reserved. /©2017 Nintendo
　　　　　　　　　　　　　　日本ゲーム大賞年間部門賞より引用
歩くだけででも楽しい！と思わせた理由を私なりに3つに分けて分析してみます。
①今までになかった活きるをテーマに制作されている
　今までのゼルダシリーズは、ラスボスを倒し、世界を救う勇者になるというのが基本ベースでした。
　今作からは、リンクも普通の人間として生きている様に見せる工夫が多々盛り込まれています。

・山や崖をスタミナが尽きるまで登ることができる
・天候で周りの景色が変化する
・周りの気温によってリンクの体調が変化する
・自身で狩猟を行い、肉や魚などを採取できる
・集めた材料で料理を作ることができる
・武器は魔物から奪い現地調達することができる

などが大まかに上げられます。
これが、歩くだけでも楽しいゲームの秘訣になります。
まず、今回のゼルダの伝説は山や崖が沢山あり、どんな急斜面でも大体は登れる仕様になっています。
そのため、色々な場所に進むことができ、プレイヤーは「あっちには何があるんだろう！」と未知の世界に興味がわくようになっています。
基本的に、どこでも行けるということを知ったプレイヤーは、そのたどり着いた場所にある村、町、景色、魔物などと出会うわけです。
このような楽しみ方をプレイヤーが独自に発見して行くのが、今までのシリーズ作品と大きく異なる変化となります。

②過去のゼルダシリーズにはない戦闘システム
今作のゼルダな伝説は、※※過去作のような初めから剣を持っている※※という概念が取り払われています。
ではどうやって戦うのか？
それは、近くの木の棒や畑を耕す鍬などを武器にしたり、魔物から奪った武器を自分の武器にしたりして戦います。
ちなみに、これらの武器には耐久値があります。
※※これも今回のゼルダの伝説において大事な要素となります。※※
各武器は耐久値が0になると壊れてしまい、壊れた武器はその場で消滅してしまいます。
そのため、複数個の武器を所持できるようなシステムになっています。
この武器が壊れる、複数個所持できるというシステムがあることで、

・新しい武器を求めて新天地に向かう
・強そうな魔物がかっこいい武器を持っていたら、何とか倒して手に入れる方法はないか考える
・気に入った武器を大量にコレクションする
・ボス戦や普通の雑魚戦ですら武器の耐久値を考慮して戦わなければならない

このように、プレイヤーは武器という一つのコンテンツだけでもいろいろな目的で遊ぶことができるのです。

③ラスボスである「ガノン」にすぐ挑むことができる
今までのゼルダシリーズは、数々の困難を乗り越えて強くなったリンクでガノンと戦い世界を救うというお決まりのストーリーが王道でしたが、
今作は「チュートリアル部分さえクリアすれば、ガノンがいるダンジョンに行くことができる」という、王道な設計を覆しました。
これにも大きな理由があります。
プレイヤーに一本道で遊ばせるのではなく、プレイヤーが与えた環境でいかに自分の遊び方を見つけるかを体現するためだったのです。
プレイヤーにも色々なタイプの方がいると思います。

・ストーリーをなぞってクリアするプレイヤー
・ストーリーより色々寄り道をして遊ぶプレイヤー
・いかに早くガノンを倒すことができるかRTAをするプレイヤー

など、プレイヤーの数だけ遊び方がるようにゲーム設計を行ったのがわかります。
その結果として、性別・世代を問わず5歳から74歳までの圧倒的な支持を獲得したのだと思われます。

ゲームデザイナーズ大賞を受賞したちょっと不思議なゲーム

　　　　　　　　　　　　
　　　Copyright © 2017 CESA, All Rights Reserved. /©2016 Playdead. All rights reserved.
　　　　　　　　　　　　　日本ゲーム大賞年間部門賞より引用
次にINSIDEという一風変わったゲームが今年のゲームデザイナーズ賞を受賞しました。
選考理由として

・操作方法は極めてオーソドックス
・印象的な描写が心に残る
・主人公を含めた、謎めいた世界の表現手法は、数多の作品と比較しても、「似ている」と言　　
　える作品がほぼ無い
とのことらしいです。

私自身もこのゲームを知ったのが賞を受賞した時からでした。
そのため、詳しくは知りません。
では、どのような作品なのか？一緒に見ていきましょう。

INSIDEのプレイヤーを引き込む世界観

　　　　
　　　　Copyright © 2017 CESA, All Rights Reserved. /©2016 Playdead. All rights reserved.
　　　　　　　　　　　　　日本ゲーム大賞年間部門賞より引用
まず、どういったゲームなのか少し書いてみると、

INSIDEとは、デンマークのインディー系ゲーム開発スタジオPLAYDEADによって開発された
2.5Dパズルプラットフォーマーアドベンチャーゲーム
となります

作品内容としては、主人公の少年は何かに追われており、やがて謎の大きな闇プロジェクトに巻き込まれていくお話になります。

操作方法はいたってシンプルで、方向キーでの移動、ジャンプ、アクションだけです。
最近のゲームと比べると、すごくシンプルと思います。

しかし、先に進むためにいろいろなギミックがあり、自身のヒラメキと、これまでクリアしてきたギミックの応用を解かなければいけないと少々難易度は高めの様子です。

この作品はの一番の見どころであるデザイン部分ですが、
モノクロに近い色彩で表現された世界となります。薄暗い雰囲気にすることで、プレイヤーは、プレイするときの緊張感や謎の何かに追われている恐怖感が倍増します。
しかも、ストーリの説明、キャラクターのセリフ、各種テキストが一切なく、
全てプレイしているプレイヤーの解釈に委ねられています。
この全てプレイしているプレイヤーの解釈に委るが実はとても凄い部分かなと私は思っています。
それはゲームに答えがないということです。
これを私風に言い換えるなら終わることのない物語と表現します。
どういうことかというと、
世界を救った勇者は次の世界を救うためにまた旅だった！
というゲームの終わり方があると、プレイヤーは「その後、どうなったのだろうか？」
「次の世界はどのようなところなのだろうか？」と考察し、それぞれのプレイヤーによって想像や考え方が違うようになってきます。だからこそ、考察したプレイした者同士が話すと話が弾んで話題性が生まれます。これが、先ほど言った終わることのない物語に当てはまります。
ただ、ほとんどのゲームは、ストーリーをすべてクリアしてその後勇者は～という
流れが多いのです。

しかし、このゲームに関しては、ゲーム開始からその終ることのない物語が始まっているのです。
これは、大きな挑戦だったっと思います。ストーリーの説明も何もない世界でただ何かに追われるのを逃げていくという内容をなぜ、追われているのか？などをすべて考えさせるように設計するのは至難の業且つ下手をすればプレイヤーは少しプレイしたら飽きてやめてしまうかもしれません。

そうならないように、世界観にこだわり、まるで自分が本当に逃げていると没入感を持たせる作りだからこそ、多くのプレイヤーの支持を獲得できたのだと思います。

今年の日本ゲーム大賞についてのまとめ

今年は、過去類に見ないほどゲーム業界で革命がおこった年だったと思います。
スマホアプリが流行る昨今、コンシューマーソフトが大きく息を吹き返した感じがします。
上記２タイトル以外も受賞されている作品は多々ありますので、こちたにURLを記載しておきます。

URL：http://awards.cesa.or.jp/prize/index.html

また、来年にもモンスターハンター：ワールドという過去最大規模のモンハンのゲームも発売されます。
※今年のフューチャー賞を受賞しており、来年の年間作品部門の大賞を受賞するかもしれないくらい期待度が高い作品となっています。

来年は、私自身もTGSに参加して生で色々なゲームの作品に触れてみたいです。

さて、次の記事ですが「プランナーはコミュニケーション能力が大事！」について
色々、書いていきたいと思います。

最近、寒さが増してきてますのでどうか風邪を引かずに来月も読みにいらしてください(/・ω・)/

この記事はアピリッツの技術ブログ「DoRuby」から移行した記事です。情報が古い可能性がありますのでご注意ください。

ガバガバックプロパゲーション感漂う記事です。

はじめに

皆さんお久しぶりです、武道館のアリーナA一桁列引いて最近テンション高いくろすです。
マルチプロセス&複数サーバー環境下でのRailsの各キャッシュについてとか、stackprofを使ってプロファイリングしてみたって感じのこと書こうと思ってたんですけど、あまりうまく纏まらないので適当な流し記事を書くことにしました。

みなさん、微分積分いい気分で行きましょう。

Backpropagation

Backpropagation(誤差逆伝播法)はニューラルネットワークの学習に使われるアルゴリズムです。教師信号と出力の誤差をネットワークの各重みに反映するための勾配計算に使われます。この勾配を利用した最急降下法まで含めてBackpropagationと呼ばれることもあります。
Backpropagation自体はNNの学習に必要な数値の計算に使われるだけなので、何らかの形でネットワークの出力を誤差に変換することができるならば、教師ありなし問わず使えます。

導出

l層目k番目のパーセプトロンの入出力を以下のように設定
入力 : 
出力 : 
誤差関数Eに対する重みの勾配は以下の式

ここで右辺はパーセプトロンの入出力の式から

なので無事以下のようにl-1層目のi番目のパーセプトロンとl層目j番目の間の重みとEの勾配が既知の値を使って表現できるわけですね。

でこの勾配を指標にして学習率をかけて引いてみたり、慣性項を追加してみたり、正則化項を追加してみたり色々するわけです。

まあこれ自体はちょっとハチャメチャすぎてプログラムに起こすのが大変そうなのでざっくり行列で行きましょう。
活性化関数にシグモイド、誤差関数にクロスエントロピーを使うとサクッといけます。



tが誤差計算に使われる教師信号から計算される出力なので

o^-1 は前段階の出力になってます
気持ちいいですね。

終わりに

以上、エンジニアにあるまじき思考放棄の数式画像の連投でした。

誤差関数と活性化関数の微分ができれば(微分可能であれば)データに合わせた関数を適宜選択して学習ができます。
自分で書く機会なんてほとんどない気もしますが。

今回ここに書いたようなことはだいたいここの2章や3章あたりに読みやすくまとまってると思います。

この記事はアピリッツの技術ブログ「DoRuby」から移行した記事です。情報が古い可能性がありますのでご注意ください。

業務でWebページをいじったときに地味にハマったので備忘録として投稿します。

経緯

　ボタンをCSS側の設定でデザインして作るのではなく、画像ファイルを使って実装したい。
…ということであれこれ検索しながらCSSでマウスオーバー時に画像を切り替えようと思い

<body>
<style>
  .button{
    background: url(/images/sampleA.png) left top no-repeat;
  }

  .button:hover{
    background: url(/images/sampleB.png) left top no-repeat;
  }
</style>
<img class="button" alt="" onclick="func()" />
</body>

関係ない箇所は全て省略しましたが、こんな感じでコードを書いてみました。
ページに飛んで試しにマウスオーバー…無事反応して出来た。と思ったのもつかの間、一度ボタンをクリックしたらその後クリックは効くものの、マウスオーバーしても全く効かなくなってしまった。
　

原因

　特定条件下でボタンが効かないように処理を加えたりしなければならず、JavaScript側でボタン押下時の処理をしていたのでそれに加える形で

<script>
  function func(){
    //
    // ボタン押下時の処理
    //

    button.style.display="none";
  }
</script>

こんな風にJavaScriptから表示非表示を切り替える処理を加えたり、CSSの設定を変更しているのが原因だったようです。
　
CSSには優先度というものがあり、JavaScriptでCSSの設定を上書きしてしまうとJavaScript側の設定が最優先されてしまい、CSSでの再設定もJavaScriptでの設定が優先されてしまい、何も変化しなくなってしまっていたようです。
　

対処

　CSS側で下のように、末尾に「! important」と加えるだけで問題なく動作しました。

<style>
  .button:hover{
    background: url(/images/sampleB.png) left top no-repeat ! important;
  }
</style>

この「! important」はこれを優先してください！というような命令なのでJavaScriptで変更した設定も変更することが可能になるそうです。
　

最後に

そもそもクリック時の処理をJavaScript側だけで済ませてしまおうと横着せずにCSSでcheckedとか使って処理すればハマることもなかったと思います…が、一つ勉強になりました。(おそらく結構初歩的なことだと思いますが)
今回はCSS内での優先度によるものでなかったのと、知識不足な今の私にはいまいち理解しきれなかったので今回はこれで終わりますが、どうやら「! important」を使わないクールな書き方もあるそうなので、もしマスターした時にはそちらも紹介しようと思います。

この記事はアピリッツの技術ブログ「DoRuby」から移行した記事です。情報が古い可能性がありますのでご注意ください。

イラストの線画による印象の違いをそれぞれ画像を作成し比較しました。

はじめに

nocoです。

このところイラストを描く際に「線画」の工程に時間をかけるようになりました。
強弱をつけたり、普段使わないブラシで線画を引いてみたり…少しずつこだわっていく中で線画によってイラストの印象が大きく変わることに興味を持ちました。

今回、イラストの線画のみを変えた画像をいくつか用意しました。
印象の違いに注目してご覧ください。

線画による印象の比較

ベースとなる線画

そのままバケツで塗り分けらえるような隙間のない線画です。
強弱を意識せず、スッと単色で線を引きました。
この線画に手を加え印象の違いを比較していきます。

線画の色を馴染ませる

それぞれの線の近くにある色を拾って線画に薄く乗せたものです。
線画と塗りが馴染み、やわらかな印象を与えます。

これは手法として確立し「色トレス」と呼ばれているそうです。
近年のゲーム系イラストのほとんどに使われているように思います。

線に強弱をつける

影の落ちる部分やすぼまった部分、手前にきている部分に線を加筆しました。
線に強弱をつけるだけでキャラクターの存在感がぐっと増します。

輪郭を縁取りする

輪郭を縁取るだけで、一気にまとまった印象になります。
背景に埋もれづらくなるため画面をスッキリさせることができます。

SDイラストの仕上げとして使用されることも多いですね。

ブラシの種類を変える

左から筆、水彩、鉛筆にブラシの種類を変えそれぞれ加筆したものです。
目指したいイラストの雰囲気に合わせてブラシを選びましょう。

近年のペイントソフトは、ベクターレイヤーに線画を描くことであとからブラシの種類を変更することができとても便利です。
ベクターレイヤーとは何ぞ？または詳しく知りたいという方は下記URLをご参照ください。

●レイヤーの種類1　ラスターとベクター – CLIP STUDIO (外部リンク)
https://howto.clip-studio.com/library/page/view/clipstudiopaint_tora_001_030

おわりに

着彩がシンプルなほど線画の表情は印象的になります。
目指したい表現に合わせた線画を作成し、より魅力的なイラストを目指したいですね。

この記事はアピリッツの技術ブログ「DoRuby」から移行した記事です。情報が古い可能性がありますのでご注意ください。

はじめに

こんにちは、なすちゃです。
今回はPhotoshopCS6を使用した内容になります。
他のバージョンとは異なる部分もあるかと思いますがご了承ください。

Photoshop

画像編集に特化した有料ソフトです。
有名なソフトなので名前だけでも聞いたことがある方も多いかと思います。
写真の加工やグラフィックデザイン・イラスト制作など様々な機能があるPhotoshopですが、
今回はタイムライン機能を自身の復習も兼ねてご紹介します。

・タイムライン機能
動画編集、アニメーション制作ができます。
ペイント・画像編集をしながら動画のフレームの編集などができ、
作成した動画を書き出し簡単にweb上にアップすることができます。

今回は、7月の投稿で作ったコンテを使用します。

Photoshopを起動し素材を用意したら、ウィンドウ＞タイムラインを開きます。

選択を「フレームアニメーションを作成」にします。

各レイヤーフォルダに秒数を設定していきます。
編集の時点で描き加えることも可能です。

編集ができたらレンダリングします。
web用に保存を選択

設定画面が表示されます

gifを選択＞保存で完了です。

モーションを作る前にコンテを動かし確認したりと、簡単に作ることができます。

この記事はアピリッツの技術ブログ「DoRuby」から移行した記事です。情報が古い可能性がありますのでご注意ください。

　最近マジリク(マージリクエスト)のレビューを依頼されることがありました。今まではレビューの依頼が一切なかったので、他人がプッシュしたマージされていないブランチをどうやって確認すれば良いか分かりませんでした。今回の記事は、マージされていないブランチの確認方法をまとめてみました。

マージされていないブランチをローカルで確認する方法

　マージされていないのでpullしてもローカルで確認することができません。そこで、以下のコマンドで確認できるようにします。
git fetch
git checkout -b 「確認したいブランチ名」

　fetchコマンドで、リモートにプッシュされたブランチの履歴をローカルにコピーします。
次にcheckoutコマンドでローカルにコピーしたブランチに切り替えます。これで、他人がプッシュしたマージされていないブランチの確認ができます。

fetchコマンド

　上記のfetchコマンドについてもう少し説明すると、fetchはリポジトリとブランチを以下のように指定することができます。指定しない場合は全てのリポジトリのブランチをローカルにコピーします。
git fetch 「リポジトリ」 「ブランチ名」

リポジトリがorigin、ブランチ名がtest_branchの場合は、以下のようになります。
git fetch origin test_branch

　fetchは、リモートから履歴を取得しているだけなのでローカルのファイルに影響がありません。ちなみにpullは、fetchした後にmergeを行う為ローカルのファイルが更新されてしまいます。

まとめ

　普段は、fetch+mergeを使用せずにpullのみ使用していたのでfetchのことを知ることができる良い機会でした。gitはまだ使いこなせていないコマンドが多いので、少しでも多く使いこなせるように頑張っていきたいです。

この記事はアピリッツの技術ブログ「DoRuby」から移行した記事です。情報が古い可能性がありますのでご注意ください。

社員もよくいくランチにおすすめのアピリッツ周辺のお店についてご紹介します。

　こんにちは飯処を探すのが趣味のtokinです。
皆さん勤務中の昼食は何を食べていますか？弁当やコンビニ･･･そして外食。昼の栄養摂取は様々です。その中でも社員さんとの昼の外食は、ただしっかりとした食事が楽しめるだけでなく、業務とはまた別の交流が深められる場であると最近痛感しております。
というわけで今回は現在アピリッツが位置している明治神宮通り～表参道周辺の社員もよく行くランチにおすすめの店を3店舗ご紹介したいと思います！

穏田 一甫 （オンデン イッポ）

　表参道から一つ裏に出た通りにある居酒屋定食屋。アピリッツの社員さんもよく利用しています。階段を下りた地下にある店内はちょっとした隠れ家のような内装で、落ち着いた雰囲気の中美味しい和食が楽しめます。さらにランチでは格安の海鮮丼が１５食限定で登場。他にも刺身定食や煮魚、焼き魚の定食、出汁のきいた饂飩などほっと一息つける品ぞろえ。ご飯の量も大盛りから小盛りまで選べるのでお腹の具合に合わせられるのも嬉しいところです。夜のお酒のラインナップも充実しているそうなのでランチだけでなくゆっくり呑みに行くのにもオススメのお店です。ツイッターにて毎日日替わりのランチ定食の内容もご紹介されてますのでお昼ご飯に迷った際はぜひご利用ください。
・穏田 一甫（食べログ）
・twitter

北陸酒場

　キュープラザ４階にある居酒屋。ランチでは野菜を中心とした日替わりのお惣菜ビュッフェが楽しめます。数種類の和え物や煮物、こだわりの豆腐やご飯がおかわり自由のこちらのビュッフェは定食に付属しており、1000円台で肉も野菜もたっぷり味わえます。ランチ定食は野菜と日本海で捕れた魚中心の健康的な和食メニュー、夜は日本酒と北陸酒場自家製の美味しい干物や素材のうまみを引き出した温かなおでんが味わえる居酒屋。野菜をたっぷり食べたい時や、酒と共に美味しい干物を心ゆくまで楽しみたい時にいかがでしょうか。
・北陸酒場

MIZUcafe

　浄水器でおなじみのクリンスイがプロデュースしたカフェ。
水にこだわり飲み物から食事まで“クリンスイのいい水”をベースに作られています。
メニューはパンネクックなどのデザート系からローストビーフ丼などのお食事系のものまで様々。なかでもローストビーフ丼はローストビーフの上にたっぷりの葉菜、加えて酸味のきいたドレッシングがかかっているためさっぱりとした味。上にのった卵の黄身を崩してもこのドレッシングの酸味により最後まで重くならずさっぱりいただけます。
更にこちらのカフェでは、セルフサービスで三種類のデトックスウォーターが味わえたり、「浄水、炭酸入り浄水、アルカリ水」の三種類の水の飲み比べまでが無料で体験できるそう。まさにクリンスイプロデュースならではの水を楽しむメニューですね（こちらの無料ドリンクのみの注文はご遠慮ください）。
日常的に摂取する水を此方のお店では様々な形で味わうことができます。水にこだわりをもったメニューぜひお楽しみください。

・MIZUcafe

最後に

いかがでしょうか。アピリッツ近辺には他にも美味しい食事が楽しめるお店がたくさんあります。アピリッツに入社した際、近辺に立ち寄った際はぜひ散策してみてください。

この記事はアピリッツの技術ブログ「DoRuby」から移行した記事です。情報が古い可能性がありますのでご注意ください。

先日、AppleからiPhone8/iPhoneX（10）が発売されましたね。 しかし、そのどちらにも、6以前にはあったイヤホンジャックは搭載されていないようです・・・ 従来のイヤホン愛用のiosユーザーには辛いです。 そこで、今までちょっと敬遠していたBluetoothイヤホンについて、 普通のイヤホンと比べて、使ってみないと分からなかった所などをまとめてみました。

基本的に、iPhoneで使ったときの印象です。
ちなみに使っているのは、iPhone7。イヤホンジャックはありません。
なので、従来のイヤホンを使う場合は、充電用のLightning端子に、
イヤホンジャックとの変換用コードをかませる必要があります。
変換用のケーブルは、iPhoneを買ったときに付属してたものを使っています。

従来のイヤホン

1. 壊れやすい。

一番の懸念点ですね。
もともとイヤホンって、付け根の部分が接触悪くなりやすいんですが、
変換ケーブルをかませてると、イヤホンか変換ケーブルどっちかがダメになるとアウトなので、
通常よりも壊れるリスクが高いと思います。
しかも、壊れたときに「これ、イヤホンとケーブル、どっちがダメになったんだ？」
という感じになるので、他の機器にイヤホンだけ接続したりして確認するしか無く、若干面倒です。

2. 充電したままイヤホンを使えない。

当然ながら、充電に使ってるLightning端子にイヤホンを差してるので、充電ケーブルと一緒に使えません。
一応、Lightning端子からイヤホン端子とLightning端子に枝分けする周辺機器もありますが、
なんか見た目が非常にダサいので そんなに充電しながら使う場面が無いので、自分は今のところ使っていません。

3. 使い回せる。

これも当たり前のことですが、変換ケーブルを抜けば他のイヤホンジャック付きの機器にそのまま使い回せます。
ただ、そのとき変換ケーブルをなくさないように注意が必要です。

これに関しては、Bluetoothイヤホン対応機器も増えてきてるので、将来的にはあまり差別化にならなくなるかもしれませんが。

Bluetoothイヤホン

1. 意外と接続が楽。

無線機器なので、初期設定が面倒なのかと思っていたのですが。
iPhone側でBluetoothをオンにして、後はイヤホンの電源を入れて、iPhoneの設定画面でイヤホンを選ぶだけ。
これだけでイヤホンが近くにあると勝手に接続するようになります。
しかも結構範囲が広い。接続したまま隣の部屋に行っても切れません（イヤホンや状況にもよるでしょうが）。

2. 値段が高い。

購入するときのネックになりやすい点です。
同じメーカーのものでも、普通のイヤホンに比べ、1.5倍~3倍くらいの値段になります。ピンキリですが。
ただ、イヤホンジャックに挿す必要が無くなるので、付け根周辺の接続不良などでの買い替えは起こりにくいかもです。

3. 音ズレがある。

個人的に買って一番驚いた所。
買うまであんまり気づいてなかったのですが、有線のイヤホンと違い通信を使うので、
どうしても多少、音が耳に届くのが遅れます。

プレイヤーで音楽を聴くだけなら、全く問題ありません。
しかし、普通に動画などを見るとき、（通信の具合にもよるのですが）口の動きと声がかなりずれるとか、そういうことがたまにあったりします。

スマホでゲームをするときにもすこし影響が出ます。
とはいえ、普通のRPGとかならタップ時の演出と効果音がちょっとずれるかな？ぐらい。
最初は違和感があるかもしれませんが、慣れてしまえば大したことは無いと思います。

この音ズレが顕著なのは、いわゆる「音ゲー」をプレイする時です。
基本的に曲のリズムに合わせてタップしたりする関係上、数コンマのズレでかなりやり辛くなります。
ゲーム側でタイミングを調整できる場合もありますが、それでもやはりタップ時に出る音がずれるので、かなりリズムが取りにくい印象です。

慣れている音ゲーマーさんとかなら良いのかもしれませんが、
そもそも音ゲーをあんまりやらない層からすると、ものすごく難易度が上がって感じます。
もはや音聴かずにやった方が良いのでは？と思うくらいでした・・・。

音ゲーにハマっていたり、よく動画を見たりする人で、ずっと有線のイヤホンを使っていたって人は、Bluetoothイヤホンにするのはリスキーかもしれませんね。
音楽聞くときだけBluetoothイヤホン、その他は有線、とかの使い分けも在処も知れません。経費かかりますが。

おまけ：Lightningイヤホン

これは自分は買っていないのですが、家電量販店で見かけたのでついでに。
普通のイヤホンの端子じゃなくて、先端がLightning端子になっているので、iPhoneにも直接挿せる形になっている有線のイヤホンです。
最初見たときは、『イヤホンジャックが無くなっても、これがあるなら良いじゃん！』と思ったのですが・・・。

1. 値段が高い？

びっくりしました。
自分の行ったお店では、Bluetoothイヤホンより余裕で割高でした。平気で1万を超えてきます。
相場としては、普通のイヤホンの4~5倍くらい？という印象でした。

使う側からすると、先っぽの端子がちょっと違うだけなのに・・・。

ただ、ネットショップだとそこそこの値段のものもあったりしたので、ピンキリ、ということなんでしょうか。

2. 種類が少ない。

これもお店によるでしょうが、普通のイヤホンやBluetoothイヤホンより、圧倒的に種類が少なかったです。
作っているメーカーが少ないんでしょうか？
たしかに、使える機器が限られてて、需要は少なそうですが・・・ちょっと残念。。

この記事はアピリッツの技術ブログ「DoRuby」から移行した記事です。情報が古い可能性がありますのでご注意ください。

Gem MechanizeでWebスクレイピング

以前Webスクレイピングを行う際に利用した、RubyのMechanizeが良い感じだったので紹介したいと思います。

参考
https://www.xmisao.com/2013/10/05/ruby-www-mechanize.html

環境

Mac OS X El Captain 10.11.5

ruby 2.4.1

Mechanizeとは

web上での操作を、rubyでも行えるようにしてくれるgemです。
フォームの操作や、リンクの取得・遷移などを簡単におこなうことが出来ます。

Mechanizeのインストール

$ gem install mechanize
# nokogiriを利用しているので、一緒にインストールされます。
# 2017/09/XX現在、最新バージョンは2.7.5です  

以下のように、Mechanizeクラスのインスタンスを作成することで、webページへのアクセス・情報取得が可能です。

require 'rubygems'
require 'mechanize'

# Mehcanizeのインスタンス作成
agent = Mechanize.new
# getメソッドでページへのアクセス
page = agent.get('https://www.google.co.jp')

# 例：ページタイトルの表示
p page.title
# => "google"

Mechanizeで出来ること

mechanizeには、便利なメソッドが数多く存在します。
自分がwebスクレイピングをする際に利用したものを、いくつか紹介したいと思います。

フォーム操作

自分はこれがやりたくてこのgemに辿り着きました。（調査不足だっただけで、ほかのgemでも出来るかもしれません。）

取得したページからフォームを取得して、値を代入・ボタンのクリックをすることで遷移先のページが取得できます。

##Googleの検索フォームで、Dorubyを検索する

#検索フォームの取得
form = page.forms.first
=> #<Mechanize::Form
 {name "f"}
 {method "GET"}
 {action "/search"}
 {fields
  [hidden:0x3ff22e4a64f0 type: hidden name: ie value: Shift_JIS]
  [hidden:0x3ff22e4a6388 type: hidden name: hl value: ja]
  [hidden:0x3ff22e4a6220 type: hidden name: source value: hp]
  [hidden:0x3ff22e4a60b8 type: hidden name: biw value: ]
  [hidden:0x3ff22e8afd94 type: hidden name: bih value: ]
  [text:0x3ff22e8af790 type:  name: q value: ]
  [hidden:0x3ff22e8ae9e4 type: hidden name: gbv value: 1]}
 {radiobuttons}
 {checkboxes}
 {file_uploads}
 {buttons
  [submit:0x3ff22e8af3d0 type: submit name: btnG value: Google 検索]
  [submit:0x3ff22e8aefc0 type: submit name: btnI value: Im Feeling Lucky]}>

# name: q　に検索クエリを代入
form['q'] = 'doruby'

# 検索ボタンのクリック
search_result = form.click_button

p search_result.title 
=> "doruby - Google 検索"

リンクを辿る

clickメソッドを使うことで、ページに含まれるリンクを辿ることが出来ます。
下記の例では、link_withを利用してリンクの取得を行っています。
今回はtextで取得していますが、classやidで指定・取得することも可能です。

# リンクの取得とクリック
doruby_page = search_result.link_with(text: "DoRuby: Web技術・マーケティング情報発信ブログ").click

p doruby_page.title
=> "Web技術・マーケティング情報発信ブログ | DoRuby"

Xpathを利用したWebスクレイピング

取得したページは、Xpathを利用してスクレイピングすることが出来ます。
また、この際にMechanize::PageからNokogiri::XML::Nodeにパースされるので、返り値はNokogiriになっています

# page.search('Xpath')で、XPathを利用した探索が可能

# aタグのhref要素に、entriesが含まれるものを探す
entries_first = doruby_page.search('//a[contains(@href, "entries")]').first
p entries_first.values
=> ["/users/r357_on_rails/entries/Kali-Linux(2016-X)の日本語利用について"]

上記の3つがあれば、比較的楽にwebスクレイピングを行うことが出来ると思います。
また、数多くのメソッドがあるので、そちらを利用すればより快適に利用することが出来るかもしれません。
参考:: Ruby-docs::Mechanize

補足: ユーザーエージェントの指定

webページにアクセスする際に、ユーザーエージェントを指定することが出来ます。
以前コードを書いた時は文字列で指定したのですが、エイリアスを利用して簡単に指定出来るようです。

agent = Mechanize.new
#文字列でのUAの指定
agent.user_agent = "Mozilla/5.0 (iPhone; CPU iPhone OS 10_3_2 like Mac OS X) AppleWebKit/603.2.4 (KHTML, like Gecko) Version/10.0 Mobile/14F89 Safari/602.1"

#エイリアスを利用したUAの指定
agent.user_agent_alias = "iPhone (iOS 9.1)"

おわりに

Rubyの便利なgem、mechanizeを紹介させていただきました。
他にもスクレイピングするのに便利なgem等ありましたら、ご紹介いただけるとうれしいです。

この記事はアピリッツの技術ブログ「DoRuby」から移行した記事です。情報が古い可能性がありますのでご注意ください。

一通りの作業に慣れてきたら次は作業の効率化に挑戦してみましょう。 Mayaではプログラミングの知識がなくても簡単にMelスクリプトを使って作業を効率化することが出来ます。 本記事ではそのやり方を紹介しています。

はじめに

Mayaのいくつかの機能の目的や使い方を理解し、だんだんと「自分流」のモデリングやアニメーションの作業が身についてくると、
作業の中で繰り返し行わなければならない単調なアクションがとにかく多いことに気づいてきます。

例えば私がモデリング作業の中でなにかとよく行うのが、オブジェクトの左右反転コピーです。
顔や体など対称軸がY軸上にあれば「ジオメトリのミラー」で反転コピーできますが、このコピーはオブジェクトを中心としたミラーしかできないので、猫耳だったりイヤリングなどミラーの基準軸から離れているパーツに関しては思っている結果になりません。

この左右反転コピーを行うには

オブジェクトを複製（Ctrl+D） 
　↓
 ピボットをワールドの中心に合わせる（「修正」→「トランスフォームのフリーズ」+「トランスフォームのリセット」）
　↓ 
チャネルボックス上でオブジェクトのスケールXの値を-1にしてもう一度「トランスフォームのフリーズ」

という3段階の手順を踏まなくてはなりません。（自分が知る限りでは）

Mayaには左右対称のモデリングをする際に便利な機能として「シンメトリの軸」を指定できたり、「特殊な複製」で複製して反面だけモデリングすればもう一方にも作業が反映されるというものがあります。

しかし、いまいち冒頭で述べた「自分流」に合わないということもあり、結局左右対称のモデリングをするときに私がよく使うのが「左右反転コピー」になります。
15秒程度のちょっとした作業ですが、一日に何度も行う日もあるのでできればワンクリックで済ませたいですよね。

Mayaはスクリプトで自由にカスタマイズできる

Mayaは一つ一つの機能がMelという言語で制御されており
頂点一つ一つの移動からノードの接続関係までそのほとんどがMelで動いており使い手からもスクリプトでの実行が可能です。
保存時によく見かける保存形式の「.MB」（Mayaバイナリ）と「.MA」（Mayaアスキー）という２種類の内の「.MA」という種類では
複雑な3DシーンがすべてMelスクリプトで記述して保存されているようです。

感覚的に3D制作ができるイメージが強いMayaですが実はかなり論理的でお堅いソフトみたいです。

参考 チュートリアル / 読んで触ってよくわかる！Mayaを使いこなす為のAtoZ 第70回：Maya
ASCIIとMayaBinaryの違い

左右反転コピーをワンクリックでできるようにしよう

説明が長くなってしまいましたが、さっそくMelスクリプトの力を借りてこれまで行ってきた単調な作業に終止符を打ちたいと思います。

ただ私自身プログラミングの知識がほぼありません。
きっとこの記事にたどり着いた方の多くも同じかと思います。
でも安心してください。
Mayaでは「スクリプトエディタ」上からすべての実行されたスクリプトが見られるようになっているので自分のアクションに対応したスクリプトがわかりやすいです。

まずさっそくオブジェクトを選択して複製してみましょう
するとスクリプトエディタ上には

と表示されます。複製のスクリプトは

duplicate -rr;

みたいなので、ひとまずメモ帳などにコピペしておきましょう。
続けてトランスフォームのフリーズとリセットを行います。

スクリプトエディタ上にはこのように出ますが見る限り今のアクションの実行文ではなさそうですね。
実行されたスクリプトが表示されていないみたいなのでスクリプトエディタ上のこの「すべてのコマンドのエコー」というボタンを押して再度同じアクションを行ってみます。



すると上の画像の通り新しく実行文が表示されました。

FreezeTransformations;
ResetTransformations;

この二つがそれっぽいですね。メモ帳に追加でコピペしておきましょう。
最後にスケールXを-1にします。

setAttr "pCube2.scaleX" -1;

これも同じくコピペして
抽出した文が以下になります。

duplicate -rr;
FreezeTransformations;
ResetTransformations;
setAttr "pCube2.scaleX" -1;
FreezeTransformations;

ただこのままだと”pCube2″というオブジェクトの名前が入ってしまっているので他の名前のオブジェクトでは機能しなさそうです。
少し調べてみると、選択中のオブジェクトのスケールXを変えるには
setAttr .scaleX -1;
だけで十分みたいです。

というわけで出来上がったのが以下の実行文になります。

duplicate -rr;
FreezeTransformations;
ResetTransformations;
setAttr .scaleX -1;
FreezeTransformations;

試しにこの寄せ集めで作ったスクリプトで左右反転を実行してみます。
スクリプトを実行する際はスクリプトエディタ上の縦に２分割されている下の空白に打ち込んでこのボタンで実行できます。

実行前

実行後

無事に左右反転コピーができましたね！
では、あとはこのスクリプトをボタンとしてシェルフに登録してあげるだけでワンクリック左右反転が実現します。

シェルフに登録

スクリプトを登録する手順を紹介します。
「ウィンドウ」→「設定/プリファレンス」→「シェルフエディタ」
でシェルフエディタを開きます。

「コマンド」タブを開いて先ほどの左右反転コピースクリプトをコピペ。
このボタンの名前やツールヒントなど自分に分かりやすいように入力してすべての「シェルフを保存」で登録完了です。

正常に動いていますね。

これで単調な作業におさらばして、作業の効率化と、省いた時間でクオリティ向上に注力していけますね。

まとめ

MayaではMelスクリプト以外にもPythonで動かすことが可能です。
今回の記事ではプログラミングの知識がない人でもMelスクリプトをコピペして簡単に作業の効率化を実現する方法を紹介しました。
ほかにも頭身の違う複数のキャラクターのセットアップ（コントロール作成等）をボタン一つで行うツールであったり、自分用にUIを作成してツールを使いやすくしたりと様々な事例があるみたいです。

人それぞれ作り方に「自分流」があって、ほしい機能もやはり個々によって異なります。
まずは自分の作業周りで困ったことやめんどくさいと感じたことを効率化していく努力をして、
徐々にチームでも重宝されるような開発ツールが作れるようになれば、一段と価値の高いデザイナーになれるのではと思います。

あなたも「テクニカルアーティスト」を目指してみてはいかがでしょうか。

Mel・Pythonコマンド一覧

この記事はアピリッツの技術ブログ「DoRuby」から移行した記事です。情報が古い可能性がありますのでご注意ください。

テクスチャのインポート設定での一つである “Generate Mip Maps” を自動でオフにする方法を考えます。

はじめに

こんにちは、inoooooocchiです。
気付けばあと2週間程度で10月。
入社から半年が経過しようとしていることにびっくりしています。早すぎます。

そんなこんなで今までやってきた作業や実装内容を思い返していたのですが、毎週のように行っている作業の中でおまじない的に行っているものがあり、「この一手間によって何がどう変わるんだろう…」と思ったため、調べてみました。

その作業とは、テクスチャのインポート です。
私はオンラインゲーム部に所属しているエンジニアなので、ゲームのUIなどで新しいグラフィックを使う際には、Unityにテクスチャをインポートする必要があります。
この業務内容を教わる際、先輩から「インポートしたらGenerateMipMapsのチェックをオフにすること」と教わっていました。
もちろんその時に説明をして頂いたのですが、当時は入社直後で覚えることが多く、大まかな流れを覚えるだけで精一杯でした。

と、いうことで、GenerateMipMapsのチェックをオフにする 意味を追い求めて行きます。

MipMapとは？

GenerateMipMaps…つまり、MipMapを生成するということなのですが、
そもそもMipMapってなに？
という疑問が浮かんできました。

Unityの公式マニュアルによると、

ミップマップはかなり小さくした画像イメージを複数集めた一覧であり、これによりリアルタイム 3D エンジンでのパフォーマンスを最適化します。カメラから遠く離れたオブジェクトはテクスチャの小さいものを使用します。ミップマップを使用すると 33% 多くメモリを使用しますが、使用しないとパフォーマンスのロスが顕著になります。

とのこと。
どうやら、縮小したテクスチャのリストのようなもので、カメラとの距離が離れて小さく描画する必要がある際に、ミップマップの中から適切なサイズのテクスチャを選んで描画する、といったもののようです。
リストを保持しておくためにメモリ使用量は増えますが、描画の際に小さなサイズを描画させることが出来るのでパフォーマンスが良くなるということでしょうか。

MipMapの効果検証

MipMapの意味が分かったところで、何故GenerateMipMapsのチェックをオフにするのか考えてみます。

先ほどのマニュアルの説明では、”リアルタイム 3D エンジンでのパフォーマンスを最適化”するためにMipMapを使っていると書かれていました。
つまり2Dでゲームを制作する場合、カメラとの距離も何も無いので、基本的に使われることは無さそうです。
ただし、2Dでもテクスチャを縮小して使いたい場合はあります。
そのような時にMipMapがどのような影響を及ぼすのか、実際に見てみました。

今回は、MipMapによる描画の違いの例として、
弊社Appiritsのゲームシリーズ「式姫プロジェクト(公式サイト：式姫大全)」から「狛犬(詳細はこちら)」に出演して頂きました。

• GenerateMipMaps オン
  
• GenerateMipMaps オフ
  

この例では、もともとのサイズが1024×1024のテクスチャを300×300のImageにアタッチしています。
一目瞭然ですが、MipMapを使っている方は全体的にアンチエイリアスがかかり、少し滲んだ感じがしますが、滑らかに表示されています。
一方、MipMapを使わない方は、ジャギーが目立ちますが色合いや細部ははっきりと表示されています。

このように、どうやら2DでもMipMapによって画像の描画の仕方が変わるようです。

ゲームのUIにおけるMipMap

さて、先ほどはテクスチャのサイズを元より小さくした際にMipMapが適用されることを確認しましたが、ゲームのUIに使うテクスチャのように、サイズが変動しないことを前提としているテクスチャもあると思います。
これらのテクスチャに対し、GenerateMipMapsをオンにしてしまうと、使いもしないのに縮小されたテクスチャが生成されることになってしまいます。

これでようやく、私のインポート作業の中でGenerateMipMapsのチェックをオフにする意味がはっきりしました。
UIに使うテクスチャはMipMapを生成しても使わないので生成するだけメモリの無駄！
ということですね。

インポート作業を簡単にしよう

というわけで、テクスチャをインポートするたびにGenerateMipMapsをオフにする作業をこれからも続けていかなければならないわけですが、「2DゲームだからMipMapいらないか…」と割り切ってしまえば、この作業は簡単に自動化出来ます。

以下のスクリプトファイルを作成することで、インポート時及びインポート設定の変更時に、GenerateMipMapsを自動でオフにしてくれます。

using UnityEditor;
using UnityEngine;

public class TextureImportProcessor : AssetPostprocessor {
    // インポート設定のデフォルト値をインポート前に変更可能
    public void OnPreprocessTexture(){
        // assetImporterがインポート設定を持っている
        var importer = assetImporter as TextureImporter;

        // GenerateMipMapsをオフにする
        importer.mipmapEnabled = false;
    }
}

AssetPostprocessorというクラスを継承することで、インポート処理にフックしてスクリプトを実行することが出来ます。
今回はテクスチャのインポート設定を変更したいので、TextureImportProcessorというクラスを作りました。

OnPreprocessTexture関数は、インポート処理の前に呼び出されます。この時点でインポート設定を変更しておけば、インポートされるテクスチャの設定にその変更が自動的に反映されます。

AssetPostprocessorの詳細に関しては、公式のスクリプトリファレンスを見ればなんとなく分かると思います。

余談ですが、上記のスクリプトを使う場合、どう頑張ってもGenerateMipMapsをオンに出来ません。
オンにして設定を保存すると、即座にオフに変更されるからです。
UIだけオフにしたい等の場合は、UIとそれ以外でテクスチャのディレクトリや命名規則を分け、スクリプト内で判定して区別してあげる必要があります。

最後に

簡単なスクリプトを書くだけで、作業の手間が省けるのは非常にありがたいですね。
Unityの拡張性の高さに、改めて驚かされますね。
DoRubyでは、他のライターの方がUnityのエディタ拡張について書いているため、興味があればそちらもご覧ください。
( UnityEditor上で複数のゲームオブジェクトをプレハブ化する方法)

これまた余談ですが、弊社のゲーム作品「かくりよの門」及び「うつしよの帳」で使われている式姫スタンプの、狛犬の「突撃ッスー！」がアホ丸出しでなんだか好きです。

この記事はアピリッツの技術ブログ「DoRuby」から移行した記事です。情報が古い可能性がありますのでご注意ください。

パソコンの入力デバイスとしてのマウスと聞いて、おそらくみなさんが同じものを思い浮かべることでしょう。 今回はそれとはちょっと違う、トラックボールマウスのご紹介をします。

トラックボールマウスとは？

現在主流となっているレーザー式や光学式が採用される以前、マウスの裏側にはボールが入っていました。それは、

マウスを動かす -> ボールが動く -> カーソルが動く

という仕組みの、現在ではほとんど見なくなった絶滅危惧種のマウスです。

そんなボール方式のマウスのボール部分を直接操作できるようにしたのが、トラックボールマウスです。

トラックボールマウスの良いところ

• 省スペースで扱える
  
  本体を動かさずに操作できるため、設置するスペースさえ確保できれば使うことができます。
  
  ワイヤレストラックボールマウスの場合、膝の上やひじ掛けの上などお好きな場所で使うことが出来ます。
  
  マウスを動かすスペースがないほど机の上が物で溢れかえっている方は、ぜひトラックボールマウスを使いましょう。
• 手首が疲れない
  
  指先のみで操作を行うため、手首への負担が軽減されます。
  
  手首の痛みに悩んでいる方は、ぜひトラックボールマウスを使いましょう。

トラックボールマウスの悪いところ

• 慣れるまで操作が難しい
  
  普通のマウスを使っている人がトラックボールマウスを使用した際に最もネックとなるのが操作感です。
  
  慣れないうちは思ったようにカーソルを動かすことができず、イライラすることがあります。
• 汚れが溜まりやすい
  
  ボールを動かしてカーソルを操作するという特性上、センサー周辺にホコリなどのゴミが溜まりやすく、ボールの動きを阻害してしまいます。
  
  操作感を保つためにもこまめな掃除が必要となります。

おわりに

トラックボールマウスを使いこなすには慣れが必要ですが、一度慣れてしまうと手放せない魅力があります。

これからトラックボールマウスを使おうと思っている方に私がおすすめするのは、Logicoolの Trackman Marble と ナカバヤシ株式会社の Digio2 Q です。

この機会にみなさま、トラックボールマウスを使ってみてはいかがでしょうか。

この記事はアピリッツの技術ブログ「DoRuby」から移行した記事です。情報が古い可能性がありますのでご注意ください。

ゲーム制作をする人なら多くの人が聞いたことがあり、 そうなりたくないと思っている「エターなる」。 今回はかつて個人でゲーム制作をしていて、現在アピリッツで 働いている身としてこの事を考えてみる。

「エターなる」って？

　知らない人もいると思うので「エターなる」の意味を一応解説しておこう。「エターなる」とは「永遠に（eternal）作品が完成しない」ことを意味している。その理由は制作環境の変化や病気といったものから、飽きたなんていうものまで多岐に渡る。
　昨今では「エターなりたくなかったらこうしたほうがいい」なんて話はあちこちで散見される。しかし、個々人によって性格や得手不得手があるので、どれが正しいとかは一概には言えない。それでも今回書くのは1人でも多くの人にエターなってほしくないからである。　

企画書・仕様書を書く

　「そんなガチなことしたくない」「どうせ頭の中に入ってるし」「書く暇があったら作りたい」と個人で制作している人ほど思ってしまい、飛ばしてしまうこの工程。（自分もかつて1人で制作していた身としては実に思い当たる節がある。過去に戻れるなら説教している。）
　企画書・仕様書を書くとは、「今から自分がどんなものを作ろうとしているのか」をまとめる行為であり、「後で見返して一貫性を保つ」と共に、「作品の限界を決定する」ことができる。「作品の限界を決定する」と言うと怒られそうだし、制作途中で新たな仕様を追加しても全然ＯＫなのだが、よく考えずに「コレ良いから追加しよ！」は非常に危険と言わざるを得ない。
　追加するということは仕様が増えるということで、制作時間が伸びるということになる。制作途中でどんどん仕様が増えて永遠に制作が終わらない、エターなる一直線である。

モチベーションを維持する

　はい、そうですかと言って簡単にできるものではないのは百も承知だが大事なこと。ただ、「維持する」とは毎日四六時中「うおぉぉ！」ってなってることではないので、そこを勘違いしていると本当はモチベーションがあるのに維持できていないと思い込んで、本当にモチベーションが無くなってしまったりする。要は自分の環境や性格に合わせて「毎日20時から2時間」「土日に6時間」とか決めておいたり、やる気がでないときに無理にやったりしないようにすればいい。
　また、よく言われる対策として「ときどき友人・知人に見てもらったり、インターネットで公開すると反応が貰えてモチベーションに繋がる」というのがある。これは本当にそうだし、制作サイドでは気づかない観点で情報を得られるので作品のクオリティアップにも繋がるので絶対にやった方がいい。
　ただ、やりすぎると逆効果になることもあったり、実施に時間がかかるので数ヶ月に1回程度にするのをオススメする。

まとめ

　最後に１つだけ。よく言われるアドバイスではあるのだが、「完璧を目指す前に完成させろ」は大事な精神。クオリティアップは後から好きなだけ出来るし、一通り完成していると心持ちが全く違う。多少ハリボテでも遊べないよりはずっと良い。

この記事はアピリッツの技術ブログ「DoRuby」から移行した記事です。情報が古い可能性がありますのでご注意ください。

今回はタイトル通り、ゲームを少しの手間をかけて面白く見せる工夫をしようと思います。
まずは３時間くらいかけて錬成したゲームをみてください 。

疑う余地の無いホッケー (?)ゲームです。
ちなみに左側は僕が操作していて右は適当にプログラムで動かしています。

これが面白く見えるように要素を足していこうと思います。

何かしら動かす

無操作状態だとしても全く動きのない画面のあるゲームはあんまり無いと思います。動きが無いと動作しているのかのか不安ですし寂しいですよね。
ですが、逆にゲーム画面は動きがあるだけで少しそれっぽくなるものです。

なので足してみました。

四角を適当に降らしているだけでもなかなか観れるものになったと思います。
背景などプレイに関係の無いものは一定の動きを繰り返すような単調な動きが楽だし丁度いいです。

アクションにはリアクション！

ユーザーのアクション対して反応があると気持ち良さが上がります。
このゲームのアクションは球にぶつかるくらいなものなのでぶつかった時にエフェクトを出してあげます。

当たった感が増えました。
そしてなにより当たらなかった事がよりわかりやすくなりました。
当たっている事を明確にする事により、表現しにくい「当たらなかった」ということも伝える事ができます。

情報を視覚化させる

このホッケーゲームは球を弾くたびに球の速度が上がっていきます。
早さに応じて色を赤くしていますがゲームのメインにしては少し物足りない気がするのでわかりやすく軌跡をつけてあげましょう。

スピードが上がっていくのが分かりやすいだけでなく、滑らかに動いているようにすら見えます。
このゲームでユーザーが一番見るところはおそらく球なので、主役にはもう少し手間をかけてもいいと思いました。

まとめ

少しは楽しく見えるようになったのではないでしょうか。
これらの追加にかかったのは30分くらいで、思ったよりお手軽にできたと思います。
以上、ゲームを面白くする工夫でした。

※この記事の内容はあくまで作者の主観によるものです。

この記事はアピリッツの技術ブログ「DoRuby」から移行した記事です。情報が古い可能性がありますのでご注意ください。

今回は、近い将来に実用化がされるかもしれない、「量子テレポーテーション」という現象について紹介します。※本記事は分かりやすさを重視するため、正確性を犠牲にしています。ご了承ください。ふんわりと内容をお伝えできればと思います。

量子テレポーテーションとは？

Wikipediaによると、

古典的な情報伝達手段と量子もつれ (Quantum entanglement) の効果を利用して離れた場所に量子状態を転送することである。

とあります。難しい言葉がふんだんに用いられているので、自分なりに用語を解説したいと思います。
まず、
・量子：物理量の最小単位、ものっっっすごく小さい粒というイメージです。
・古典的な情報伝達手段：現在使われている、メールや電話といった一般的な情報伝達手段のことです。
・量子もつれ
　これが一番意味の分からない単語ですね。簡単に解説すると、
「片方の状態が分かると、対になるもう片方の状態が分かる」ような状態のことです。
例えば、二つの箱の中の一方にボールを隠します。ボールは二つの箱の内の一つにしか隠されていません。従って、片方の箱を開けて中身を確かめれば、自動的にもう片方の箱の中身が決まります。簡単に言うと、このような状態のことです。

これらを踏まえて、量子テレポーテーションを説明すると、
「特別な関係にある粒子の効果と電話を一緒に使って、離れた場所に粒子の状態を転送すること」
となります。まだまだイメージが付きにくいと思うので、例を用いて説明していきます。

ものすごく大雑把な例

ここでは例として、「卵焼き」をテレポートさせてみようと思います。
前提として、二人の人間、AさんとBさんに「全く同じ卵」を渡して、遠く離れた場所にいてもらいます。（「量子もつれ：特別な状態」を簡略化し、全く同じものとして考えます。）
ここからBさんの作った卵焼きをAさんのもとへテレポートさせます。
①Bさんがこの特別な卵を使って卵焼きを作ります。
②Bさんが出来上がった卵焼きをよく味わって食べて、超詳細にレポートを書きます。
③BさんがAさんへ電話をし、レポートと作成手順を超詳細に教えます。
④AさんがBさんの言われたとおりに卵焼きを作ります。
⑤あら不思議、Bさんの作った卵焼きがAさんのもとへテレポートしました。

いかがでしょうか。ただのレシピの口伝じゃないか、と思うかもしれませんが、ここで重要なことが二つあります。
一つ目は、BさんはAさんにレシピを伝えるために、火の入れ加減から箸でつついた回数、卵を割るときのヒビの入り方、さらには卵分子の並び方に至るため、超詳細に分析しているということ。
二つ目は、AさんはBさんの情報をもとに、卵分子の並び方まで完全に再現できたということ。
この二つです。こんなこと非現実的だと思われるかもしれませんが、その通りです。
卵焼きのような大きな物質では非現実的に思えるほど難しいですが、現在では、考えられる状態が少ない超小さい粒子において、この量子テレポーテーションの実験に成功したと発表されています。

応用①：テレポート

ここからは現実的かどうかは置いておいて、応用例を紹介します。
その①はテレポートです。
上の例での「卵焼き」を「人間」に置き換えるだけです。
すると、会社から自宅へ「私」の構成要素と作り方を送ると、自宅の機械が「私」を再現し、あたかもテレポートしたように移動できます。
つまり、人間を構成する要素と、その詳細なレポートを書いてくれるマシーンがあれば、どこにでもテレポートすることが出来るのです。
ただし、技術的な壁も高いですが、会社にいた「私」は、分子の並び方などの超詳細なデータを取るために機械にバラバラにされてしまうので、倫理的にも非現実的なものと言えます。

応用②：情報通信

こちらは現実的な応用例です。
上の卵焼きの例で、一つ重要なことがあります。
それは、
「手元に特別な卵がない限り、この卵焼きを再現できないこと」です。
現在の情報伝達手段では、送りたいものを（暗号化等の処理を挟むにしても）、そのまま送ることしかできません。情報漏洩が起これば、大変な被害が生じかねません。
しかし、この量子テレポーテーションを用いれば、粒の状態をどうやって変化させるか、という手順書を送るだけで情報のやり取りができます。
これは、たとえ情報漏洩が起こったとしても、特定の粒（上の例では特別な卵）が手元に存在しなければ意味がありません。従って、情報漏洩に対してとても強い情報通信手段になりえます。

終わりに

いかがでしょうか。人間のテレポートという夢のような手段にしては、倫理的にも技術的にも問題だらけであるのが現状ですが、とても面白い技術ではないでしょうか。
※繰り返しになりますが、本記事は分かりやすさを重視するため、正確性を犠牲にしています。ご了承ください。

この記事はアピリッツの技術ブログ「DoRuby」から移行した記事です。情報が古い可能性がありますのでご注意ください。

アピリッツは、日頃より最新技術にアンテナを張り研究しています。それを、新しいビジネスに役立てたり、お客様のサービスにとって最適な情報である場合は、ご提案したりと役立てています。 今回、会社の中からブロックチェーンに興味のある技術者やコンサルタントなど職種や役職を問わず募集し、「アピリッツ・ブロックチェーン・ラボ（ABCL)」を2017年6月8日に創設しました。

創設の目的

昨今、ブロックチェーンは注目され、各社研究され実証実験が行われ、金融、IoT、物流などの幅広い分野で応用されています。
少し乗り遅れていますが、アピリッツではブロックチェーン技術を利用したビジネスの検討を行うため、アピリッツ・ブロックチェーン・ラボ（ABCL）を創設し、情報収集や実証実験などを行っていきます。

ABCLの活動内容

• 定例会
  • 収集した情報の報告・宿題事項の報告
• ハッカソン、アイデアソン実施
  • 実際に触れてみて、仕組みを理解
  • ビジネスを考えてみる
• DoRuby記事執筆
  • BCCC委員会への参加・フィードバック
  • JBA定例への参加・フィードバック

今後の予定

• 情報収集
  • ユースケース調査
  • 仮想通貨またはトークンの目的と技術調査
• 技術検証
  • Bitcoin、Litecoin、Ethereumなどのソースを触り、実際に稼働させ、マイニングの実施や簡易アプリケーションの作成を行います。
  • ハッカソンを実施（社内）します。
• 企画
  • アイデアソンを実施（社内）します。
  • 共同研究などが出来るのであれば実施します。
• 施策検証
  • 実際に企画したものを作成して動作・効果検証します。
• 情報共有
  • 社内外にABCLで行っていることを共有します。

この記事はアピリッツの技術ブログ「DoRuby」から移行した記事です。情報が古い可能性がありますのでご注意ください。

2があるかどうかは微妙。

　こんにちは、HelloWorld+です。
　今回もまた、ActiveRecord関連の話をしようと思います。

状況

　どんなゲームにおいても、キャラクターは無くてはない存在です。
　そして、以下のような人間マスタと、人間パラメータマスタがあるとします。

HumanMaster

id:                          integer
code:                        integer
name:                        string
hp_parameter_code:           integer
power_parameter_code:        integer
intelligence_parameter_code: integer
speed_parameter_code:        integer


HumanParameterMaster

id:        integer
code:      integer
age:       integer
parameter: integer

　才能とか、画像コードとか、職業とか年収とか余命とか、そんなものも実際のHumanMasterには含まれますが、今回は簡略化してこんな感じで。
　そして、上記のマスタからだと、人間そのもののデータの形は以下のようになります。

Human
id:             integer
human_code:     integer
hp:             integer
power:          integer
intelligence:   integer
speed:          integer
age:            integer

　Humanそのもので保存するデータは、HumanMasterと紐付ける為の最小限のデータ(今回だと、HumanMasterのcodeとHumanのhuman_codeが紐付いている形になります)と、Human一体一体で違った値になるパラメータ周りになります。
　そして、Humanが加齢した際には、HumanMasterのパラメータコード、そしてHumanの年齢を参照し、HumanParameterMasterそれぞれのパラメータの値を取得、更新する形になります。
　今回は、パラメータはHuman単位ではなく、Parameter単位で管理されている、とします。どちらにも利点と欠点があるのですが、そこあたりは割愛します。

加齢の工程

Human加齢！
↓
Humanのcodeから該当するHumanMasterを取得。
↓
Humanのage、HumanMasterのそれぞれのparameter_codeからHumanParameterMasterのパラメータを取得。
↓
Humanのパラメータを上書きして加齢による能力値変動が完了。

この工程を、サーバー側で行う為の、Railsのコードに起こしてみましょう。

def birthday!(human)
  #人間マスタ取得
  human_master = HumanMaster.find_by(code: human.code)
  #パラメータ上書き
  ["hp", "power", "intelligence", "speed"].each do |param_str|
    parameter_code = human_master[param_str + "_parameter_code"]
    parameter_master = HumanParameterMaster.find_by(code: parameter_code, age: human.age)
    human[param_str] = parameter_master.parameter
  end
  #保存
  human.save
end

　基本的には、まあ、こんな感じでしょう。でも、これだとやや冗長なところがあります。
　以下の一文になります。

parameter_master = HumanParameterMaster.find_by(code: parameter_code, age: human.age)

　え？　単純に取得してきてるだけじゃん、と思うかもしれませんが、これだとまだ冗長なのです。
　パラメータマスタを取得してきて、使っているのはparameterだけです。それ以外のデータは必要ありません。
　そして、レコードそのものを取ってくるより、カラムの一つのデータを取ってくる方が速いのです。
　今回はパラメータを参照する回数はhp, power, intelligence, speedの4回だけですが、もっと数が増えてきた場合、同じように一々レコードそのものを参照していると如実に処理速度の差が出てきます。
　ただ、ここで問題が生じます。
　find_byからでは、カラム単体のデータを取ってくる術はありません。
　では、どうしたら一つのデータを取って来る事が可能か？
　方法は二つあります。
　一つ目は、whereからのselectとかpluckとか。

parameter = HumanParameterMaster.where(code: parameter_code, age: human.age).select(:parameter).take.parameter

　もう一つは、SQL直打ち。

parameter = ActiveRecord::Base.connection.select_value("SELECT parameter FROM human_parameter_masters WHERE code = #{parameter_code} AND age = #{human.age}")

　SQL直打ちの方がちょっとだけ速いのですが、まあ、コードの中にSQL直打ちするのは美しくないと色々言われたりするので、本当に速さを求めない限りは、上で大丈夫でしょう。上に置き換えるだけでも、処理速度はかなり速くなります。

　さて、最後にRailsで実際に作った人間パラメータマスタで以下のようなコードを打ってみて、実行時間の差を感じて貰って終わりにしたいと思います。

def get_time
  time = Time.now
  yield
  p Time.now - time
end

#レコードそのまんま
get_time do
  1000.times do |n|
    HumanParameterMaster.find_by(id: n + 1)
  end
end
#3.851174sec

#絞り込み
get_time do
  1000.times do |n|
    HumanParameterMaster.where(id: n + 1).select(:parameter).take.parameter
  end
end
#0.714646sec

#SQL直打ち
get_time do
  1000.times do |n|
    ActiveRecord::Base.connection.select_value("SELECT parameter FROM human_parameter_masters WHERE id = #{n}")
  end
end
#0.369945sec

　では、より速さを求める(時にはコードの綺麗さを犠牲にして)Railsライフを送りましょう。

この記事はアピリッツの技術ブログ「DoRuby」から移行した記事です。情報が古い可能性がありますのでご注意ください。

エンジニアも非エンジニアも、Markdownを使うと生活が豊かになることでしょう。

Markdownとはなんぞや

Markdown は プレーンテキストで見出し・箇条書きなどのちょっと構造化した文章がかける便利なマークアップ言語です。
が、細かい話はなしで 記号や書式をちょっと変えてみませんか？ くらいの話です。

Markdownでものを書くときの利点は

• そのままでもそこそこの見た目の文書になる
• 変換するとかなりそこそこの見た目の文書になる

ことです。

たとえばこの記事もMarkdownで書いています。上の文章は実際には以下のようなテキストです。

Markdownとはなんぞや
====

[Markdown][1] は プレーンテキストで見出し・箇条書きなどのちょっと構造化した文章がかける便利なマークアップ言語です。
が、細かい話はなしで **メモをとるときの記号や書式をちょっと変えてみませんか？** くらいの話です。

Markdownでものを書くときの利点は

* そのままでもそこそこの見た目の文書になる
* 変換するとかなりそこそこの見た目の文書になる

ことです。

[1]: https://daringfireball.net/projects/markdown/

ここでは色々使っていますが、とりあえず箇条書きと見出しだけでも覚えれば生活が楽になります。
エディタやサービスによっては少し書式が違うものもありますが、主要なものはあまり差はありません。

フォントを変えたり色を変えたりするほど高機能でなくてもいいけど、ただの文章よりはもう少しちゃんとした文章を書きたい…そんなときに便利です。

「markdown エディタ」などで検索すると、markdownの入力補助や変換、表示をしてくれるものが色々見つかると思います。

普段は Kobito を使ってメモを書いたりしていたのですが、この記事を書いていたところ HackMD というWebアプリを教えてもらいました。
共有・共同編集も簡単にできますし、チーム内で使うのによさそうです。dockerイメージもあることなので今度導入してみたいですね……。

エンジニアとして幾つか挙げましたが、この世に数多存在するエディタから、導入や使い方のハードル・目的に応じて好きなものを選んでいただければと思います。

すぐにできるかんたんMarkdown

箇条書き

メモをとるときに箇条書きする人は多いと思いますが、私もその一人です。
箇条書きは箇条書き記号を半角アスタリスクと半角スペースにして、前後に空行を入れるだけです。

* あああああ
* いいいいい

• あああああ
• いいいいい

箇条書き記号はアスタリスクではなく半角ハイフンでもよいです。
また、箇条書きは先頭に半角スペースかタブを入れることで入れ子にできます。階層によって記号を変えると読みやすくなります。
半角スペースの数は4つにしておくとだいたいどんなものでもきちんと入れ子にしてくれます。

* あああああ
    - いいいいい
    - ううううう
* かかかかか
    - ききききき

• あああああ
  • いいいいい
  • ううううう
• かかかかか
  • ききききき

もっと入れ子にできますがそこまではあまり使う機会がないかもしれません。

見出し

要するに章・節を分けたときのタイトルですね。今この文章の上にある「見出し」もそうです。

大きいほうから

# 一番大きい見出し
## 二番目に大きい見出し
### 三番目に大きい見出し
#### 四番目に大きい見出し
##### 五番目に大きい見出し

一番大きい見出し

二番目に大きい見出し

三番目に大きい見出し

四番目に大きい見出し

五番目に大きい見出し

一番大きい見出し、二番目に大きい見出しには別の記法もあります。

一番大きい見出し
====

二番目に大きい見出し
----

一番大きい見出し

二番目に大きい見出し

=や-の数は1つ以上であればいくらでも伸ばせます。
見出しの前後に改行を入れると見出しとして認識しやすくなります。

引用

文章を引用するときは、以下のように行頭に > と半角スペースを入れます。

> ああああああ
> いいいいいい

ああああああ
いいいいいい

強調・打ち消し線などの文字装飾

斜体・太字・打ち消し線なども書けます。テキストで見たときに箇条書きや見出しほど直感的でないのが少し残念です。
個人的によく使うのは 太字 です。

*あああああ*
**いいいいい**
~~ううううう~~

あああああ
いいいいい
ううううう

文中で使うときは **このように** 前後に半角スペースを入れる必要があります。

他にも色々な記法がありますが、普通の文章(こういったブログなど)を書くのにはこのくらいわかれば十分な気がします。

まとめ

ぼーっとしているとゴミのような文章を書いてしまうことも多いのですが、箇条書き・見出しを活用すると構造を少し意識して書くようになって少しまともな文章が書けるようになった気がします。
読みやすい文章を書いて豊かな生活を送りたいものです。

この記事はアピリッツの技術ブログ「DoRuby」から移行した記事です。情報が古い可能性がありますのでご注意ください。

はじめに

こんにちは　motsukaです。

みなさんUnityを使うとき何気なくオブジェクトをプレハブ化して使っていますよね？
ですが、その中身がどうなっているかなんて知らないで使っている人が多いんじゃないですか？わたしは実際どうなっているか知りませんでした。
ですが、UnityをGit管理しているとき、よくプレハブがコンフリクトを起こしてしまって手動でマージしないといけない時、適当なエディタでファイルを開きますよね？
その時の構造を知れば、もっと安全に修正ができるとは思いませんか？
ということで、中身を読んでいきたいと思います。

GameObjectを読む

では下準備として、インスペクター上で新しくゲームオブジェクトをつくり、それをそのままプレハブとして保存します。

その保存したプレハブをテキストエディタで開いてみましょう。

そうすると、以下のようになっています。

  %YAML 1.1
  %TAG !u! tag:unity3d.com,2011:
  --- !u!1001 &100100000
  Prefab:
    m_ObjectHideFlags: 1
    serializedVersion: 2
    m_Modification:
      m_TransformParent: {fileID: 0}
      m_Modifications: []
      m_RemovedComponents: []
    m_ParentPrefab: {fileID: 0}
    m_RootGameObject: {fileID: 1000012251039328}
    m_IsPrefabParent: 1
  --- !u!1 &1000012251039328
  GameObject:
    m_ObjectHideFlags: 0
    m_PrefabParentObject: {fileID: 0}
    m_PrefabInternal: {fileID: 100100000}
    serializedVersion: 4
    m_Component:
    - 4: {fileID: 4000012487135774}
    m_Layer: 0
    m_Name: GameObject
    m_TagString: Untagged
    m_Icon: {fileID: 0}
    m_NavMeshLayer: 0
    m_StaticEditorFlags: 0
    m_IsActive: 1
  --- !u!4 &4000012487135774
  Transform:
    m_ObjectHideFlags: 1
    m_PrefabParentObject: {fileID: 0}
    m_PrefabInternal: {fileID: 100100000}
    m_GameObject: {fileID: 1000012251039328}
    m_LocalRotation: {x: 0, y: 0, z: 0, w: 1}
    m_LocalPosition: {x: 2464.8406, y: 272.8769, z: 0}
    m_LocalScale: {x: 1, y: 1, z: 1}
    m_LocalEulerAnglesHint: {x: 0, y: 0, z: 0}
    m_Children: []
    m_Father: {fileID: 0}
    m_RootOrder: 0

では、上から見ていきましょう。

上から2行はただのヘッダーですので、気にしないでいいです。
3行目の !u!1 &6　とは、基本的にコンポーネントの切れ目に存在するもので、!u!の後の数字は オブジェクトクラスというUnityに割り振られたオブジェクトのIDが書かれています。このIDを使ってこのオブジェクトがなんなのかを判別しています。
&10010000は任意に名付けられるファイルIDでこの値を参照してどこのオブジェクトの子にいるのかなどに使われています。
その下からプレハブ内部の情報が書いてあります。

  Prefab:
    m_ObjectHideFlags: 1
    serializedVersion: 2
    m_Modification:
      m_TransformParent: {fileID: 0}
      m_Modifications: []
      m_RemovedComponents: []
    m_ParentPrefab: {fileID: 0}
    m_RootGameObject: {fileID: 1000012251039328}
    m_IsPrefabParent: 1

基本的にプレハブの参照関係が書かれています。
また参照　{fileID: 1000012251039328}は、
このファイルIDを参照していることを意味しています。
ファイルIDは、ファイル内でユニークな値ですので、違うファイルにも同じ値があることがあります。また、{fileID: 0} はどこにも参照していないことを示しています。
では、このプレハブが参照しているファイルIDのゲームオブジェクトを見ていきましょう

--- !u!1 &1000012251039328
GameObject:
  m_ObjectHideFlags: 0
  m_PrefabParentObject: {fileID: 0}
  m_PrefabInternal: {fileID: 100100000}
  serializedVersion: 4
  m_Component:
  - 4: {fileID: 4000012487135774}
  m_Layer: 0
  m_Name: GameObject
  m_TagString: Untagged
  m_Icon: {fileID: 0}
  m_NavMeshLayer: 0
  m_StaticEditorFlags: 0
  m_IsActive: 1

先ほど参照されていたファイルIDと同じものだということが１行目で確認できますね。
先ほど示したものはプレハブの情報だけしか載っていなかったのですが、ここからはゲームオブジェクトにくっついている様々なコンポーネントなどの情報が書かれています。
ここで大事な部分は、７行目のm_Componentの部分です。
これはこのゲームオブジェクトにどんなコンポーネントがついているかの参照が書かれています。

m_Component:
- 4: {fileID: 4000012487135774}

ここでは、オブジェクトクラスIDとファイルIDの参照が書かれています。
4という数字がオブジェクトクラスIDで、Unityのリファレンスで確認してみると、Transformということがわかります。
では、この参照されているTransformのファイルIDをファイルないから探してみましょう。

    --- !u!4 &4000012487135774
    Transform:
      m_ObjectHideFlags: 1
      m_PrefabParentObject: {fileID: 0}
      m_PrefabInternal: {fileID: 100100000}
      m_GameObject: {fileID: 1000012251039328}
      m_LocalRotation: {x: 0, y: 0, z: 0, w: 1}
      m_LocalPosition: {x: 2464.8406, y: 272.8769, z: 0}
      m_LocalScale: {x: 1, y: 1, z: 1}
      m_LocalEulerAnglesHint: {x: 0, y: 0, z: 0}
      m_Children: []
      m_Father: {fileID: 0}
      m_RootOrder: 0

これが参照されているファイルIDのオブジェクトです。
確かにオブジェクトクラスIDに示されえている通りTransformですね。
TransformなのでPositionやRotationなどの項目がありますね。
またm_GameObjectの参照を見てみると先ほど見ていたゲームオブジェクトに参照がされていることがわかります。

まとめ

いかがだったでしょうか？プレハブファイルが読めるようになるとgitでコンフリクトした時にも役に立つので皆さんも是非読んでみてくださいね。
興味のある人はSceneファイルも同じ形式で書かれているので読んでみるといいと思います。
もう少し詳しく知りたいなら、Unityマニュアルの
https://docs.unity3d.com/ja/current/Manual/FormatDescription.html
のところを読んでみると面白いと思います。