約 3,023,089 件
https://w.atwiki.jp/dqmb/pages/993.html
キングレオ このページはAC版のレジェンドクエストIVで敵として登場するキングレオについて書かれています。 →ビクトリー レジェンドクエスト時 →ビクトリー モンスターカード版 HP ちから かしこさ みのまもり すばやさ 回避率 3100 254 74 89 21 ★ 属性耐性 つよい 灼熱/氷 よわい 雷・風属性の攻撃/爆発呪文/獣系特攻 状態異常耐性 つよい 精神的行動不能/さそうおどり/マネマネ/武器破壊 よわい 毒/幻/かわいいおどり/モシャス/ラーのかがみ/正義のソロバン/天使の眼差し 技名 種類 対象 属性 威力★ 補足 ねっぷうのいき ブレス 敵全体 炎 百獣拳 物理 敵単体 打撃・風 2回攻撃 特徴 レジェンドクエストIV第1章に登場するモンスター。 プレイヤー使用時とは違い、百獣拳が2回攻撃になっている。
https://w.atwiki.jp/houseofhero/pages/688.html
マスターレジスト シスター、プリースト系が使う最高のスキル技。 全員のダウンを含む状態異常を全て治癒する。 ハイパワーレジストと比較してもその性能は群を抜く。 ただし、ダウンを治癒できるとは言え、 瀕死状態で復活してくるので、すぐに体力回復の必要があるため、 この魔法を使用したからと言って油断は出来ない。
https://w.atwiki.jp/irosumass/pages/591.html
▽メニュー一覧 オリジナルキャラクター バトディマジ3兄弟 我らバトディマジ3兄弟!3匹の恐竜に復讐するのだ!弱すぎるとは言わさん! 剣担当のバトール、守り担当のディフェース、魔法担当のマジークからなる三つ子の石人。一応弱いけどね。 ボタメンムリス オデ達はダークレジスタンスの兵士なんだな~我々は…上からの命令でここまで来た… 太っちょのオークのボタメン、ガリガリとやせ細っているグールのムリスからなる2人組。 レックスジェネラル 身体を引き千切る迄、このジュラシック・ハンドからは逃げられはせん! コルテックスが手塩にかけて育てたダークレジスタンスのグラトニーズNo.1。ティラノサウルスと融合したビショップ。頭部は実はカモフラージュであり、右腕のジュラシック・ハンドが本体。 ギガホーン お前ら!!戦う気あるのか!!! コルテックスが手塩にかけて育てたダークレジスタンスのグラトニーズNo.2。一本角が付いた短気なコモドオオトカゲ。ファイターが戦う事を怠ると、「戦う気、あるのか!?」と言って癇癪を起こす。
https://w.atwiki.jp/bwm_synthesis/pages/276.html
942:睡蓮 2006/04/05(水)21 10 08 ID wQeTYfSCO イレジスタブルは彼に直接会う際に自分のこめかみにほんの少し擦り込み、 彼の目をしっかりと見て話すといいですよ。 あと、彼の荷物か服か座っている椅子にからないようにつけておくのもオススメです。(^-^)
https://w.atwiki.jp/yukimi0/pages/113.html
レジスタンスの設定に合わせてなんだけど、各地のレジスタンスと戦っているのはとりあえず その国固有の軍隊でいいのかな? それとも、各国に統一連合政府の軍隊が配備してあって、それが出動な案もあるのだけど・・・。 後半の一斉蜂起の時に、国保持のMSがないといけないから。 主権返上(切り捨てること可能だけどね)した国には統一連合軍がいるでいいのかな。 もしくは1話プロットの平和式典会場は、統一国家を樹立することを目指した会議・声明の後の 式典とか まず、レジスタンスがMSが使用してきたときには、まず国の軍隊が鎮圧に向かう。 それで上手く裁けないときには統一連合軍が協力にくる、命令がないと動けないし統一連合軍。 ある程度の成功をレジスタンスが収めているなら、描写の中で連合軍機体がでても不自然じゃない。 問題はPG。ラクスのとこにいつでもいるとなると、迅速な行動ができない。さすがに移動時間を 考慮しなければいけないから。またPG基地を遠くから見張っていればPGが出動状態にあるか どうか分かる。(そんな情報をレジスタンスに売る情報屋がいてもいいかも) PGの半分がラクスの手元にいて、残りの半分は、順次各地域を巡回しながら警戒に当たって いるとしてもいいけど、世界規模での巡回なんて、激しくエネルギーと経費の無駄遣い。 出勤なら一食用意でいいけど、朝昼晩の食費やら、待機状態にある母艦と 稼動中にある母艦にかかる費用の差、地味に見えてお金は結構使う。 ま、そんな無駄遣いをラクスしてそうだけどw PGの動きは、この先、「ぎゃー、PGがでてきたぞー!」の説得力を持たすために必要だから 今の議論がおわったら叩いてくれると嬉しい。 各地のレジスタンスはPGが出張ってくると、動きをとりあえず静かにすることでやりすごせるし。 PGがどこどこにいる>レジスタンスの横のつながりで情報を流す>一番PGが現場到着まで時間が かかる地域で行動を起こす>PGがやってくる>静かにして(以下略 あと、世界統一連合政府の施設やら、PGの本拠地は、今や世界の中心となったオーブに あるってことでいいのかな?
https://w.atwiki.jp/magicman/pages/49594.html
レジスタンス・アクア・ガード レジスタンス・アクア・ガード C 水 3 クリーチャー:レジスタンス/リキッド・ピープル 1000 ■ブロッカー ■このクリーチャーは攻撃できない。 ■レジスタンス・コミュニケーション:このクリーチャーが出た時、自分のバトルゾーンにあるレジスタンスの数、カードを1枚引く。 作者:master ワープ先 DM24RP55 「新融合大戦」 評価(1) 選択肢 投票 壊れ (0) 強 (0) 良 (0) 弱 (0) 評価(2) 名前 コメント
https://w.atwiki.jp/imops-forth/pages/15.html
レジスタ割当 前提問題 Forth系の言語の場合、構文解析や意味解析はコンパイラをつくる時点では考える必要がない。詳細はプログラミング段階に回せるからだ。すると考えなければならないのは初っ端から最適化ということになる。今日のコンピュータはほとんどがレジスタマシンであるため、レジスタをどのように割り当てるかがまずは最重要課題となる。 レジスタマシンとは、レジスタと呼ばれる小さく高速な内部記憶装置を備えたコンピュータのことと思って良い。レジスタは変数の一種と考えてもよい。数値やメモリ内のデータをできるだけレジスタに保持して処理することで高速な処理が可能となる。64ビットマシンといわれるのは、このレジスタ1本で2進数の64桁まで記憶可能な機械のことである。32ビットなら32桁である。x86は古い汎用機仕様であるため、もともとは、このレジスタは8本しかない。64ビット(8バイト)に拡張された際に個数が倍増され16本となった。64ビットモードは、これにさらに浮動小数点数(若干誤差のある小数)も整数も扱えるベクトル演算(一つの命令で並行して何個かの四則演算を同時にできる:最近は英語に似せてベクターということが多いようだが、自分にとってはベクトルは日本語だ)用の128ビット(16バイト)レジスタ16本が追加された。従来x86で小数演算に用いられた80ビットFPUレジスタ(x87)については今も8本に止まっているため、x86-64最適化の解説本では、通常の小数演算に関しても128ビットベクトルレジスタの下半分のビットを使うことが推奨されている。64ビットでいわゆるダブル(double)小数の規格を満たす。Mac OS X(あるいはGCCというべきか)はその推奨に遵っているようだ。iMopsでも同様である。 従来のx86から見れば16個のレジスタは極めて多いように見えるのかもしれないが、PowerMopsが稼働するPowerPCという機械は、整数および小数用に各32本のレジスタをもっている。さらに倍、である!これはRISCとCISCという仕組みの違いも絡む。しかし、概して言えば、レジスタが多い方が最適化しやすい。8本だと通常数値へのレジスタ利用は一つか二つが限度でほとんどあてにできない。逆に言えば最適なレジスタ割当など考えなくてもほぼ決まっている。16本あればまあまあ割り当てられるがまだ窮屈である。そして32本もあれば、もうふんだんにあるといって良い感じである — ただしforthを前提した場合であるが— 。16本というのは特に整数レジスタでは微妙なところなのである。ちなみに、コンパイラ技術ではレジスタ割当は高等な分野とされているらしいが、英文のコンパイラ上級テキストでも論文等でも、大抵は仮想的なRISCマシンでレジスタがふんだんにある状況を想定している。デスクトップで圧倒的なシェアのx86はCISCであるしレジスタ数も少ないので、あまり実践的想定とは言えない。スマートフォンなどで利用が拡大したARMはRISCだがレジスタ数は16本に止まる。(新しい64ビット規格では32本に増えたようである。) そのようなわけで、16本の整数レジスタという微妙な数で最適化を目指すことになるわけである。ちなみに、小数レジスタの方は、16本もあれば十分という感じだった。整数レジスタと小数レジスタのこのような状況の差異は、メモリーアドレスは整数とされているという事実からくる。小数レジスタも実際はベクトルレジスタであるから整数を格納することはできるが、その値をメモリーアドレスとして扱う機械命令は組み込まれていないのである。そのため、内容となる値が整数であろうが小数であろうが、メモリーとの間で値をやり取りするときには必ず整数レジスタを一つそのために消費しなければならないことになる。それが整数値処理に割り当てられるレジスタを圧迫するのである。他方で小数レジスタは数値のみを扱えば良いので負担は軽く、同じ16でもその使用感は大きく異なるのである。 ノードグラフ レジスタ割当はノードグラフで考える。 ここでいうグラフは、いわゆるグラフ理論の有限グラフだが、有限個のノード(結節点)の関連あるもの同士をエッジ(辺)で結んだもの、というイメージで良い。iMopsではこれをそのまま実装した。エッジは双方向リンクである。ノードとして何を採るかは色々あり得るのかも知れないが、iMopsではスタックアイテムを採った。普通の言語なら変数を採るところだろう。ノードは初めて用いられたときに生まれ、最後に用いられたときに死ぬ。このライフタイムが重なりあうノード同士は干渉する(interfere)という。干渉しあうノードには同じレジスタを割り当てることはできない。 これは「隣り合う領域同士は異なる色でなければならない」という条件のもとで、分割された小領域を分割数より少ない色数で色分けする有名なアルゴリズム問題と同値であることがわかる。“如何なる場合も効率的に解ける手順”というものはないらしい。一般の有名変数を用いる言語なら確かにあらゆる場合が考えられる。しかし、forthの変数にはスタックというデータ構造がある。この構造の制約を加えると配分問題はほとんど自明になるように思われた。というのは、スタックでは演算に供せられるノードはトップから順に取られ、一度使われればアイテムはなくなる。トップアイテムは直ちに使われて費消されるが、スタックの下方に行けばいくほど、長い間使われないことになる。とすれば、トップから順にレジスタを割り当てて、足りない部分はメモリアイテムを割り当てるのが、当然、最も合理的な配分であり、それで最適化はできたことになる。もっとも、スタックを深くかき回すワードもないではないので、そのような場合は別のやり方が最適になる場合もあり得るが、それはよっぽどヘタクソなforthプログラムでもなければ滅多に起こらないことだ。 そのようなわけで、レジスタ割り当ての最適化は極めて簡単になる。まずはトップから、ということだ。 ノードの連結 ノードの連結の問題は、スタックというデータ構造の特性をその基本的前提としている。ノードの同一視・保持の問題であれば値の同一性が基準となる。しかし、ここでいうノードの連結においては、その格納場所としての同一性、つまり変数としての同定こそが本質的である。 スタックアイテムは、一度使用されるとそこで消費され、そのアイテムに対応するノードは、そこで消滅することになる。これがforth系のノードを追跡する場合の際立った特徴となる。したがって、演算とともにノードの消滅と生成が繰り返されるのである。 そのような、いわば切れ切れのノードを、値の関連によって連結しようとするのがここでの問題である。 専門書や論文で前提とされているRISCマシンでは、例えば足し算などの二項演算は、二つの入力と一つの出力について、都合三つのレジスタが利用できる場合がほとんどである。しかし、x86では、通常は、二つしか使えない。つまり、一方に他方を足すという操作になるのであって、入力値の一つは破壊されてしまう。 演算によってアイテムが破壊されるスタック演算にとっては、これはそれほど困った事態ではない。しかし、問題は、このようなマシンの演算特性とスタックの状態をノードグラフにおいて結びつけるということである。 具体的にいえば、x86では破壊される入力オペランドは出力オペランドと一致するので、それらに対応するノード同士をリンクしておくのである。そうすれば、リンクを辿って同じ変数(レジスタないしスタックセル)を割り当てられる。このリンクがノードの関連ということであり、これをすることでスタックの状態とマシン演算が結びつけられるのである。 結局、二項演算では、破壊的に演算結果が格納されるレジスタは関連ノードとして接続されていき、もう一方の入力は、値は残っているものの、スタックアイテムとしては放棄されるので、ノードとしては消滅することになる。 ちなみに、多くのRISCマシンのように、出力に別レジスタを利用できるのであれば、ノードはバラバラのままでよく、連結などする必要はない。 最適化しないやり方(ノードグラフ不要) x86はレジスタが少ない代わりに、メモリー領域を演算のオペランドにできる。ただし、メモリーアイテム同士で演算することはできない。少なくとも一方はレジスタでなければならない。そこで、直ちに考えつくのは、スタックのトップをまずレジスタにロードし、それに演算を加えていく、という手順である。このやり方だと、ノードグラフなど作る必要が無い。一つ一つの演算に適当なロード(ポップ)とストア(プッシュ)を付け足した上で順にコンパイルしていけばよいだけだ。 簡単な最適化 しかし、いちいちロード/ストアを繰り返すのは、キャッシュは効くとしても、いかにも効率が悪い。トップアイテムはできるだけレジスタに保持しておいて、どうしても必要なときだけスタックに退避させれば、それだけでも実行速度はかなり上がる。32ビットのforthの多くはこのような最適化を図っている。32ビットでは汎用レジスタが8本しかないが、アイテムキャッシュ用レジスタが一本だけあれば足りるこの方法なら実現可能である。この場合は、トップアイテムが現在どこにあるのかについて常時監視する必要があるだろう。しかし、グラフといえるほどのノードデータは必要ないのではないかと思われる。 最適化の方法 iMopsの採った効率化方法は単純である。演算をまず、ノードリストの上に書き込んでいくのである。最後に生まれたノードはスタックの頂上にある。演算は、生きているノードを上から取って演算項として、結果をまたノードリストに追加する。演算項として取られたノードは、その時点で死ぬわけである。操作一つ毎に、グローバルにステップを進めていく。X86はCISC型の演算で、二項演算は結果を入力項のどちらかに書き出すしかない。つまり、入力破壊的な演算である。そのため、演算項の一方は出力と同じレジスタ(メモリ)にならなければならない。そこで、スタックの下の入力ノードと出力ノードを相互リンクする。レジスタ割り当てのときには、このリンクを辿ってノードを統合していく。スタック操作ワードも、ノードのリンクで済ませる。結果として、演算直前のスタック操作は大抵何の動作も必要なくなる。 もう少し具体的に書いてみよう。 iMopsはヒープ上に256項目(1項目はスペア)のリストを持ち、各項目にはIDとして初期化の際に番号を打ってある。スタックノードは下方に伸びていく可能性もある(入力項目を消費していくばかりの場合)ので、リストのやや上方に基準点を設けて、そこから演算の疑似コンパイルを開始する。例えば、二項演算がコンパイルされれば、その入力として2つの項目が取られる。既に生きているノードが2つ以上あれば、そのトップ2つを取れば良いが、足りない場合は下方に伸ばしていく。そして、出力ノードは、上方に伸びるように取り、出力ノードの方に何の演算であるのかを書き込む。そして、入力ノードのID番号を入力として出力ノードのオペランドデータフィールドに記録し、上に述べたような双方向リンクを、通常は一方の入力ノードとの間に形成する。これを基本ブロックが尽きるまで続けていく。 リンクで結ばれているノードは、同じレジスターあるいは同じメモリーフィールドであることが望ましいノードである。したがって、レジスターをまずトップに配置し、リンクがあれば、それをたどって、リンクが尽きるか、他の理由によるレジスター配置と衝突(interfereないしcollision)する直前まで、同じレジスターを連続的に配備していく。スタックキャッシュ用のレジスターは4つ確保してあるので、その4つを、まだレジスター配置されていないノードを上から順に、同じようにたどって配置するのである。そして、レジスターを配置できなかったノードには、メモリーフィールドが配置される。スタックポインタからのオフセットが、そのアイテムを特徴付けることになる。 コンパイルに際しては、下の方のノードから演算表示を持つかどうかチェックし、コンパイルすべき演算表示をもつなら、入力ノードがレジスタかメモリーかをチェックしつつ、順にマシンインストラクションを生成していく。ノード上への演算記録が下から上へ向けて行われるのであるから、そのマシンインストラクションの順序は、記録された順序に一致するはずである。 基本は以上のようなものであって、若干の調整と、いくつかの細かい省略(最適化)が付け加えられるだけである。発想としては、多分、いわゆる「貪欲アルゴリズム」になるのだろう。考えは単純である。結果も、この場合は、まあまあのようである。 したがって、iMopsのコンパイルは二段構え(2パス)ともいえる。いったん、ノードグラフに書き込み、そこで可能な最適化を行っているからである。しかし、グローバルな最適化は特別にはしていない。Forth系言語の直截性のおかげで、構成もコーディングの段階で考えて確定できるからである。 具体的局面 iMopsでワードがコンパイルされるとき、具体的にコンパイルされると想定されているコードを説明してみよう。もちろん、これは予定通りに動いた場合であって、状況によってはあまりうまくいっていないかも知れない。 まず、ワード定義の初めの方にスタックアイテムを消費するインラインワード(四則演算やスタック操作ワードがそれに当たる)があれば、そこに必要な入力ノードと出力ノードが配置される。この位置では通常はレジスターが衝突することはない(4つまで)ので、入力出力ノードにはレジスタが割り当てられる。その場合、今定義しているワードの入力としてもレジスタが用いられるようになり、そのデータはワードに付帯するデータとしてディクショナリ内に記録される。このデータは、このワードをコールするときに利用される。 全般的レジスタ割り当てと実際のコンパイルは、何か他所でコロン定義したワードを呼び出したときや、ループ、条件分岐を引き金として起こる。 条件分岐もループも、基本的にはワード呼び出しの場合に準じた扱いになっている。したがって、ワードを呼び出す際に起こる状況を説明しよう。 まず、ワード呼び出しをコンパイラが感知したとき、呼び出されるワード(Callee)の入力および出力での利用レジスタのデータをディクショナリから読み取る。呼び出されるワードは既に機械語へのコンパイルが終わっているから、入出力レジスタの個数も、レジスタ番号も確定している。そこで、まず入力レジスタデータを用いて、まだコンパイルされていない呼び出し側の出力ノードに上からレジスタ配置する。 例えば、呼び出されるワードの入力レジスタが二つで、スタックの上からRDI、RSIであったとする。そのときは、ノードリストの生きているノードのうちトップ二つに、RDI、RSIを配置するのである。そして、まずRDIを、既に配置されているレジスタ状態と衝突しない限りにおいて、リンクをたどって遡る形で、最大限まで配置していく。これはいわゆるcoalescingされたノードである。次に、RSIが配置されたノードも、リンクが延ばせる限り、遡って配置する。 続いて、残ったノードにも、上から順にレジスタを配置する。これはつまり、後から生じたノードを優先的にレジスタ割り当てするということである。これも衝突しないように可能な限りリンクを遡って配置する。もしもリンクを遡ったとき、既にレジスタかメモリーが配置されているノードに行き当たったときには、その場所にMOV(ムーブ)オペレーションを指定しておく(まだコンパイルはしない)。どうしてもレジスタを割り当てられないノードにはメモリー上のスタックアイテムを指定しておく。 最後に、メモリーに指定したノードについて、スタックポインタからのオフセットを計算する。基本ブロックの最初の段階のスタックポインタの値が、ブロックの終了直前まで保持される。したがって、メモリーノードのオフセットは、それを基準として位置指定される。リンクされているノードはもちろん同じオフセットが入らなければならないので、まず、一つオフセットを指定したなら、その値を、やはりリンクを使って拡張していく。次からは、このノードと干渉するメモリーノードのオフセット指定に際して、このオフセットの値と矛盾しないように計算しなければならない。ここは少し面倒であった。 レジスタとメモリーの配置が終わったなら、基本ブロックの頭から、マシンコードに変換していく。 その後はスタックの調整をしなければならない。 まず、基本ブロック終了時に、呼び出されるワードの入力レジスタ個数2個を超えてスタックアイテムが生存している場合、それらのノードはスタックメモリーの適切な位置に格納しなければならない。生存ノードはメモリーノードの場合もレジスタノードの場合もあり得る。メモリーノードである場合は、臨時用のレジスタを経由してスタックの適当な場所に移す。実はこの部分がもっとも難しかった。というのは、スタックに残っているまだ有用な値を上書きすることなく、適切な順序で配置換えしなければならないからである。せっかくのレジスタアイテムまでここでメモリーに格納してしまうのは、スタックキャッシュ用のレジスタは、スクラッチで使うことになっているから、呼び出し前のレジスタの値が、戻ってきた後まで保持されている確率は極めて低いからである。加えて、決定的な理由は、呼び出されるワードの側は、入力レジスタ以外のスタックアイテムを使うかも知れず、そして、それはスタックメモリーにあると想定しているからである。 これで出力状態でのスタックの高さが決まる。これにあわせてスタックポインタレジスタの値を調整し、そしてCALLのインストラクションをコンパイルする。 終わりは、また新しいブロックを始める。その際に、呼び出されたワードの出力レジスタのデータを利用する。例えば、出力レジスタが1個で、RDIであったとすると、新しいブロックは、ノードが一つある所から始まる。そして、そのノードにはRDIが予め配置され、変更不可マークが付けられる。これが、次の基本ブロック開始時におけるスタックのトップアイテムになる。二つ目の基本ブロックからは、前のブロックの結果を前提につないでいかなければならないのである。 余談 コンパイラ設計ではレジスタ割り当て(割り付け)の問題は最適化の重要課題であるが、高級言語でも、プログラマーの意志で変数をレジスタに割り当てるように指定できたりする場合がある。この場合も、どの変数にレジスターを割り当てるのが最も実行速度向上に寄与するかを考える必要はある。しかし、現実問題としてこれは極めて難しい。「よく使う変数をレジスタに」という基準では、おそらくダメであろうということは容易に想像できる。これは、高級言語では、周辺がどういうコードで処理されているかが想像しにくいからである。 まず、レジスター変数を指定したとしても、どのレジスターが使用されるか当てにならない場合が多い。使用されるレジスターが、もともとサブルーチン呼び出しの前後に常に保存・回復されなければならないものとされているレジスターならばよいが、そうでない場合、レジスタ変数として使うことでメモリーへの保存・回復操作が追加されてしまうことになる。むしろ通常はスクラッチで使うレジスタを利用するから余分な保存・回復操作は普通は増える。レジスタ変数として指定したとしても、特別にレジスタの個数が多い場合を除けば、その変数のためのメモリー領域は、使おうが使うまいがとりあえず確保されなければならないだろう。大抵の言語では、サブルーチン(関数)のパラメターはスタックメモリー渡しであり、局所変数もスタックフレームをつくって割り当てる。そうだとすると、メモリーフレーム内にレジスタの内容を何度も保存したり読み出したりするくらいなら、原則としてメモリーレファレンスのまま使用し、必要に応じてレジスタに取り出す方が、高速な処理が期待できる。 実際、スタックフレームを固有データ域とするサブルーチンを単位とするような実装法の言語では、やみくもにレジスタ変数を指定しても効果は上がらないであろう。(昔はレジスタ変数指定をしても無視するコンパイラがほとんどだったとか。)リーフコール(他のルーチンを呼び出さないルーチン)最適化としてならば意味はあるかも知れない。けれども、その状況でさえ、コンパイラがどのようなコードを生成してくれるか分らない状況では、レジスタ変数指定しても高速化はほとんど当てにできないものと思われる。
https://w.atwiki.jp/magicman/pages/50142.html
レジスタンス・コミュニケーション レジスタンスコミュニケーションは自分のレジスタンスがバトルゾーンにある数、発動させる能力です。 ■レジスタンス・コミュニケーション:(トリガー)時、自分のバトルゾーンにあるレジスタンスの数(能力) 作者:master ワープ先 DM24RP55 「新融合大戦」 評価(1) 選択肢 投票 壊れ (0) 強 (0) 良 (0) 弱 (0) 評価(2) 名前 コメント
https://w.atwiki.jp/affiliking3/pages/27.html
■アフィリキング基本機能 A8Twiking 環境設定のやり方 広告管理のやり方 ソース管理のやり方 テンプレート設定のやり方 A8Twikingでアフィリエイト広告を自動ツイート RSSコレクター RSSコレクターの使い方 オートレジスター オートレジスターの使い方 オートブロガー オートブロガーの設定 自動投稿のやり方 ブックマークキング ブックマークキングの使い方
https://w.atwiki.jp/dq_dictionary_2han/pages/811.html
概要 Ⅳに登場するボスモンスター。 絶大な力を誇る魔族の雄で、獣王属最強の魔物。 銀の鬣に8本足を備えた青紫の体躯を持つ、高い魔力を誇る魔獣。 色違いのモンスターには【アームライオン】と【やつざきアニマル】がいる。 DQⅣ第四章 第五章 DQM1、2 DQMCH DQMJ2 DQMBⅡL カードゲーム DQⅣ 【キングレオ城】の主として君臨している。 元はキングレオ城の王子であったのだが、悪魔に魂を譲り渡して魔物と化し、【デスピサロ】の配下となった。 その後は革命を起こして前【キングレオ王】を牢屋に幽閉し、【バルザック】を新たな王に据えて【進化の秘法】を完成させようとしていた。 本編中では第四章と第五章で2回戦うことになる。 第四章 キングレオ城にてバルザックを倒した後にいきなり登場し、そのまま襲い掛かってくる。 このときのキングレオは異様に強く、圧倒的な攻撃力でこちらを全滅に追い込んでくる。 通常攻撃の他にベギラマと高熱のガスで攻撃し、ベホマで完全回復まで行う。その上FC版では完全2回行動。 HPは999で攻撃力と守備力も非常に高く、さらにHPの【自動回復】特性まで備えている。 普通に戦ったのでは勝てるわけがない所謂【負けバトル】である。 ちなみにDQ史上で初めてプレイヤーが直面する強制的な全滅でもある。 FC版ではターン毎の自動回復量が999、つまり全回復なので、正攻法ではどんなにレベルを上げても勝つことはできない。 データ改造を行ってマーニャとミネアに【キラーピアス】を装備させ、二人の力を255まで上げ、さらに【8逃げ技】も利用して、 1ターンで会心の一撃を四発(1発250超え×4)叩き込めれば、なんとか倒せるような相手である。 ただし、そうして無理やり勝ったところで報酬は何も無く、即座に再戦となる。 リメイク版では自動回復量が100になっているため、レベルさえ十分に上げれば正攻法で勝つことも一応可能。 とはいえ、キングレオが無限のMPでベホマを使用する関係上は多少の運も絡むため、勝つのが難しいことには変わりはない。 なお、リメイク版では負けた時と同様の展開になる。 負けた後は姉妹は牢屋に入れられるが、二人は投獄されていた前キングレオ王の手引きで脱獄に成功し、第五章へと繋がっていく。 ちなみにこの時のキングレオのステータスは以下の通り。 HP MP 攻撃力 守備力 素早さ 備考 FC版 999 ∞ 170 120 30 毎ターンHPが999回復/完全2回行動 リメイク版 150 毎ターンHPが100回復 第五章 第四章の時と変わらず、キングレオ城に居る。 第五章での戦いは負けバトルではないので、前回のような異様な戦闘力を持っているわけではないが、 それでも強力なボスであるという点は変わっていない。 FC版に比べリメイク版では非常に強化されている。 FC版では1~2回行動で、通常攻撃の他にギラと氷の息を使う。さらにターン毎にHPが50ポイント自動回復する。 ギラで10~18、氷の息で9~13ダメージと全体攻撃の威力こそ低めだが、 攻撃力が140と高いため、単純な打撃の2回攻撃でごっそりHPを持っていかれる。 攻撃呪文はギラ・バギ・デイン系が有効。それ以外は弱耐性。 補助呪文はルカニが確実に効き、マヌーサとマホトーンに強耐性。それ以外には完全耐性を持っている。 最も怖いのは通常攻撃なので、回復呪文も使えるクリフトをメンバーに入れてスクルトを使わせれば一気に楽になるだろう。 リメイク版では完全2回行動となり、通常攻撃の他にギラと凍える吹雪を使う。 さらにHPの自動回復特性がなくなった代わりにHPが2倍以上に増加している。 攻撃力は123と若干低下したが、ブレスの威力が40~60ダメージと大幅に上がっているのが脅威的。 しかもリメイク版の仲間のステータスはこの時点ではFC版よりも下がっており(特にLv17~19で主人公とアリーナのHPはFC版では160程なのに対し、リメイク版では120程度と、40程もの差があり大幅に下がっている)、そのLvまでに必要な経験値も若干多くなってしまっている。 1回の行動確率は攻撃:ギラ:吹雪=3:2:1で吹雪の使用頻度はそれほど高くないが、 運悪く凍える吹雪を2回連続使われてしまうと80~120もダメージを受けてしまい、 主人公・アリーナ・トルネコ以外の魔法系メンバーならそれだけで死亡する可能性が高い。 最初のターンで2回凍える吹雪を使われた人は【ムドー】を思い出し、Lvを急激に上げたり、先に他の地方を回った人が多い。 しかし、凍える吹雪の使用頻度は低いので、運が良ければ低レベルでもあっさり倒せるが、逆に運が悪ければ何度も全滅ということもある。 FC版をプレイした人の中には「あれ?こいつこんなに強かったか?」という感想を抱くこともありうる。 そのせいか公式ガイドブックでのコーミズの洞窟(魔法のカギ入手時)の目標レベルは22になっている。 耐性面では攻撃呪文に対する耐性が全くなくなり、マホトーン耐性が弱耐性へと下がった。 ギラを封じてしまうと凍える吹雪の使用頻度が上がるためマホトーンは使用すべきではないという説が流れているが、プレイした人は2回行動とも攻撃が大半だったという感想が多かったため、ダメージ量から考えれば使ったほうが良いだろう。 とにかく完全2回行動で凍える吹雪を吐くというのが非常に厄介なため、 どうしても勝てないようなら、先にロザリーヒル・エンドールのカジノなどに向かい強い装備を揃えるか、王家の墓ではぐれメタルを狩ってレベルを上げるなりすると良い。 マーニャが威力の高いメラミを覚えればかなり楽になるだろう。 倒すと必ずはがねのよろいを落としていく。 ちなみにこいつとバルザックにはマーニャとミネアの攻撃呪文が有効という共通点がある。 第四章での敗北のリベンジ的な意味もあるので、ストーリー重視なプレイヤーなら是非パーティに入れよう。 単純に戦力としてもマーニャのメラミ・ルカニとミネアのベホイミはこの戦いにおいて大きな助けとなる。 なお、FC版では倒した後は断末魔と共に消え去ってしまうが、リメイク版では元の王子の姿に戻る。 ただし、元の姿に戻った際にはそれまでの記憶を失い何も思い出せない状態となっている。 第五章でのキングレオのステータスは以下の通り。 HP MP 攻撃力 守備力 素早さ 備考 FC版 400 ∞ 140 80 35 毎ターンHPが50回復/1~2回行動 リメイク版 950 123 18 完全2回行動 DQM1、2 獣系のモンスターとして登場。 習得特技はギラ、つめたいいき、れんぞくこうげき。 本編五章でのキングレオそのものといったラインナップの特技を習得する。 強力なれんぞくこうげきを覚えられ、配合が簡単なので比較的早く作れる。 代表的な配合方法はパオーム同士を配合すること。 そのパオームもキラーエイプ同士の配合で誕生するので、 【お見合い】を活用すればより簡単に作ることができる。 その上成長も早いので、他の系統最強モンスターと違って育てるのが楽。 ステータスの成長も目覚しいので、パーティの補強に最適である。 また、進化の秘法繋がりか【デスピサロ】を血統にキングレオを配合すると【エスターク】が誕生する。 DQMCH 動物系のモンスターとして登場。 ランクはSで、重さは5。主にオーブのダンジョンに出現する。 習得特技はギラ、つめたいいき、ちからをためる。 ステータスは攻撃力と守備力の伸びが良い肉弾戦タイプ。 ランク転身での転身方法は動物系×動物系の心+エレメント系の心、 もしくはエレメント系×動物系の心+エレメント系の心。 特殊転身では【インフェルゴン】の心を二つ使って転身すれば全種族がキングレオとなる。 DQMJ2 魔獣系Aランクのモンスターとして登場。 バッファロンとモヒカントを配合すると生まれる。 野生のものは魔界の断崖エリア(物質系の柱がある場所)の頂上で、卵を挟んで二匹で向かい合っており、もちろんスカウト可能。 他にはGJに勝った際に無敵コレクションを指定すると、たまにレベル40のキングレオが貰える。 また、今回はキャプテン・クロウの海賊団が用心棒として雇っており、ボスとして戦う場面もある。 特性はメガボディとれんぞく(3回)、ヒャドブレイク。 能力はなかなか高く、特にHPや攻撃力は高いので、ヒャドブレイクの特性を活かしてブリザーラッシュで攻めると良い。 また、素で装備できる武器が剣、ヤリ、ムチ、ツメ、杖と多く、メタル狩りでも力を発揮するだろう。 耐性はザキ・息封じ無効、ギラ系を吸収、ベタンに弱い。 状態変化にはあまり強くないので、運用の際はその辺に注意が必要。 ライオンがモチーフのモンスターだけに、【闘神レオソード】の配合素材にもなるので、しっかり育てておこう。 スキルは「イオ&ギラ」。 DQMBⅡL 【レジェンドクエストⅣ】の第四章、及びモンスターバトルロードビクトリーの同レジェンドクエストの第一章で、合体モンスターのような位置づけで登場。 ステータスはHP:3200 ちから:254 かしこさ:74 みのまもり:89 すばやさ:21。 技は「ねっぷうの息」と「百獣拳」。 前者は炎属性の全体ブレス攻撃、後者は敵単体を何度も爪で切り裂く風属性付きの単体回攻撃。 モーションは武闘家【アームライオン】からの流用。 また、ビクトリー版レジェンドクエストⅣをAランク以上でクリアすると、こいつのカードを入手出来る。そうする事で、こちらも使用可能になる。 ステータスはHP:905 ちから:177 かしこさ:81 みのまもり:24 すばやさ:36に変更となった。 一枠モンスターになったため、攻撃と耐久の両方で降下が見られるが、すばやさは多少上がってる。 技の追加効果も変更になり、百獣拳は2回攻撃の代わりに、会心の一撃の発生率が上昇している。 さらに、武闘家と組む事で、ねっぷうの息が「百獣王の吐息」に変わる。 こちらは炎属性の「爆炎の吐息」か、氷属性で行動不能の追加効果のある「爆氷の吐息」のどちらかがランダムに発動する。 威力はとても高いが、相手の弱点によって使い分けが出来ないのが難点。 なお、モーションは変化前と変わらない。 また、どちらのレジェンドクエストでも、【銀のタロット】でプラス効果を出す必要がある。 カードゲーム FC版Ⅳが発売された後に「キングレオ」という名のカードゲームも発売されている。対象年齢は8歳~135歳(!)。 ルールは「UNO」とほぼ同じ。 しかしカードの絵柄にDQのキャラやモンスターが描かれていたり、 リバースがラナルータ、ドローツーがザラキ(挿絵はもちろんクリフト)などといったDQ風の名称になっている。 解説書は知る人ぞ知る「老師」と「弟子」が繰り広げるマンガでわかりやすく解説されている。 21世紀となったこの時代において入手するのはかなり困難であると思われる。