untitled

(1)

1

ゲームプログラミング

HSP を利用した RPG の作成

経営情報学部経営情報学科情報システムコース竹元学 5106158

(2)

2 目次

第１章

はじめに...3

第２章

第３章

作成物の詳細と利用技術...7

第１節作成物の紹介 ... 7 第２節画像の取り込み... 7 第３節マップチップ ... 8 第４節ドット絵 ... 9 第５節レイヤー構造技術 ... 10

第４章

作成物の詳細 ...10

第１節フィールド描画... 10 第２節表示範囲の設定... 12 第３節 HSP の透明色の設定 ... 13 第４節操作キャラクタの移動処理... 14 第５節衝突判定による進入禁止 ... 14 第６節操作キャラクタ以外のキャラクタの配置。... 16 第７節移動処理中の操作キャラクタの描画方法 ... 16 第８節メッセージボックスの表示... 18

第５章

終わりに...19

まとめ参考文献謝辞

(3)

3

第１章

はじめに

近年、多くの場所でゲーム機にて遊んでいる人たちを目にする。家庭内で行うビデオゲームだけではなく、電車の中で行うことができる携帯ゲーム機、またパソコンを用いたコンピュータゲーム等、様々なゲームが世に存在する。私自身もゲーム、特に家庭用ゲームが好きであり、現在もよく行っている。しかし何気に行っているゲームであるが、実際どのように動作しているかはよくわからない。つまり、中身がどのように動作してゲームが成り立っているかよくわからないブラックボックス状態である。そこで、プログラム言語 Hot Soup Processor(以下 HSP)を用いた自作によるコンピュータゲームの作成を行う。これによりゲームを作成する際のプログラムの基本構造を理解することを目指す。今回作成するゲームプログラムはパソコンにて動作するシンプルなRPG ゲームを作成する。作成理由とし私自身が好んでプレイするゲームがRPG であるからである。また、ゲームの作成手法を学ぶ際に、ゲーム作成の基礎知識を身につけるにはRPG が最も好ましいと言われているからである。理由として、ゲームではポピュラーなジャンルとして、また他の教材等からよくサンプル作品の筆頭に出されていたからである[1]。続いて、プログラミング言語にHSP を選択した理由を述べる。私自身ゲームをプレイする事はあっても作成する事は全くなかった。つまりプログラムに関する知識や技術はほとんど持ってはいない。そこでプログラム言語の選択には文法が簡潔なものを選択する必要があった。このようなプログラミング言語があるのかを探すとHSP が向いているとの結論に至った。理由として、全体的に初心者向けという特徴があり、数多くの参考書が売られているからである。何よりゲーム作成に向いていたのがという特徴から Hot Soup Processor(以下 HSP)を選択した。また RPG を作成する点からも HSP にて RPG の作成が盛んに行われており、参考資料や参考ソースプログラムが多く存在するからである。HSP の詳細については第２章関連研究の第５節で解説する。作成するゲームの内容として背景は初期段階では作成せず、キャラクタ等の細かなグラフィックと基本的な動作を作成する。理由として本テーマは世に販売されているような RPG の作成を目的とせず、RPG ゲームの動作する基本構造について理解する為である。つまりRPG と密接な関係のあるストーリー性に関しては今回保留とし基本構造を理解することを最優先とする。これはストーリーとはRPG のプログラム観点から見て、ストーリーは後付け、つまりプログラム観点から言えばおまけみたいなものだからである。基本的なキャラクタと動作が完成後は、「迷いの道に入り込んだ戦士の脱出劇」という短編のシナリオを後付けの形で作成した。ゲーム作成技術を学ぶ上では基盤を作成することが重要なので、コンパクトサイズのプログラムを作成することができれば、その同じシステムを繰り返し用いることで長編のシナリオも作成ができるからだ。本稿は２章では関連研究を述べ、３章では実際に作成したプログラムの紹介を述べ、４

(4)

4 章で作品の詳細を加え、最後の５章で以降の目標を述べる。

第２章

関連研究

本テーマはHSP にて RPG ゲームの作成を行った。RPG についての詳細、HSP の紹介を行い、またゲーム作成の際に使用した技術、マップチップ、レイヤー構造やそれに関わった技術を紹介する。第１節テーブル RPG とは

