進捗状況

だから、公開もしていないプログラミングのネタを書いてどーするんだと…一人つっこみ

この土日にちょっといじりました。

昨日書いたアルゴリズムの実装。

意外に楽でしたね。
そのアルゴリズムに自力で到達することはありえなさそうですが、アルゴリズムさえ教えてもらえれば、プログラミングするのは楽だった。

というか、Delphiのソースが載ってるから、なんとなく読み取って、C++似のSystem4に変換するだけのことだし。

デバッグでちょっとだけバグでましたけどね。


１．射程3にしたらこんな形になったorz

			□
		□	□	□
	□	□	□	□	□
		□	○	□
	□	□	□	□	□
		□	□	□
			□

原因は、「一度到達したマスであったら、そこから思考するのは無意味なので思考停止」という条件文
つまり、下の図の矢印の順で思考したために、改めてスタート地点から横に伸ばそうとしたとき、「あ、ココはチェック済みだからもう伸ばさなくていいね」という思考をしてしまっていたせい。

			□
		□	□	□
	□	←	↑	□	□
		↓	○	□
	□	□	□	□	□
		□	□	□
			□

だから、「チェック済みなら思考停止」ではなく、「既に最短距離で到達しているなら思考停止」にした。
上の例の場合、左のマスに矢印ルートでは３マスかかってる。すぐに横に行こうとしたら１マスで到達している。だから、思考継続となる。
そうすることで、ダイヤ型の範囲表示ができるようになった。



２．４マス以上の射程にすると、現在地(中心・射程０)も射程内に入ってしまう…orz
これは、

←	↑
↓	→

という感じで元の位置も探索対称になってしまっているため。
これは綺麗な解決の仕方思いつかなかったので、思考全て終了後に、現在地を除外するという命令追加で回避した。
現在地は対象にしないという条件追加するよりも、後で取り除いた方が楽だと思うからね。


んで、ちょっと画面表示の画像処理ルーチンも変更して、ままにょにょであるように、その射程内にマウスのポインタもって行ったらそのマスの色が変わるようにした。

さて、いよいよ攻撃の実装だろうか。
射程内でのクリックを読み取り、そのマスに敵がいるかどうかを判別して、いたら攻撃処理。いなければ無視。
射程外をクリックしても無視。
右クリックで攻撃選択モードキャンセルは実装済み。

後、音の実装もしないと。
多少音楽の知識はあるが、作曲は知識やらセンスとかないので、フリーの音楽拾ってくるか、アリスソフトの素材(ランスシリーズの曲そのまんまｗ)を使うかだな。
効果音も拾ってくるしかない。
ま、自分でそういうサイト探すの案外大変だけど、某同人ゲームが使っている素材やさんリストから、気に入ったサイトさんのを利用させてもらうとしようｗ

しかし、開発に時間かかってるな～ｗ

３月にまとめて時間取れたら一気に進むんだろうか？？
それとも、時間取れてもゲーム作る方じゃなく、遊ぶ方に没頭するかな…ｗ
それとも、そもそもそんな時間取れないか…

ま、ここ忙しい中で久しぶりにのんびりした土日でしたよと。

移動のアルゴリズム

普通、SRPGであれば、移動のアルゴリズムが一つの壁だと思っています。
(もちろんプログラミング初心者って前提ですよｗ　ゲームプログラマにしてみりゃ、それがどうしたってレベルでしょうからｗ)

今回のMDでは、そのところは問題ありません。

何故かというと、特異な移動方法を採用しているから。


普通、SRPGでの移動というと、歩ける歩数が3とか4とか設定されていて、
地形で1歩で進める平原や2歩必要な荒地、3歩必要な山とかそんな設定がされていて、
キャラクターをクリックしたら、地形の必要歩数を考慮して移動可能なエリアが表示されて、移動したいところをクリックしたら、そこにテコテコと歩いていく、というものです。

ま、この地形や歩数に関係するところや、テコテコと移動する過程を表示する場合は、どの経路で歩くのかのアルゴリズムがちょっと難しいわけです。


しかし、私のMDでは、そんなことは一切関係ありません。
特殊な移動方法なためなんですね。

普通は、先ほど行ったように、ターンが回って自分の番になると、決められた歩数だけ歩けます。

MDでは、それが一歩に限定されています。

一歩しか歩かないんだから、上下左右に一歩動くだけ。
地形ごとに何歩必要とかいうアルゴリズムは一切関係なし。単純です。

