元駆け出しエンジニアが自称プロゲーマー時代に学んだこと

挨拶

こんにちは、株式会社FLINTERSでエンジニアをしている星です。

本投稿は、自分がゲームで成長する/勝つために用いていた考え方のフレームワークをまとめ、対戦ゲームとソフトウェアエンジニアリングの共通点を考えるものになっています。

エンジニア未経験だが興味がある方、対人ゲームに興味がある方などの考え方の参考になれば幸いです。

ちなみにこちらの記事は、梅雨にも負けないブログ祭りという企画の一環の記事です。詳細はリンクへ！

目次

• 目的意識の徹底
• • 目的に付随する要素を考える
  • 余分な要素を捨てる
  • 目的と目標を作成する
  • 目的を基準としてもつ
• 抽象化した反省
• • 反省は具体的すぎてはいけない
  • 抽象化
• これらを元に意識していたこと
• 共通点を考える
• 最後に

目的意識の徹底と抽象化した反省

早速ですが自分が対人ゲームをする際に主に意識していたものはこの2つです。そしてこの2つの考え方はソフトウェアエンジニアになった今も通用しています。

目的意識の徹底

目的に付随する要素を考える

今回は例としてランクシステムが導入されており、プレイヤーがランキング付されるようなゲームにおいて上位ランカーになることを目的とします。この目的の本質はとにかく対人戦に勝つことですが様々な要素が付随しています。

極論、一番簡単に勝つ方法はチートですがこれは基本的に継続性がないです。所謂そういうのではないんだよ...というやつですし、古来より対人ゲームでのチートは御法度なのでいずれBANされます。

上記のように極端なケースを突き合わせて考えると

• 継続して勝ちたい
• 自分の実力をステップアップしながら勝ちたい
• 強い相手に勝ちたい
• ゲーム自体を楽しみながら勝ちたい
• 気持ちよく勝ちたい
• etc...

など、粒度は違えど様々な〇〇して勝ちたいが潜在していたことがわかると思います。

余分な要素を捨てる

次に効率的にゲームに勝つために不必要な要素を削ぎ落としていきます。同じ人間同士、大小の差はあれど費やすことができるリソースには限界があるため、勝負の世界においては余分なものを削ることができた人間が勝つと考えるからです。

先ほどの要素のうち

• 強い相手に勝ちたい
• ゲーム自体を楽しみながら勝ちたい
• 気持ちよく勝ちたい

これらは不必要な要素になります。特に強い相手に勝ちたいという要素は一見必要に見えますし本質的な競技の原動力ですが感情が占める部分が大きいため、徹底した目的意識を持つためのフローの一環として目的からは排除します。個人的にこういったものは結果として受け取ってあげるのが良い感じです。

目的と目標を作成する

先ほどのステップの結果今残っている目的の要素として

• 継続して勝ちたい
• 自分の実力をステップアップしながら勝ちたい

がありますこれらが残った理由としては上位ランカーになるためには

• 一回だけの勝利ではなく継続的に勝ち勝率を保たなければランキングは上がらない
• 初めからゲームが上手い訳ではないので成長も必須

などが最低限必須と考えたためです。ですがこれらは目的のための目標であるため再度整理すると

• 上位ランカーになりたい
• • そのために継続的に勝利したい
  • さらにそのために継続的に成長したい

というような構図が生まれます。これでざっくりですが目的化が完了しました。

目的を基準としてもつ

作成した目的目標は今後ゲームをプレイするにおいて判断、選択を迫られた時の基準になります。

いわゆるキャラクター、アイテム、戦法/立ち回りなど、基本的にゲームは判断と選択の連続です。ゲーム開始前に適切な選択をしていなかったが故に自分の首絞めるなんてことはザラにあると思います。なのでそのような自体を回避するために都度目的と目標を思い出して判断します。

抽象化した反省

目的意識は整理されましたが成長するためには実践⇆反省の反復が大切です。ここでは適切な反省の仕方を考えます。

反省は具体的すぎてはいけない

具体的すぎる反省とはなんでしょうか、以下に説明します。

