Pluglog

Tkool Replay コメントは随時受け付けておりますので、古い記事でも遠慮なくお書きくださいませ。
Admin
TOP ≫ CATEGORY ≫ 考察文
CATEGORY ≫ 考察文
      

スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。
Comments (-) Trackbacks (-) スポンサー広告

Elonaに学ぶ、ゲームの意外性


最近ニコニコに上がってたこれをなぜか見て、Elonaの面白さを端的に表現した動画だなあと思った。
予測を裏切ることが次々に襲い掛かってきて、プレイヤーが翻弄されるラッシュ
・チュートリアルで肉をもらったぞ!→人肉やんけ
・腹が減る→食い物探して食ったら呪われてる
・ペットを連れまわしてたら→井戸に落ちて即死
・プチばっかで弱いぞ→こんにちはスライム
・なんか風が吹いてる→ほっといたら凄い勢いで病気が・・

プレイヤーが理解していけば、対処できることなのだけれど初見にとっては理不尽な罠
これは不親切と言い換えることもできるのだけど、こういう要素がプレイヤーの間では苦労談としてあるあるネタになったりする
ゲームは苦労があって、それを乗り越える挑戦があるから輝かしい思い出になるのかもしれない

~~~

自分のゲームを振り返ると、こういう要素がまだ足りてないかなーという気がした。
この手の仕掛けで最もインパクトがあるのは、やっぱり死・ゲームオーバーが絡むこと。
単純なものでは調べると死ぬイベント、いわゆる即死トラップ。これを設置しまくるのが死に覚えゲー。
ただあまりに単純すぎるものは理不尽すぎてくそげーになってしまう・・この感覚の違いはどこからくるのか・・

考えつく一つの要素は、プレイヤーの注意力次第で回避可能かどうか・・
プレイヤーの行動によって引き起こされる結果であるか、ということかもしれない
ようは制作者側からの意図の押し付けでなく、プレイヤーが選択した結果だと認識できるか否か

Elonaの井戸にペットボッシュートなんかはまるで予測不能だけれど、
ペットを井戸に乗せなければ回避できるのだし、情景をイメージすればなるほどそうなるのかと妙な納得感も生まれる
行動回避可能か&納得感 が大事なのかもしれない・・

納得感をもたらすには、ゲーム世界へのシンクロが必要になるのだろう
行動によって引き起こされることに、ゲーム節理としての統一感、そして想像力をもたせねば

常識を少し外れた意外性、そういうのがプレイのスパイスになりそうだ
わりと質素で落ち着いた作品になってきてる気がするので、驚きの要素も少し追加していきたいところ・・
スポンサーサイト

不確定イベントの出現方法

ツクールでマップ上にキャラやシンボルを出現させるためには、俗にいう「イベント」を設定する。
そのマップで起きるイベントは、あらかじめ設定しておかなければならない。

しかし、ランダムな位置に出現させたり出たり出なかったりの不確定要素も加えたい!
そう思うことはよくあっただろう。
これを擬似的に表現する手段として一つの方法は・・

1.イベントページ1を並列処理にして、マップに入った瞬間に乱数を判定
2.判定OKならランダムな位置に移動させセルフスイッチAをON、NGならイベントの一時消去を行う
3.セルフスイッチAのページに本処理を書く


まずはこれでマップに入った時に、特定の出現率でランダムな位置に現れるような仕組みが作れる。
ただこれだと、次に入った時にセルフスイッチAが入ったままなので、再度現れることがなくなってしまう。

そこで、マップに入ったときにセルフスイッチAをOFFにする仕組みが必要になる。
リフレッシュ判定用のスイッチを一つ用意して、マップ移動時にONにしておき、
そのスイッチが入ってるとき各イベントで並列処理でAオフにさせていく、なんてやり方もある。

for i in 1..$game_map.events.values.size
next if $game_map.events[i] == nil
$game_self_switches[[@map_id, i, "A"]] = false
end


スクリプトでやるなら↑のようなものを実行して、一括でリフレッシュさせることもできる。

これで「マップに入る度に出現するイベント」のギミックができた。
けれど、敵シンボルなどは出入りする度に一定数現れるのでもいいけれど、
宝箱など、プレイヤーメリットになるものは出入りだけで単純に出現してしまうと、
今度は出入り口に陣とって行ったり来たりするのが効率の良い稼ぎ方になってしまう。
探索感が損なわれてしまうので、それは個人的にあまり望ましくない。

