闘いの挽歌 / Trojan 全2周ノーミスクリア 基板録画

Tatakai no Banka / Trojan capcom 1986 arcade pcb
521,450pts 2-6 all 連なし player up2
各面ボスの速攻パターン
をすべて繋げるという考えには無理があった･･･
プレイヤーの剣を振る動作が8フレームなので 60 / 8 = 7.5[回/sec]
1秒間に7.5回の割合(等間隔)でボタンを押すと最速の連打になります
(もちろん2倍の15連打できるならそれでもOK)
剣を振ってる音(SE)は連打の速さに応じてもっと速くなるが
実際には1秒間に7.5回の速さが上限です
半端に速いスピードで連打すると却って同期が取れず
最速連打にならない場合があります
各ボスのダメージポイントに最速で剣を振ると速攻で倒せるが
2周目の剣王だけは例外でプレイヤーと同じ速さで剣を振る上に
ダメージがこちらの3倍なので正面から打ち合うと不利
ただ、2周目の剣王はいくつか特殊なところがあって
1.最初に飛び込んで攻撃するとき一度に2回攻撃が当たる間合いがある
2.剣王の攻撃に攻撃判定が出てないときがある
3.一度の攻撃で剣王に2度ダメージを与えてるときがある
4.剣王の反撃より早くこちらの攻撃が当たるときがある
1.はプレイヤーがジャンプして降下するときに剣ボタンを
　押しっぱなしにすると剣が出たままになるのを利用して
　攻撃が長く当たるように間合いを調整する
　ただ剣の振り始めのタイミングがすごくシビア
　というか剣匠さんのコメントにあるようにランダムっぽい
2.はランダムで狙ってできないと思うけど
　その場合被ダメージ0で2ダメージ以上与えられる
3.と4.は剣王が攻撃を受けたときのよろけフレームが、
　1～6フレームで幅があり、1フレームのときはこちらの攻撃判定の
　持続時間中にもう一度攻撃が当たり、5フレーム以上のときは
　剣王の反撃より速く2撃目を入れることができる
　しかしこれも剣王のよろけ時間がランダムで狙って実践できません
どれも成功率は10～20％くらいですが
2.～4.が起こることを期待して1回の飛込みで2回(3回)剣を振って
盾を構えるという攻略に至りました
つまり2回被ダメージがあっても死なないのを前提にした攻略です
1.～4.までの現象が一度に2･3回起きれば、1回の飛び込みで倒すことも可能
(それを動画にしたかったがノーミスでとなると確率が低すぎて・・・)
動画では1.と4.が成功してます

[@荒和幸奇四十一]

何度プレイすればこんなに上手くなるんだ・・・

[@WARASUBOFACTORY]

プレイ内容とは関係無い話で恐縮ですが…このプレイ動画はゲーム基板(PCB)から直にRGB信号を取ってビデオ録画したモノなのでしょうか？ 自分の知ってる知識だと、基板録画はどうやってもピクセル滲みが生じてしまい、いわゆるMAME等のPC上でエミュを動かしてその画像をキャプチャ録画する方式みたいなグラフィックのドット角がカッチリと描画されたキレイな映像にはならない～という認識だったので。非常に驚いています。 このプレイ動画は映像のピクセルエッジがキレイに角々と描画されていて実に美しいです。何か特殊な機材などを使用しているのでしょうか？それとも単に自分の知識が90年代頃のモノで止まっていて、令和の時代では割と普通の事なのでしょうか…？撮影機材、プレイ環境など、差し支えなければ御教授願いたいです。

[@up2assembled]

私のところは、コントロールボックスRGB出力→分配器→一つは操作用モニター、もう一つは 録画用コンバーター(XRGBフレームマイスター1080p出力)→キャプチャーボード (SC-512N1-L/DVI無圧縮avi1080p取込み)→AviUtlで編集mp4という感じです だいぶ前に作った環境なので、今ならもっといいやり方があるんじゃないかと思います コンバーターによって色合いにクセがあるようで微妙に気に入らない部分もあるんですが 修正する技術力が無い・・・

[@WARASUBOFACTORY]

@@up2assembled 早速の返信、ありがとうございます。 その「XRGBフレームマイスター」てのが、ゲーム基板からのRGB信号をイイ感じにデジタル画像化してくれてる感じでしょうかね。自分の頃は、基板からプレイ動画を撮影する際には、コントロールボックスの映像出力をそのまま直に「VHSビデオ機器」に繋げて録画してましたので(笑)。フレームとかもズレてましたし、とにかく映像の滲みが酷かった記憶しかありません。 KZbin上でも時々、色んなゲーム基板から録画したプレイ動画が投稿されていますが、どれも画質が良くない感じだったので、自分の頃と比べても余り録画技術は進歩していないのかと思っていましたが…。その「映像信号コンバータ」の種類や性能によって出来上がりがピンきりになるのかもしれませんね。 P.S. 編集ソフトの機能にもよりますが。物理機器の方で色々と調整を完璧に行うのは非常に手間がかかりますので、よほど変になっていない限り、とりあえず初期設定というか安定録画可能な設定でアナログ映像として素材録画してしまい。その後にAVIやMPEG形式のデジタル動画に変換してから、それを色々と色調整とか行う方が編集作業的にも楽だと思いますよ。 人間の目基準だとどうしてもファジー感覚になるので、タイトル画面とかのスクショ画像をMAME版と比較しながら色合わせ等を行い、その色補正数値を一括で動画の方にもデジタル処理する感じでいいんじゃないかと思います。

