この記事はアピリッツの技術ブログ「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
のところを読んでみると面白いと思います。

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

皆さんこんにちは
モツ太郎です。
そろそろ記事のネタが尽きてきました…
そんな中今回どんな記事を書こうかなーと思っていたのですが、せっかくなので最近から始めたプランナーが行う発注について書いていこうかなと思います。
※いつも通り個人のやり方なので悪しからず。

そもそも発注とは？

新しいマップやイベントを行う際には当然敵のキャラクターも場面にあったものを作らないといけないですよね。
そこで、こういう敵がほしいというのをデザイナーさんにお願いすることが、発注となります。

発注の要件

個人的に発注を行う際に必ず伝えているのが、以下の二つになります。
・モチーフは何か
・どういう形をしていてほしいか

この二つの中身についてちょっと解説していきます。
まず「モチーフは何か」というところですが、当然デザイナーさんにお願いするときには前述したとおり新しいマップやイベントの時にすることが多くなります。その時にそのマップやイベントのイメージを伝えます。
イベントが一番わかりやすいと思うのですが、例えば4月の「花見イベント」や8月だと「海イベント」など大枠のイメージを伝えます。

次に「どういう形にしてほしいか」というところですが、大雑把に言うと人型であるかそれとも動物の何かをモチーフにするのか、はたまた機械的な何かにするのかというのを指定します。例えばですが、4月の花見イベントの時の敵キャラを酔っぱらった人にしてほしいといったように書くための大まかな指針を立ててデザイナーさんにお願いします。

おわりに

今回はデザイナーさんへの発注について書き綴って見ましたが、いかがだったでしょうか？
今回の記事では最低限ここは抑えておくべきというところを書いていきました。
人によってはもっと細かく指定する場合もあります。ただ、自分の中では「餅は餅屋」という考えがあり、基本的には細かく指定しないでそのデザイナーの想像力に任せたいかなと考えています。(もちろん相手もプロであるという前提の上でですが…)
この記事を読んで、発注することがある人がいたら上記の最低の要件を抑えつつ自分なりにどこまで相手にお願いするかということを考えて発注をすればいいと思います。
今後こういう機会がある人の役に立てば幸いです。

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

gitを利用して開発する際に、branch名を入力するのが煩わしいというのが悩みでした。
何か良い方法は無いかと調べた結果、簡単に補完出来るようになることがわかりました。
また、合わせてプロンプト上にgitの情報を表示できるようになったので、そちらも紹介したいと思います。

参考にした記事:
MacのターミナルでGitのブランチ名を表示する
MacのGitで補完を効かせたりブランチ名を表示する設定

環境

CentOS release 6.5 (Final)

git-completion.bashの利用

git-completion.bashは、gitコマンドの補完スクリプトです。
こちらを利用することで、tab補完を利用することが出来るようになります。
gitのインストール時に既に準備されているので、そのまま利用することが出来ます。

$ find / -name "git-completion"
/usr/share/doc/git-1.7.1/contrib/completion/git-completion.bash

環境やgitの導入方法によって、パスは異なるようです。(自分はyumで導入しました)
また、個別に直接入手することも可能です。

git/contrib/completion

git-prompt.shの利用

git-prompt.shを利用することで、プロンプトでgitの情報を表示出来るようになります。
こちらも同様に、インストール時に準備されているものか、直接入手したものを利用します。

git/contrib/completion

利用方法はgit-prompt.shに記載されているので、今回は一部を紹介したいと思います。

$ find / -name "git-prompt"
/usr/local/git/contrib/completion/git-prompt.sh

bashrcへの記述

git-completion,git-promptを読み込むことで、補完やプロンプトへの情報表示を実現します。
それぞれを読み込んだ後に、__git_ps1を環境変数に加えれば、情報の表示が可能です。

今回は、色の変更も合わせて行いました。
また、__git_ps1には様々なオプションがあるので、用途に合わせてカスタマイズすることも可能です。こちらもgit-prompt.sh内に説明があります。

~/.bashrc

# git-completion,git-promptの読込
source /usr/share/doc/git-1.7.1/contrib/completion/git-completion.bash
source /usr/local/git/contrib/completion/git-prompt.sh

# __git_ps1のオプション指定

