unityroomに作品投稿する時の罠まとめ
unityroomに投稿するときに当たり
やらかしがちなミスをまとめているページです。
uinty1weekのベテラン勢は割と経験から回避していますが、
駆け出しの作者は割とミスしてしまっている印象です。
直近のunity1week投稿作品を見直して、もし引っ掛かってるものがあったら、次のunity1weekでは解消していくことで、よりユーザフレンドリーな作品になっていくでしょう。
■サウンド編
■音量調整をつける
BGM、SEに対してそれぞれ設定で音量調整をできるようにする。
なんかもうunity1weekの半常識と化している案件。
これがないとサウンドの項目を下げる過激派人もいるくらい。
自前で実装してもいいですが、
おなじみnaichi神によるアセットも公開されています。
自分に合った方法で実装しましょう。
■BGMはちゃんとループ確認する
たまーにBGMのループ設定が行われていないケースがあります。
BGMに当たるサウンドはちゃんとAudio SourceのLoopにチェックが入っているか確認しましょう。
尚、（結構なレアケースだとは思いますが）意図的にループさせないケースもなくはないです。ループしないことに意図があるならば、もちろんループさせる必要はありません（小泉構文）
■WebGL上でのオーディオ仕様を確認する
unityのwebGLは結構内部で強引にサウンドを鳴らしているらしく、
エディター上のサウンド再生機構では結構仕様が違います。
webGLでは使えない機能なども結構多いので事前にwebGL上のサウンド再生の仕様は確認した方が良いでしょう。
公式が仕様と仕様をミスタイポしているのだが
簡単にいえば、高度なエフェクトはだいたい使えません。
エフェクトで使えるのはピッチ変更やボリューム変更くらいです。
その他細かいところではGetSpectrumData()も使えません。
■webGL上でのノイズ確認をする
webGLの再生仕様のせいか、エディタ上とは違う音になっているケースがあります。特に短いSE。「ﾌﾟﾁｯ」というノイズが載っていることもあります。一度webGL上で一通り確認をした方が良いでしょう。（ていうかサウンドだけじゃなくwebGL上の動作確認は全面的にしたほうがいいですが）
ﾌﾟﾁｯとなるSEに関しては、圧縮設定を変えたり元のファイルをoggにすると直ることがある、などの情報がありますが確証はない感じです。（情報があったら追記予定）
■webGL上では最初は音が鳴らない
これはブラウザ的な仕様の問題で、「ページを開いただけで音が鳴る」事が望ましくないためです。一度画面をクリックするまでは音が鳴りません。
このため、いきなりタイトルが表示、BGMが鳴る……みたいな構成をしている場合、うまく作者が意図した演出にならないケースが存在します。
最初にユーザにタップさせる画面をワンクッション設けることで、この問題を解決する事が出来ます。やっている作品もそこそこあります。
■画面サイズ対応編
■ブラウザの拡縮に対応する
ブラウザには拡縮の機能があります。
ChromeだとCtrl+マウスホイールなどで行えますね。
この機能を使うと、unityのサイズもそれに合わせて変わります。
可変サイズ対応を行っていないとUIが崩れて表示されます。 特にuGUIのデフォルトの設定はこの可変サイズに対応しない設定のために、
実際のu1wの作品でもUIが崩れてしまう作品はかなり多いです。
キモはCanvasオブジェクトにあるCanvas Scalerの設定です。
ここのUI Scale Modeの設定をScale With Screen Sizeに変更する事で
ブラウザの拡縮にある程度対応する事が出来ます。
もちろん設定するだけでなく、エディタ上でウインドウサイズの設定を変えてみて、崩れないことを確認するのが望ましいです。
■フルスクリーンの動作を確認する
unityroomにはフルスクリーンで遊べる設定が存在します。
これも前項と同じように、画面サイズを変えることになるため、
可変サイズ対応を行っていない場合、UIが崩れることになります。
フルスクリーンで厄介なのは、環境によってアス比（縦横比）が16:9とは限らない事です。これは前項のスケール設定だけでは対応できません。
これに対応するためには、UIの配置を画面端からのanchorで設定するなど、ある程度工夫する必要があります。詳しいことはこの記事では省略します。anchor,uGUIあたりで検索すれば解説記事が出ると思うので。
ただ、慣れてないとそこそこ手間取る対応です。対応が難しいと感じたら、思い切ってフルスクリーンの項目を外してしまうのも手です。
■動作速度編
■非アクティブ時にも動作するようにする
デフォルト設定では、非アクティブ状態になると、
動作が止まるようになっています。
これは一部のゲームのバランスに影響を及ぼすことがあります。
例えば、時間制限以内に２つの絵の違いを探す間違い探しゲームがあったとしましょう。非アクティブ時に動作が止まる場合、時間のカウントも止まるため、全く時間を気にせず探すことが出来てしまいます。 こうなってしまうとゲームバランスは崩壊してしまいます。
対処の仕方は簡単で、Build Settings＞Player Settings＞Resolution and Presentation＞Run In BackGroundのチェックをつけることです。これにチェックをつけることで、非アクティブ時にも動作するようになります。基本的にはつけておいたほうがいいでしょう。
■可変フレーム対応する
これはまあよく言われていることだし、webGLに限定されている事ではありませんが。
一般的なモニターはリフレッシュレートが60Hz前後であり、UnityのUpdateもそれに準じた回数呼ばれます。しかし、環境によっては144Hzなどの高フレームレートのモニターも存在します。ここで可変フレーム対応を行っていない場合、2.4倍速でゲームが動作します。ACTやSTGならまず無理ゲーと化すでしょう。
Time.deltaTimeなどを用いる事を忘れないようにしましょう。エディタ上で疑似的にフレームレートを落とす方法があったはずなので追記予定。
■インプット編
■そもそもその入力方法は適切ですか？
そもそも論になりますが、その操作形態が一番遊びやすい方法かはよく吟味したほうがいいです。
Unityのデフォルトの入力方式に、WASDで移動、左Shiftでダッシュ、スペースキーでジャンプ、マウスでカメラ制御のFPS式操作形態がありますが、これマイクラ他FPS系のゲームに慣れている人以外はくっそ難しいです。実際にFPS系のゲームならともかく、2Dのアクションならこの操作方法である必然性はないです。ていうかWでジャンプさせてくれ。ダッシュも歩きと使い分ける必要がないゲームデザインならデフォルトでダッシュ速度でいいわけですし。
まあジャンルによりけりなので確実にこれが正解！ というわけではないですけど、キーボードとマウスどちらも使うタイプのゲームは確実に脱落者が出て、操作性に項目も芳しくなくなるのがunity1weekの傾向とは言えます。
■ブラウザ内で機能を持つキーは避けよう
しかしだからといって自分で操作体系を考える時、どのキーでも使っていいわけではありません。例えばEscキーは、フルスクリーン状態の解除の機能を持ちます。 その他、マウスの右クリックや、左下のWindows、Fn、Alt、上段のファンクションキーも避けた方が良いでしょう。使っても問題ないのは英字キー、Shift、スペース、アローキーあたりです。
■キーボードの同時押しには限界がある
RealForceなど、同時押しに強いキーボードを使っていると却って引っ掛かりやすい項目。キーボードがどれだけ同時押しに対応しているかは環境依存が大きいです。英字キーは３つ以上の同時押しが出来ないケースがあります。
アローキー、スペース、Shiftなどは独立して動作し、また、ゲーム系の定番であるのか、ZXCやWASDも比較的同時押しを受け入れるキーボードが多いです。やはり定番の配置が良いのでしょう。
■GetAxis() の呪い
GetAxis()はUnityの標準的なインプット命令であり、WASD操作体系とゲームパッド対応を同時に行える便利な代物です。
……ですが、このキーボード側の操作にクセがあり、WASDがスティックに相当するためか、1f入力しただけでも滑ったような移動になってしまいます。2Dの精密系プラットフォーマーだとこれはかなり致命的です。
※たしか対処法があったはずだけど覚えてないので調べた後追記
■ランキング編
重要：この一連の項目は、自分のゲームにランキングを導入して、ゲーマー陣の中でランキングで盛り上がって欲しい！ と思う人向けの内容となります。そのようなタイプのゲームではない場合、これらの項目は無視してかまいません。
■ランキングを導入する？
これは必須事項ではないです。
ただ、unity1weekにおいて、スコアや、タイムなど競う要素があるゲームはランキングを実装した方が確実に盛り上がります。
何故かunity1weekのランキングを荒らすことに執念を燃やす一派なんかも界隈に居ます。なんでだろうなあ。
ランキング機能を自前で実装するのは、まあそこそこ手間がかかります。
プログラミング初心者ならやはりnaichi先生のランキングアセットを導入するのが楽だと思います。
……とまあ、ランキング機能の導入自体は存分にオススメしたいのですが、
導入する場合は（そして厳密には、ランカーに好かれるためには）気を付けなければならない事項が幾分増えます。それは次の項目で。
■ランキングの設定をする（そして確認する）
ないち神製ランキングはいくつかの設定項目があります。
大きくは２つで、時間／スコア系設定と、そして昇順、降順です。
前者はともかく、後者の設定を間違えるケースはそこそこみます。
逆にしてしまうとランキングは破綻してしまいます。
ちゃんと２つ以上のユーザで確認した方が良いでしょう。
エディタ上の確認とwebGLの確認で丁度２人ぶんになりますしね。
■クイックリスタートを入れよう！！
ランカーズという生き物は、ランキングがあるゲームに寄り付きますが、クイックリトライが無いと気づくと去ってしまいます。ゲーム中にＲキーでクイックリトライできるようにするのが慣例です。
クリックリトライできるようにするだけでなく、ゲームサイクルもできるだけ高速回転できるほうが望ましいです。ゲーム終わるたびに10秒待たされるゲームはランカーはやらねえ！！
■でも名前入力中にリトライするな！！
クイックリトライを入れた時にやらかす案件。
名前入力中にRを押したせいでリトライされてしまう。
自分の名前にRが入ってない人はうっかりやらかしがちなようです。
ゲームが終わったらリトライは効かないようにしましょう
（クイックリトライはゲーム中のみ有効にしましょう。）
なお私はMetaForMerなのでひっかかる方の作者です。
■そのゲーム、競技として成立する？
これはゲームによりけりなので「こうすればよい」というのはないですが、
結構「永久が成立する」などでランキングが破綻しているゲームは見ます。
・耐久系で難易度最高状態でも耐えてしまう
・制限時間が過ぎたら終わりだけど時間延長系アイテムがあるせいで時間が無くならない
・ゲームを終わらせず無限にスコアを稼ぐ手段がある
このあたりが代表的なパターンです。
ゲームが上手くない作者ほどやらかしがちなようです。
「こうすれば回避できる」という確定の方法は存在しませんが、不安な場合ランカーズにテストプレイをお願いする、が一番いい手段かもしれません。破綻している場合は指摘してくれるでしょう。
■その他
■Tweet機能があると拡散力が上がる
これは罠というよりは「やったほうがお得」な話です。
Tweet機能を実装し、スコアなどをツイートできるようにしておくと、SNS上での拡散力が上がり、そこから更にプレイする人が増えたりします。
３たび登場のないち先生のサンプルです。
使うのも簡単なのでぜひ導入してみましょう。
……なお、細かくも重要な話ですが、Twitterのロゴは基本的に加工してはいけません。（Twitterの規約） デザイン拘る人ほど要注意。
■数字を表示するテキストは等幅フォントを使おう
必須ではないですが、例えばゲーム内で時間が表示されているとき、
等幅フォントでないとガクガクとした表示になります。
等幅フォントを使った方が見栄えが良くなります。
■ネガティブな判定は小さく、ポジティブな判定は大きく
これはwebGLとか関係なく、ゲーム制作論の範疇ですが……
当たってはいけないオブジェクトの判定は見た目より小さく 、逆に
当てるべきや取るべきなオブジェクトは見た目より大きくしましょう。
それがユーザビリティというものです。
∧∧∧∧∧ ←こういうトゲが四角形の判定を持ってるとキレます。
■ゲームの目的を明示する
これ、作ってる側は当たり前すぎて、逆に説明しそこなったりするんですよね。マリオを作ってる人は、目的はゴールにたどり着く事 というのを当たり前のこととして認識するのですが、プレイヤーはそうとは認識せず、敵を全滅させるゲーム だと勘違いする可能性もあるわけです。ちゃんと説明しましょう。
これも自分だと気づきにくいので、誰かにテストプレイをお願いするなどするのが良い方法です。
■というかちゃんと実機上で最後まで動作確認する
あまりに当たり前すぎるのですが重要なのであえて最後に書く。
ちゃんとwebGLにアップしたら最初から最後まで通しで確認しましょう。
思いがけぬところにwebGL限定のエラーが生じたりします。
（これ作者、動作確認してないだろ……）みたいな作品を見つけたとたん、全ての評価は★２以下になります。いや、マジな話。
■おわり
以上、確認した方が良い項目一覧でした。
あくまでこれらは「やると減点を防げる項目」であり、
ゲームそのものを面白くするものではありません。
ゲームを面白くするのは、また別の手腕なのです。
それっぽく〆たところで終わり。
なんか新しいの思いついたら追記するかもしれません。