ゲームプログラミング/書類/説明書の書き方
フリーゲームなどの場合
編集フリーウェアやフリーゲームなら、そこまで細かく説明書を書く必要は無いでしょう。
フリーゲームの説明書なんて、例えば、そこいらのゲームセンターにある対戦格闘ゲームにある、筐体に貼り付けされている操作説明のシールに、毛が生えた程度の情報量でも十分でしょう。これは別に皮肉で言ってるのではなく、ゲームプレイヤーの中には説明書を読むのが苦痛な人もいますので、そういった人への配慮でもあります。また、仕事でもないフリーウェアに、あまり予算や時間をかけるわけにもいきませんので、説明書がフリーウェアで省かれるのは、よくある事です。
要点
編集重要なことは、テストプレイをしながら説明書を書く、と言うことです。なので、将来的なデバッグや仕様変更などによって変更しそうな細部の説明は、後回しにすべきでしょう。
だから「基本操作」のように、仕様変更の可能性が低い場所を優先して、説明書には書くべきでしょう。（だからフリーゲームなどで「基本操作」しか操作説明が書かれてないのも、これはこれで合理的なわけです。）
説明書
編集当然のことですが、そのゲームの操作方法などの説明書を書く必要があります。
パソコンゲームの場合、「説明書.txt」とかの名前で説明書を書きます。
企業などだと「readme.txt」という名前の場合もあり、read me 、つまり「私を読んで」、意訳すると「これを読んでください」という意味です。パソコンの設定によっては、ファイル名に英数字以外の日本語が入ると文字化けをする可能性があるので、「readme.txt」にするのが無難でしょう。
しかし、ゲームプレイヤーの中には、企業の事を知らない人もいるので（子供もプレイします）、ゲームの説明書では「説明書.txt」などの名前にするのが無難でしょう。
なお、テキストファイルなので、画像は使えません。
画像を使いたい場合、方法は下記のような方法がある。
- ・ HTMLファイルで説明書を書く。
- ・ PDFファイルで説明書を書く。
- ・ PNG画像などで説明書を書く。
- ・ ゲーム中で説明する。
- ゲーム中で説明する場合
もし画像が必要な場合は、いっそゲーム中で画像つきで説明する方法などもあります。
たとえばオープニング画面に「操作説明」コマンドを追加するとか、あるいはRPGならマップ移動中に開いたメニュー画面に「操作説明」コマンドとか、あるいはアクションゲームなどでメニューがないなら、オープニング後のステージ選択画面とかキャラクター選択画面にでも「操作説明」コマンドでも追加して、そのコマンドでプレイヤーの知りたい操作を説明する、などの方式です。
- HTML説明書やPDF説明書の場合
これとは別に、html形式で別冊の説明書を書くか、あるいはPDF形式で説明書を書く、などの方法もあります。（もしhtmlの説明書を作る場合、テキストファイルの説明書と区別しやすくするため、ファイル名を変えましょう。「詳細説明書.html」とか「manual_detail.html」とか名づけて、readme.txtとは区別しやすくしましょう。）
ただし、HTMLの場合、Windowsのブラウザのバージョン更新によって、古い説明書が読めなくなったりすることがあるので、ゲーム作者は定期的に説明書の更新が必要になる場合があります。MacやLinuxむけゲームでも同様です。
PDFの場合、いちおう、フリーソフトでPDF作成ソフトがあるし、あるいは家電屋などで売ってる3000円くらいのPDF作成編集ソフトなどで、PDFを作れます。ゲームにかぎらず、よく市販の製品のウェブ説明書でもPDF形式で説明しているものがありますので、PDF編集・作成を練習してみるのもよいでしょう。
なお、PDFを閲覧するビューワー（閲覧ソフトのこと）は無料のものが配布されています。またFirefoxなどのウェブブラウザにもPDFビューワーが組み込まれています。
また、たとえばアドビのPDFビューワー（無料）で Adobe Acrobat Reader があります。というか、PDFはもともとアドビのソフトです。なお現在PDFは特許が無償公開されており、ISO国際規格になっています。
- PNG画像などの場合
このほか、PNG画像などの画像ファイルで説明する方法もあります。けっして、「画像を説明書ファイルに組み込む」という意味ではなく、説明書そのものを、何枚かのPNG画像で説明する方法です。
しかし、この方法は、あまりフリーゲーム界隈では取られません。
フリーゲームで見られる使用例として、操作の単純なアクションゲームなどで、1行程度の説明文が枚数あたり2個程度まで入った画像で説明されている場合があります。
なお、あまり文字が多いと、文字が読みづらくなるので、操作の簡単なゲームの場合のみ、有効な方法です。画像も、あまり多いと検索しづらいので、せいぜい画像は5枚程度が限度でしょう。（それ以上多い場合は、画像だと検索しづらいので、HTMLファイル説明書などを検討したほうが良いでしょう。）
JPEGだと、細かい文字が潰れることがありうるので、PNGやbitmapにするのが安全でしょう。
下記では、テキストファイル形式の説明書の書き方について、解説します。
なるべく簡潔に書く
編集説明書では、幅広く、起動方法,ゲーム中の操作方法,インストールの有無,著作者,スタッフ, ・・・・・・・など、いろいろなことを解説しないといけないので、
それぞれの情報は、なるべく簡潔に書くべきです。
細かい情報は、他のファイルに書きます。
- 例. 対戦格闘アクションゲームの場合
たとえば、対戦格闘アクションゲームの説明書の場合なら、
説明書の「操作方法」の章では、共通の操作方法を書くべきです。
たとえば、対戦格闘アクションゲームのreadmeなら、
【操作方法】 * 格闘中の操作 Z : パンチ X : キック ↑ : ジャンプ →または← : キャラクターを左右に移動 ↓ : しゃがむ * その他、選択肢メニューの操作 Z : 決定 ↑、↓、→、← : カーソルをそれぞれの方向に移動
のような共通操作だけを書くべきでしょう。
一方、例えば、その格闘ゲームの各キャラクターの必殺技コマンド
（矢印キーはキャラが右向きの場合） 武田謙信 ↓＼→ Z : 龍虎拳 →↓＼ X : 百烈猛脚
とかは、別ファイル（「必殺技.txt」など）にまとめるのが無難でしょう。
- 例. 世界観やキャラ設定
世界観やキャラ設定などの説明は、ついつい長々と説明したくなりがちですが、しかし説明書では、それらの設定の説明は、それぞれ数行にまとめましょう。
どうしても長い設定を説明したい場合は、別途、「作品設定.txt」などのファイルを作って、そちらで説明しましょう。
ゲーム名などを書く
編集まず、ゲームの説明書には、冒頭に
Wiki宇宙戦争 （※体験版）
～ 取り扱い説明書 ～
ver 0.01
=============================
のように、ゲーム名と、説明書であることを書きます。
また、初めて公開する場合などは、エラーがあるかないかをプレイヤーにテストしてもらうためのテスト公開である場合が普通なので、「体験版」などの注記を追記しておきます。
正確には、「体験版」とは、かならずしも開発中ソフトのテストプレイ目的のバージョンだけでなく、たとえば有料ソフトの、ユーザーが使用しているハードウェアなどでの動作チェックのための無料試験版などの場合にも「体験版」を使うのですが、しかし無料ゲームなどの制作では、そこまで気にしなくても平気でしょう。実際にネットに出回っている日本製の無料ゲームを見ても、開発中の無料ゲームソフトのテスト目的のバージョンでも「体験版」という表記を行っているゲームは多くあります。
どうしても用語の厳密性が気になるなら「テスト版」とか「アルファテスト版」、「ベータテスト版」などの表記をする方法もあります。
「ベータテスト」や「アルファテスト」とはIT業界の用語です。「ベータテスト」とは、完成間近のあるソフトウェアを、ボランティアのプレイヤーに実際にアプリ起動してもらい使用してもらって、そのソフトのバグなどを報告してもらう検査のことです。
なお、「ベータテスト」が完成間近な一方、「アルファテスト」とは開発の比較的に初期の段階での検査で、実際にアプリ起動をして、実際にアプリ使用をして行う検査です。
もし有料ゲームを作る場合であって開発中の場合は、「体験版」だと「アプリ完成後の無料お試しプレイ版のことだろう」と誤解される場合がありうるので、ひょっとしたら「テスト版」などと明記したほうが良いかもしれません。
さて、文字の言語についてですが、海外のパソコンでは、ファイル名に日本語が使えない場合があるので、ファイル内の文章の冒頭で、作品名の提示と、説明書の提示を行う必要があります。
また、将来的に、ソフトのバグ修正などでバージョンを更新する可能性があるので、ソフト更新時に説明書の内容も変わる可能性がありますので、バージョン番号をつけてください。
バージョン番号の付けかたには、主に2つの方式があります。
- ・ 「ver0.01」 や 「ver 0.02」 のように番号をつける方式。
- ・ 「20190908」のように、公開した年月日をつける方式。
新旧の区別さえできれば良いので、日付でも構いません。たとえば2019年9月8日に公開したバージョンなら、 「20190908」のような番号にする方式もあります。
ただし、一般的に、日付によるバージョン管理は、開発のごく初期の段階に使われる慣習があります。
ゲームソフトにかぎらず、一般的にver1.00以降は完成品に使うバージョンです。（ver1.00自身も完成品バージョンに含まれます。）
ゲームに限らずIT業界での一般的な慣習として、たとえ開発中は「20190908」のような日付け方式で管理していても、とりあえずの完成品には「ver1.00」以降の番号をつけるのが慣習です。
そして、いったんver◯◯方式の番号で管理したら、以降は日付方式の バージョン番号はなるべく使わないのが慣習です。（日付方式の管理番号は、開発初期に使う慣習であるため。）
もし「ver ◯◯ 」方式でバージョン番号を管理するなら、製作中のゲームには、1.00より低いバージョンをつけるのが安全でしょう。製作を始めたばかりの段階なら、ver0.10くらいにしておきましょう。
一般的に、ver0.90やver0.95などの、ver1.00に近い数字は、「完成の直前」とかの意味です。なので、まだ開始したばかりの段階では、1.00に近い数字はやめておきましょう。
- ver1.00の呼び名
なお一般にIT業界でver1.00および以降（ver1.00～）のバージョンことを「リリース版」と言います。ですが、フリーゲーム界隈や同人ゲーム業界では、あまり「リリース版」という言い方は普及していないので、「正規版」とか「正式版」とか「完成版」とかの表現でver1.00および以降バージョンのことを言ったりします。 「正規版」と言っても、別に今までが海賊版だったわけでもなく、また、「完成版」といっても今後もバグ修正が続きます。
概要を書く
編集また、起動方法の前後に、ゲームの概要を、たとえば
* 概要 このゲームはシューティングゲームです。 2D（二次元）シューティングゲームです。
のように、数行で短く書いてください。
原作者はジャンルを知ってても、第三者にとっては、そのゲームのジャンルが何なのかは、説明されるまで不明です。
普通のプレイヤーは、そのゲームのおおまかな内容すら分からない段階では、起動しようとは思わないでしょう。
動作環境や起動方法などを書く
編集つづけて、動作環境や起動方法やインストール方法などを、説明書に書く必要があります。
- 動作環境の説明
動作環境では、最低限、そのゲームが動くOSがWindowsなのかMacなのかLinuxなのか説明すべきです。
意外と記述を忘れがちですので、気をつけましょう。
- 起動方法の説明
まず、インストールの必要があるのかないのか、ソフトウェアの起動において重要なことですので、書く必要があります。（例えば、学校や会社などのパソコンの設定によっては、管理者以外によるインストールを禁止されている場合もあります。）
インストールの必要がある場合、アンインストールの方法も書くべきです。
インストールの要・不要に関わらず、起動方法は書くべきです。なぜならゲーム制作ツールごとに、プレイヤー配布用のゲームファイルの構造や各種ファイル名やその書式が異なるので、その制作ツール製ゲーム（たとえば「ウディタ製ゲーム」「Unity製ゲーム」など）になれてない初心者プレイヤーには、起動方法が分かりません。
例としてインストールが不要な場合、たとえば下記のように起動方法を書くと良いかもしれません。
* インストールおよび起動方法 インストールは不要です。（インストールできない仕様です。） 起動するには、解凍したゲームファイル内に同梱されているアイコン『Game.exe』をダブルクリックして実行してください。 するとゲームが起動します。
のように、具体的にどのファイルをどう押すと、何が起きるか等、ゲームの起動方法を書きます。
ときどき「ダブルクリック」を単に「クリック」と省略しがちですので、気をつけましょう。
また、起動で押すファイル名（上記の例の場合は「Game.exe」）は必ず書きかましょう。理由のひとつとして、制作ツールごとに書式が異なっています（ツクールとウディタはたまたま同じ書式ですが、しかし他の制作ツールだと書式が異なる場合もあるからです。）。
実際、Unityだと起動ファイル名の書式が異なり、多くのUnity作品は起動ファイル名が「作品名.exe」の書式です（Windows用の場合）。たとえば『ウッキークエスト.exe』のようになります。
一方、ツクールやウディタでは起動ファイル名は通常「Game.exe」ですので、ツクール作品しか過去にプレイした事ないユーザーには、説明書で起動ファイル名が無いと不明です。
そもそもUnityの場合、ゲーム以外の産業用のアプリなどにも応用される場合があり、Unityの3D描画機能の利用目的で各種の産業で応用される可能性もあります。（たとえば3D機能を使って、住宅建築業界が新築シミュレーションなど、そういう応用が考えられます。）なので、おそらくですが、実行ファイル名に「Game」という名前はUnityでは使われていないのでしょう。
開発ツールを使った場合、できればその開発ツール名を書く
編集たとえば、自作のゲームがRPGツクールを使って作られた場合、いちいち操作方法を細かく書かなくても、「このゲームはRPGツクールを使って開発しました。」とか書いておけば、
多くのプレイヤーは、操作方法を予想できます。
なぜなら、RPGツクールの標準設定になっている操作方法や、それらの開発ツールのサンプルゲームの操作方法が既にあるからです。
なので、それら標準設定やサンプルゲームと同じ操作方法については、プレイヤーは、説明を読む時間を節約できます。
ツクールを例に説明しましたが、べつにツクールにかぎらずウディタや吉里吉里（きりきり）など、ほかのゲーム開発ツールでも同様です。なので、もし開発ツールを使用した場合、できれば説明書に開発ツール名を書きましょう。
操作方法を書く
編集細かな操作方法は、ジャンル名を説明したあとに、説明するべきです。
* 概要 このゲームはシューティングゲームです。 2D（二次元）シューティングゲームです。 * 操作方法 矢印キー : 機体の移動。または選択肢カーソルの移動。 Zボタン : ミサイルの発射。 Xボタン : ボムの投下。
のようにです。
もし仮に、ジャンルを説明されずに、いきなり「Xボタン : ボムの投下。」とか言われても、第三者には意味不明です。
また、仮に、RPGツクールとかウディタとかのゲーム開発ツールを使って作ったゲームであっても、標準設定の操作方法のままの部分の説明もふくめて、自作ゲームの操作方法を説明してください。
なぜなら、プレイヤーのなかには、そのゲーム開発ツクールの標準設定の操作をまだ知らない人も多くいます（人生で初めてツクール製ゲームをプレイするような人も、世間には、います）。
公開日
編集自作のパソコン用ゲームの場合、説明書などの最後などの、わかりやすい箇所に、すくなくともver1.00 の公開日を書く必要があります。
ver1.00の公開日: 2018年05月14日
などのように、なるべく具体的な日付を書く必要があります。
「初版の公開日:」ではなく「ver1.00の公開日:」のように、具体的にバージョン番号を明記してください。
「初版」だと、開発中バージョンのver0.01などと混同される可能性がありえます。
著作権などの管理上、ver1.00 の公開日が必要になる場合があるので、安全のため、かならず公開日をつけてください。
もし公開日がないと、最悪の場合、もし盗作などをされた場合、たとえ自分のほうが先だとしても、証明しづらくなります。
盗作の危険のほかにも、偶然にアイデアが他の作家と 重なっててしまう場合もあります（俗（ぞく）に「ネタかぶり」といいます）。
なので、ver0.01やver0.10などの初公開日や、ver1.00以前のベータ版時点での大幅なアップデートをした日なども、ver1.00が出てから1年ほどは書いておくと安全です。
日本に同人ゲーム作家やフリーゲーム作家は少なくとも何千人かはいるので、もしもネタが誰かと重なっても、しばらくはお互いに気づけません。
このように、いろいろな日付の情報がしばらくは必要なため、とりあえず、ver0.01などの初公開以降にバージョン更新をしたら、すべてのバージョンの日付は更新履歴に書いてしまうのがラクチンです。
もし将来になってver1.00以前の履歴が不要だと思ったら、そのときになって消去すれば済みます。
フリーゲーム配布ウェブサイトで見られる「登録日」などの情報では、はたして開発版の初公開日なのかver1.00の公開日なのかも不明ですし、また、開発途中で追加されたアイデアの公開日なども不明です。
開発版の初公開の段階でほとんど完成しているのなら、サイト登録日などで代用してもよいでしょうが、しかし開発が1年以上に長引いたりする場合もあるので、とりあえず全てのバージョンの更新日などを更新履歴などに書くのが安全です。
あと、ウソの公開日を捏造するのは、やめてください。（ウソの日付を書くのは、違法の可能性があります。）
そのゲームを最初に公開した日を書きたい場合は、「公開開始」など用語が、誤解を招かないでしょう。
一方、「初版」という言い方には、日本語として「校閲済み」のようなニュアンスがあるので「非・体験版」のような印象を与えるので、体験版には「初版」という言い方は不適切かもしれません。
たとえば
ver0.10: 2017年11月07日 公開開始
のようになります。
上記の例をまとめると、たとえば
ver0.10: 2017年11月07日 体験版の公開開始 ver1.00: 2018年05月14日 リリース開始
のようになるでしょうか？
ver1.00の正式版の開始についての更新履歴の書式は、同人ゲーム作家によって表現が異なり、「リリース」という人もいれば、「初版」という人もいるし、何も併記しない人もいます。
作者の名義
編集ゲームの説明書の最初のほうか、あるいは最後のほうに、
できれば、作者名（ペンネームでも可）を書いてください。ペンネームでも構いませんが、そのペンネームを、責任をもって使ってください。
著作権の管理で、作者名が必要になります。
また、連絡先の確認も兼ねています。
もしホームページアドレスやメールアドレスなどを書いていても、もしかしたら将来的にアドレスは何らかの経済的な事情などで変更する場合があります。
その場合、もし、名義が無責任に運用されていると、同業者が作者名をつきとめる際に混乱します。
どうしても、名義を非公開にしたい場合には、「作者名は非公開です。」とか「匿名希望」（とくめいきぼう）とか、その旨を書いてください。
名義非公開の場合に、その旨が説明書に書かれてないと、読者が、「作者が書き忘れたのかな？」とか混乱します。
なので、名義非公開なら、べつに非公開でもいいので、読者に「作者の名義は非公開です」と説明してください。
なお、フリーゲーム業界では、説明書の著者名は、特に断らないかぎり、ゲームの作者名と同一人物である、と判断されます。なので、作者名とは別に各書類の著者名を書く必要は、ないです。
- 合作などの場合
合作などで、製作メンバーが多人数にわたる場合、
説明書とはべつに、クレジット (credit.txt) などのファイルを用意して、そこに、製作メンバーを書くのがよいでしょう。
誰が何を担当したかも、分かるように書いてください。
スタッフ クレジット
============================
【プログラム】
プログラマー : 山田太郎
プログラマー : 鈴木二郎
【ストーリー】
シナリオライター : 山田太郎
【イラスト】
イラストレーター、ドット画像作成 : 田中花子
ドット画像作成 : 鈴木二郎 （プログラマー鈴木二郎と同一人物）
（後略）
のように書くことになるでしょう。
外部の画像素材、音楽素材などを利用した場合
編集一般的に、外部の無料の画像素材や無料の音楽素材を利用した場合、その素材の利用規約により、その素材を使用したことを明記する義務があります。
なので、もし、これらの素材を利用した場合、作者であるアナタは、自身のゲームの説明書ファイルやクレジットファイルで、利用した素材の名称などを書くことになります。
使用素材
============================
【画像】
* 背景画像
伊藤五郎 さま
ゴローのフリー画像サイト http://xxxxxxxxxxxxxxxxxxxxxxxxxxxxx
* 機体グラフィック、ボム画像
高橋二郎 さま
高橋シューティング大好き！ http://△△△△△△△△△△△△
【音楽】
斉藤三郎 さま
斉藤ミュージック館 http://○○○○○○/○○○○○○
（後略）
のように、最低限でも、誰の素材を使ったか、書いてください。同姓同名の人などがいる場合がありますので、素材作者の名義に加えて、さらに素材作者のwebサイトなど素材公開場所も書いてください。
また、使った素材が、画像なのか音楽なのか区別できるように、書いてください。
ホームページのアドレスは、もしかしたら将来的に変更される可能性があります。しかし慣習的に、（説明書での素材ホームページアドレス紹介は、）ゲーム公開当時のアドレスのままでも良いということになっています。
ゲームは初公開後にも、5年や10年たってもダウンロードされてプレイされる可能性があるため、作者がずっとアドレスの変更を追うのは困難です。
どうしても、素材配布元のアドレスが変更されていることが気になるのであれば、「素材の配布元のホームページアドレスは、当ゲームの ver1.00 公開当時のものです。その後にアドレスは変更されている可能性があります。」とでも、自分の説明書に、但し書き（ただしがき） を加えるくらいでも十分でしょう。
完成後の追加事項
編集更新履歴を書くこと
編集バグ修正などの履歴
編集ゲームのとりあえずのver1.00の公開後にも、
バグの修正などをすれば、その修正履歴を、説明書などに追加する必要があります。
なぜなら、バグ修正版よりも古い前バージョンをプレイしているプレイヤーも、いるかもしれないからです。
もし、説明書に、修正の履歴がないと、前のバグ報告をしたプレイヤーとは別プレイヤーから、もういちど同じバグについてバグ報告をされてしまいます。
なので、説明書には、バグ修正の履歴を書く必要があります。 どのバージョンが、なんのバグ修正を行ったかの履歴を、バグ1つごとに、簡潔に1行で書きましょう。
また、「バグ修正履歴」ではなく「更新履歴」ですので、バグ修正以外の変更も書きましょう。
たとえば、次のような記載になります。
2019/05/12 ver1.37 ・（バグ修正）シンジク町の武器屋ビルの壁を通過できてしまったので修正。 ・（シナリオ追加）クリア後の隠しダンジョンを追加。 2019/02/05 ver1.36 ・（バグ修正）薬草を85個以上所持すると画面がフリーズして続行不能になる現象をたぶん修正。
のような感じです。
機能追加やシナリオ追加した場合、新たなバグも混入する場合があるので、更新履歴には、バグ修正履歴だけでなく、シナリオ・機能などの追加履歴などもあると、今後のデバッグ時にも便利です。
ゲーム製作に限らず、ビジネスの書類において、そもそもエンドユーザーおよび消費者の知りたい事としては、改良のプロセスよりも、何を改良したかを（消費者は）先に知りたいのです。改良されたモノが何かを知ってから、その改良結果が自分にとって重要か否かを判断してから、あとから原因を調べる価値があるかどうかを、消費者は判定します。
なので、たとえ不具合の原因などが分かっても、更新履歴などの報告書では、まず先に何を改良したかを説明しましょう。
たとえば、原因を追記するなら
2019/05/12 ver1.37 ・（バグ修正）シンジク町の武器屋ビルの壁を通過できてしまったので修正。原因は、マップチップでカベと同色の床タイルの貼り間違え。 ・（シナリオ追加）クリア後の隠しダンジョンを追加。 2019/02/05 ver1.36 ・（バグ修正）薬草を85個以上所持すると画面がフリーズして続行不能になる現象をたぶん修正。原因は不明なので、とりあえず所持数をプログラム内部的には50個までにして、そのアイテムを2種類用意して2×50＝100として所持数100個までサポート。50個以上は2種類目との合計を表示の仕様。
みたいになるでしょう。
最低限の記載
編集- フリーゲームの場合
フリーゲームの場合、慣習では、更新履歴の記載のあるテキストファイルは、必ずしも、配布ゲームファイルに入れる必要は、ないです。
最低限、配布サイトなどでゲーム紹介文の見れる場所に更新履歴があれば十分です。
また、けっして、今までのすべてのバージョンの更新履歴を記載する必要は無く、最低限、現在のバージョンと、いくつか前のバージョンの更新履歴があれば十分です。
また、日付は不要です。 つまり、
ver1.37 ・（バグ修正）シンジク町の武器屋ビルの壁を通過できてしまったので修正。 ・（シナリオ追加）クリア後の隠しダンジョンを追加。 ver1.36 ・（バグ修正）薬草を85個以上所持すると画面がフリーズして続行不能になる現象をたぶん修正。
のように、日付を省いても、かまいません。
ただし、これはあくまで、フリーゲームや、趣味の範囲の同人ゲームなどの場合です。
仕事で作るソフトの場合、公開するかはともかく、なるべくver1.00からの全部のバージョンを、日付つきで更新履歴を保管しておくのが、（仕事で作るソフトでは）安全です。
修正できなかったバグについて
編集ゲーム製作者が、バグの存在に気づいていても、技術的な理由などで、修正が困難な場合があります。
たとえば、開発ツールそのものに起因するバグは、ゲーム製作者側では、修正できません。
それぞれの開発ツール用の、コミュニテイのつくった外部スクリプトのバグなどの場合もあります。
その他、単に自分の知識不足などで、修正が困難な場合もあります。
また、修正に手間のかかる割りに、修正しなくてもゲームを楽しめるバグの場合には、修正しないままにされる場合もあります。
いずれにせよ、修正のできなかったバグについても、説明書では、そのバグの存在について記載しておく必要があります。
なぜなら、記載しないと、多くのプレイヤーから何度もバグ報告をされてしまいます。
プレイヤーが100人いたら、その100人から、それぞれバグ報告をされかねません。その100人にいちいち、修正しない理由の説明をするのは、とてもメンドウです。
なので、修正しないバグについても、けっして無言で放置しないで、説明書などに記載しましょう。
べつに更新履歴の記載場所は、説明書ではなく、「更新履歴」という名のテキストファイルを作って、説明書と同じフォルダに入れておいても、かまいません。
履歴の更新作業中に、あやまって説明書の文章を書き換えたりなどのミスも減らすためにも、「更新履歴」というファイルを作っておくのも安全でしょう。
シナリオ追加や、機能追加や仕様変更なども書く
編集ver1.00よりもあとのバージョンで、シナリオ追加したり仕様変更した場合も、
説明書の更新履歴には、その履歴を簡潔に1行ていどでいいので、書きましょう。
理由のひとつとして、よくあるのは、追加した機能やゲーム内イベントなどに、バグが潜んでいる場合があります。
バランス調整などは履歴の記載を省略する場合がある
編集この話題はどちらかというと、開発版（ver0.01～ver0.99）の話題ですが、ネットで普及しているチマタのフリーゲームでは、実際には「更新履歴」で紹介されている内容の他にも、じつはもっと多くの更新がされており、細かなバランス調整による更新が行われています。
特に、開発版（ver0.01～ver0.99）の更新履歴が公開されている作品の場合、開発版のソフト内データと完成版（ver1.00～）のソフト内データとを比較すると、じつは、さまざまなパラメータの数値がそこそこ違っている場合もあります。たとえばRPGなどが分かりやすく、武器の攻撃力や防具の防御力といった装備品の性能の値が、開発版と完成版とで微妙に数値が違っていたりする場合もよくあります。
しかし、そういったバランス調整は、『更新履歴』ファイルの記載からは除外されているのが普通です。
理由は、おそらくですが、もし開発版で、いちいち『更新履歴』にバランス調整まで記載していると、記載内容が膨大になりすぎてしまう結果になりかねないのが普通であり、そのせいで肝心のバグ修正や仕様変更などの記載が埋もれてしまうからでしょう。
バランス調整については、よほど目立つ変化でないかぎり、開発版の段階でのバランス調整については、『更新履歴』での記載は不要でしょう。
たとえばRPGの武器・防具の性能なら、ゲーム序盤で入手できる武器の攻撃力・防御力の1ケタていどの数値の変化とか、ゲーム中盤以降でも、せいぜい10％ていどの数値の変化なら、よほど目立つ場所に記載されているパラメータでないかぎり、フリーゲームなら、いちいち『更新履歴』に記載する必要は無いでしょう。
また、ver1.00以降の完成版でも、フリーゲームや同人ゲームの更新履歴でバランス調整した事をもし記載する場合でも「ver1.01 バランス調整をした。」くらいに簡略に書いていても、プレイヤーは特に気にしないでしょう。
ただし、これはあくまでフリーゲームや同人作品などの場合です。はたして、ゲーム会社などの商業製品のゲームの『更新履歴』の管理がどうなってるかは、知らないです。
サポート終了する場合
編集「今後はもう、バグが見つかっても更新しない」などの、サポート終了する事自体は、けっして悪いことではありません。
一般に、こういうアフターケア終了、開発終了のことは、IT業界では「サポート終了」といいます。
ですが、終了の場合にも、気をつけないといけないことがあります。
まず、終了宣言後も、後述のようにセキュリティなどの問題があれば、いくつか対応しないといけません。
終了宣言後も例外的に修正しないといけない場合
編集たとえ「今後、バグ修正や要望などは、原則的に受け付けません。」と宣言しても、例外的に、修正しないといけない場合が、数種類あります。
どのような場合かというと、たとえば次のような場合です。
- ・ セキュリティ対応
- ・ 連絡先を変更した場合の、説明書などにある連絡先の記述の更新
- セキュリティ対応
めったに起きない現象ですがもし、自分の配布しているソフトウェアがコンピュータウイルスなどに感染してしまっている場合、または、セキュリティ的に危険な動作をしてしまっていてウイルス同様な場合は、開発終了を宣言していても、対応しないと、場合によっては裁判などで賠償などを請求されかねず危険です。なので修正対応または配布終了などの処置をしましょう。
このような場合も修正に対応できるように、念のため、ソースコードは残しておきましょう。
もし、ウイルスやセキュリティなどの問題がある状態なのに、ソフトウェアを修正せずに放置すると、最悪の場合、訴訟を起こされたり、あるいは、アップロード先のサーバの企業等から、アップロードを削除されて禁止される場合なども、ありえます。
なお、万が一、自作ソフトにウイルス感染などの問題があった場合、もし修正できなければ、配布の終了を決断しなければいけない必要もあります。
なお、これとは別の現象として、自作ソフトがウイルス感染してないのに、市販のウイルス対策ソフトが、自作のゲームを「ウイルス」ソフトだと誤って判定する場合があります。この場合、自分と似たような開発ツールを使っている別作者のソフトも、ウイルスだと誤判定されるのが普通です（もし、そうでないなら（自作ソフトだけウイルス判定される場合には）、果たして本当に自作ソフトにウイルスが混じってないか、詳しく調べる必要がある）。
- 連絡先の変更
連絡先が変更した場合も、こっそりでいいので、修正対応をする必要があります。説明書などに記載した連絡先を、いま現在に使用している連絡先へと更新する必要があります。
もし連絡先修正の対応をしないと、自分の古い連絡先と同じアドレスを使っているかもしれない人（自分とは別の第三者です）に、迷惑が掛かってしまうかもしれません。
あと、運が悪いと、自分の古い連絡先を使っているサイトが もしも詐欺サイトだったりすると、自分の評判も落ちます。
たとえ、自分に引越しなどをする気がなくても、契約しているプロパイダがメール事業サービスなどから撤退したりするなどで、連絡先アドレスの変更などの必要に迫られる場合もあります。
なので、サポート終了宣言しても、とりあえず、ゲームのアップローダなどのアカウントは残しておきましょう。
サポートの完全終了の場合
編集ゲームのver1.00から数年も立てば、新作や次回作をつくるために、前作については、開発を終了したい場合があります。
その場合、説明書などのどこかに「本作のサポートは終了させていただきます。そのため、バグ修正や要望などは、原則的に受け付けません。」などの注意書きが、あるほうが、良いでしょう。
また、単に、ソースコードを紛失して、今後のバグ修正が不可能になる場合もあります。
どちらにせよ、今後は修正しないつもりなら、そのことを明記すべきです。
というのも、もし、開発終了の明記がないと、プレイヤーは親切心で、サポート終了した作品のバグ報告をしてしまうかもしれないからです。
せっかく親切心で報告してくれたのに、それを無視するのは、両者とも、心のいたむことです。
なので、サポート終了を決心した場合は、そのことを明記しましょう。
また、ゲームにかぎらず、一般に事務系（オフィスソフトなど）の有料ソフトウェアには、商品ごとに一定の年数のバグ修正の受け付けの期間があります（いわゆる「サポート期間」）。IT企業などは、もしソフトウェアの修正サポートの終了をした場合、そのことを明記する必要があります。
なお、「保証期間」ではなく「サポート期間」ですので、混同しないように。
無料ソフトなら、バグなどがあっても、金銭による賠償（ばいしょう）などの保証は不要でしょう。
古いバージョンとの互換性サポート終了
編集ゲームに限らず、一般的に有料ソフトウェアでは、セーブデータについて、ver1.00以降で作成されたデータは、特別な理由のないかぎり、なるべくセーブデータの互換性を維持する必要があります。
つまり、新バージョン（たとえばver1.02）が出ても、前のセーブデータ（たとえばver1.01）を使用できるようにする必要があります。
しかし、自主制作ゲームでは、特別な場合、過去バージョンのデータとの互換性の維持が困難になる場合があります。
もしバグ修正などで、ゲーム内システムのデータ形式が関わるバグ修正のためにデータ形式を変更せざるを得ない場合などは、過去バージョンからのデータ形式との違いから、セーブデータなどの引継ぎが困難になって、互換性のなくなる場合があります。原理的には互換が不可能でなくても、経済的に互換させるのが困難になる場合もあります。
このような場合も、該当する古いバージョンからの互換性サポートの終了を宣言して明記する必要があります。
また、同じような理由で、完成版 ver1.00 が出た後に、プレイヤーからの互換性についての要望で、たとえば体験版 ver0.25 とかからのセーブデータの引継ぎ機能などを要望されても、
もしver0.25以降にデータ形式が大きく変わっていたりすると、引継ぎ機能を実装するのが、イヤな場合もあるでしょう。
このようなとき、場合によっては、互換性サポートの終了を宣言する必要もあります。
なお、シナリオはそのままだが大幅な機能追加などを行った場合などにも、セーブデータの互換性が不可能に場合もあります。このような場合、セーブデータの互換性が無いことを配布サイトの紹介文などで記載するのが良いでしょう。