## unstaged fileがある時は*, staged fileがあるときは+を表示
GIT_PS1_SHOWDIRTYSTATE = 1
## stash fileがあるときは、$を表示
GIT_PS1_SHOWSTASHSTATE = 1
## untracked fileがある時は、%を表示
GIT_PS1_SHOWUNTRACKEDFILES = 1

# 環境変数PS1の変更
export PS1='\[\033[1;32m\]\u\[\033[00m\]:\[\033[1;34m\]\w\[\033[1;31m\]$(__git_ps1)\[\033[00m\] \$ '

実際の画面は以下のようになります。
デフォルトのまま使っていたので、だいぶわかりやすくなりました。
また、gitコマンドやbranch名もtab補完出来るようになっています。

おわりに

tab補完のおかげで、branch名の入力ミス等が減りだいぶ捗るようになりました。
色々調べていると、まだまだ作業に役立ちそうなカスタマイズ等を見かけるので、暇をみて試してみたいと思います。

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

Slackを使っていてただチャットツールとして使っているだけでは気づきにくい、でも知っていると便利な使い方を3つご紹介します。

Slackって何？

“よくぞ聞いてくれました！Slack とは一連の業務の拠点となるデジタルワークスペースです。人々と組織、そしてツールをつなぐことで、作業効率を改善し、組織を活性化します。”※

※Slackガイドより引用

ビジネス向けのチャットツールという認識の方が多いのではないかと思います。
使っていて楽しいこともあってビジネスに限らずコミュニケーションツールとしても有用です。
今回はSlackを使っていてただチャットツールとして使っているだけでは気づきにくい、でも知っていると便利な使い方を3つご紹介します。

自分と会話しよう！？

ダイレクトメッセージを打つところに自分の名前があるのは皆さんお気づきでしょうか？
そうです！なんとSlackでは自分と会話が出来るんです！
自分と会話出来たからなんやねん！って思った方、甘く見てはいけません！
To Doリストを作成できたり、リマインド設定することで簡易タスク管理も出来てしまいます！
工夫次第では他にも活用できるかもしれませんね。

Threadを活用しよう！

Threadとは話題ごとに発言を別途まとめることが出来る機能です。
チャットツールにありがちな発言が多くて前の話が流れてしまって反応しづらいなどといった状況を防ぐことができます。

実際どのようにして使うのか見ていきましょう。

Step1

使い方は簡単、発言のリアクションボタンの横の「Start a thread」を選択。

Step2

これだけでThreadが作成できました。
あとは「Reply…」にメッセージを打つだけ！

Step3

今回は一つ目に紹介した自分にダイレクトメッセージを送る機能と併用してタスクの詳細チェック表を作ってみました。

通知はどこに来るの？

ちなみに通知はAll Threadsにきます。
通知が来ると「All Threads」が「New Threads」に変わります。

大勢の人が参加しているチャンネルでもトピックごとに会話をすることが出来るのでまだ使ったことがない人はぜひ活用してみてください。

チャンネルを使い分けよう！

パブリックチャンネルであればJOINしなくても他のチャンネルを見ることができる。
これはSlackの大きな特徴の一つとも言えるでしょう。
すでにご存知の方も多いと思います。
既存チャンネルに入らなくても先に会話を見れることで入る前に自分もそのチャンネルに参加するかどうか考えることが出来ます。お試しに近いイメージですかね。（決して覗き見しているわけではありませんよ！）
この機能はコミュニケーションツールとしては非常にありがたく、またビジネスの観点からは同じ会社の仲間の仕事の状況の把握や、ノウハウの共有などに役立ちます。
どうしても見られたくない、社内の中でも一部の人間が知るべき情報などもあると思います。そんなときはプライベートチャンネル。JOINしていない人は見ることは出来ない設定もきちんと用意されています。
上手く情報を共有して、皆で活用していきたいですね。

まとめ

今回は
・自分にダイレクトメッセージを送る機能の活用
・Thread機能について
・パブリックチャンネルとプライベートチャンネルを使い分ける

以上3点をご紹介しました。Slackを使い始めて数カ月と初心者であるため、基本的な内容になりましたがSlackは中々便利なツールだと感じています。まだまだ他にもbotやスラッシュコマンド、外部サービスとの連携など多くの機能があるようです。その辺り詳しいことはまた別の機会に書きたいと思います。
それでは皆さん良いSlackライフを！

