iOS版「聖剣伝説2」の操作性を考えてみる
ページ概要
懐かしいゲームを遊んでいるので、操作性について考えてみました。 覚書のようなものです。
対象となる物
操作性の概要
- 移動を左側のパッド
- 攻撃とダッシュボタンが右下
- ショートカット用ボタンが右上に3つ
- 画面左上にメニュー開閉用のボタン
- 画面下のキャラクターアイコンをタップでキャラクター切り替え
- 画面下のキャラクターアイコンを上にドラッグ&ドロップで個人メニューを開く
印象
- 移動の誤作動が多い
- 「斜め攻撃」がシステム上存在しない為、移動の誤操作で攻撃を当てるのが難しい
- チャージ攻撃をどうやるか気になっていたけど、移植前と同じ、攻撃ボタンの長押し
- 物理パッドを使うのが良い。バーチャル操作は非常に辛い……(´・ω・`)
- 武器の切り替えの手間が大きい
- メニューのリングの反応が鈍い
- メニューのリングのどこを選択しているか分かり辛い
移動の問題点と解決案の妄想
移動が「 移動用パッドの中心位置からどの角度をタッチしたか」で判断されており、従来の十字キーを操作する感覚には程遠い。聖剣伝説1の移動と同じように、タップした位置からの相対位置にするのが正しいと思われる。
中心位置が固定されている場合、移動用のタッチ位置を常に意識して正確に行わなければならず、アクションゲームで戦っている際は機敏な操作が出来ずにダメージを受けやすく、ダメージを与え辛い。 中心位置を固定化する場合、中心位置を明確にして、中心位置付近の移動の判定に遊び領域が必要だと思われる。遊び領域が多いと斜め移動の判定がシビアになりそうだが、誤操作を招くよりはずっといいはず
攻撃時に多少の向き補正を付けることで、移動のストレスを軽減できるかもしれない。
リングメニューの問題について
原作道理リングメニューが多層になっているが、次のリングへの操作が画面中央のフェイスアイコンの上下スライドが非常に分かり辛い リングメニューの1つを考えた場合、余白が多くあるのだがリングを回す操作感度が悪くタッチしたエフェクト等が出ず、うまく操作出来ているか分かり辛い。 リングの回転の速度が遅く、回転させるにしても選択しているアイテムが分かり辛い。
結論
聖剣伝説1のリメイクの操作性の良さがよくわかりました。 リングメニューはもう少し使い勝手が良くできそうな感じがあり、基本的な矩形のメニューよりも楽しく見えるので使ってみたい所
Legend of Grimrock をプレイ開始
プレイ開始したもの
どういう経緯で知ったか
Store で偶々見つけて面白そうだった為。Store で見ただけで買うのは久しぶり。 2015 年リリースなのにおススメの上位にいたし、定期的に売れているのだろうか?
どんなゲーム?
薄暗いダンジョンをサバイバルしながら進むゲーム。戦闘はリアルタイムのアクション。ローグ系と言えば分かり易いのだろうか、灯りとなる松明が時間によって燃え尽きてしまったり、キャラクターのお腹が減ったりする。
壁のスイッチを探すために結構画面を凝視しているので、いきなり攻撃されると本当にびっくりします(´・ω・`)
2012 年に発売されていたようで、2作目も Steam で販売されていた。…… Steam 版買えばよかったと思わなくもない。
やっと4Fに到達しました。
遊んでみて面白いか?
ダンジョンの中をうろうろして、ギミックを解き、壁のスイッチを探しながら攻撃される。アイテムを整理しながら英語のアイテムを首をかしげながら進んでいく。
いやぁ……超面白い(`・ω・´)
ダンジョンを進むのが好きな人にはお勧めできる。
タッチ操作がかなり快適でダンジョンを見渡せるのは気持ちい。移動のタッチミスで窮地に立たされたりして、結構スリリングな部分もある。参考にしよう。
戦闘は命中率が意外と低くて、ストレスがたまる印象。敵の攻撃時に合わせて攻撃すれば、命中率上がったりするのかな?よく分からない。
備考
- 全て英語のため、ヒントの内容が頭に入ってこなかったりアイテムを上手く認識できないときがあります。それでも楽しい。むしろ楽しい。
少し見ただけで人を魅了する「ドラゴンボール ファイターズ」の良さを考えてみた
動機について
今更ながら動画を初めて見て、非常に綺麗で魅了されたので
どういう所が良かった、気になったかをまとめてみました。
実際に見た動画
気になったポイント
キャラクター周り
- キャラクターたちのアウトラインの綺麗さ。細くきれいに入り過ぎてちょっと不安を感じる時もある。
- キャラクターへの動的な影の入り方の綺麗でイラストチック
- 対戦開始時の入りの演出がカッコいい。 立ちポーズで始まる格ゲーより、対戦開始時の入りの気持ち良さを感じる
- 演出時の漫画的なパース変更で漫画を読んでいる時の迫力感を感じる(前に表示される腕が異常に大きい)
- 超必殺系のキャラクターの表情表現が豊か
- 超必殺時のアップ用モデルも入っている感じがする どれだけモデルが入っているのだろうか
- フリーザの攻撃時のしっぽの太さが変わっている気がする。これもモデル変更?
- 瞬間移動時、キャラクターが一時的に2体になるっぽい。同時に何体出せるのだろう?
- 勝利演出等だと背景とキャラが馴染んでいない気もする。アニメと実写を混ぜたときの違和感に近い
攻撃、エフェクト周り
- 攻撃の軌跡の綺麗さ(漫画っぽさ) ギルティだと専用の軌跡モデルも用意してたと思う
- 汎用的なエフェクトのイラスト感、特に綺麗な方向性を持つ火花系
- 攻撃による相手へのライトの影響(多分攻撃ライトに切り替わるっぽい。色が混ざってない綺麗な感じ)
- 爆発の派手さ
- エリアル開始時などの移動の軌跡のドラゴンボールっぽさ
- 戦った影響がステージに残っていくのは雰囲気づくりに重要
- エフェクトの多くはキャラクターの後ろかな?
加速時、攻撃時の線などの特融の軌跡、超必、爆発系の画面を覆うものは前
ランク付けされている感じがする - 爆発系のエフェクト、ギルティで見た事ある気がする。違和感はない
- HPバーは結構表示順番が後ろっぽい、UIの順番変えてそう
- カメラワークかっこいいけど、見ていると酔ってもくる。でもかっこいい
最後に
ギルティギアを見ている時も良く思いますが、演出がカッコ良いし綺麗です。
さすがのアークシステムワークス様ですε= (´∞` )
「なるはや」の危険性と対策について
検討した理由
身の回りで「なるべく早く」「出来るだけ早く」「うーん、なるはやで!」といった言葉が良く聞こえるようになったため
「なるはや」は何故危険なのか
まず仕事は早く終わる事が良いという事。
人を雇っている間は人件費がかかる為、極端な話をすれば何事も早くできるに越した事はない。
では何が危険なのか、以下に列挙してみた。
- 仕事の優先順位が分からなくなる
- 仕事の期限が曖昧になる
- スケジュールが壊れる\(^o^)/
チームで業務を行っていくにはアジャイル開発であっても、スケジュールが必要となってくる。
「なるはや」と聞かされ続けたメンバーはスケジュールを軽視し、最終的には更新されなくなった謎スケジュールが残る。
正直そんなチームには誰も入りたくないし、仕事の効率は下がる一方である。
では何故「なるはや」と言ってしまうのか
何名かを観察した結果として、原因をまとめてみた。
- 仕事を出す人がスケジュールを把握していない、もしくは軽視している
- 仕事の優先順位が付けれず手に取った物を「なるはや」で処理しようとしている
- 仕事量があふれている、残業が続いている、など体力面での低下でスペックが下がっている
- 仕事の発端の人が「なるはや」を使っていた為、「なるはや」と言ってしまう
スケジュールが全てではないが、悪循環を起こしているのは間違いない。 1回回り始めてしまった悪循環を変えるのは容易ではなく、残業が続けば体力気力が減り、思考力が低下してしまう。
底なし沼へようこそ(´・ω・`)ノ
どうやって「なるはや」の悪循環から生き残るか
状況を正しくしようと思えば、誰かがリーダーシップをとり関係者全員を巻き込んで現状に対する認識を合わせ、変えようと声を大にして言うしかない。
注意する点は以下の通り。
- 事実や分析結果に基づいた認識を合わせ、感情論では無い事を伝える
- 口論をしない
- 相手の話を聞く
- 自分の意見を伝え、意見をすり合わせる
- 社外の人に相談する場合は、NDA に気を付ける
- 自分を大事にして、無理をしない
日々続いている慣習、状況を変えたいと言うのは並大抵の気持ちでは行えない。
実際に「誰か」が現れる事はなく、気づいた人自身がリーダーシップを取って行動するしかない。
誰も面倒な事はやりたくはない、疲れていれば猶更である。
最後に
何かを変えるには代償が必要になる。自分の時間、立場、心など失う物もある。
辛い物、面倒な物を見て見ぬふりをするのは悪い事だけど、普通の事
でも本当に変えたいと願うなら、自分を信じて行動する事が大事だと思います。
TDDの本を読んでみた
読んだ本
本の概要
- TDD についての説明
- 実際に pact を使っての説明
読んだ経緯
Unity でゲームを開発する上でデバッグにかかる工数が年々増加傾向にあり、工数を短縮したい状態になっていました。ゲームのテストコードを殆ど書いたことがなかったためTDD自体をよく知らないため、知識をつけるために読みました。
所感
TDD(テスト関係)は必要ない、私の所には適用できないって言う人は読んでみて欲しい。 「仕様のテスト」か「実装のテスト」か、何がプロジェクトに有効かを考える切欠になりました。 ページ数は少ないですが、少ないからこそ気軽に読めると思います。(事実私は気軽に買って読みました)
実際に自身が使うと考えてみて、部分的に導入するのは良さそうに感じました。明確な意図を持って作られるツールやライブラリの類なら工数の短縮は出来るかもしれない。ゲームのような曖昧な物にこそテストを作りたいが、作りなれていないとメンテナンスコストだけが膨れ上がってしまう。
「テスト」のテストをしても恐らく実感がわかないと思うので、次に作成するツールで部分的に試してみようかと思います。上手くいったら記事にします(^ω^)
C++ から Unity+C# に移行して変化した事 定数と変数
ページ概要
Unity で他の人のコードを見た際に、私自身のコードが変化している事に気づきました。 気づいた内容をまとめていきます。
書き始めると細々も気になる点が出てきたため、変数に関係する部分のみを取り上げています(^ω^;)
定数定義の変化
C++ 時代は以下の通りです。
// 定数定義 #define _DEBUG_ // enum を使った定義 enum DIR { DIR_LEFT = 0, DIR_RIGHT, DIR_DEFAULT = DIR_LEFT, };
C#だと以下のように変わりました。
// 文字列の定義 public classs SystemData { public const string SaveKey= "TitleName_01234"; } // enum 定義 public enum Dir { Left, Right, }
C++ では定数は全て大文字で定義していました。define の中に一杯処理を詰め込む人が多く、定数はマジックナンバーより安心できるが劇薬の可能性がありました。
そのため、定数が分かり易くないなんて信じられない、と考えていました。
C# の場合プロパティの get や set の中で色々する人がいますが、define を使った複雑なコードを書く人が減りました。 また、使う際に必ず Dir.Left のように enum の名前を書く為コードを読む際も定数に気づきやすいです。
定数の取り扱いが変化しただけで、人のコードが大幅に読みやすくなりました。
グローバル変数が消えた
チーム制作時に良く問題になったグローバル変数を使うことがほぼなくなりました。 似たような挙動を作る事は出来ますが大概は Hierarchy にオブジェクトが存在している為、「気が付いた時には中身が書き変わってる…?」といった問題が発生する確率も下がったと感じます。
メンバ変数が分かり易くなった
メンバ変数は public か SerializeField しておくことで、Unity の Inspector に表示されます。 ゲーム画面に頑張って表示させなくても inspector を見れば確認できるので、動作の確認がしやすくなりました。
[SerializeField] int m_Count;
見えるメンバ変数を大量に用意されると inspector が見づらくなりますが この場合はメンバ変数が大量になっている事が目に見えて分かる為、リファクタリングの指示を出しやすく聞き入れやすくなります。
プロパティは便利だけど要注意
変数のように取り扱え、get や set の中に色々な処理を入れる事が出来る。 get と set のアクセスレベルを書き換えれるのは便利。
アクセスレベルを気にしない場合は、 public メンバ変数と殆ど同じです。
特にプロジェクトの規模が大きい場合は不具合の原因となりやすいため、 本当にクラスの外部に公開するべきかどうかを考える必要があります。
参考にしたかった資料
- 公式ドキュメントより、名前付けのガイドライン