calendar_viewer 日記/2015-10
new<<
2015-10;
>>old
[日記] |
||||||||||||||||||||||||||||||
1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 |
2015/10/28 (水)
雑記:2015ハロウィン。†
表記、そんな感じ。
もともと短期間のイベントですし、友瀬的にはもう終わったも同然(笑)
なので、簡単にまとめ。
一言で言うと、『短期間の季節イベントで、このクエストはやめてよ』かな。
前提というか。†
RO ではこういう『毎年恒例の季節イベント』については、大きくいうと以下の3要素を詰め込むのが通例です。
- 要素0:独特の背景
- 要素1:そのイベント独特な効果。
- 要素2:『イベント参加した』証拠的なクエスト。
要素0は、まあいいですよね。
なんでこんなイベントをやっているのか、という話ですから。
要素1は、なかなか言いづらいですが・・・
ことハロウィンについては、
『高性能回復剤 カボチャパイ』を入手できる、というのがわかりやすい話です。
要素2もいろいろですが、最近のイベントでは
要素0の背景を反映するようなクエストが作られるのが常です。
登場人物と縁をつなぐようなクエストで、それをこなしておくと、
年末のクリスマスイベントで当該人物からちょっとしたボーナスが得られる、という類。
これ自体には、ある意味当たり前の話で、極端な不満はないです。
で、今回のハロウィンでは?†
端的に言うと、上記でいうところの「要素2」のクエストが、厳しかった。
なにが、というと『所要時間』と『見返りの少なさ』という観点で。
クエスト自体は面白かったです。1回見る分には。
システム面も、後述する通り光る点もある良いものだと思います。
ただ、そのシステムを生かすためにクエスト自体が長くなってしまった。端的に言えば30分コース。
そしてそれを実施した後に得られるのは『限定衣装1つ』と『年末ボーナス』。
正直に言って友瀬はこういう類のクエストはあまり好きではないです。
もちろん『やらない自由』はありますが。
でもそれは『何がくるかわからない年末ボーナス』を捨てるということでもあるわけです。
というわけで、今回も『2週目以降は苦痛』でした。
『年末ボーナスで後悔しない』ために多くのキャラでまわした、というのが一番近いです。
たぶん、かけた時間に見合った報酬はないだろうな、と思いつつ。
あまりに苦痛だったので、ついクエストWiki の充実に貢献しちゃったよ(笑)
評価していること:今回独特のシステム†
とまあ、悪口ばかりではアレなので、ほめることもしておく。
RO のクエストでは一般的に『吹き出しでの会話処理』が行われています。
単純にいえば『n者択一』;複数の選択肢を表示して、プレイヤーの選択に応じてクエストが進む、という類。
今回は、このn者択一に変わる2つの新しいメカニズムが投入されていました。
# 完全に新規、というわけでもないですが。
■メカニズムその1:『n者択m』
n者から任意数を選択して実行、というタイプ。
吹き出し内にn個の選択項目がリスト表示され。
ある項目を選択すると、それが「選択状態」で表示され再びn択画面に。
・・・というかたち。
メカニズム的にはまにゃん島での『Wizardry的アイテム回収』の際にも搭載されていましたが、
クエスト用に使われたのは初めてだと思います。
今回のクエストではもう少しバリエーションがありました:こういう面でもよかったと思う。
- 任意数選んで『選択完了』をプレイヤーが指定するタイプ
- 選択数が決まっており、例えば『3個選ぶと選択完了』とするタイプ
■メカニズムその2:『時間指定入力』
例えば、『20秒後に Nextを押して。』というようなメッセージ。
これが出た後、ちょうど20秒で押せればOK分岐、ずれていたらNG分岐、というもの。
■具体的にはどう生かしていた?
今回のイベントの『料理』の特性を、これの機能を組み合わせてうまく表現していたと思います。
- 『n者択m』で『どの食材を使うか』を入力==複数の食材を入れる
- リズムよくやるような作業を『1秒待ち入力』x『3回繰り返し』で再現。
- 煮込み時間を表現するような作業で、『10数秒の待ち』
・・・といった感じ。
・・・すごく個人的ではあるんだけど、昔やっていたペルソナウェアを思い出したよ。
あれも似たような『吹き出し』だけがユーザ向けI/Fで。
ペルソナ開発側としては、それでどんなことを提供するか、ずいぶん頭をひねったよ。
攻略情報†
こんな寂れた・検索避けもしているサイトでやるのもどうかとは思うけど、いちおー。
多数のキャラを持つ友瀬が、今回のハロウィンを効率的に回るためにいろいろやったことをメモ。
もちろん基本はクエストwikiにある通りですが、あそこには書かなかった==個人判断の範疇の話です。
- 攻略上の特徴的な部分は?
- 基本的な方針として、決糖を『省エネ』で進めます。
決糖では料理作成のために『正確な操作』を『多数』要求され、クエスト時間のかかる理由の1つになっています。
ですがこれ、相手よりも『1点でも高得点』なら勝ちなので、手を抜く余地があるのです。- 例えば『盛り付けLv10』が可能ならば、それだけで100点は確定です。
もし対戦相手の点数が100未満であれば、料理手順はすべていい加減に実施しても『盛り付けLv10』すれば勝ちです。
- 例えば『盛り付けLv10』が可能ならば、それだけで100点は確定です。
- 上記を考えれば、決糖のあちこちで『時間をかけない』ことができるのがわかると思います。
- 『時間待ち入力』とか『数値入力』『択一入力』部分は連打でスキップできます。
『待つ』とか『正解を調べて入れる』とかの時間が省略できます。 - 『n者択m入力』の部分は細かい操作をせずに即『一番下の終了を選ぶ』でよい。
『正しい選択肢を調べて、複数選んで、繰り返し』という作業時間を省略できます。
- 『時間待ち入力』とか『数値入力』『択一入力』部分は連打でスキップできます。
- 料理レシピには『ある手順で作った素材を、次以降の手順で使う』という部分があります。
手順を間違って必要な素材を作っていないと点数が伸びないのですが。
逆に言えば『点数がいらないのならば』順番を無視することで工程いくつかを丸ごと省略できます。- 例えばプディングの作成レシピでは大きく3工程が必要ですが。
最後の「原液作成」から始めると、他の2工程を完全に省略できます。もちろんその分点数は下がりますが。
- 例えばプディングの作成レシピでは大きく3工程が必要ですが。
- 決糖の事前準備も手抜きできます。
最高得点を伸ばすには「勉強10レベル」「技能3つ習得」「必要材料全部所持」が必要ですが。
前述の通りの『省エネ』で勝つなら、そこまではいりません。
- 具体的には、友瀬は以下のようにしました。
- 「勉強」はレベル7まで実施します。
もちろんレベル10までとれば余裕ができますが、レベル7まででも最大点数が30下がるだけなので十分。
『神の目』の習得条件の都合上、これ以上は省略できません。 - 「技能」は『氷炎』と『神の目』だけ習得します。
『無残斬り』は討伐クエストが手間なため、無視します。
- 「勉強」はレベル7まで実施します。
- 基本的な方針として、決糖を『省エネ』で進めます。
- 最終的に、決糖は移動も含めて最低限で済ませることになりました。
- 具体的には、番長のいる部屋にいる3人だけです。
このルートは、いろんな意味で省略・節約できます。 - 同じ部屋に全員いるため、移動がいりません。
- 『作る料理が、実質的にパフェだけ』というのもメリットです。
いろんなレシピを見る必要がなく楽です。
最初の1人は別料理(プディング)なのですが、要求得点が低いのでレシピをまったく知らなくてよいです。 - 所持すべき材料も『神の目』習得の条件で十分です。
- 具体的には、番長のいる部屋にいる3人だけです。
- さらに具体的には。
- 1人目の子分は 50点台の得点しか出さないので、前述の通り『盛り付けのみ』で勝利できます。
料理工程はいきなり「原液作成」で手順省略できます。 - 2人目もやや省略可能。パフェの工程を『後ろから逆順で』やることで、1工程省略しながら勝てます。
選択肢は少しくらいのミスは大丈夫です。そこそこ真面目に。 - さすがに3人目は350点を越えるので、真面目に。
それでも上記条件だとプレイヤーの得点は最高380点になるので、一応20点程度の余裕があります。 - なお上記の前提として、友瀬は前回イベントクリアで最初から『決糖値3』でした。
今回新規だと、下記内容に加えてもう1キャラ、決闘値1のキャラと戦わなければならないです。
ただこの場合も『盛り付けだけで勝利』できるので、それほど問題ないと思います。
- 1人目の子分は 50点台の得点しか出さないので、前述の通り『盛り付けのみ』で勝利できます。
ご意見などがあれば。
2015/10/13 (火)
ホムAI:0.69 情報メモ†
先日の記事もあわせて、いくつか気になる点が出てきています。
いずれも『致命的とはいえない』レベルではあるのですが、
あまり貯めると面倒なので、適当に更新しようかと思います。
以下、自分のメモ的要素も含めて。
ステータス読み出しで落ちる可能性†
テレポなどのAIリロード前後での状態(通常/追従など)を維持するために、
ファイルを使ってデータを中継している。
そのファイルが何らかの理由で異常になると、AIが落ちる可能性がある。
起きる現象は致命的に見えるが、この『異常』はファイル入出力途中でRO自体/OS自体がおちるようなときにしかおきないはず。
そのため、一般的には発生しないので危険度が低い。つーか友瀬自体は一度も発生したことはない。
ただ、実際に発生したユーザさんがいるようなので、手を入れておこうかな、というレベル。
具体的な場所は showstate_rap.lua の function CheckSavedStatusFileMode() 内の以下の2つ。
- ファイルオープンに失敗した場合に、適切ではない動作になる。
- 現状:if(fp == nil) then return
- 修正:if(fp == nil) then return 1
- ファイルがあったが、内容がおかしい場合におかしくなる
- 現状の『tmpstate = fp:read()』の直後に以下を追加。
- if tmpstate == nil then tmpstate = StatusList[1]
手動スキル使用後の行動†
Glenelg はもともとバニル用のAIだったため、遠距離から手動でスキルを撃った場合に
『非戦闘のIDLE状態に戻る』
仕様になっている。
別の言い方をすると『遠距離からの手動でカプリスを撃った後は、あえて接近戦を仕掛けない』仕様。
ですがこの仕様、多くのホム/ホムSの持つ接近戦用スキルでも同じように動いており、結果好ましくない動きをするケースがある。
具体的なケースの1つとしては、数セル先の非アクティブ対象の敵に対してスキル指定した場合。
- スキルを手動指定→ホムはその敵に接近移動開始する。
- 接近戦用スキルの射程内にまで近づいたら、そのスキルで攻撃を行う。
- スキル使用終了したので、ホムは『IDLE』状態になる。
- IDLE 状態なので、ホム、索敵開始。
- 今スキルで狙った相手は『ホムにとっては非アクティブ対象』なので、『近くに積極的に攻撃すべき敵がいない』状態である。
- 『近くに敵がいない』ので、ボスへの追従行動開始。
ボスの足元に移動開始。- わかりますよね?
わざわざ『白兵戦スキル』を使わせたのだから、ユーザが想定するのはおそらく『そこで足を止めて、その敵に通常攻撃開始』です。
戻ってこられても困るわけです。 - ちなみに、敵側がアクティブ型だったり敵のASPDが十分速かったりすると、比較的目立ちません。
なぜならば:上記ホムが『IDLE』になる前後でその敵がホムに対して攻撃を開始するため。
ホムはIDLE状態での索敵処理の中で、それを『反撃すべき敵』と判断して戦闘を開始するわけです。
- わかりますよね?
実はいちおー、上記に対しては現状の Glenelg のままでも対応はできる。
そうなっているから、友瀬は困ってなかったわけで。
具体的には『接近戦をしたい場合は、普通に攻撃指定する』だけでよい:
接近戦スキルをオートスキル指定しておけば、接近後の初撃でスキルを使ってくれる。
スキル割当などで例えば『ソニッククローLv4』を『対象を攻撃』に割り当てておけばいいのです。
ただ、接近戦スキルがいろいろあって状況によって使い分けたい、という希望もありそうなので。
『使用したスキルの種類によって振舞いを変える』仕組みを作ってもいいかな、と。
- 射撃系スキルでは、状態をIDLEに戻す。現状の仕様通り。
- 白兵戦系スキルでは、状態を ATTACKにする。その敵に戦闘開始。
- 射撃系スキルでも『戦闘を継続する』ことを望む人がいるかもしれない。
それについては、前述の『対象を攻撃』で我慢する。
- 射撃系スキルでも『戦闘を継続する』ことを望む人がいるかもしれない。
意外と面倒なので、ここでの変更部分の詳細記載はしません(^^;
ご意見などがあれば。
2015/10/3 (土)
ホムAI:0.69でのバグ。†
表記件、知人の Error.txt 解析で発見されたバグです。
影響範囲: スキルによる詠唱反応動作。
この動作を指定していなければ、特に対応不要です。
単純にいうと、スキルでの詠唱反応動作で落ちていました。
アップデートはてきとーに実施しますが、とりあえず以下に手動修正方法を記載します。
対象ファイル:showstate_rap.lua
対象行:934行目
現状: elseif (GetV (V_SKILLATTACKRANGE,id1,GetOpt("BREAK_SKILL_TYPE")) <TmpDistance) then
修正: elseif (GetV (V_SKILLATTACKRANGE,MyID,GetOpt("BREAK_SKILL_TYPE")) <TmpDistance) then
以上、簡単ながらとりいそぎ。
ご意見などがあれば。