※本記事の内容は個人の見解によるものを含みます。

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

はじめに

最近都会独特の暑さにやられつつあるBe82Mです。
九州で生まれ育ち上京して今年初めての夏を過ごしていますが、都内は排熱やコンクリート等でこもったような暑さ。想像を超える辛さで会社でも家でもずっとクーラーがついた部屋で過ごしていますが、それでもけだるい。なんか頭痛い。いろいろ調べていたらクーラー病なるものを見つけたので、症状や原因、対策についてまとめてみようと思います。
　

症状と原因

人によってさまざまですが、頭痛やだるさ、肩こり、不眠症、食欲不振などが主な症状。これよりも症状がひどくなっていくと発熱、吐き気までしてくる人もいるようです。これは、自立神経の乱れが主たる原因だそうで、クーラーの温度を涼しく設定しすぎてしまうと体が冬と勘違いして寒さに対応しようとし、外に出ると暑いので今度は暑さに対応しようとします。これを繰り返すと自律神経が混乱してしまい、このような症状が出てきてしまうようです。
夏になるとなぜかこれらの症状が出てくる、という人はクーラー病の可能性が高いです。
　

対策

これらの症状を改善する方法をいくつか調べてみました。

外気と室内の温度差を5度以内に抑える

体感的に涼しさを感じるまで設定温度を下げてしまいがちですが、一番の原因はこれ。
温度差が激しすぎると先述したように自律神経を混乱させてしまう要因になります。

でも暑いから強くしてしまう…

クーラーの設定温度を下げず、他の方法をとりましょう。
※ どうしても暑い場合は熱中症の危険性も出てきてしまうため少しずつ温度を下げましょう。

• 首元を冷やす
• 扇風機を利用する
  　寒いけど公共の場はどうにもできない…温度だけでなく、単に体を冷やさないようにするだけでも対策になるようです。
• ブランケットや軽い羽織りものなどで体を冷やさないようにする
• 温かいものを口にして体の内部から温める

外で汗をかいた後にクーラーの効きすぎた部屋に入ってしまうと夏風邪をひいてしまう原因にもなるので気をつけましょう。
　

食生活を改める

主に夏野菜といわれるものは体温を下げる効果があるため暑さを凌ぎやすくなるため、夏野菜を摂取するといいそうです。逆に、冬野菜は体温を上げる効果があるものが多いため、あまりよくないようです。
夏野菜：きゅうりなどのウリ科、トマトやピーマン、ナスなど
冬野菜：大根や白菜、ほうれん草など
また、夏の暑い日にキンキンに冷えた飲み物はとてもおいしいですが、体を急激に冷やすのもあまりよくないので、せめて寝る前は控えるようにしましょう。
　

最後に

夏の気だるさや頭痛は暑さが原因とばかり思っていましたが、暑さゆえの行動が原因だったようです。
今後は少しずつ生活を見直して夏を乗り切りたいと思います。

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

はじめに

nocoです。夏らしからぬ涼しい気候が続いたかと思いきや最近また暑くなってきましたね。

前回に続き立ち絵を魅力的に描くためのポイントを共有したいと思います。
今回はキャラクターの体型による個性についてお話しします。

体型による個性とその特徴

一つの世界観を作り上げる中で、同じ年齢や体型のキャラクターばかりがいるわけではないと思います。
体型の異なる4人の男性のシルエットを並べてみます。

衣服を着用していないただの素体ですが、シルエットだけでもそれぞれの年齢がおおよそ伝わるのではないでしょうか。

シルエットを外しました。

子供は大人に対し線が細く体に対して頭が大きく、
太った人はお腹が突き出て少しだらしない立ち方に、
老人は腰が曲がり体のバランスを杖で支えたり…
年齢、体型によってさまざまな特徴があります。
日頃からプロポーションの比率を観察してみましょう。

背格好や肉の付き方に伴って立つ時の重心も異なってきます。
その点も意識して立ち絵に取り込むことでキャラクターの個性が強まります。

キャラクターデザインはシルエットだけで誰か判別できると良いと言われていますね。
髪型や服装はもちろんですが、体型やその特徴を意識して描き分けることでシルエットも自然と差別化されていきます。