RPG とは、ロールプレイングゲーム(Role Playing Game)の頭文字を取った略語である。現時点で大きく分けて、テーブルゲームのRPG（以下テーブル RPG）と、コンピュータゲーム(以下コンピュータ RPG)の二種類がある。テーブルRPG はゲームの舞台の司会、演出を行う一人のゲームマスターと、その架空の背景や人格が付加されたキャラクタを担当する一人から数人のプレイヤーで遊ぶゲームである。ゲームマスター(以下 GM)はゲームの舞台やその事件、人物を解説するいわば司会者としての役割(ロール)を持っている。プレイヤーは作成したキャラクタを演じ、GM や他プレイヤーの演出に応じてキャラクタを動かす役割を持つ。これにより GM やプレイヤーがそれぞれ演じるキャラクタの行動は基本的にそのゲーム上で決められたルールに従い成功するか否かを判定し、ゲームを進行させていく。リアルタイムにプレイヤーの反応を GM が対応出来る為、柔軟にゲームの進行が行うことができ、事前に作成されたシナリオとは別で、プレイヤーと GM によるアドリブによるゲーム進行が可能である。その反面、ルールによって定められたデータ管理が難しく、ゲームの進行を忘れがちになることも珍しくはない。元々ロールプレイングの言葉には役割を演じるという意味があるので、そういった意味ではテーブルRPG が本来の意味を用いていると言える。ただし、後述のコンピュータ RPG と比べてその知名度の差からRPG として呼ばれることは少なく、テーブルトーク RPG あるいはTRPG 等と呼ばれることが多い。[6] 第２節コンピュータ RPG とはコンピュータRPG はコンピュータゲームにおける一つのジャンルを指している。仮想的ながらキャラクタの成長の過程をあたかも自分自身の成長のように体感ができるコンピュータゲームと言える。またコンピュータRPG はテーブル RPG から生まれたものとされているが、日本ではコンピュータゲームが一般的によばれるRPG である。コンピュータRPG は成長の概念を取り組んでいる為、物語の途中において、何らかの問題で行き詰ったとしても、ある行動を起こすことでその行き詰まりを解消することが可能である。例えばバトルで強大な敵が現れて倒せない等の状況が発生したとする。ほかのジ

(5)

5 ャンルのゲームでは敵の攻撃パターンを読むなどプレイヤーの操作が求められる事が多く、操作が得意でないプレイヤーでは、どうしても先に進めなくなってしまうことが多い。しかし、RPG では成長の概念を用いるため準備を前もって行うことが出来る。例えばレベルを上げる等の行動を事前に行うことで、より簡単にその敵を突破できるようにゲーム進行を行うことができる。逆にあえて成長の概念を極端に使用しないことで、より難しく強大な敵に挑戦することも可能である。このようなゲーム進行を「やりこみ」と言われており、動画サイトや雑誌の付録の CD 等で公開されており、また人気もある。こういった難易度の調整が身近で、かつ手軽に行える点も、コンピュータRPG が好まれる理由のひとつである。ただし、後述のコンピュータ RPG の歴史の流れから、国内と海外のコンピュータ RPG の定義が異なる面がある。一般的に日本内ではじっくり時間をかけて遊べるタイプのコンピュータRPG が好まれ、海外ではアクション要素が盛り込まれたリアルタイム指向のものが好まれる。また、その文化の異なりから、国内で作られるRPG はストーリー等の表現を特化する傾向にある為に、元々のRPG 要素を疎かにしがちになっている面もある。第３節 RPG の歴史コンピュータRPG の始まりは、1974 年に作られたテーブル RPG ダンジョンズ＆ドラゴンズ（以下D&D）がコンピュータゲームとして移植されたものが始まりとされている。D&D は1954 年に出版された小説、指輪物語の人気がとても高く、その世界観を体感できる遊びが欲しいという有志の願いから、アメリカのTSR(Tactical Studies Rule)社によって作り出されたボードゲームである。これにはレベルアップとステータス、つまりRPG の根底の要素と言える成長の概念及びキャラクタの特徴が表現されている。しかしテーブルRPG では原則二人以上でプレイする遊びであり、前述のテーブルRPG の欠点を面倒に思うプレイヤーも少なくなかった。その理由から、GM の役割をコンピュータで代用しようとする考えも生まれる事になる。その結果、コンピュータゲームへの移植がされるようになったD&D も大ヒット作品となる。その後、1981 年に登場したウィザードリィ、ウルティマ等の作品により、RPG のジャンルにおけるゲームシステムの基盤がより固まることとなる。このようなジャンルのゲームも日本に輸入されることになるが、ゲームの形だけに留まってしまう。第４節日本における RPG の歴史外国版のコンピュータRPG をプレイする日本のプレイヤーも多く、本格的な日本製のコンピュータRPG を強く望む声も増えた。そして 1986 年、日本でドラゴンクエストがファミリーコンピュータにて発売される。これまでのコンピュータRPG と比べて操作性が単純化され、誰でも遊べるように改良されていた。その結果として、日本にとってドラゴンクエストがRPG の定番として築き上げられる。その後、RPG の成長は日本と外国では異なる進化を遂げることにある。理由として、海

