株式などの投資をする際には「損切り」という考え方がとても重要となります。その考え方がゲーム開発に応用できそうだったので、まとめてみました。

■損切りとは

損切りとは、購入した株などの資産が購入時の金額を下回っている状態となり、値段が回復する見込みがないと考え、その資産を売却して損失を確定させることとなります。
例えば、購入時に「1000円」だったものが、業績悪化で「800円」まで下がってしまった場合、「もっと下がるかもしれない」というリスクを考慮して、これ以上の損失を出さないためにその時点で売却し「200円」の損失で食い止める、という行動です。

■損切りがなぜ難しいのか

損切りが難しい理由は2つあります。
1つは「損失を受け入れたくない」という心理です。
例えば以下のような実験をした場合、

A. テストの成績が前回より上がったら、2000円を渡す
B. 子供に最初に2000円を渡して、テストの成績が前回より下がったら取り上げる

どちらも「成績が良かったら 2000円を渡す」という条件は同じなのですが、"B" の方が成績が良くなった人が多かったそうです。この理由として、人は「与えたものを取り上げる」という損失を受けることを嫌う心理が働くからです。

これは、無料で受けられたサービスが、ある日を境に有料になると怒り出す人がたくさんいる、ということに近いかもしれません。

* それまで無料だったネットワーク対戦が有料になった
* それまで無料だった音楽配信サービスが有料になった

もともと無料で受けられることが提供側の多大なサービスだったとしても、ユーザーにとっては損失なので、なかなか受け入れられにくいこととなります。

「損切り」が難しいもう１つの理由は、損失を受けた場合に積極的にリスクを取ってしまい損失を拡大させやすい、という行動原理があります。

A.コイントスをして、表が出たら2万円もらえる。裏が出たら0円
B.コイントスをしないで、確実に1万円もらえる

この場合、"B" を選択する人が多いという実験結果が出ています。
先ほど説明した通り、"A" を選んでせっかく得た1万円を失いたくない、というリスク回避の心理が働くためです。

C.コイントスをして、表が出たら2万円支払う。裏が出たら0円
D.コイントスをしないで、確実に1万円支払う

しかし、損失の場合は、"C" を選ぶ人が多くなります。理由は "C" の場合「うまくいけば損失を回避できる」からです。しかし損失を拡大させるリスクが高まります。

■ゲーム開発における損失とは

投資であれば損失は "お金" ですが、ゲーム開発の場合は以下のものが損失と言えそうです。

* 面白くならないゲームを作り続けて時間を無駄にする
* モチベーションが下がってしまう
* 作っていて楽しくない

投資と同じで、面白くならないゲームを作り続けると、時間を無駄にしたり、やる気がなくなったりして、損失を拡大させていくこととなります。
面白くないとわかっているのに「せっかく作ったのだから完成させよう」「失敗したくない」という損失を回避する心理がズルズルと開発を続けさせてしまいます。

ちなみに私の失敗例も書いておきます。

* 技術不足：ゲームシステムは完成したが、ゲームに合ったシナリオを作ろうとしたものの、いいシナリオが作れずにお蔵入り
* 面白くない：基本となるゲームシステムに色々と要素を足したものの、しっくりこない(足す前の方が良かった)のと、プログラムが複雑になったのでお蔵入り
* モチベーションの低下：開発中に仕事が忙しくなって、ゲーム内容も微妙だったので色々面倒になってお蔵入り

■損切りのメリット

損切りを行うと損失が発生しますがメリットもあります。それは自由に使える資金が戻ってくることです。1000円で買ったものを800円で売ってしまうと損失となりますが、800円というお金が手に入ります。それにより別の投資に挑戦できる資金を獲得することになります。

ゲーム開発もこれと同じで、開発を中止すると、別の面白くなるかもしれないゲーム開発に移ることができる機会を得ます。

■損切りをするタイミング

投資で儲けている人に共通するのは、損失を無駄に拡大させないための「損切り」をしっかりできる、ということです。そして「損切り」がしっかりできる人は、"損切りするルールを事前に決めて、それに従って行動している" となります。

つまり、ゲーム開発の損失の拡大を防ぐために一定のルールで 「開発を中止する」ということを事前に決めておいて、それに従って中止するかしないかを判断するというのが良さそうです。

■ゲーム開発で損切りするルール

ゲーム開発で損切りするルールは以下のものが良いかもしれません。

* ゲームを面白くする方法が見つからない：期待したほど面白くなかった。ゲームの核となる部分の面白さが確立できない。面白さの見込みが立たない。テストプレイヤーの反応が微妙
* モチベーションの低下：開発中のプロジェクトの作業が１週間〜１ヶ月以上着手できていない。開発を続けることが楽しさよりも義務感となってしまっている
* 経験不足を解消する方法がない：バグが多くて解決できない。規模を無計画に拡大させすぎた。ゲームメカニクスを盛り込みすぎて収拾がつかなくなった。ジャンルの知識不足で間違ったゲームデザインで進めてしまった
* 開発期間が長くなりすぎている：事前に予定していた開発期間を大幅に超えている

■失敗したプロジェクトの活用方法

失敗したプロジェクトをそのまま捨ててしまうのはもったいないです。できれば実装に費やした部分の技術情報をドキュメントに残しておいて再利用できるようにします。コードやリソースが再利用できるのであれば、それを整理するのも良いです。
もしくは、あと少しで完成するのであれば、つまらないゲームであっても、面倒な部分を削って省略するなどして頑張って完成まで持っていき、リリースしてしまうのも良いかもしれません。

■ゲーム開発では分散投資は避ける

投資の世界では「分散投資」をすることが基本となります。というのも１つの銘柄に集中投資を行うと、当たるとでかいのですが、外れた場合の損失も大きなものとなってしまうからです。

ただ、これはゲーム開発には直接当てはまりません。複数のプロジェクトを同時に開発すると、どれも中途半端に終わってしまうので、できれば１つのプロジェクトに集中して終わらせた方が、良い結果になると思います。
また、様々なゲームの要素を詰め込む、例えばメインゲームから外れたミニゲームをたくさん用意する、という物量勝負のゲームデザインは個人開発ではリソースが限られているためオススメできません。個人開発では１つの核となるゲームシステムを活用することに集中させた方が良いです。

開発環境に関しては、プロトタイプ作成用と本制作用で環境を分けるというのはアリかもしれません。例えば私の場合「GameMaker:Studio」「Pyxel」はお手軽にゲームを作れるのでちょっとしたアイデアを試すには良い環境だと思っています。それに対して「HaxelFlixel」「Unity」は静的型付けの言語を採用しているので、中規模以上のしっかり作り込むのに向いている環境ではないかと感じています。
ただやはり、様々な環境に手を出しすぎると使い方を覚えるのに時間を浪費してしまうので、ある程度は絞った方が良いのかもしれません。

■参考にした記事

インディーゲーム開発において失敗するのはどういう原因で起こるのか、また失敗した場合はどのようにするのが良いのか、といったことについてまとまっていて、とても良い記事です。

■関連する記事

今回の記事を書くにあたって、過去の自分の失敗を振り返って思い出したのが "Game A Week" です。"Game A Week" は失敗してもお蔵入りせずに完成させられるから、良い手法だなぁ……などと改めて思ったりしました。

今回の記事では損切りのメリットを強調しましたが、当然ながらゲームは完成させた方が得られるものが多いです。こちらの記事では、ゲームを完成させるための障害となる傾向についてまとめてみました。