体型の異なるキャラクターが並ぶことでお互いの個性を引き立て、そのコントラストによってそれぞれをより魅力的に見せてくれます。
ヒーローがいるからヒロインはより美しく、ヒロインがいるからヒーローはより格好良くなるものです。
イラストそのものの魅力も大切ですが、キャラクター同士のバランスも考えてデザインできると尚良いでしょう。

終わりに

趣味でイラストを描いているとどうしても自分の得意なタイプのキャラクターばかり描いてしまうのですが、業務で老若男女を描く中でそれぞれの個性の付け方について考えさせられました。
体型の描き分けだけでもキャラクターの職業や人柄を表現することができます。
前回お話したポーズや表情による表現とも合わせて、さらに魅力的なキャラクターを作っていきましょう。

立ち絵の描き方については今回でおしまいになります。
次回からまた別のテーマでイラスト制作に関する記事を書いていきたいと思います。

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

第3回「第3回！Lionがゲームプランナーになるきっかけを与えたゲームとは！？」を話します。 興味があれば、見ていってね！

みなさんお久しぶりです！Lionです。
前回の記事いかがだったでしょうか？
和製と海外製のゲームって何が違うのだろう？が少しでも伝わったのであれば、こちらとしても嬉しいです。

さて、本日は「第3回！Lionがゲームプランナーになるきっかけを与えたゲームとは！？」について話させていただきます。
今回は、自分語り的な内容となりますがお付き合いくださいませ(੭ु´･ω･`)੭ु⁾⁾

「自分の人生を変えたゲーム」

私の人生を大きく変えたゲームのタイトルは「ゼルダの伝説 時のオカリナ」です。
今じゃアクションRPGの金字塔と言われるほど人気の作品です。
※『ゼルダの伝説 時のオカリナ』は、1998年11月21日に任天堂より発売されたNINTENDO64用アクションアドベンチャーゲーム
「ゼルダの伝説 時のオカリナの公式ページ」
※Wii Uのバーチャルコンソールではありますが、公式ゲームPVがありましたので載せておきます。
「Wii U ゼルダの伝説 時のオカリナ」

少しゲームの概要を話しますと…
ゼルダの伝説シリーズの第5作目であり、今までの2D作品からシリーズ初の3D作品となったことが最大の特徴です。
3Dになったことにより、奥行きのある立体的な空間内をよりリアルな視点位置で見渡すことができるようになりました。もちろん、バトルや謎解きにも革新的な変化がもたらされました。

・3Dゲームに付きものだったカメラワークや操作性の問題点を軽減する「Z注目システム」
・Aボタンアクションでの特殊アクションの自動化

それ以外でも、カットインムービーも多数盛り込まれ、物語の臨場感を大幅に高めています。
シナリオ面でも、少年リンクと青年リンクに区分したことで、色々なリンクを見ることもでき、
猪の怪物だけだった魔王ガノンに「ガノンドロフ」という本名と人間の姿が与えられ、以後のゼルダ作品の要素・設定に引き継がれシリーズに与えた影響は大きかった模様。

完成度の高さと革新的なゲーム性は世界中から高く評価され、第3回CESA大賞や、第2回文化庁メディア芸術祭 デジタルアート部門 大賞など、日米欧で数多くの賞を受賞した。

いわゆる神ゲーである( ˘•ω•˘ )
参考資料：Wikipedia

「人生を変えるほどに面白かった理由とは？」

当時、このゲームを始めてプレイした時が、確か小学三年生くらいだったかなぁと思います。
あまりに面白すぎるor感動してしまい、父親に段ボールで剣や盾を作ってもらったほどです（笑

今でもニコニコ動画などの実況プレイ動画を見たり、友人と寝ずに全クリアできるかなど
徹夜で遊ぶほどです。

では、私を含めた世界各地のユーザーを魅了した「時のオカリナのパワーとは一体何か！？」を要素ごとに書いていきます。

「過去、現在、未来を行き来する圧巻のストーリー！」

ハイラルのコキリの森に住む少年リンクは、いたって普通の子供でした。
ただ、コキリの森に住む住人として、必要なパートナーである妖精を自分だけ持っておらず、仲間に馬鹿にされている日々。
そんなある日のこと、リンクのもとに妖精ナビィが訪れ、コキリ族の守護神である「デクの樹サマ」が危機に落ちていることを知らせにやってきます。
勇敢な少年リンクは、デクの樹サマの体内に入り、苦しませている原因の魔物を退治しました。
しかし、蝕まれたデクの樹サマの命までは戻らず、命尽き果てていくデクの樹サマから最後に森の精霊石を授けられ、ハイラルで「神に選ばれし姫」に出会うように言われます。

ここから、少年リンクの大冒険がスタートします。
「神に選ばれた姫」に出会いなさい。
子供のころこれにすごくワクワクとドキドキを隠せませんでした。

その後、ゼルダ姫に出会ったリンクは、彼女から魔盗賊ガノンドロフの野望と精霊石の秘密を聞かされます。
ガノンドロフは聖地に眠る「トライフォース」を得るため、その地への扉を開くために必要な「精霊石」を探していると…。
リンクはガノンドロフの野望を阻止するため、彼より先に精霊石を集めて聖地への扉を開こうとした。
そして、扉を開けることに成功した。しかし、扉の鍵である「マスターソード」を引き抜いた途端に、リンクの身体が封印されてしまうとう事態に！？
封印の末に大人に成長したリンクは封印が解かれ7年もの歳月を得て目を覚まします。
しかし、ハイラルは既に「力のトライフォース」を得たガノンドロフに支配されていた…
ガノンドロフを倒すためには「伝説の賢者」の力が必要であると聞かされたリンクは、賢者たちの協力を得るため、マスターソードを手にハイラルを救う勇者になり立ち向かうのであった！

これが大まかなストーリーとなります。
このストーリーは、この先のゼルダの伝説シリーズに多大な影響を及ぼしたと言っても過言ではありません。
少年時代、青年時代、とリンクのハイラル世界に対する視点も変わってくるのも面白さの1つです。
また、自分が子供の時にプレイしたのもあってか、少年リンクから青年リンクに変わって世界を救うという部分に「自分も大人になったら世界を救うんだ！」と心から思っていました（笑）
当時、自分と同じことを思った方も少なくはないんじゃないでしょうか？

「3Dだからこそできるゲームシステム！」

ゼルダシリーズおなじみの謎解きとアクションというゲームシステムは色あせない状態で、完全に3D用として制作されました。
「草や岩を持ち上げて任意の方向に投げる」、「ヒビの入った壁や石像を爆弾やハンマーで壊す」など過去作同様のアクションを3Dでもできるように開発！
また、このゲームにおいて一番大事なシステムである「Z注目システム」があります。

プレイヤーは対象となる物体を任意にロックオンすることができ、対象物に向かって移動したり、パチンコや弓矢などを確実に当てることを可能としたシステムです。
このシステムのおかげで、戦闘もしやすくなり、対象が見えなくならないようにカメラワークもセミオートで補正してくれるため、キャラクターの位置の把握や敵との間合いを取ることが分かり易い&容易となるのです。
このシステムによって、3Dアクションの難点とされていたカメラワークと操作性の問題が大きく改善され、以後多くの3Dアクションゲームに類似したシステムが搭載されることとなりました。

戦闘が苦手な人でも気軽に楽しめます。
自分も小学三年生でしたが、とても戦いやすかったのを覚えています。
また、フィールドを自由自在に走り回り、剣や弓矢で敵をバッサバッサとなぎ倒していくのもとても面白かったです。
当時、ここまで爽快感があるゲームはそうそうなかったと思います。

「全てのダンジョンの謎解きやギミックが面白い！」

ゼルダの伝説シリーズおなじみの謎解きやギミックですが、過去最高だとユーザーからの声も高いと思います。
ダンジョンで手に入れたアイテムや武器を使って謎を解き、そしてボスを倒すという過去作と同じですが、3Dになったことで、天井、床、壁と360度全体でギミックを仕込むことができます。
特に、皆様お馴染みである「水の神殿」の難易度は今になっても語り継がれていると思います。
神殿内の水位を変動させて、移動したり物を動かしたりするのが本当に難しかったです。
この神殿で手に入る「ロングフックショット」は、壁にフックをかけて、そこまで飛んで行ったり、遠くのアイテムを引き寄せたりできる神アイテムでした。
また武器にもできるというところも魅力の1つです。

ちなみに私は難しすぎて友人にクリア法を教えてもらった経験があります（笑）
今ではきちんとクリアできます。しかし、大人の方でも初見でプレイさせると確実に詰まると思われます。
それほどに難しいですが、プレイ応えがある最高のダンジョンでもあります。

「ここまで話してみて…」

どうでしょうか？少しでも「ゼルダの伝説 時のオカリナ」の魅力は伝わったでしょうか？
まだまだ、語ろうと思えば語れますが、際限がないのでこれくらいにしておきます。

そして、私がゲームプランナーになると決めた理由は、「自分自身で、ゼルダの伝説 時のオカリナのような面白い世界を作ってみたい！そして、自分が作ったゲームで自分が味わったこの感動を世界中の人たちに伝えたい！」と子供の頃に思ったからです。
実際、大人になってもこの思いは色褪せることはありませんでした。
現在はプランナーとして働いていますが、もっと上を目指して精進していく所存です！

今回の記事、いかがだったでしょうか？
「ゼルダの伝説 時のオカリナ」の魅力や筆者ってこんな人なんだなぁというのが少しでも伝わってくれたら嬉しいです。

次回は来月開催されるTGS（東京ゲームショー）についてお話します。
「第4回　TGSで日本ゲーム大賞に選ばれた作品たち！」についてお話します(੭ु´･ω･`)੭ु⁾⁾
※筆者は極度のファンです
では、みなさん！夏ももう終わりですが熱中症にはお気を付けください( ˘ω˘ )

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