(6)

6 外では当時誰でも扱える訳ではなかったパソコンで遊ぶ大人のプレイヤーが多かったことに対し、日本では手軽に扱えるファミリーコンピュータで子供を中心に遊ぶ事が多いという異なる条件でRPG がスタートしたからである。日本製のRPG の主な特徴としては、主人公の年齢層が低い、ゲームクリア重視、ストーリー重視の３種類が上げられる。一つ目の主人公の年齢層が低い理由としては、先ほど記述した仮想的ながらキャラクタの成長の過程をあたかも自分自身の成長のように体感ができる、という特徴をより深める為、当時のRPG のプレイヤーの年齢層が低い事をあわせたことに理由がある。二つ目のゲームクリア重視は、クリアすることによる達成感を与える為である。ファミリーコンピュータによって作られたゲームは必ずといっていいほど、終点が用意されており、その影響を受けている。三つ目の、ストーリー重視としての理由は、これまでのRPG の特徴では強くなる理由付けがあまり注目されていなかったのである。この強くなる理由として、RPG の終着点とも言える強敵を倒す事が上げられる。強敵を倒す事を目標とする事でストーリーが生まれ、キャラクタを強化することになる。特に三つ目のストーリーに関してはより深く影響を受けることとなり、RPG をプレイする年齢層も徐々に上がってきたのもあいなって、RPG のシステムよりも練りこまれたシナリオを求められるようになっていく。結果としてRPG のシステムの基盤を着眼点に置く事はなくなり、その成長は遅れてしまうことになった[5]。

第５節 Hot Soup Processor（HSP）とは

Hot Soup Processor（以下 HSP）とは、製作者おにたま氏が作成した Windows 用のスクリプト言語のひとつである[7]。HSP の特徴として、文法が簡潔であり大文字小文字の区別を行なわず、変数を使用するのにあらかじめ変数の定義をおこなう必要が無いことである。ラベルによるプログラムの実行順序を自由に設定できることから記入が手軽に行える。加えて、フリーソフトという特性上コストがほぼ必要ないことから簡単に利用できる。プログラム始めたばかりの初心者や、低年齢層をはじめとしたアマチュア向けのツールプログラムとして広く認知されている。このことから、個人で遊ぶプログラムからオンラインで遊ぶプログラムと幅広い範囲で利用されている。また、フリーソフトという性質から ONION software 以外でも個人単位から HSP 用の拡張ツールの作成、開発が行われている。欠点としては実行順序が自由であるため、プログラムの構造が大きくなればなるほど実行順序が複雑に絡みあってしまう。そのため、プログラムの整理が難しく、他者が作成したプログラムを把握しづらいことがある。特に変数の定義を行う必要がないため、HSP 初心者には変数と構文を混ぜて解釈してしまう恐れがある。また、開発経緯の関係上OS や、それに近いところでの開発を行うことは不向きである。 HSP が開発されたきっかけは、おにたま氏はプログラムの開発において、Windows の基礎的な部分におかれている機能を手軽に利用できるようにしたツールが必要だと考えていた[2]。そこで BＡSIC 言語の書式をベースにし HSP が作成された。HSP の開発は、1994

(7)

7 年に非営利団体 ONION software (オニオンソフトウェア)製作が中心となって始まり、 1996 年以降にフリーソフトとして公開された[2]。現在も HSP は不定期ではあるもののバージョンアップが進められており、2009 年 5 月 13 日には HSP3.2β3 とバージョンアップされている。しかしバージョンアップにより、過去に作成したプログラムが使用できなくなる可能性がある。これらのサポートを怠っているわけではなく、現在のHSP と互換性ある程度を持たせるように設定を行うマクロをリリースするなどのサポートも行われている。また、Windows 用だけではなく、Macintosh 用の HSP の開発も進められており，現在ではテスト版であるHSPMac2.55α3 がリリースされている。しかし 2003 年からの更新から現在までの間、Macintosh 用の正式版 HSP がリリースされていない。なお、ONION software は HSP の開発だけではなく、2003 年から HSP で開発されたプログラムで競うHSP プログラムコンテストを公式に開催している。このコンテストは、一般部門、HSPTV 部門の二つの部門で行われている。また、2005 年 8 月からポータルサイトHSPTV！も作られており、ONION software からの交流の場の提供もしっかりと生み出しているといえる[3]。

第３章

作成物の紹介と利用技術