なのでさらに、一定ターンの行動数毎にリフレッシュフラグを立てるという仕組みに行き着いた。
これならばフラグが立っていない状態でマップ移動を行うと、宝箱の出現判定で減ることはあっても増えることがない。
ある程度探索してから次に進む方が効率の良い宝箱収集になる、という目論み。

前作はこんな感じの方法を駆使して作られていて、エディタ上では適当に置かれていた模様。
20160920173758.png



さて・・ここまでは、前作までの方法にすぎない。
なんと、イベント自体をスクリプトで追加することができるようになってしまった。

20160920181922.png
部分的にはこんな感じでできた。(もしかしたら何かしらまだ不具合はあるかもだが)
ヘルプのリファレンスを読み込んでいけば、大抵のことは実現可能なようだ。

こうなると何が嬉しいかというと・・
20160920182551.png
もうこのマップにタグ設定するだけで敵が湧く・・
各種設定はスクリプト側で一括修正すればいいので管理も楽!好きなタイミングや間隔も調整しやすくなった。
エンカウント欄をメモ代わりに使うのはちょっとオススメな方法だったりする。

文章自動生成

Elona制作者さまの新作『Elin』開発中だそうで、ひえーそんな大物がくるまえに自作完成させたいですね
グラフィック面めちゃくちゃクオリティあがってますけど、サウンドにElonaの片鱗が見えてニヤリ

今日はちょうどランダムクエストと、文章の自動生成について考えていたのでElonaに学ぶところがありました。
基本的に"ランダムに出現する何か"については、メッセージもランダムで作成したい!と思うところがあります。

ランダムメッセージにハマったきっかけ・・あれはそう・・RPGツクールGB・・(回想モード)
あれにはイベントコマンドにランダムメッセージというコマンドがありまして・・
それを設定しておくと、話しかける度にキャラグラフィックに応じてあらかじめ設定されたメッセージがランダムに変わるという。
なんだかそれにわくわくしたものでした。
いくつか定型文を用意して乱数で分岐すれば可能なので、ツクールとしては初歩的な処理でした。(GB乱数なかったかもしれないけど)

しかしPC版ツクールでは、より高度なことができます。
文字列の配列を用意して、その中からランダムで抜き出したり、文字同士を足したりもできるのです。

a = ["やぁ、","こんにちは、","ハロー"]
b = ["元気?","調子はどう?"]
$game_variables[1] = a[rand(a.size)] + b[rand(b.size)]


てなかんじでスクリプトを組んで、変数1に代入しておいて、文章表示で\v[1]とやれば・・
「やぁ、元気?」「こんにちは、元気?」「ハロー元気?」
「やぁ、調子はどう?」「こんにちは、調子はどう?」「ハロー調子はどう?」
これだけで3×2の6パターンの文章が自動生成できちゃうわけです。

これを利用して、前作FuhrungWeissでは
ライバル「URYEEEEEEEEE!私は魔法少女の下僕だよ。
     パンデモニウムを狩りにきたんだ。
     暇だから、ジハードする?」
みたいな文章を生成していたわけですね。

今作ではさらにこれを体系化して、もっと法則性をつけたり汎用的にできたらいいなと思ってます。
例えばクール属性を持ってるキャラなら、落ち着いた話し方や「……」がでやすかったり、
楽天的なキャラなら元気のいい感じになったり、みたいな。
人物を示すワードや、場所を示すワードなどのリストをあらかじめ作っておいて、使いまわすとか。

Elonaの掲示板依頼なんかは、そのへんスマートにやっているので参考になります・・
dataフォルダの中にboard.txtってのが入ってるんですよね
20160912233347.png
これを見ると、置き換えようのワードがまず最初にいくつか定義してあって、
{ある}はある、ありますのどちらかにランダムに振られるようになっているようです。

20160912233341.png
そして実際の依頼内容はこちら、定型文を主体に依頼対象や語尾などが埋め込みワードで変数化されてるわけですね
これは編集するときにも非常にわかりやすい書き方で、拡張性も高くていいですね!

Rubyでも式展開

x = "変数"
"文章中に#{x}を埋め込める" # => 文章中に変数を埋め込める


ってなことができるので、似たようなことはできます。

