HSP を利用した RPG - Hannan University
20
1 ゲームプログラミング HSP を利用した RPG の作成 経営情報学部経営情報学科情報システムコース 竹元 学 5106158
Transcript of HSP を利用した RPG - Hannan University
1
ゲームプログラミング HSPを利用した RPGの作成
経営情報学部経営情報学科情報システムコース 竹元 学 5106158
2
目次
第１章 はじめに......................................................................3
第２章 関連研究......................................................................4 第１節 テーブル RPGとは................................................................. 4
第２節 コンピュータ RPGとは.......................................................... 4
第３節 RPGの歴史 ............................................................................ 5
第４節 日本における RPGの歴史 ...................................................... 5
第５節 Hot Soup Processor（HSP）とは.......................................... 6
第３章 作成物の詳細と利用技術.............................................7 第１節 作成物の紹介 .......................................................................... 7
第２節 画像の取り込み....................................................................... 7
第３節 マップチップ .......................................................................... 8
第４節 ドット絵 ................................................................................. 9
第５節 レイヤー構造技術 ................................................................. 10
第４章 作成物の詳細 ............................................................10 第１節 フィールド描画..................................................................... 10
第２節 表示範囲の設定..................................................................... 12
第３節 HSPの透明色の設定 ............................................................ 13
第４節 操作キャラクタの移動処理................................................... 14
第５節 衝突判定による進入禁止 ...................................................... 14
第６節 操作キャラクタ以外のキャラクタの配置。.......................... 16
第７節 移動処理中の操作キャラクタの描画方法 ............................. 16
第８節 メッセージボックスの表示................................................... 18
第５章 終わりに....................................................................19 まとめ 参考文献 謝辞
3
第１章 はじめに
近年、多くの場所でゲーム機にて遊んでいる人たちを目にする。家庭内で行うビデオゲ
ームだけではなく、電車の中で行うことができる携帯ゲーム機、またパソコンを用いたコ
ンピュータゲーム等、様々なゲームが世に存在する。私自身もゲーム、特に家庭用ゲーム
が好きであり、現在もよく行っている。しかし何気に行っているゲームであるが、実際ど
のように動作しているかはよくわからない。つまり、中身がどのように動作してゲームが
成り立っているかよくわからないブラックボックス状態である。そこで、プログラム言語
Hot Soup Processor(以下 HSP)を用いた自作によるコンピュータゲームの作成を行う。これによりゲームを作成する際のプログラムの基本構造を理解することを目指す。 今回作成するゲームプログラムはパソコンにて動作するシンプルなRPGゲームを作成する。作成理由とし私自身が好んでプレイするゲームが RPGであるからである。また、ゲームの作成手法を学ぶ際に、ゲーム作成の基礎知識を身につけるには RPGが最も好ましいと言われているからである。理由として、ゲームではポピュラーなジャンルとして、また他
の教材等からよくサンプル作品の筆頭に出されていたからである[1]。 続いて、プログラミング言語に HSPを選択した理由を述べる。私自身ゲームをプレイする事はあっても作成する事は全くなかった。つまりプログラムに関する知識や技術はほと
んど持ってはいない。そこでプログラム言語の選択には文法が簡潔なものを選択する必要
があった。このようなプログラミング言語があるのかを探すと HSPが向いているとの結論に至った。理由として、全体的に初心者向けという特徴があり、数多くの参考書が売られ
ているからである。何よりゲーム作成に向いていたのがという特徴から Hot Soup Processor(以下 HSP)を選択した。また RPGを作成する点からも HSPにて RPGの作成が盛んに行われており、参考資料や参考ソースプログラムが多く存在するからである。HSPの詳細については第２章関連研究の第５節で解説する。 作成するゲームの内容として背景は初期段階では作成せず、キャラクタ等の細かなグラ
フィックと基本的な動作を作成する。理由として本テーマは世に販売されているような
RPGの作成を目的とせず、RPGゲームの動作する基本構造について理解する為である。つまりRPGと密接な関係のあるストーリー性に関しては今回保留とし基本構造を理解することを最優先とする。これはストーリーとは RPGのプログラム観点から見て、ストーリーは後付け、つまりプログラム観点から言えばおまけみたいなものだからである。基本的なキ
ャラクタと動作が完成後は、「迷いの道に入り込んだ戦士の脱出劇」という短編のシナリオ
を後付けの形で作成した。ゲーム作成技術を学ぶ上では基盤を作成することが重要なので、
コンパクトサイズのプログラムを作成することができれば、その同じシステムを繰り返し
用いることで長編のシナリオも作成ができるからだ。 本稿は２章では関連研究を述べ、３章では実際に作成したプログラムの紹介を述べ、４
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
ャンルのゲームでは敵の攻撃パターンを読むなどプレイヤーの操作が求められる事が多く、
操作が得意でないプレイヤーでは、どうしても先に進めなくなってしまうことが多い。し
かし、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
外では当時誰でも扱える訳ではなかったパソコンで遊ぶ大人のプレイヤーが多かったこと
に対し、日本では手軽に扱えるファミリーコンピュータで子供を中心に遊ぶ事が多いとい
う異なる条件で 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
年に非営利団体 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
る番号を記入する。そして縦のサイズと横のサイズをそれぞれ記入する。この時、指定し
たサイズが保存する画像より小さいと、画像を取り込むことができない。逆に画像より大
きい場合は全ての画像を取り込むことができるのだが、代わりに本来画像が無い部分まで
もあるように扱ってしまい、結果として余分に容量を使ってしまうことになる。イメージ
で言えば、パソコンの画像を無圧縮のまま、印刷用紙に出力する感じである。（ソースコー
ドは図１で表示） なお、この方法 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
その為、マップチップの繋がり、特に辺には注意する必要がある。
第４節 ドット絵
画像の色が付けられる最小単位のブロック、極力少ない色の種類でドット（ピクセル）
単位から作成したグラフィックのことである。２色と特定のパターンで組み合わせること
で人間の目では多数の色を用いているように見せかけさせるグラデーション等をはじめと
して小さな画像から、様々な表現技法が使われている(図 3) 。1980年代でのゲームの表現方法では、コンピュータのスペックの問題から限りある色の種類でどれほど精巧なグラフ
ィックを表すかが一つの指標となっていた。現在では DirectX 等の最新技術によりコンシュマーゲーム内では廃れつつあるものの、その技巧と芸術性の高さから今でも盛んに使わ
れている。またデジタルカメラで撮った写真等もこのドット絵に含まれているように思え
るが、描画の経緯の違いを主な理由として含まれていない。なお、ドット絵の定義は人に
よって細かな認識の違いがある事ため、この項目で説明していることは一つの見方である
ことに注意する[4]。
図 2.ゲーム処理上でマップチップの１枚ごとの範囲
マップチップ画像 通常の画像
10
第５節 レイヤー構造技術
レイヤー構造技術とは透明色を使用していない画像を下地に使い、そこからさらに透明
色を使用した画像をかぶせ、一つの絵として表す技術である。この技術を用いてレイヤー
技術が使われていなかった場合、もし誤って下地に変な絵を書き込んで保存してしまった
とすると、下地と重なった部分の絵の情報、色、形等は消えてしまう、つまり修正にさら
に手間をかけてしまうことになる。しかしレイヤー技術を用いれば、その下地の情報が消
えず、手直しも楽に行えるようになる。半透明のフィルムに描かれた数枚の絵を重なり合
わせて一つの絵として見せているイメージである。この技術は重ね合わせる画像編集で特
に用いられている。
第４章 作成物の詳細
第１節 フィールド描画
前節で取り込んだマップチップはそのままでは何も起こさない。キャラクタを動かすフ
ィールドの座標は 20x20 に設定している。座標は編集やテストプレイ時に実際のゲーム画面と配列を比較しやすくする為にテキストファイルを用意してそこに座標の変数の値を作
成し、HSPに取り込む形をとっている（図 4にソースコードを表示）。 なお、今回画像を作成するにあたって、予め必要な画像はある程度種類別に区切りでひ
とつの画像としてまとめ上げている。そして変数によって纏め上げた画像の特定の範囲を
ゲームのプログラム上で切り抜き、マップチップ画像として使用している。取り込んだ座
標はそれぞれに取り込んだ変数を対応したマップチップに反映させて、ゲーム画面に出力
するように設定している(図 5)。 また、後述のワープイベント用に別途自動的に絵柄が変化し続ける地面を作成した。前
述の方法では同じ座標には同じ画像を貼り付けていたが、今回では同じ場所に連続して異
なる画像を貼り付け続けている。これにより画像に動きのある表現を作り出すことができ
る。方法としては、予めアニメーション用の変数を作成する。次にその変数を加算し続け、
一定の値になったら 0に戻す処理を繰り返し行わせる。最後に、取り込んだ画像を指定し、変数から切り取る範囲を決めて、表示する座標に画像を貼り付ける。このように行うこと
図 3.ドット絵
拡大
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
を一回で全て表示するわけにはいかない。ゲーム画面が使用しているモニターで表示でき
るサイズをはみ出てしまうことが有り得るからである。たとえ無理にマップ全体をモニタ
ーに収まるように縮小したとしても、操作しているキャラクタがどこにいるのか把握しづ
らくなったり、何が表示されているかが見づらくなったりと遊ぶことに不便が出てくる。
それどころか、これからの話の展開やゲームのギミックがわかってしまい、最悪ゲーム性
を損なう危険性がある。これらを解決する方法として特定の座標を基点とし、その周囲の
マップをモニターにある収まる程度表示することが最も良い解決策である。（図 7） ここでの問題点は、ゲーム画面がMAPの端の座標からはみ出た場合である。表示する画面を固定しない場合では HSPだと本来読み込めない座標を読み込もうとしてしまい、その結果ゲームが止まってしまう致命的なバグがおきてしまう。このエラーの解消法として、
マップチップの描画の際に座標の四辺にあたる変数をコピーし、その外の存在しない座標
に架空の座標として見立てて貼り付ける。こうすることで座標の外側にあたる本来存在し
ない座標に画像を補完することができ、結果としてバグを起こらないようにすることがで
きる。その性質上、これだけでは外枠側の画像はどうしても複雑な組み合わせの背景を作
成することはできないので注意が必要である。また、座標そのものも使われているわけで
はないので、ここで補完したマップチップの方向へ操作するキャラクタを移動させてしま
うとエラーがおきてしまう。この解消法としては前もって別のマップを用意してワープさ
せるか、侵入できないようにプログラムする必要がある。今回は後者を採用している。（図
8。なお、ソースコードは図 9記述している。
図 7.面と、一定のマップで表示した場合
一つのマップを全画面表示した場合 操作キャラの周囲を表示した場合
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
つまり、このままの状態でレイヤーを使っても下地となった画像は被せた画像に全て塗り
つぶされてしまう。これではせっかく作った下地が無駄になってしまうことになる。例え
るなら、一枚の絵の上に白紙を覆いかぶせる様なものである。これを解決する方法として、
HSP 上で特定のグラフィックを透明にする色を指定する。これにより透明色を使用することができ、下地を塗りつぶすことなくレイヤー技術を利用することができる。ただし、こ
の技術を利用する際にはそのグラフィックを利用する上で使わない色を透明色に設定しな
ければならない。また、HSP は画像毎に透明色を設定できるので、必ずしもすべての画像が特定の色を透明色にしなくてもよい。 キャラクタの描画については、この方法とレイヤー構造技術、透明化とを組み合わせて
描画している。これによってキャラクタを固定しマップそのものをずらすことで、キャラ
クタが移動しているように錯覚させる。この時マップがずれた場合キャラクタの向きを変
更することで進行方向にキャラクタが歩くようにアニメーションしている。ただし、操作
キャラクタは画面中央に固定されている為に、それ以外の場所に操作キャラクタを描画で
きない欠点がある。HSP で透明色を設定する際は予め取り込んだ画像を呼び出し、その次の行に透明にする背景色を指定する必要がある(図 10)。
第４節 操作キャラクタの移動処理
まず、マップの中心に操作するキャラクタを配置する変数を設定する。キャラクタを移
動する場合は、キーボードのアローキーを入力することで、入力したアローキーの方向に
対応してキャラクタの画像の向きを変更しつつ移動する。移動方向の設定にアローキーを
選んだ理由としてはキーボードにも矢印として表示している為に視覚的にもわかりやすい
為である。なお、この移動が終了されるまでの間はアローキーを再入力しても立ち止るこ
とも、移動方向が変更されることもない。ただしアローキーを２種類同時に入力した場合
は、どの方向も移動せず立ち止まったままとなる。第５節に表示している図 11にこの時作成したソースコードを記述している。
第５節 衝突判定による進入禁止
RPG ゲームには壁や登場人物などの障害物が必ず存在する。しかしマップチップそのも
図 10.透明色の設定前と設定後
赤色を透明色として
設定すると必要の無
い赤色の部分が透け
る。
人物の外部から枠内
までの赤色が下地を
塗り潰してしまって
いるが。
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
図 11.キャラクタ移動に関するソースコード
16
第６節 操作キャラクタ以外のキャラクタの配置。
キャラクタの手動によって移動が行われるように設定されているが、自働で動く別キャ
ラクタ、通称 NPC(Non Player Character)を作成する。これは移動に行う変数をキーボード入力ではなくランダムに変更する事で、プレイヤーが操作しないキャラクタを作成する
ことができる。ランダムで変数を変化させることによって、左右上下に自動的に方向が変
わるように設定している。基本的なプログラムの構成は前述の図とほとんど同じである。
また、この手法の応用としては変数も新たに構成する必要がある。また、変数もそれぞれ
数列に変更する事で同じプログラムで数列の数だけ個別のキャラクタをランダムに動かす
ことができるようになる。さらに個別に移動できる範囲を設定することができるので、NPCのみが移動できる場所等を設定することができる。
第７節 移動処理中の操作キャラクタの描画方法
操作するキャラクタの描画には、移動中にキャラクタを歩かせるように３枚の画像を繰
り返し表示することで歩いているようにみせることができる。画像はゲームと同フォルダ
内に存在する画像 charatip.bmpを仮想上で縦に４分割、横に３分割したものを使用している。縦に分けた場合はキャラクタの左に移動、上に移動、右に移動、下に移動に対応して
いる。そして、横にわけた場合は歩く表現を出すために、１番目に右足を前に出した様子、
２番目に直立した様子、最後に左足を前に出した様子をそれぞれ表している。これを１番
目、２番目、３番目、２番目のローテーションを行うことで、歩いているようなアニメー
ションを演出している（図 12）。 左下の座標に入った場合、強制的にマップを移動する方法としては、現在の操作するキ
ャラクタに用いた座標を、離れた数値に書き換えることで、あたかも別の座標へ突然ワー
プしたかのようにみせることができる。記入は if関数での移動処理が終了した時点で x座標と y座標がそれぞれ指定した値になっている時、そのそれぞれの座標を片方、あるいは両方書き換えることで、瞬時に座標を切り替えることができる。その時、描画も同時に座
標にあわせるので、視覚上では実際にワープしたように見える（図 13）。 左上の座標に入った場合、壁をすり抜けて、強制的に右へ座標５つ分強制的に移動する
ように作成した。この時、進入不可の座標もすりぬけるようになっているが、それはその
間に進入不可の座標に侵入しようとした際に変数を切り替える処理がこの間に挟まれてい
ないためである。記入した内容としては、移動目標の座標に右に移動するように数値を与
えている。なお、強制的に移動させている間はプレイヤーがキャラクタを操作できないよ
うにする（図 14）。このデータに作成したソースコードは図 15に表示する。
17
図 14.強制移動についての表示
ここから上の座標へ移動すると 強制的に右側に移動していく、この間操作不能 同時に普通では通れない壁がすりぬけられる。
図 13.ワープについての表示 左下の赤いワープゾーンに入ると 指定した座標に瞬間的に移動する。
例：左方向へ移動する場合 上のサイクルで画像を変化させる。
図 12.操作キャラクタの描画。
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
第５章 終わりに
本稿ではRPGゲームの動作原理を知るために実際にHSPを用いてRPGゲームを製作した。内容としてはマップチップを利用し大きなマップを作成した。そこに主人公であるキ
ャラクタをドット絵で作成し、ドット絵を数枚の絵を何度も再描画することで動きのある
キャラクタを作成した。また他のキャラクタ（NPC）を作成し、ランダムで行動する事も実現した。これらの技術を応用し、キャラクタが大勢いる町を作成することもできる。も
ちろんマップ上にてメッセージボックスを表示させることもでき、これによりマップ上で
他のキャラクタに話しかける等のアクションを起こすことも可能である。 今後の課題として最も RPGで重要であるキャラクタの成長を実装する必要がある。その
ために戦闘要素を追加する必要がある。また BGMが一切無いため BGMを作成する等の課題は非常に多い。これらを実装することで初めて RPGとなる。現段階ではまだ、迷路ゲームレベルであるため今後の課題は非常に多い。 蛇足ではあるが本制作物は２名で共同作成するのが当初の予定であった。しかし、どの
ようなものを作成しようかでお互いが悩んだ経緯があった。その後は二つに分担して作業
を行ったが、互いの能力や知識量の差から進捗報告がうまく伝わらないことも多く、うま
く意思疎通をすることが難しく、コミュニケーション能力は非常に重要であると経験させ
られた。 また、予定通りのプログラムを作成したつもりであったとしても、実際に起動テストを
エラーや、予定外の動作を起こす事が多々あった。例えば、キャラクタの動きを表現する
ための座標の移動するプログラムを作成したものは初期段階では、操作するキャラクタを
正しい方向に向かうどころか、開始直後からゲームが止まることも珍しくなかった。更に
新しく作成したプログラムが、過去に作成したプログラムにバグがあり結果にエラーが起
きてしまい、ゲームが不正落ちしたことも多々あった。このゲーム制作にて経験した、ま
たは感じた事はバグがないゲームやプログラム（システム）は作成が非常に困難であり、
また存在しない物を作成するということが極めて困難であると実感させられた。
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」/おにたま氏に感謝を申し上げます。これまでの製作において私は数多くの人々の協力がなければこの論文や製
作物を一つの形として完成させることができませんでした。重ねて感謝の言葉を申し上げ
ます。最後に、数多くの助言を贈ってくださった花川 典子教授に感謝の言葉を申し上げます。本当に有難う御座いました。