第１節作成物の紹介フィールド上に操作するキャラクタを配置し、フィールド上で操作するゲームを作成した。内容としては道に迷った一人の旅人が、脱出する為に歩きまわるRPG である。ただし、今回作成した物は２章で説明したRPG とは異なり戦闘や、キャラクタを育成するという要素は入っていない。ゲームの内容は閉鎖的な空間にて自由に移動できるフィールドを作成し、岩場等により侵入不可能な場所を表現し、出口を探すものである。つまり、迷路的な要素を含まれたものである。利用技術としては小さな画像の素材をコピーして利用することで、大きなマップを作製し、座標毎の侵入不可能の設定や、特定地点にキャラクタを移動させた場合でのギミックの発生を作成した。この章では、作成したゲームの利用技術を説明する。第２節画像の取り込み HSP 自体にもプログラム上で描画する機能があるが、実行しなければ確認が不可能である。そのため、確認しながら修正ができない為、HSP 外で画像ファイルを作成し取り込むことにした。画像の拡張子にはbmp を使用しており、無圧縮である為容量が必要になるが保存した画像が劣化しない利点がある。画像の編集ソフトにはWindows に予め用意されたペイントツールで作成することにした。画像表示方法としては、同じファイル内に画像ファイルを用意し、HSP にその画像ファイル取り込むよう記入している。まず１行目にbuffer を記入し、次に保存する画像を割振

(8)

8 る番号を記入する。そして縦のサイズと横のサイズをそれぞれ記入する。この時、指定したサイズが保存する画像より小さいと、画像を取り込むことができない。逆に画像より大きい場合は全ての画像を取り込むことができるのだが、代わりに本来画像が無い部分までもあるように扱ってしまい、結果として余分に容量を使ってしまうことになる。イメージで言えば、パソコンの画像を無圧縮のまま、印刷用紙に出力する感じである。（ソースコードは図１で表示）なお、この方法HSP 内部に画像を取り込むだけであり、実際に出力するには別途プログラムする必要がある、具体的な手段は第３節マップチップ等で解説する。第３節マップチップゲームのグラフィック技術としてマップチップ方式を今回採用した。マップチップとは１つの大きなマップを描写する際に小さなサイズで作られた１つの画像ファイルを複数の画像として使用し、タイル状に並べることで大きなマップとして表示する方式である。この方法を使用すると、描画の処理がより多くなるなり、メモリ領域を多く必要になってしまう欠点がある。しかし同じような連続した画像を使用することで、用量が小さくなると言った長所もある。画像を切り取り、貼り付けをする要領で、小さなサイズの単位で変更や追加が容易に行うことができる利点がある。また、応用として画像に割り当てた変数を別の数値に変更することであたかもパラパラ漫画のような動きを表現することができる。この技術の歴史は古くから利用されており、ゲーム製作ではゲームソフトに入れられる容量は極めて限られており、特にグラフィックは容量を多く必要とする要素の一つとなっていた。その為山は山、地面は地面といったように、共通の要素を持つものを一つのマップチップで使いまわしていたことで、容量を節約していた。ただし、現在では膨大な記憶容量外部媒体、例えばCD、DVD 等を利用することで容量を解消し、処理速度を優先するために背景などに一枚絵のグラフィックを使うケースも少なくない。なお、マップチップを作成するに当たる際に気をつけなければならないことがある。マップチップの間に境界線、例えば草原と森等を入れる場合、隣り合ったマップチップ同士が繋がるようにしなければつなぎ合わせた結果、変な画像を生み出すこととなってしまう。図1.画像の取り込みのソースコード buffer 1,96,32;数値は順番に割振り番号、横のサイズ、縦のサイズとなっている。 picload " img¥¥maptip.bmp"";前の行で作成した buffer に指定した画像を取り込ませる buffer 2,72,128 picload "img¥¥syujinko.bmp" buffer 5,72,128 picload "img¥¥chartip.bmp" buffer 3,300,110 picload "img¥¥warp.bmp"

(9)

9 その為、マップチップの繋がり、特に辺には注意する必要がある。第４節ドット絵画像の色が付けられる最小単位のブロック、極力少ない色の種類でドット（ピクセル）単位から作成したグラフィックのことである。２色と特定のパターンで組み合わせることで人間の目では多数の色を用いているように見せかけさせるグラデーション等をはじめとして小さな画像から、様々な表現技法が使われている(図 3) 。1980 年代でのゲームの表現方法では、コンピュータのスペックの問題から限りある色の種類でどれほど精巧なグラフィックを表すかが一つの指標となっていた。現在では DirectX 等の最新技術によりコンシュマーゲーム内では廃れつつあるものの、その技巧と芸術性の高さから今でも盛んに使われている。またデジタルカメラで撮った写真等もこのドット絵に含まれているように思えるが、描画の経緯の違いを主な理由として含まれていない。なお、ドット絵の定義は人によって細かな認識の違いがある事ため、この項目で説明していることは一つの見方であることに注意する[4]。図2.ゲーム処理上でマップチップの１枚ごとの範囲マップチップ画像 _{通常の画像}