{ある}をある、あります に変換するような方法の場合は
a = ["ある","あります"] のような配列を作って、要素をランダムに抜き出すか・・
a = "ある,あります".split(/,/) のように区切り文字を決めてsplitを使って同様に配列化する方法がとりあえずのところ。
後者の方が編集は楽できそうだけれど、結局配列化するならsplitの分処理が増えてしまうので、負荷的には前者の方がいいかも。
splitの方法に気づかず、そもそも前者で作ってたのでまあこのままでいいかなって感じですが、
もっといい方法あれば知りたいなー なんてことを今日は考えていましたとさ。

ランダムエンチャント オプション値の振れ幅について考える

脱線ネタなんですけども、ランダムエンチャントでなにか能力値が決定される場合に、
例えば攻撃力+0~100 みたいに振れ幅があるとするじゃないですか

これをプログラム的に単純にrand(101) ってすると、
早い段階で+100のアイテムを拾える可能性も結構高いと思うんですよね
ようは「0」がでる確率も「100」がでる確率も一緒・・
でも、高い数値のアイテムはでにくい!みたいなのを表現したい場合もありますやんね!?

そんなときに使えるテクニック・・

rand(101) ** 2 / 100


乱数を2乗して、最大値が同じになるように割る こんな感じにすると・・
1のときは0で同じ、100のときは100×100=10000 ÷100となって、同じ100になるけれど・・
たとえば50のときは50×50=2500 ÷100 となって25に
つまり高い数値ほど出にくくなるということが実現できるわけです!

実際の計算結果の全パターンは以下の通り(小数は切り捨てになります)
0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 2 2 2 3 3 4 4 4 5 5 6 6 7 7 8 9 9 10 10 11 12 12 13 14 15 16 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 36 37 38 39 40 42 43 44 46 47 49 50 51 53 54 56 57 59 60 62 64 65 67 68 70 72 73 75 77 79 81 82 84 86 88 90 92 94 96 98 100

同じ101通りでも、小さい数がかたまってでやすくなるわけですね

20160814193637.png
グラフにするとこんな感じで、2乗の部分を3乗、4乗・・としていけば
その分カーブがきつくなって、高い数値はでにくくなってゆきます

またrand(101)ならば101通りなのでだいたい1%の確率で最高値がでるわけですが、
これもrand(1000)、rand(10000)・・などとしていけば、最高値がでる確率は絞られていき・・
天文学的な確率の激レア値オプションなんてのも作れて、非常に高いやりこみ度のランダム性が作れそうです

これのいいところはたった一つの式で定義できるというところでもありますね
バランスを変えたくなったときも、これをちょいっと変えればOK!
ちなみにランダムオプション以外にも、ランダムに出現する高レベルの敵なんてのにも使えますね

まあ今作にそれほどシビアな厳選性を組み込む予定はなかったんですが・・
オプション値をランダムにするのは、製造系のシステムを入れるとするとかち合うんすよね まあ製造も未定なんですけど
こういうのも面白そうだなーと思いつつ、余裕ができたら組み込んでみようかなあ

極限状況の中で、リスクリターンを探る

最近、紹介記事をみっけて面白そうだった「Vagante」っていう海外製の洞窟探索アクションフリゲを触ってみたり、
ニコニコでなんとなく「The Last of Us」っていうサバイバルアクションゲーのプレイ動画を観てました。
「Vagante」はまた改めてプレイ感想記事を書きたいとこですけど、それはおいておいて、
両者の面白さの共通点は「極限状態でのサバイバル」なんですよね。

人が最も目的意識を持てるのって、"死が迫ったとき、それに抗う術を考える瞬間"で、それはゲームにおいても
"キャラのHPが0になりそうなとき"、"ゲームオーバーが迫ったとき"などと重ねあわせることができるのではないかと思います。
「この戦闘でもし死んでも、別になんのペナルティもないしその場で復活できるよ」みたいなゲームだと危機意識が全然違うわけです。
やっぱりこの辺りに死にゲーの魅力はありますね。
けれど一方で「この戦いに負けたらお金を半分失い、アイテムをロストして町に戻される」みたいにすれば危機感が生まれるかというと、ストレスの方が上回りかねないのでリスクが多ければいいというものでもないですけどね。

その点、今回挙げたゲームは「死んだら終わり」なのでリスクとしては最大級。これはアクションゲーだからこそ可能なことなのかもしれませんが、
わずかなミスで生命が危ぶまれるような常に極限状態におかれることで、少しでも生存率を上げるには……
アイテム一つ一つの可能性を吟味したり、敵の特性を見極めたり、これを考えることに目的意識を注ぐことができるんだと感じます。