[@up2assembled]

@@WARASUBOFACTORYアドバイスありがとうございます 私もちょっと聞きたいことがあるんですが このゲームのラスボスは最初に停止していて、こちらの攻撃が先にできるんですが その攻撃が同じ間合い(ドット単位)、同じタイミング(フレーム単位)で 攻撃してもヒットするときとガードになるときがあって、そういう反応は 他の対戦格闘のCPUでも割とあったりしますか？やっぱりランダムなのかなぁと思ったので

[@WARASUBOFACTORY]

@@up2assembled ＞ヒットorガード 結論から言えば「ゲームによる」としか。結局は全てはゲーム内のプログラム次第というか、どういった処理ルーチンを組んでいるのかに依存しますので。 例えば『餓狼伝説 (1991/SNK)』では通常のR中であれば、プレイヤキャラとCOMのお互いの打撃技を同時にカチ合わせる事により、いわゆる「相打ち」が発生しますが。これを互いの体力をギリギリまで減らして後1発でKOになる様な状態にしてから実行すると、何故かその最後の瞬間だけは絶対に「相打ち」が発生せずにプレイヤキャラかCOMキャラのどちらかが必ず生き残り、スト2みたいな "DKO" は絶対に発生しないのですが。これは内部プログラムのKO判定処理が1P側と2P側(COM側)で同じ1フレーム内に同時処理が完結されず、時間差で先に1P側から判定が行われた後に次のフレームに以降した後で2P側のKO判定が処理されるために起こる怪奇現象です(従ってプレイヤキャラ、COMキャラを問わずに2P側に居る方が必ず生き残る)。 同じCAPCOM社のゲームであれば『ストリートファイターII (1991/CAPCOM)』でも。通常、格闘ゲームの常識と言うか、相手の攻撃はレバーを後ろ方向へ入れて置く事で自動的に「ガード」になるシステムになっていますが。一部の技がガード不能になるバグというか仕様があって、それは「攻撃発生が1フレームの技は密着状態だとガード不能になる」というモノです。厳密に言うと「1/2でガード不能になる」という事が分かっています。ブランカの「ローリング」とか、サガットの「アッパーカット」がこれに該当します。 これらは恐らく1990年代前半のPCB性能だと演算速度に不安があったので、幾つかの処理が重なって重くなりそうな場合には、画面描画が遅れる様な「処理落ち」をさせる事無くスムーズにゲーム進行を処理するために、意図的に判定処理を分散させて同一フレーム内で処理させずに、次フレームへ持ち越して処理させる事によってプレイヤに体感での遅延を感じさせない様な内部処理をおこなっているせいではないかと推測します。逆に考えなしに全ての処理を漫然とゲーム内で発生した順に次々と立て続けに処理させる様なプログラムならば、複数の処理が1フレーム内に集中してしまった時には『グラディウス (1985/konami)』みたいな "処理落ち" が発生してしまいます。 今でこそ「処理落ち」は一種の演出として認められていますが。少なくとも1980年～1990年代前半くらいまでは「プログラマーの恥」として認識されていましたし、あってはならない事だという認識が一般的でしたので。当時のプログラマー達はあの手この手の裏技的ハックを駆使して、何としても「処理落ちだけは回避する」というのがまともなプログラマーの矜持だった様に思います。 スト2の「ガード不能」の事例も、その技が発生した瞬間の処理で「1/2で～」みたいになっている訳では無く、恐らく「奇数フレーム時は攻撃側の処理を優先し、偶数フレーム時は防御側の処理を優先」みたいな感じで内部処理を行っているため、結果的に「1/2でガード不能=ランダム」みたいになっているのだと思います。この『闘いの挽歌』でも恐らく似た様な内部処理が行われた結果、プレイヤキャラ側の攻撃開始の距離px数等は同一であるにも関わらず、恐らくはゲーム基板の起動fps数(電源ON時間)によって結果にランダム性が生じているのではないかなと推測します。 こういった「フレーム単位での厳密な計測」は実機PCBを用いてだと非常に困難であり、こういったフレーム関連の検証作業は事実上、MAME等のエミュ環境でしか検証不可能だと思われます。

[@up2assembled]

@@WARASUBOFACTORY 想像以上の詳細な解説ありがとうございました 大変勉強になりました