(10)

10 第５節レイヤー構造技術レイヤー構造技術とは透明色を使用していない画像を下地に使い、そこからさらに透明色を使用した画像をかぶせ、一つの絵として表す技術である。この技術を用いてレイヤー技術が使われていなかった場合、もし誤って下地に変な絵を書き込んで保存してしまったとすると、下地と重なった部分の絵の情報、色、形等は消えてしまう、つまり修正にさらに手間をかけてしまうことになる。しかしレイヤー技術を用いれば、その下地の情報が消えず、手直しも楽に行えるようになる。半透明のフィルムに描かれた数枚の絵を重なり合わせて一つの絵として見せているイメージである。この技術は重ね合わせる画像編集で特に用いられている。

第４章

作成物の詳細

第１節フィールド描画前節で取り込んだマップチップはそのままでは何も起こさない。キャラクタを動かすフィールドの座標は20x20 に設定している。座標は編集やテストプレイ時に実際のゲーム画面と配列を比較しやすくする為にテキストファイルを用意してそこに座標の変数の値を作成し、HSP に取り込む形をとっている（図 4 にソースコードを表示）。なお、今回画像を作成するにあたって、予め必要な画像はある程度種類別に区切りでひとつの画像としてまとめ上げている。そして変数によって纏め上げた画像の特定の範囲をゲームのプログラム上で切り抜き、マップチップ画像として使用している。取り込んだ座標はそれぞれに取り込んだ変数を対応したマップチップに反映させて、ゲーム画面に出力するように設定している(図 5)。また、後述のワープイベント用に別途自動的に絵柄が変化し続ける地面を作成した。前述の方法では同じ座標には同じ画像を貼り付けていたが、今回では同じ場所に連続して異なる画像を貼り付け続けている。これにより画像に動きのある表現を作り出すことができる。方法としては、予めアニメーション用の変数を作成する。次にその変数を加算し続け、一定の値になったら0 に戻す処理を繰り返し行わせる。最後に、取り込んだ画像を指定し、変数から切り取る範囲を決めて、表示する座標に画像を貼り付ける。このように行うこと図3.ドット絵拡大

(11)

11 でパラパラ漫画のように自動的にアニメーションを行うことができる（図6）。第２節表示範囲の設定 RPG は広大なマップによりゲームが成り立つ事が一般的である。しかし、大きなマップ図6.ワープ地点の描画アニメーションとソースコード *teni if a = 6 : a = 0 a++ gcopy 3,a*32,0,32,32;特定の範囲を切り取り貼り付ける。 return 図5.マップチップと変数の切り抜き変数が 0 ならこの範囲を抜き取ってのようなマップチップとして加工する。繰り返す事で上のように表示できる図4.フィールド描画のソースコード dim map,20,20 notesel buf

noteload "map.txt",1200;map.txt の内容を buf に読み込む 1200byte まで取り込み可能 repeat 20

noteget row,i //buf の i 行目のデータを row に代入する repeat 20 getstr tip,row,index,',' index += strsize map(cnt,i) = int(tip) loop i++ index = 0

(12)

12 を一回で全て表示するわけにはいかない。ゲーム画面が使用しているモニターで表示できるサイズをはみ出てしまうことが有り得るからである。たとえ無理にマップ全体をモニターに収まるように縮小したとしても、操作しているキャラクタがどこにいるのか把握しづらくなったり、何が表示されているかが見づらくなったりと遊ぶことに不便が出てくる。それどころか、これからの話の展開やゲームのギミックがわかってしまい、最悪ゲーム性を損なう危険性がある。これらを解決する方法として特定の座標を基点とし、その周囲のマップをモニターにある収まる程度表示することが最も良い解決策である。（図7）ここでの問題点は、ゲーム画面がMAP の端の座標からはみ出た場合である。表示する画面を固定しない場合ではHSP だと本来読み込めない座標を読み込もうとしてしまい、その結果ゲームが止まってしまう致命的なバグがおきてしまう。このエラーの解消法として、マップチップの描画の際に座標の四辺にあたる変数をコピーし、その外の存在しない座標に架空の座標として見立てて貼り付ける。こうすることで座標の外側にあたる本来存在しない座標に画像を補完することができ、結果としてバグを起こらないようにすることができる。その性質上、これだけでは外枠側の画像はどうしても複雑な組み合わせの背景を作成することはできないので注意が必要である。また、座標そのものも使われているわけではないので、ここで補完したマップチップの方向へ操作するキャラクタを移動させてしまうとエラーがおきてしまう。この解消法としては前もって別のマップを用意してワープさせるか、侵入できないようにプログラムする必要がある。今回は後者を採用している。（図 8。なお、ソースコードは図 9 記述している。図7.面と、一定のマップで表示した場合一つのマップを全画面表示した場合操作キャラの周囲を表示した場合