ここで使うべきか使わざるべきか、そこを進むべきか迂回すべきか。選択肢に悩めるゲームは面白いと思います。
「The Last of Us」の場合は、キープできるアイテムっていうのが限られていて、落ちているレンガとか瓶を1個だけ手に持っておけるけど一発投げたら使い切りだったり、木の棒やら鉄パイプやらの武器も耐久度があって一つずつしか持てないので、手に入る機会が多くてもどんどん蓄えることができるわけではないという点でアイテムの価値を高めていると感じます。
「Vagante」の場合は、HPを回復させる手段に乏しいのでボスと戦うのはきついけれど、装備さえ手に入れば探索がどんどん楽になるので、リスクとリターンをダイレクトに秤にかけられるバランス。

RPGでこのライブ感を演出するのは結構難しいんですよね。基本的に積み上げるものが多いジャンルなので(Lvやアイテムや仲間やら・・)
ギリギリのバランスっていうのが設定し辛い。

"回復アイテム"はどうあるべきか

今作での回復アイテムをどういう位置づけにするか、っていうのを考えてました。
RPGの戦術といえば「ダメージを受けたら回復、死なないようにして進む」がセオリーなんですよね。
そこで、いかに回復手段を無くさないように立ち回るかが重要なので、
これに直接影響する「回復アイテム」のポジションはかなり大事だと思います。

回復アイテムをどのようにしてコントロールするか。
重量制もその一環で、回復アイテムの大量買い込みを制限する目的がありました。
それに加えて、今作では「敵ドロップからは回復アイテムは手に入らない」ようにしようかと思ってます。

これはなぜかというと、
「テキトーにやってたら回復アイテムも集まってた」みたいな事態にしたくないためです。
回復アイテムの戦術管理はなるべくプレイヤーに委ねたいんですよね。
あと、終盤になってから下級の回復アイテムをポロッと落とされても邪魔になるということもあります。
(もったいないから使おう→カーソル移動 って地味に面倒じゃないですか)

なので本作では"エリクサーがもったいなくて使えない"ってことが起きないです。
"使うためにエリクサーを作る"みたいなゲームを目指したいので。

シナリオを考える

自分けっこうシステム系の性格なせいか、シナリオが壊滅的に書けないというインフェリオリティコンプレックスを抱え込んでました。
でも最近アニメをいっぱい観てるうちに、どういう話が面白く、どういうのがダメだと感じるか、そのツボについてあることに気付いたんですよね。

それは、キャラクターの心情に納得できるかどうか、感情移入できるかってとこでした。
わりと基本的なことかもしれないんですけど、ほんとに、キャラの感情とか行動が筋道立っていて、それを理解できるだけで面白いです。
大抵つまらんと感じるのは、キャラの行動が突拍子なかったり思考が理解できないやつだったのです。
自分はこれができてないんだわ・・と痛感したので、これをまじで意識してお話作ったら、もうちょっとマシなものができるんじゃないかと思います。

それとStoryEditorってやつ初めて使ってみたんですけどこれ凄く便利ですね!
http://www.vector.co.jp/soft/win95/writing/se051723.html

別にシナリオ書くのとは関係なく使ってみたんですけど、スゲェ便利でした。

精神力ゲー

自然癒やってたときも思ったんですが、VXのツクールゲーって火力に関係するステータスが攻撃力と精神力が備わってますが、精神力依存系のスキルだとかキャラの方が強くなりがちっていうのがある気がします。

というのも精神力は魔法攻撃力だけでなく魔法防御力も兼ねているので、魔法職は防御力と精神力を伸ばしていれば盤石になるのに対し、
物理職は攻撃力と防御力を上げただけでは魔法に対し弱いままという弱点を抱えなくてはなりません。

なので自由にステ振りができたりすると、物理キャラは精神振りも考えなきゃいけなくて伸ばしにくかったりします。

まぁパラメータ設定が最初から決まっているタイプの作品なら、精神高いやつは防御低めみたいに大抵なってるだろうからバランスは取れてるかもしれないですが・・
ステータス操作がしやすいタイプの作品だとこの辺の不公平感はちょっと気になるところかもです。


そして新たに東方魔幻想というゲームをやりはじめましたぁ!
制作者というよりプレイヤー側視点な感じですが、チャージ期間ということで・・しばらくはこんな調子でゲーム遊んで感想書いたり雑文ネタ書いてったりするかもしれません。
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。