また、移動できるのは前進後退のみ。横には進めません。
横に進むには、旋回を必要とします。

つまりこんな感じ。

	左旋回
	↑
後退←	○	→前進
	↓
	右旋回

左旋回したら

	前進
	↑
左旋回←	○	→右旋回
	↓
	後退

こうなる。

1ターンに行動できるのは、
攻撃か、前進か、後退か、旋回かどれか一つのみ。
移動してから攻撃、なんてことはできません。

後ろ向くには2ターンかけて旋回する必要あり。

こんな感じです。


また、攻撃に関しては、人間をユニットとした場合、方向性を持たせるのであれば、正面側にしか攻撃できません。
もし、方向転換にコストがかかるシステムであれば、自由に攻撃はできないということになります。
ま、普通のゲームは、方向転換にコストはかからないですよね。
移動先でも、どっちに向いて終了ってのを選べたりするのもあるぐらいです。


MDでは、移動の方向転換にコストを持たせています。進む、戻ると同じコストが、方向転換にもかかります。
さて、これで攻撃を前面のみとしたら、なかなかに窮屈なゲームです。
どっちを向くか、というのが非常に重要になってきます。
ま、そういうゲームシステムでも面白いんですが…実際のMDでは、攻撃は全方向にできるようにするつもり。


移動は前と後ろにしかできないけど、攻撃はどの方向にもできる。

なんでこんな方式を採用しようとしているか、というと私の中での戦車イメージのせいです。

戦車って前に進んだり後ろに進んだりは簡単そうだけど、なんか曲がるのって不得意そうに思えません？
実際に戦車が走ってるところ見たことないから、どうやって動くのか知らないんだけど…
なんとなく、前進、後退、その場旋回ってイメージなのよ。
キャタピラを左右逆回転させれば、その場でくるくる回れそうじゃん？
だから、その場旋回。