(13)

13 第３節 HSP の透明色の設定前章でレイヤー構造技術について解説したが、使用している画像は透明色が存在しない｡ *lord_map gmode 0,132 map_x = 0 :map_y = 0 repeat 11 j = cnt+my_y-5 if j<0 : j=0 if j>19 : j=19 repeat 11 i = cnt+my_x-5 if i<0: i=0 if i>19: i=19 pos map_x-walk*walk_x*8,map_y-walk*walk_y*8 if map(i,j) < 6 : gcopy 1,map(i,j)*32,0,32,32

if map(i,j) = 7 : gosub *teni map_x += 32 loop map_x = 0 : map_y += 32 loop return 図9 ソースコード図8.外の描画のフォロー内側の座標をコピーして、外側の画像へ貼り付けるように設定している。

(14)

14 つまり、このままの状態でレイヤーを使っても下地となった画像は被せた画像に全て塗りつぶされてしまう。これではせっかく作った下地が無駄になってしまうことになる。例えるなら、一枚の絵の上に白紙を覆いかぶせる様なものである。これを解決する方法として、 HSP 上で特定のグラフィックを透明にする色を指定する。これにより透明色を使用することができ、下地を塗りつぶすことなくレイヤー技術を利用することができる。ただし、この技術を利用する際にはそのグラフィックを利用する上で使わない色を透明色に設定しなければならない。また、HSP は画像毎に透明色を設定できるので、必ずしもすべての画像が特定の色を透明色にしなくてもよい。キャラクタの描画については、この方法とレイヤー構造技術、透明化とを組み合わせて描画している。これによってキャラクタを固定しマップそのものをずらすことで、キャラクタが移動しているように錯覚させる。この時マップがずれた場合キャラクタの向きを変更することで進行方向にキャラクタが歩くようにアニメーションしている。ただし、操作キャラクタは画面中央に固定されている為に、それ以外の場所に操作キャラクタを描画できない欠点がある。HSP で透明色を設定する際は予め取り込んだ画像を呼び出し、その次の行に透明にする背景色を指定する必要がある(図 10)。第４節操作キャラクタの移動処理まず、マップの中心に操作するキャラクタを配置する変数を設定する。キャラクタを移動する場合は、キーボードのアローキーを入力することで、入力したアローキーの方向に対応してキャラクタの画像の向きを変更しつつ移動する。移動方向の設定にアローキーを選んだ理由としてはキーボードにも矢印として表示している為に視覚的にもわかりやすい為である。なお、この移動が終了されるまでの間はアローキーを再入力しても立ち止ることも、移動方向が変更されることもない。ただしアローキーを２種類同時に入力した場合は、どの方向も移動せず立ち止まったままとなる。第５節に表示している図11 にこの時作成したソースコードを記述している。第５節衝突判定による進入禁止 RPG ゲームには壁や登場人物などの障害物が必ず存在する。しかしマップチップそのも図10.透明色の設定前と設定後赤色を透明色として設定すると必要の無い赤色の部分が透ける。人物の外部から枠内までの赤色が下地を塗り潰してしまっているが。

(15)