　railsで開発しているとN+1 Queryというエラーに遭遇しました。このN+1 Queryについて調べてみると、別名N+1問題と呼ばれており、サービスのパフォーマンスを落とす問題の一つであることがわかりました。今回は、この問題を解決する為に調べたN+1問題の原因と解決方法について記事にしました。

N+1問題とは

　N+1問題を簡単に説明すると、クエリがデータ数よりも多くなります。データ数よりも多くのクエリが発行されることで、サービスのパフォーマンスを低下させます。少量のデータの場合は、問題を感じることは少ないと思いますが、実際にサービス運用では膨大なデータ量を扱うことがほとんどなので放っておくことはできません。

問題発生例

　実際に、どのような場合にこの問題が発生するのか例題を使って説明します。
　以下のようなハードウェアモデルとソフトウェアモデルが存在するとします。ハードウェア1つに対して複数のソフトウェアが結びつく関係です。

class Hardware < ActiveRecode::Base
  has_many :softwares
end

class Software < ActiveRecode::Base
  belongs_to :hardware
end

　この2つのモデルを使用したコードが以下にありますが、このコードがN+1問題を発生させてしまいます。このコードの処理は次のことを行っています。
1. ジャンルがアクションのソフトウェアのデータを取得
2. 取得したソフトウェアのデータ1つ1つに対してハードウェアのデータを取得