車みたいにカーブ描けるのかね？
とりあえず、知らんのよ。
だから、自分の固定イメージでシステム組んでる(ぉ
(ま、普通に考えればカーブ描けない車なんて不便極まりないから描けるんだろうな…)


後、ゲームシステムとして、１ターンでポコポコと何歩も移動するのではなく、１ターンにつき、行動1回というシステムを考えたかった。
行動1回というのが、移動なら1歩という考え方。

不思議のダンジョンシリーズがそんな感じだよね。
(ま、大元をたどれば、ローグのような形式というべきか…)
こちらが一歩動いたら、敵も一歩動く。
こちらが攻撃やアイテム使用などの行動を1回したら、敵は一歩動くか、攻撃射程なら攻撃してくる。

そんなのをイメージしています。

実際には、アクティブターンにするつもりなので、戦車のカスタマイズの内容次第で、素早く動ける車両と、鈍い車両が存在します。
だから、鈍い戦車　対　素早い戦車だと、のろい方が1回行動する間にはやい方は2回行動、何てこともありうる。
(もちろん、素早く動ける車両にするためには、攻撃力や防御力を削らないといけない、というところでバランスとるつもり。)

それが一歩ずつしか動けないシステムの理由。


さて、もう一つの、方向転換に1ターンかかるくせに、なんで攻撃は全方向可能なのか…
だって、戦車だもん。

下のキャタピラがどっち向いてようが、上の砲塔はそれとは無関係にぐるぐる回るもんだよね？戦車って…
だから、下の足がどっち向いていようが、攻撃はどの方向にも攻撃可能ということにした。

ん？そんなに車両の旋回にコストかけたいのなら、砲塔の旋回にもコストかけろって？

…面倒臭いから、やだ。

足の向いている方向と、砲塔の向いている方向をそれぞれ別個に管理することになり、システムが複雑化するし、
キャタピラが右向いてて、主砲は上向いてるような沢山のパターンの画像こしらえるのが大変ですから。


ま、MDでの移動のシステムはこんな感じです。

さて、冒頭に述べた、移動のアルゴリズム。
移動にそのアルゴリズム自体は使わないんですが、移動可能領域の表示のアルゴリズムと同じようなアルゴリズムが、攻撃可能領域の表示で必要になってきます。

基本的に、接近攻撃しかなければ、

	□
□	○	□
	□

の範囲です。

2マスなら、

		□
	□	□	□
□	□	○	□	□
	□	□	□
		□

の範囲です。

3マスなら…

パターンが少なければ、個別にそれらの絵を描いた方が早いかもしれません。
けれど、システムとしては、何マスにでも対応可能な一般化したものを作りたいと考えています。
(6×10マスのマップなんで、9が最高かな。)
そうすると、移動の時のようなアルゴリズムを利用することになるんですよね。

日本語で書くと、
手を伸ばせる回数(攻撃距離)をあらかじめ決めておく。
基点から前後左右の4方向に一歩手を伸ばす。(伸ばせる回数-1)
その延ばした先から、伸ばせる回数がまだ残っていればさらに前左右の3方向に手を伸ばす。(伸ばせる回数-1)
更にその延ばした先から…同じ思考を繰り返す。
もし、伸ばせる回数が残っていなければ、そこの思考は終了。

思考がいったん終了したら、他のまだ伸ばし残しているところから、更に伸ばす思考を繰り返す。
すべての手が伸ばしきったら思考はすべて終了。

こんな感じでしょうか。
まー、これを関数で表記しなきゃいけないと。
DelphiやCやHSPなんかでは、この思考を書いてあるプログラムソースもどっかにあるのかもしれませんが、System4.0のものなんてありはしないだろうから、同じアルゴリズムにしたがって、System4.0で書かないといけないんすよね。

昔System3.8だったか、3.9だったかをいじっていた時には、この思考を自動的にやってくれる関数があったようにも思うんだけど、それはSACTとは相容れないものだった気がする。
だから、SACT2で作っている以上、がんばって自作するかな？という感じ。
ま、System3xと4.0じゃ、設計思考が違うそうなので、同じ関数が存在するかってのも疑問なんで、その点からも頼れないんですけどね。

このアルゴリズムが結局のところ、攻撃範囲の表示にとどまらず、敵の思考ルーチンを作るうえでも重要なものになるようなので、しっかりと組まないといけないっす。

このあたりのプログラムを作るときに参考にしているのはこちらのページ

system4.0

まー、前から述べているように、趣味の一つとして、ゲームプログラミングをしています。

ま、CGIゲームの改造も一種のプログラミングですけどね。
とりあえず、今回の話題はオフライン用の方のお話。

それほど趣味のメインとして据えているわけでもないので、開発は極めてのろのろペースです。

その開発ツールとして選択したのが、アリスソフト社製のSystem4.0SDKです。

何故これを選択したのか。

昔、アリスソフトのゲームを買ってきたら、アリスCDというのがおまけについてきました。
この中に、System3x開発キットが入っていたのであります。

まー、昔はHPでも普通に配布していたような気もする。

最初に触れたのは、HPのヤツをDLしたんだったか、アリスCDについていたやつを触ったんだか忘れましたが…

とにかくSystem3x開発キットをいじるようになったんですよ。

昔から、ゲームは大好きで、自分で作ってみたいっていう要求もあったんですよね。
RPGツクールがコンシューマーで発売されたときも、注目はしていました。触りはしませんでしたが…


ま、アドベンチャーゲーム作るなら、他にも開発ツールあるみたいですね。
NScripterとか吉里吉里とかが有名なんでしょうか？
けれど、ADV作りたいわけではないので、こいつらは役に立たないと思います。
(触ったことはないんですがｗ)

RPGならやっぱりツクールが有名か…
でも、なんかツクールはストーリーとかで独自色出すものであって、システム的なところでの独自色は出しにくそうなんだよね…
おいらはストーリーとかは考えられない人なんで、システムで勝負したいんだし…


んで、大きくなって、パソコンいじるようになって、パソコンゲームをやっている流れで、アリスのSystemに触る機会が出てきたと。

それと前後して、独学でCとかC++とかもちょっと勉強しました。

んで、Cを勉強した結果、CやC++で一からゲーム作るのは不可能！！
プロならいざ知らず、シロートが趣味レベルでやれるレベルではありません。

DOSレベルのプログラムなら、ちょっとは組めるかもしれませんが、WindowsのGUIレベルのものを作るだけでどれだけの労力がかかるんだか…

それをゲームへと発展させるとなると…考えたくもありませんｗ

ま、触った本にのっているプログラムがDOSベースのものだったし、コンパイラもフリーのものだったせいもあるのかもしれません。
MicrosoftのVisualシリーズなら、GUIのもの、作りやすいのかもしれませんが…
投資する気はなしと…ｗ

さて、Windowsのプログラミング言語でフリーで使えて比較的容易な言語として有名なのに、HSP(Hot Soup Processor)というのもあります。
こちらならば、WindowsのGUIを作るのは比較的楽なのかもしれません。
けれど、また改めて別の言語を勉強するのも少々敷居が高く感じてしまいました。


そんな中アリスのSystemというのはプログラミング言語とツクールの中間ぐらいの存在だと思います。
スクリプトを書いていき、コンパイルして…という流れはプログラミング言語ライク。
けれど、アドベンチャー(ADV)をつくるのであれば、テキスト表示やCG表示や音楽再生など、基本的なライブラリは既に揃っていて簡単に作れるようになっていて、ツクールライク。
んで、スクリプトの記述はCやC++ライク。

そういうわけで、プログラミング言語で一からゲーム作るよりは、System使うと作りやすそうだなーと感じたわけなんですよ。

それで、Systemファンになっちゃったわけで。

以前に、ちょっとしたRPGのコマンド選択式の戦闘プログラムは組んでみたことはありました。
結局ゲームとして完成させるまでには至りませんでしたけどね。

そいで、今回、System3xの次のバージョンのSystem4.0SDKがフリーで使えるようになったことに合わせて、ちょっとしたゲーム制作意欲が湧いてきたことから、ProjectMDなんてたいそうな名前付けて、ゲーム製作に取り掛かることにしたわけであります。

System3xは、歴史的にはアリスの初期作品がアドベンチャーが多かったことから、アドベンチャーが作りやすいようにライブラリが揃っていました。
その後、RPGやSLGも色々と作るようになって、機能も色々大きくなってきました。

んで、そんないろんなゲームが作れるような柔軟性を念頭において再設計されたSystem4SDKは本当にいろんなゲームが作れる可能性を秘めたキットです。
ま、そのいろんな機能を発揮するには、それに対応したDLLが必要なんですけどね…^^;
ま、ADVなら、SACTのライブラリで十分でしょう。
他にも標準のSDKでいろいろなDLL付属しているみたいです。

RPG作るのに必要なCSV形式のデータを取り込むライブラリもあるみたい。

私自身、ゲームを作るといってもテキストアドベンチャーを作る気はありません。
ストーリー考えたりするのは苦手分野ですので。

基本的に、RPG系です。
ストーリーは考えられないので、ひたすら戦闘を続けるような、そういうゲームです。
そんな戦闘のバリエーションや、バランスを考えるのが好きなんですよね。
で、それを実装したゲームを作ってみたいと。

んで、System3の前期の時期であれば、コマンド式バトルプログラムしか作れなかった。
(私の技術として…ね。ツール的にはもっといろいろ作れるはずなんだがｗ)

SACTというスプライトを操れるライブラリが発表されてからは、SRPGライクな物も作れそうな感じになってきました。

System4.0SDKは、そんなスプライト処理のライブラリSACT2が標準で付属されています。

んで、今はSRPGライクな物を作ろうとしているわけです。


さて、私としては、このSystem4.0SDKのよさを広めていきたい気持ちもあり、こうやって紹介文をBlogにアップしているわけですが、HPのコンテンツにも作った方がよいのかな？

昔のSystem3xの時代には開発を助けてくれるようなHPもいくつかあったんですが、いつの間にか閉鎖されているところが多いです。

んで、System4になると、なかなか見つからない…

私も稚拙な技術の持ち主ですので、他人様に指導できるような技術はないですから、講座なんてコンテンツ作ることは出来ないですよねー。
ちょっとしたTipsを紹介できるぐらいかな？？

まー、他人様に公開できるようなTipsがでてきたらHPのhtml部分でも作成しますかね。
今、書けるとしたら、SACTのCG関数の詳細解説かな。あれ、マニュアルにほとんど解説書いてないからね。
CGの処理するとき、めちゃくちゃ試行錯誤していますｗ

画像は、現在の開発途中のMDの画面です。
背景はSystem4.0SDKの素材を使ってみました。それ以外は自分で描いてます。
Developed using Alicesoft System4.0

～・～・～・～・～・～・～・～・～・～・～・～

そうそう、System4.0SDKは無料なので、どなたでもご利用になれます。
アリスソフトのHPで、ユーザークラブに登録をして(メールアドレスの登録が必要・無料)、ユーザークラブ専用HPからダウンロードできます。

しかし、わざわざ登録するのは面倒って方もおられるでしょう。
SDKは再配布も認められていますが、かなり膨大な容量のために、私は再配布するつもりはありません。

Ruby Eyeさんのところで再配布されています。(年齢認証があるので、18歳未満のよい子は結局ダメかも…)
年齢認証→SYSTEM4.0利用法→SYSTEM4.0SDKダウンロードから落とせます。
アリスソフト社製の各種素材もアップロードされています。

もし、興味が湧いた方は触ってみてはいかがでしょうか？

久しぶりのMD

一年ぶりでしょうか、ProjectMDに手をつけた。

前回までの状況。

戦車が画面上に登場して、こちらの指示通りに画面上を移動する。
という代物。

いちおー、戦車は、今後のことを考えて、一枚絵の表示ではなく、カスタマイズ可能な、パーツを組み合わせて表示したものを作ってみました。主砲が1～3本で変更可能、色も変更可能。
そして、移動の座標はマス目なんですが、移動の際は、ワープのようにマス目間を瞬間移動するのではなく、滑らかにズズズッと動いていきます。
方向転換する時もくるくる回ります。

まぁ、ごく簡単なものではありますが、シロートが１から絵を描いたり、プログラムしたりすると、これだけでも数日かかったのであります。

で、とりあえず、次の目標は、もぐら叩きもどきのゲームに仕上げること。

よーするに、自分がちょこちょこと動くだけじゃなくって、敵を自動配置して、それに攻撃できるようにするということですね。

本日のところは、まだまだそこまで行っておりません。

少し移動のプログラムを改良しました。

移動禁止区域の設定。
よーするに、敵とか、障害物があるマスには移動できないようにした。
ついでに、画面外への移動禁止の処理をちょっと変更。

今までは、単に矢印キー押したらその方向にほぼ無条件で移動。
画面外に行かないようにするには、マスが10×6だから、現在地がその端っこのマスなら、それ以上は行っちゃダメ、という代物。

今回の変更は、移動先に障害物があったら移動しない、というものに変更。

マスは2次元配列で管理しています。
3×3なら、

0 0 0
0 0 0
0 0 0

という配列を用意。

自分のキャラがいるところは1にする。　真ん中にいれば、

0 0 0
0 1 0
0 0 0

という具合。

んで、今までは、

1 0 0
0 0 0
0 0 0

なんて時に、左や上に行っちゃダメというのは、現在地の座標が端っこだから外に行っちゃだめ、ってしてた。

これはこれで、問題なく動くんだが、今後敵とか障害物配置して、そこに重なるような移動はしちゃダメってな時に、画面外に行っちゃダメってのと異なる方法で制御したらプログラムがややこしくなるので、画面外への移動禁止と、障害物への移動禁止を一まとめで処理できるプログラムへ変更した。

つまり、今度はこうした。配列を外側に１マスずつ増やして、そこに壁(9)を配置。

9 9 9 9 9
9 1 0 0 9
9 0 0 0 9
9 0 0 0 9
9 9 9 9 9

移動先が、0、つまり空の何もない時のみ移動可能、何か入ってる時はダメ、ってした。

画面の外に当たるところには、すべて9が入っているので、これで画面の外には移動しない。
また、画面内でも、敵とか障害物がいたら、そこは0じゃなくて、2とか3になっているので、そこにも移動しないという感じ。

というわけで、とりあえず障害物(敵)の配置とそれに関する移動の制御に成功。

次のステップは、この障害物に攻撃できるようにしないとね。

そして、不動の障害物ではなく、うろうろと自動で動く敵にできたらしめたもの。

それができたら、とりあえず戦闘のプログラムの根本は出来上がったことになる。
もちろん、実際の戦闘では、命中率や攻撃力防御力などの細かいパラメーターの管理が増えるし、攻撃する武器の選択とかいろいろメニューの充実も必要だけど、とりあえず戦闘するプログラムが作れる目処は立つよーな気がする。

ま、のんびりと作っていきます。

もぐら叩きもどきができたら、いっぺんアップロードしよっかな。

マップ処理

公開してもいないゲームの開発状況細かく書いてどうすんだ??という思いもしつつ、独り言。

この間、ディスガイア１にはまりまくっていて、ほとんど進んでいません。

ちょっとだけ進歩。

今までは、移動の実装といっても画像を動かしていただけ。
つまりは、自機の位置という概念が、絵の座標というものでしかなかった。
何升の移動したではなく、何ドット動かした、っていう情報。

コレでは、ゲームに実装していく上で不便、というか無理。

ちゃんとしたゲーム開発したことないから、普通こういうときはどうするものなのかわかんないんですが、配列を使うことにしました。

10×6のマス目でマップを表現する予定。
(解像度64のユニットを640×480に一杯一杯並べて、下部に情報枠を確保すれば、こんなもんかなと。)
だから、10*6の2次元配列を考える。
(実際にはいろいろな情報を格納したいので、3次元配列使っています。)
んで、その2次元配列を升目に見立てる。
ユニットが存在するところの値は１、空は０とする。
００００００００００
００００００００００
０００１００００００
００００００００００
００００００００００
００００００００００
こんなイメージ？
移動したら、この１の場所をそれに合わせて値をずらしていくって感じ。
敵が登場したら、敵は２として管理するなど。
００００００００００
０００１００００２０
００００００００００
０００００２００００
００００００００００
０００００００００２
この配列を元に、画像を表示させたり、様々な処理をさせていこうかなと考えています。

移動のルーチンにコレを組み込んだところで今回は終了。

次は…戦闘関係のプログラムかな？
まずは、もぐらたたきのような感じで作ってみるか…

敵がターン経過とともにランダムに出現。
攻撃すると破壊ってな感じ。

コレを実装するには…
敵の出現、表示。
攻撃コマンドの表示、選択。
攻撃可能範囲の表示、攻撃対象の選択。
命中処理、撃破処理。
が必要ですかね。
一日ではできんかもなぁ～…
ま、気長にやって行こう。

Project MD始動！！

Project Metal Dungeon
ミニディスクでも、ましてやモビルドールでもありません（ぇ

アリスソフトのSystem4.0でゲーム開発がしたいという欲求が優先し、オフラインゲームとして開発を始めました。

現状→
戦車の画像表示。
戦車の移動を可能に。
アクティブターン処理。
セーブ機能の実装。
…以上！！

よーするに、画面上に戦車が登場し、矢印キーやマウスクリックに合わせてキュラキュラと画面上を移動するだけの代物です。
まだ、ゲームでも何でもありません。

戦車の画像表示が一つの山でした。
SACTを利用すれば、CGを表示するのは簡単なんですが、ちょっと手を加えたために、苦労しました。
(SACTってのは、System4.0のライブラリの一つです。いろんな関数が利用できて、便利です。)
このゲームのこだわりの一つとして、自機のカスタマイズがあります。
で、キャノンが２つに変更したら、画面表示もそう変わるというように、させようという考えがあったんですよね。
そこで、パーツのCGを組み合わせて戦車のCGを作り出す、という作業にちょっと苦労をしました。
言語のマニュアルを見ながら、CGのブレンドをする関数をいろいろ試行錯誤してました。

自機の移動も、ステップ移動では物足りないので滑らか移動を導入。
これは、チュートリアルのスクリプトを利用することであっさり解決。
続いて、なめらか回転を導入しようとして…また詰まりました。
画像の回転加工→表示→さらに回転加工→表示
としていくと、見ていられないような画像へと変化、もとい壊れていきました。
どうやら、
元の画像を回転加工→表示→回転角度を変えて元の画像を加工→表示
とするべきもののようですね。
また、90度回転させようとしたのですが、計算が間違っていたらしく、450度回ってしまいました。
ガッツさんの「360度変わったね～」じゃないですが、回りすぎです(笑

アクティブターン処理を考えているので、そのようなルーチンを組み込みました。
ココはそんなに問題なくできた。

セーブ機能の実装も、System4.0はセーブ機能が関数として導入されているので、楽です。
が、ココで落とし穴が。
セーブデータの記録日時を表示させようと、セーブのコメント機能を利用しようとしました。
そのコメント機能が上手く動作しなぁい。
SACT利用するとコメント機能が使えなくなるのか？などといらん疑いも持ったりしましたが、わかってみたら何のことはない。
関数の引数の型を間違えていました。
文字列「配列」を引数にするのに、文字列「変数」を引数にしていました。
う～ん、普段は型間違えると、コンパイルでエラーが出るんですが、今回は出ずに、実行時にエラーが出てしまい、原因究明に時間がかかってしまいました。

Perlとかは変数の型なんてテキトーですからねぇ。
intとfloatの違いなんかでも結構苦労したし、これからは気をつけないと。
(商でfloatの値が欲しいのに、int/intしたら、自動的にintで返されたし…
先に分子か分母のint→floatの型変換が必要な模様)

そんなこんなな状態です。
土日丸々使ってこんなところです。
こんなペースなら、完成はいつの日になることやら…
というか、完成するのか!?

新ゲームアイデアメモ その２

Tank Tactics(仮)
Metal Dungeonという仮名も考えてはいたりするんですが…

メタル○ックスにインスパイヤされてアイデアを練っている新ゲームです。

メタル○ックスのように自機が改造可能なゲームが作りたいのです。
後、ランダム生成ダンジョンが使いたい。

んで、問題はそれらのシステムを活かしてどういうゲームにするのか、というところ。

以前にも書きましたが、潜りゲーにするのか、対戦ゲーにするのかが悩みどころです。
双方を上手い具合に合わせたゲーム、というのは上手くバランスが取れそうには思えないため、どちらかに絞る必要があるかな、と思っています。

また、潜りゲーにしようとすると、NPCが登場することもあり、その思考ルーチンなどをサーバーにやらせるのは、ちとやばそうだな、と思うところもあり、潜りゲーにするなら、オフラインゲーム、対戦ゲーならオンラインゲーム、という感じになるのかな、と考えています。


オンラインでも、そのあたりのCPUに負荷のかかる部分はユーザー側にやらせるという手段もあるんですけどね。
流行で行くと、FLASHとかになるんだろうか。
けれど、FLASHなんていじったことないし、そもそも作成用のソフトがべらぼーに高いしw
できるだけ安く、っていうか無料で済ませたいので、FLASHはNG。
次点としては、ブラウザで起動できるプログラムとなると、javaになるんだろうか？
javaでオンラインゲームが作れるのかどうかもよくわかってないんだがw

まぁ、なんだかんだで、オンラインゲームにするのなら、PHPかPerlのブラウザゲームあたりでいけるものにしたいところです。
触ったことのある言語にしとかないと、まず挫折するだろうというのもありますが。


オフラインにするなら、なんにするかねぇ～。
Cとかで一から作るほどの気力、実力はありませぬ。
HSPとかは比較的楽なのかもしれないが…
コレも結局触ったことはない。
触ったことのあるものというと、プログラミング言語とはちょっと違うかもしれないけど、アリスソフトのSystem3.xは以前に少し触ったことがあります。
ツクールシリーズなんかと比べりゃマイナーであるとは思うんですが、ゲームメーカーが自社ゲームの開発に使っているものであるだけに、比較的ゲーム作りにはいいものだと思うんですよね。
アダルトゲームのソフトメーカーではあるんですが、このSystemを使って作られているゲームが、いわゆるAVGのビジュアルノベルにとどまらず、本格的なRPG、SRPG、SLGなんかも作られていますからね。
最近は3DRPGも出ている…
かなり作成自由度の大きい開発キットなのです。
まぁ、新しく出てることだし、あえてSystem3.8や3.9は使わずに、新しい4.0にチャレンジしてみたいところですね。


なんてことを書きながら、アイデアとしては、かなりオンライン側で今は考えています。
戦車もので、団体対戦もので、ダンジョンものというわけわかめなヤツ。

自キャラは何度も言うように、カスタマイズ可能な戦車です。

んで、ランダム生成型ダンジョンをマップとした、陣取りゲーム的なもの。
ランダム生成型ダンジョンに、本拠地と基地を数箇所配置。
プレイヤーは、それらの基地を拠点に、ダンジョンをうろついて、敵側の基地をのっとり、敵の本拠地を落とせば勝利。

んで、ウリはこれ。「ダンジョンの壁は破壊可能」(ぉぃ
壁が破壊可能になると、ダンジョンでも何でもないような気もしてしまうんですがね。
今考えているダンジョン生成ルーチンは一般的な迷路作成ルーチンのため、ある地点からある地点までの移動経路、つまりは解法が一つしかないわけです。
多数のプレイヤーが迷路を探索するものを考えると…
道は一つしかない→そこに人が殺到する→通行止め　
となるかなと。
なら、自分で新たに道を作れた方がいいかなと思ったわけなのです。
まぁ、壁が破壊可能となると、ダンジョンの価値が下がるので、そう簡単にボカスカ壊せる壁にはしないつもりですが…

今のところ、妄想だけの代物で、上手く作れるかどうか、面白いものになるのかどうか、まだまだ不明なものではあるんですが…
妄想だけは膨らんでいくものでｗ