15 のにはそれらの障害物を認識させる機能は存在しない。このままでは壁を通り過ぎてしまい、地面に描いた絵のようなものとなってしまう。このことによって、今回は衝突判定、俗に言う当たり判定をプログラミングすることにする。具体的な内容としては、キャラクタが別の座標へと移動処理を、もし移動先に湖や岩で表現した背景を使用した座標に入り込もうとした場合、移動入力から移動処理開始までの間に移動先用の変数を移動前の状態に戻す。このようにすることで、障害物にぶつかって動けないような状態にする事ができる。この際に利用する変数は、マップチップの背景の配置に用いた変数とまったく同じものを使用している。これは背景のこの方法を用いれば進入可能かどうかを第１節で作成したテキストファイルで確認することができ、新たな変数を作成する必要がなくなるので容量の節約にもなる。なお応用として変数の値を新たに追加することで、同じマップチップを用いても、座標の衝突判定の有無が異なる変数を持たせることもできる。例えば、見えない壁を演出する場合はこの技術を使用することができる。今回このゲームの作成において使用したケースは後の節で説明する。(図 11 にソースコードを表示) *move stick key,31 ;キーボード入力時に値が変化する変数を作成する。 if walk = 0 { ;入力可能受付 wdx = 0 :wdy = 0 if key = 1: walk_x-- ;左移動 if key = 2: walk_y-- ;上移動 if key = 4: walk_x++ ;右移動 if key = 8: walk_y++ ;下移動 if (walk_x ! 0) | (walk_y ! 0){ walk = 1;入力受付を禁止する。 edir = logf(key)/logf(2) ;移動方向に合わせてキャラの向きを変える x = my_x+walk_x : y = my_y+walk_y ;移動先の座標を作成する。 if (x < 1) | (x > 19) : walk = 0 :walk=_x = 0 ;座標外は移動しない if (y < 1) | (y > 19) : walk = 0 :walk=_y = 0

if (map(x,y) >3) && (map(x,y) <7):walk = 0 : walk_x=0: walk_y=0;移動先が障害物扱いの座標であれば移動しない

if x=cha_x && y=cha_y:walk_x = 0:walk_y = 0; }

} return

(16)

16

第６節操作キャラクタ以外のキャラクタの配置。

キャラクタの手動によって移動が行われるように設定されているが、自働で動く別キャラクタ、通称NPC(Non Player Character)を作成する。これは移動に行う変数をキーボード入力ではなくランダムに変更する事で、プレイヤーが操作しないキャラクタを作成することができる。ランダムで変数を変化させることによって、左右上下に自動的に方向が変わるように設定している。基本的なプログラムの構成は前述の図とほとんど同じである。また、この手法の応用としては変数も新たに構成する必要がある。また、変数もそれぞれ数列に変更する事で同じプログラムで数列の数だけ個別のキャラクタをランダムに動かすことができるようになる。さらに個別に移動できる範囲を設定することができるので、NPC のみが移動できる場所等を設定することができる。第７節移動処理中の操作キャラクタの描画方法操作するキャラクタの描画には、移動中にキャラクタを歩かせるように３枚の画像を繰り返し表示することで歩いているようにみせることができる。画像はゲームと同フォルダ内に存在する画像charatip.bmp を仮想上で縦に４分割、横に３分割したものを使用している。縦に分けた場合はキャラクタの左に移動、上に移動、右に移動、下に移動に対応している。そして、横にわけた場合は歩く表現を出すために、１番目に右足を前に出した様子、２番目に直立した様子、最後に左足を前に出した様子をそれぞれ表している。これを１番目、２番目、３番目、２番目のローテーションを行うことで、歩いているようなアニメーションを演出している（図12）。左下の座標に入った場合、強制的にマップを移動する方法としては、現在の操作するキャラクタに用いた座標を、離れた数値に書き換えることで、あたかも別の座標へ突然ワープしたかのようにみせることができる。記入はif 関数での移動処理が終了した時点で x 座標とy 座標がそれぞれ指定した値になっている時、そのそれぞれの座標を片方、あるいは両方書き換えることで、瞬時に座標を切り替えることができる。その時、描画も同時に座標にあわせるので、視覚上では実際にワープしたように見える（図13）。左上の座標に入った場合、壁をすり抜けて、強制的に右へ座標５つ分強制的に移動するように作成した。この時、進入不可の座標もすりぬけるようになっているが、それはその間に進入不可の座標に侵入しようとした際に変数を切り替える処理がこの間に挟まれていないためである。記入した内容としては、移動目標の座標に右に移動するように数値を与えている。なお、強制的に移動させている間はプレイヤーがキャラクタを操作できないようにする（図14）。このデータに作成したソースコードは図 15 に表示する。

(17)

17 図14.強制移動についての表示ここから上の座標へ移動すると強制的に右側に移動していく、この間操作不能同時に普通では通れない壁がすりぬけられる。図13.ワープについての表示左下の赤いワープゾーンに入ると指定した座標に瞬間的に移動する。例：左方向へ移動する場合上のサイクルで画像を変化させる。図12.操作キャラクタの描画。

(18)

18 第８節メッセージボックスの表示スペースキーを入力することによってメッセージボックスが表示されるようにした(図 16)。メッセージボックスが表示されている間はそのメッセージボックス用のプログラムの内部で無限ループを起こすようにしており、結果としてメッセージボックスの描画を消さない限り他の操作ができないようになっている。メッセージボックスの描画を中止するには再びスペースキーを押すことで、その無限ループから脱出することができる。図16.メッセージボックスの表示図15.移動処理中のソースコード *draw_chara gmode 4,24,32,256;キャラクタの画像を呼び出す。 color 255,0,0;RGB の順でそれぞれ 0~255 で設定可能、今回は赤色を設定。 pos 164,158

