スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

ローグライクをつくる

15/01/05改稿

※全部ウディタでの話なので注意してください。

さて。ローグライクをつくるということで、いろいろ書くに先立って、とりあえず自分がローグライクをつくってみた経験から、ウディタでローグライクをつくるうえで知っておくといいことを書き連ねてみます。

1.システムは全自作!
→当たり前ですが。ローグライクをつくろうとしたらシステムは全部自分でつくるしかないです。
どこかにローグライクコモンが落っこちていればいいですが、残念なことにウディタ公式にはそのようなものはありませんでしたね~。
ということで、最初から全自作するつもりで挑みましょう。

とはいえ、僕からするとローグライクなんて他のジャンルのゲームに比べればかなり敷居の低い方です。
アクションRPGと同等か、それ以下くらいかなぁ。
当たり判定で数学的演算が必要になる横スクロールアクションとかレーシングゲーム(種類にもよるが個人的にはこれが最難関なのではと思う)とかに比べれば、専門知識のない一般人でもつくりやすいです。

ただし、製作量はRPG並み+αなので、気力と時間のない人にはあまりお勧めできません。
コモン数は人によるけど、だいたい200~300くらいかなぁ。
ゲームの性質上、一歩歩くごとにいろんなコモンイベントを動かしまくることになるので、地道な作業が好きだったり論理的に考えるのが好きだったり、整理整頓の得意な方にそれとなくお勧めしておきます。

2.基本システムはひととおり見る!
→ローグライクに限らず、自作システムでゲームをつくるうえで土台となるのが基本システムの知識です。
コモンの扱い方とか処理軽減の仕方とか、ちょっとしたテクニックを吸収するためにも基本システムの中身は全部頭に入っているのが理想ですね。
基本システムでさえ何をやっているのかよく分からんという方は、まず基本システム改造のRPGを短編でもいいのでひとつつくってみることをお勧めします。
ローグライクってもRPGと似た部分は非常に多いので、とっても参考になることでしょう。

僕が思うに、ローグライクをつくる前に最低限、
・自作戦闘をつくれる(フロントビューなどの形式は問わず)
・自作メニュー画面をつくれる(アイテム使用、装備変更、セーブロード操作etc…万能ウィンドウも自作できるとなおよし)
・ピクチャのあらゆるコマンドの使い方を理解している(相対モード、スクロールとリンク、ディレイリセットなどなど)
くらいの技術は必要な気がします。
特に戦闘は基本システムの流れを追うだけでもいいので、ひととおり自分で形にしてみるとよいと思われます。
なにしろローグライクなんて、戦闘フェーズを無限ループさせてるようなゲームですからねぇ。
ステータス一時値再計算とか状態更新とかレベルアップ処理とか、そこらへんのコモンイベントで何をやっているのか、ちゃんと理解してますか~?

3.凝るところと凝らないところを区別する!
→ローグライクって頻繁に使う処理と使わない処理の差が激しいんですよね。
具体的にいうとターン処理なんかは一歩歩くごとに呼び出しますが、攻撃処理なんかは攻撃キーが押されたときにしか使いません。
どういうことかというと、頻繁に呼び出す処理がやたらに重かったらプレイヤーにとって非常にストレスなわけです。なので、頻繁に呼び出す処理はなるべく簡略化して、その代わり攻撃処理なんかでは思う存分演出を加えるといいんじゃないかと思います。こういう感覚は他のいろんなゲームをつくるうえでも役立つんじゃないかなぁ。

4.コモンイベントはなるべく抽象的に!
→こいつは別にローグライクに限ったことじゃないが。
基本システムを見ても分かる通り、コモンイベントの中には具体的な数値なんてほとんど入れない方がいいです。じゃないと後から改変しようと思った時に、とっっっても厄介なことになります。
特に長編をつくろうとすると、コモン数も増えるし、あとからいろいろ変えたい部分も出てくると思うので、多少面倒でも必要な数値は全部DBに打って、DB入力ひとつでコモンの動きを制御できるようにしておきましょう。
あと、コモンの呼び出しやDBの参照にはとことん「名前」を使うことをお勧めしておきます。数値で呼び出すと、項目がひとつずれただけでまったく動かなくなってしまうので…。

5.コモンイベント、DB構成はなるべく一元化・一般化させる!
→ローグライクではあらゆる生物(オブジェクト)がパラメータというものを持っています。
当然、これらのパラメータはひとつのDBで管理するし、敵も味方も同じコモンイベントを使ってAI移動させたり配置したり消滅させたりします。
アイテムの種類や生物のタイプによって通す処理を変えたりすると手間だし、なによりバグの温床になります。
というわけで、↑の内容と似通ってますが、柔軟性に富んだDB構成やコモンイベントをつくるとよいのではと思われます。
関連記事
スポンサーサイト

コメントの投稿

非公開コメント

Twitter
カテゴリ
最新コメント
月別アーカイブ
カウンター
検索フォーム
RSSリンクの表示
リンク
ブロとも申請フォーム

この人とブロともになる

QRコード
QR
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。