ゲームのリプレイを見て反省をする際にキャラクターのアクションに注目し、ここでこのスキルを回避できていたら勝っていたみたいなことはあると思います。ただこの反省の仕方は最悪です。所謂インシデントが発生した際に「資料流出しなかったらインシデントは起こらなかったのに」と某ロボットみたいなことを言っているようなものです。

RTSやMOBA、バトルロワイヤル、戦略FPSなどをイメージしてみてください。これらのジャンルは対人ゲームではあるものの戦うタイミングを選択するのはプレイヤーです。なので反省は再発防止をすることができる粒度でしましょう。上記のケースでもなぜそう言った状況に陥ったのかを考えることが有効です。

抽象化

抽象化とは共通点や法則性を見つけ、共通の本質を見つけることです。

いわゆる覚えゲー的な要素は一つずつ暗記するのではなくいくつかの枠組みを作って分類化して覚えることが多いと思います。近距離パワー型、遠距離操作型みたいな枠組みですね。

この考え方は概念を理解することに有効ですが自分は反省する際にも有効だと考えています。

ゲームに限らず体験したことがない事柄なのに過去の体験がフラッシュバックし、「これやったことがあるような気がする・・・」といったことは皆さんも経験があると思います。これは無意識的に過去の経験を抽象化できているということです。

抽象化した反省とは再発防止をすることができる粒度の反省であり「やったことがあるような気がする」の引き出しを増やすことです。

これらを元に意識していたこと

抽象化した反省の箇所がざっくりとした内容になってしまったのでゲームに例えておきます。

自分が新しいゲームをする際に意識していることです。

ベストプラクティスを探す

人気ゲームであればランクの高い先駆者がいます、彼らのプレイを抽象化して使えるとこを取り入れます。

意味がわからなくても真似してみればわかることが多いのでおすすめです。

できないことは細分化

初めてのジャンルのゲームをプレイする際には単純な操作やコンボを打つこと自体が難しいと思います。

なので自分ができる粒度まで分解しましょう。格闘ゲームのキャラを練習するイメージですね。

自然に操作をできるようになる

操作に意識を取られていると判断ができないことが多いと思います。まずは楽しみながら操作に慣れましょう。ここを楽しむことが出来ないと継続しないことが多いです、環境で強いとされているキャラを使う、扱いやすいキャラをつかうなどして無理をしないようにしましょう。

共通点を考える

自分がゲームで意識していたこととソフトウェアエンジニアリングのに関して過去に共通点を感じた項目です。

目的意識の徹底

ソフトウェアエンジニアリングは原則として課題解決のための手段

ゲームにおけるチート行為はソフトウェアエンジニアリングにおける意図した社会的信用を失う行為に似ている

DDDにおけるドメインのモデリング

ウォータフォールにおける要件定義

目的に付随する要素を考える

アジャイル・スクラムにおけるユーザーストーリーの洗い出し

余分な要素を捨てる

アジャイル・スクラムにおけるユーザーストーリーの細分化

過去に捨てた&捨てるべきだった要素

要件定義段階ででHowを気にしすぎてしまう

技術選定の根拠に個人の好みが入りすぎている

可読性を無視したトリッキーなコード

抽象化した反省

反省は具体的すぎてはいけない

インシデントやスケジュールの遅延など結果ではなく、そうならないための仕組みづくりに注力する

ベストプラクティスを探す

検索する、本を読む、教材を買うなどして先駆者の知恵と考え方を盗む

できないことは細分化

複雑な仕様の細分化

複雑なロジックをメソッド化してソースを見やすくする

デバック時にわかっている点から整理する

自然に操作をできるようになる

言語、フレームワークに慣れる&理解することで余裕が出ることで都度判断する時間ができ品質が上がる

タイピング能力の向上

mac windows linux 等のOSに対する理解による作業効率上昇

最後に

粒度はバラバラですが意外と共通点は多いように感じます。また、個人的に「自然に操作をできるようになる」 を楽しむことができる人はエンジニアとしての素養が高い認識です。

冗長&急足になってしまいましたが自分が伝えたかった考え方が伝われば幸いです。稚拙な文章ですがここまで読んでいただき、ありがとうございましたmm