if walk = 0 : gcopy 2,24,(edir * 32),24,32 ; if walk = 1 : gcopy 2,0,(edir * 32),24,32 ; if walk = 2 : gcopy 2,24,(edir * 32),24,32 ; if walk = 3 : gcopy 2,48,(edir * 32),24,32 ; if walk = 4 { gcopy 2,24,(edir * 32),24,32 walk = 0 ;移動終了と同時に入力が可能になる。 my_x += walk_x ;現在の座標を移動後の位置にする my_y += walk_y walk_x = 0 : walk_y = 0

if my_x=1 & my_y=18: my_x=6:my_y=6;左下の角に移動したらワープする。

if my_x=1 & my_y=1: walk_x = 5 :walk=1;操作を無効にし、強制的な移動を行う。

}

if walk:walk++ return

(19)

19

第５章

終わりに

本稿ではRPG ゲームの動作原理を知るために実際に HSP を用いて RPG ゲームを製作した。内容としてはマップチップを利用し大きなマップを作成した。そこに主人公であるキャラクタをドット絵で作成し、ドット絵を数枚の絵を何度も再描画することで動きのあるキャラクタを作成した。また他のキャラクタ（NPC）を作成し、ランダムで行動する事も実現した。これらの技術を応用し、キャラクタが大勢いる町を作成することもできる。もちろんマップ上にてメッセージボックスを表示させることもでき、これによりマップ上で他のキャラクタに話しかける等のアクションを起こすことも可能である。今後の課題として最もRPG で重要であるキャラクタの成長を実装する必要がある。そのために戦闘要素を追加する必要がある。またBGM が一切無いため BGM を作成する等の課題は非常に多い。これらを実装することで初めてRPG となる。現段階ではまだ、迷路ゲームレベルであるため今後の課題は非常に多い。蛇足ではあるが本制作物は２名で共同作成するのが当初の予定であった。しかし、どのようなものを作成しようかでお互いが悩んだ経緯があった。その後は二つに分担して作業を行ったが、互いの能力や知識量の差から進捗報告がうまく伝わらないことも多く、うまく意思疎通をすることが難しく、コミュニケーション能力は非常に重要であると経験させられた。また、予定通りのプログラムを作成したつもりであったとしても、実際に起動テストをエラーや、予定外の動作を起こす事が多々あった。例えば、キャラクタの動きを表現するための座標の移動するプログラムを作成したものは初期段階では、操作するキャラクタを正しい方向に向かうどころか、開始直後からゲームが止まることも珍しくなかった。更に新しく作成したプログラムが、過去に作成したプログラムにバグがあり結果にエラーが起きてしまい、ゲームが不正落ちしたことも多々あった。このゲーム制作にて経験した、または感じた事はバグがないゲームやプログラム（システム）は作成が非常に困難であり、また存在しない物を作成するということが極めて困難であると実感させられた。

(20)

20 参考文献 [1]おにたま , うすあじ , 悠黒喧史最新 HSP3.2 プログラミング入門 [2] http://www.forest.impress.co.jp/article/2002/01/17/whocreate3.html おにたまさんインタビュー [3]http://www.onionsoft.net/hsp/education/hsp3start.ppt HSP プログラムガイダンス HSP プログラミング入門 [4]http://sky.geocities.jp/r_sotton/lecture/lecture07.htm ドット絵 [5]http://homepage3.nifty.com/mmgames/column/rpg.html RPG の歴史 [6]http://www.trpg.net/WhatisTRPG.html TRPG って何? [7]スプリクト言語システム HSP3.0:「onion software」 http://hsp.tv/idman/download.html 謝辞この場を借りてこの制作において今回のRPG 制作「RPG Tester（仮名）」の製作に関わった全ての方に感謝の言葉を申し上げます。ドット絵製作を主に協力をいただいた楠原拓磨氏に感謝の言葉を申し上げます。この卒論の校閲のアドバイスをいただいた、尾花将輝氏に感謝の言葉を申し上げます。HSP を作られた「onion software」/おにたま氏に感謝を申し上げます。これまでの製作において私は数多くの人々の協力がなければこの論文や製作物を一つの形として完成させることができませんでした。重ねて感謝の言葉を申し上げます。最後に、数多くの助言を贈ってくださった花川典子教授に感謝の言葉を申し上げます。本当に有難う御座いました。