馬鹿ほど物事を複雑に考える
急にイキったことを言ってしまってすみません。
でもこれ、アインシュタインや色んな著名な方が言っている名言なんです。
私もそんな気がしています。
何となく「バカは考えが単純」って思うかもしれませんが、知識や経験が足りない状態で問題を解決しようとすると、物事を必要以上に複雑に捉えてしまい、答えを見つけられなかったり、問題をよりややこしくしてしまう傾向があります。
例えば「10人で総当たり戦を行うと何試合行うことになるか?」という問題を解いてみます。
分かってる人には簡単ですが、どうやって計算したら良いか分からないって場合は、まず少人数で考えます。
2人の場合は1試合ですよね。じゃあ3人の場合は?
A B Cがいるとして、A-B A-C B-Cの3試合ですね。
じゃあ4人の場合は?
同じように頑張って全試合出してみると、6試合あることがわかります。
こうやって少ない数で少し試すと、法則があることに気がつきます。
2人の場合は、1試合。
3人の場合は、2+1で3試合。
4人の場合は、3+2+1で6試合。
5人の場合は、4+3+2+1で10試合。
:
:
10人の場合は、9+8+7+6+5+4+3+2+1で45試合になります。
このように、少ない数で試していき、ある程度出したところで法則を見つけて計算式を出して、実際の数に適用します。
数が大きい時は小さい数で試してみると、意外に理解しやすかったりします。
総当たりの意味が分からない人は… 勉強してください!
別のケースで考えてみましょう。
以下のようなゲームを考えたとします。
対戦型アクションゲーム
2人のプレイヤーが戦います。
武器がフィールドに落ちているので、それを取って攻撃します。
武器は強・中・弱の3種類が1つずつ落ちており、攻撃したときのダメージが違います。
相手にある程度近づいたら攻撃することができ、HPが0になったら負けです。
という非常にシンプルなルールです。
しかしこのゲームは、強の武器を取ったらほぼ勝ってしまうという問題がありました。
そのため、武器に攻撃までのラグタイムを設け、強い武器にはラグタイムを大きくしてバランスを取ろうとしました。
しかし結局強い武器が変わるだけで、それを取った方が必勝という状況は変わりませんでした。
そして武器の攻撃に回数制限を設けたり、攻撃範囲を設定したりして、仕様がどんどん複雑化していきました…
さてこの仕様の問題点は、武器を取ってしまったら、勝敗がほぼ決まってしまう点です。
つまりそのあとの攻撃行動が、ただの消化試合となってしまい、やっていて面白くないという点です。
これを解決するための策を練らなければいけません。
一番簡単なのは「攻撃を避けられるようにする」ことです。
こうすることで、攻撃が当たるまでは勝ちが見えません。
攻撃される側もうまく良ければ負けません。
このギリギリまで勝敗が見えないのがハラハラドキドキするわけです。
さらには、うまく避けたら攻撃のチャンスが訪れるといった、ピンチとチャンスが行ったり来たりすると、人はもっとワクワクします。
こういった攻防が起きると、人は興奮します。
さてそうなると「武器って別に1種類でも良いんじゃない? てか最初から持ってても良くね?」とならないでしょうか?
もちろん仕様としてあっても良いんですが、結局のところ面白さはそこではなく、接近時の攻防になりますよね。
むしろそこの気持ちよさを追求した方が、限られた時間を効果的に使うには良いような気がしてきます。
まぁこれを形にすると格闘ゲームになるわけですが。
ゲーム制作に限らず、物事は出発はシンプルでも、発生した問題を解決していく際に複雑化することがよくあります。
ここで大切になってくるのは、本来の目的を明確にして、問題解決のためにアイデアをシンプル・簡単にすることです。
今回の例であれば「こんなの簡単に解決できるよ」って思う人もいるかもしれませんが、それは大人が少し複雑な足し算を解いているようなもので、実際にふりかかる問題はもっともっと難解で、そうなると人は簡単に物事を複雑化する思考に陥ってしまいます。
一見難しいと思うような問題でも、1つ1つをシンプルな形で考えていくと、理解できることがあります。
難しい問題というのは、色々な要素が複雑に絡み合った結果で、1つ1つを見ていくと比較的簡単な場合があります。(単体で難しい問題も当然あります)
諦めずに少しずつ解いていけば、いずれ全体を理解し全てをキレイに解けるようになるでしょう。
プログラミングでも、必要以上に条件分岐を作らないようにしたり、同じような処理を行なっているところを関数に分けたりして、シンプルなコードを書くことを意識してみましょう。
そうすることで、プログラム以外の物事についても、シンプルな思考ができるようになるかもしれませんよ。
コメント