softwares = Software.where(genre: "action")
softwares.each do |software|
  software.hardware
end

1.の処理では、ジャンルがアクションのソフトウェアをまとめて取得している為、クエリの数は1つになります。
2.の処理では、取得したソフトウェアの数だけバードウェアを1つずつ取得しているので、クエリの数は取得したソフトウェアの数になります。
つまりこの2つの処理では、取得したソフトウェアの数をNと置き換えると、N+1のクエリを発行していることになります。

解決方法

　N+1問題の原因は、データ一覧取得後、取得していないデータを参照していることです。（上の例だと、ソフトウェアを取得している時にハードウェアを取得せずに、後から取得している。）この原因を解消する為に、データ一覧取得時にincludesで関連するデータをまとめて取得する方法があります。下のコードは、先ほどの例題にincludesを使用して改善したものです。

softwares = Software.where(genre: "action").includes(:hardware)

　このようにincludesを使用することで後からデータを参照した場合でもクエリが発生することはありません。includesを使用した場合のクエリ数は、ジャンルがアクションのソフトウェア取得の1回と取得したソフトウェアに結び付くハードウェアの取得の1回の計2回となります。

まとめ

　RailsエラーでN+1という文字を発見したら、クエリが余分に発行されていないか確認してincludesで対応しましょう。