ヤルキデナイズド

Unclassified Articles on Software and IT

Dark Souls: The Board Game ルールブック意訳

ダークソウルのボードゲームのルールブックを意訳しています。文章の構成は原文を踏襲していますが、文意が読み取りづらい箇所・絵や実物を見ないと分かりづらい箇所は適宜言い回しを変えたり、ヒントを補ったりしてあります。

2017年9月25日現在、

  • ゲームの準備
  • タイルとノード
  • キャラクター
  • 装備
  • 篝火タイル
  • 探索
  • 遭遇のセットアップ

は翻訳済みです。

  • 遭遇
  • 戦闘の基本
  • キャラクターの行動
  • 敵の行動
  • ボスとの遭遇
  • ボスの行動

は翻訳作業中です。

関連リンク:

  • 公式ルールブックの PDF

https://static1.squarespace.com/static/56728f72a128e6b1e548ec55/t/58ebed0b15d5db2d9d8ac36c/1491856693806/DS-Core-Rules-lores.pdf

https://static1.squarespace.com/static/56728f72a128e6b1e548ec55/t/58ed0050d1758e39150c58d6/149192712%0A2180/DS-Core-FAQ-2017-04-11.pdf


ゲームの準備

初期セットアップ

1. タイルのセットアップ

まず探索の舞台となる世界を表すタイルを配置していく。

  • 通常タイル:黄色や赤などの丸いマス目が描かれているタイル
  • 篝火タイル:篝火が描かれているタイル
  • ミニボスタイル:端寄りにドクロのマスがあるタイル
  • メインボスタイルは中央にドクロ+王冠のマスがあるタイル

周囲に余裕がある場所に篝火タイルを置く。ミニボスタイルとメインボスタイルはしばらく使わないので除けておく。

残り6枚の通常タイルをシャッフルしランダムに4枚を選ぶ。篝火タイルを始点に、タイル四辺に描かれた出入口が繋がるようにして好きに並べる。選ばなかった残り2枚の通常タイルは使わないので箱に戻す。篝火タイルからもっとも遠い通常タイルの、他のタイルと接していない出入口に霧の入口トークンを置く。(ヒント:普通のタイルには両面あり、どちらを表にしてもよい。霧の入口は親指大の白い板。)

2. 篝火

篝火スパークダイヤルを篝火タイルに置く。ダイヤルの切り込みから見える数字は(6−プレイヤー人数)に合わせる。篝火ダイヤルの値は、パーティーが倒されるか、プレイヤーが篝火での休息を選んだときに1減らす。数値が0になったらそれ以上の休息はできず、その状態でパーティーが倒されるとプレイヤーはゲームに敗北する。

3. ボスの選択

ミニボスのモデル1体を好きに選び、そのミニボスの行動カードのセットと体力ダイヤルとミニボストレジャーカードを用意する。(ヒント:ミニボスの行動カードは大きいほうのカード。そのミニボスの絵が描いてある。ミニボストレジャーカードは小さいほうのカード。表面右上にそのミニボスのアイコンとオレンジのマークが描いてある。)

4. 遭遇カード

各タイルでキャラクターが遭遇する敵の配置は遭遇カードによって決まる。

遭遇カードをレベルごとの山に分けてそれぞれシャッフルする。(ヒント:遭遇カードは小さいほうのカードで、背面に紫の円+ソウルのマークが描かれている。レベル1〜3の3種類)

ミニボスのデータカード下辺に書いてある遭遇レベルを見て、対応するレベルと枚数の遭遇カードを山から引き、通常タイルの上に1枚ずつ裏向きにして置く。(ヒント:ミニボスのデータカードは、ミニボスの行動カードの中で下辺にソウルのマークが3つ描いてある1枚。)ただし、篝火タイルに近いほどレベルが低く、遠くなるにつれて高くなるように置いていく。使わなかった遭遇カードは除けておく。

5. キャラクター

(ヒント:「キャラクター」はプレイヤーの分身となる登場人物を指す。敵のことはキャラクターと呼ばない。)

各プレイヤーはキャラクターを好きに選び、キャラクターボード、キャラクターモデル、そのキャラクター用の初期装備カードを受け取る。(ヒント:初期装備カードは小さいほうのカード。表面右上に、キャラクターのクラスに応じた武器のアイコンが描いてある。)

初期装備の鎧カードを鎧スロットに置き、武器カードをキャラクターボードの右手・左手スロット、予備スロットに好きに置く。(ヒント:左右の手スロットにはそれぞれ1枚まで置ける。予備スロットには複数枚置ける。)エスト瓶トークン、ヒロイックアクショントークン、幸運トークン各1個を、表向き(絵が明るいほう)にして、ボードの対応するマークに置く。キャラクターモデルを篝火タイルに置く。キャラクターの集合をパーティーと呼ぶ。

ボードの4つのステータスバーの Base レベルに白いキューブを1個ずつ置く。

6. トレジャーデッキ

共通トレジャーカード、クラス別トレジャーカード(参加キャラクター分のみ、各クラス5枚)を裏向きにまとめてシャッフルし、トレジャーデッキとして篝火タイルに置く。(ヒント:トレジャーカードは小さいカード。共通トレジャーカードは表面右上に宝箱アイコンがあって、アイコンに他のマークが付加されていないもの。クラス別トレジャーカードは宝箱アイコンの上にクラスを表す白い武器マークがあり、かつ青いマークがないもの。)

7. トーク

残りのトークンを絵柄別に分け、プレイヤーの手の届く場所に置く。

ミニボス撃破後のメインボスセットアップ

配置されている篝火タイル以外のマップタイルを回収し、初期セットアップと同様の手順で配置しなおす。篝火スパークダイヤルを初期値まで回復する。

メインボスのフィギュアと行動カードのセットと体力ダイヤルを選ぶ。メインボスのデータカードを見て遭遇カードを選び初期セットアップと同様にタイルに配置する。

キャラクターモデルを篝火タイルに配置し、スパークを消費せずに休息効果を得る。(ヒント:休息によってすべてのキャラクターボード上のエスト瓶トークン、幸運トークン、ヒロイックアクショントークンを表向きにする。)

すでにあるトレジャーデッキに次のカードを加えてシャッフルする:クラス別の変異トレジャーカード(参加キャラクター分のみ、各クラス5枚)と、ランダムに5枚選んだ伝説のトレジャーカード。(ヒント:変異トレジャーカードは、トレジャーカード表面右上に宝箱アイコン+クラスを表す白い武器マーク+青いマークがあるもの。伝説のトレジャーカードはボスの顔アイコン+オレンジのマークがあるもの。)

(ヒント:ミニボスを倒したとき手に入れたミニボスのトレジャーカードはインベントリに置く。)

タイルとノード

基本

マップタイルに描かれた黄色・ピンク・赤のマス目をノードと呼ぶ。

  • ノードの種類
    • 黄色:基本ノード
    • 赤:遭遇ノード
    • ピンク:地形ノード
    • ドクロマーク:ミニボスノード
    • ドクロ+王冠マーク:メインボスノード
  • タイルの出入口のある辺に隣接する基本ノードは「進入ノード」でもある。遭遇時にキャラクターモデルを置く場所は、進入した出入口沿いの進入ノードのいずれかとする。
  • あるノードから縦横ナナメの8方向で隣り合うノードは、そのノードの「隣接ノード」と呼ぶ。

ノード間の移動

戦闘中、モデルはマップタイルのいずれかのノードに置かれていなければならない。モデルを動かすときはモデルのいるノードから隣接ノードへと動かす。

範囲

敵への攻撃や味方への支援効果には範囲が設定されている。(ヒント:範囲アイコン=ハルバードを振り下ろす絵柄の下に数字が描かれたアイコンを見よ。)範囲0なら、動作を行うモデルと動作の対象となるモデルが同じノードにいる必要がある。範囲1なら、動作の対象となるモデルが1つ離れたノード(またはより近いノード)にいる必要がある。範囲2以上も同様とする。範囲が無限 ∞ なら、動作の対象となるモデルはどのノードにいてもよい。

ノード上のモデル数の上限

戦闘中、1つのノードに複数のモデルを置くことがある。ただし1つのノードに置ける数には上限がある。

  • 1つのノードに置けるモデルは3つまで。4つめのモデルが進入すると他のモデルを押し出す。
  • 1つのノードに置けるボスモデルは1つまで。2つめのボスが進入すると1つめのボスモデルを押し出す。

(ヒント:押し出されるモデルの候補が複数ある場合、プレイヤーが好きに1つ選ぶ。押し出されたモデルはプレイヤーが好きに選んだ隣接ノードに置く。)

キャラクター

キャラクターボードにはキャラクターのすべての情報が記載されている。

  1. 名前(イラストの下)
  2. イラスト(右上の人間の絵)
  3. ヒロイックアクション Heroic Action (左上のテキスト)
  4. 装備スロット Equipment Slots (左側の長方形のスロット群)
  5. 耐久バー Endurance Bar (右下に並んだ10個の四角い穴)
  6. ステータス Stat Progression (右下の表)
  7. 挑発レベル Taunt Level (名前の左側の数字)
  8. ヒロイックアクショントークンスロット Heroic Action Token Slot (中央上の丸い囲み)
  9. 幸運トークンスロット Luck Token Slot (名前の左側の丸い囲み)
  10. エスト瓶トークンスロット Estus Flask Token Slot (中央下の丸い囲み)
  11. 残り火トークンスロット Ember Token Slot (左下の丸い囲み)

装備スロットにはキャラクターの武器・防具と鎧を置く。

耐久バーは戦闘中のキャラクターの残り体力を表す。

ステータスはキャラクターの4つのステータスを表す:筋力 Strength、技量 Dexterity、理力 Intelligence、信仰 Faith。ステータスの値は武器・防具・鎧を装備できるかどうかを決定する。

キャラクターの能力について

  • ヒロイックアクション:トークンが表のとき裏向きにして特殊なアクションを実行する。(ヒント:ヒロイックアクションの内容はキャラクターボード左上のテキストに書いてある。使えるタイミングはクラスごとに異なる。)
  • エスト瓶:トークンが表のとき裏向きにして、自分の耐久バーに置かれた黒キューブと赤キューブをすべて除去する。(ヒント:キャラクターの手番中のみいつでも使える。)
  • 幸運:トークンが表のとき裏向きにして、自分の攻撃・防御・回避の判定ダイスいずれか1個を振り直す。(ヒント:ダイスを振る行動をした直後に使える。)

以上の3つのトークンはゲーム開始時には表向きになっている。またパーティーが敗北するかプレイヤーが休息を選ぶかして篝火で休息したらすべて表向きにする。

(ヒント:残り火は装備のセクションで説明する。)

装備

装備カード

装備はキャラクターの戦闘能力を左右する。キャラクターはゲームの開始時に基本装備を持っているが、ゲームが進行するにつれてよりよい装備を入手することがある。装備カードには以下の情報が記載されている。

  1. 名前(イラストの上)
  2. イラスト(中央の絵)
  3. アクション(イラスト下の大きな囲み)
  4. カードタイプ(右上の一番上のアイコン)
  5. 装備スロット(右上の上から2番目、手のアイコン)
  6. 範囲(左上、ハルバードのアイコンと数字)
  7. ステータス要求値(イラストの左、4種のアイコンと数字が入った囲み)
  8. 防御(左下の盾型の囲みと数字)
  9. 魔力抵抗(防御の右隣の丸い囲みと数字)
  10. 回避(魔力抵抗の右隣のアイコンと数字)
  11. アップグレードスロット(回避の右隣のアイコンと数字)
  12. セットシンボル(右上の上から3番目、 DS と書かれたアイコン)

装備カードのアクションは戦闘中に使える攻撃や特殊効果を表示する。(「キャラクターの攻撃」セクションを見よ)

カードタイプはトレジャーとしての種類を表す。トレジャーデッキを準備するときに参照する。(「トレジャーデッキ」セクションを見よ)

(ヒント:以下、「武器」は盾や魔法なども含める。)

装備カードをキャラクターに装備するときはキャラクターボードの装備スロットに置く:

  • 鎧カードは鎧スロットに置く。
  • 左右の手スロットには各スロット1つまでの片手武器カードを置ける。または片方の手スロットに1つまでの両手武器カードを置けるが、その場合他方の手スロットには何も置けない。
  • プレイヤーは合計3つまでの武器を所持でき、手スロットに置いていないものは予備スロットに置く。予備スロットだけは複数枚の装備カードを置ける。

装備カードの範囲は敵への攻撃や味方への支援効果の基本範囲を表す。装備によってはアクションが固有の範囲を持つことがある。

ステータス要求値は装備するキャラクターのステータスが満たすべき値を表す。キャラクターの各ステータスが要求値と同じか上回っていれば装備できる。

アップグレードスロットは装備に追加できるアップグレードカードの上限数を表す。

セットシンボルはそのカードが Dark Souls: The Board Game の基本セットに属するか、拡張セットに属するかを表す。

アップグレードカード

アップグレードカードは他の装備カードの能力を強化できる。装備カードにつけられるアップグレードカードの枚数は装備のアップグレードスロットの値が上限となる。アップグレードを装備につけるときは、アップグレードカード下部のテキストが見えるようにずらして装備カードの下に重ねる。

アップグレードカードには武器につけられるものと鎧につけられるものがある。アップグレードカード左上のアイコンを見よ。

装備修飾子

装備カードのアクションには、ダイスの出目に加えるか引くかする固定値が書いてあることがある。

たとえばエストックの3スタミナ攻撃は黒ダイス3のアイコンの後ろに-1と書いてある。これは黒ダイス3つを振って出た目の合計値から1を引いたものをダメージとすることを表す。

残り火

プレイヤーが残り火カードをトレジャーデッキから引いたとき、残り火を持っていない好きなキャラクター1人のボードに残り火トークン1個を置く。(ヒント:残り火トークンに裏表はない。)

キャラクターが残り火トークンを持っている間ならいつでも、そのキャラクターが3以上のダメージを受けたとき1ダメージ軽減する。パーティーが敗北して篝火に戻ったらすべてのキャラクターボードの残り火トークンを取り除く。

残り火は1キャラクター1個まで持てる。すべてのキャラクターが残り火を持っているときにトレジャーデッキから残り火カードを引いたら、それをデッキに戻してシャッフルし、1枚引き直す。引き直すときソウルは消費しない。

篝火タイル

篝火タイルはパーティーの拠点を表し、戦闘中でなければいつでも戻ってくることができる。篝火タイルでは戦闘は起きないためノードはない。その代わりに篝火タイルはいくつかの重要な機能を持っている:

  1. 篝火
  2. トレジャーデッキ
  3. インベントリ
  4. ソウルキャッシュ
  5. 鍛冶屋アンドレ
  6. 火防女

篝火には篝火スパークダイヤルを置く。宝箱にはトレジャーデッキを置く。宝箱の横にはインベントリがあり、入手したトレジャーをまとめて置く。ソウルキャッシュには入手したソウルトークンを置く。

複数人プレイのときはソウルキャッシュが空の状態でゲームを始める。1人でプレイするときのみ16ソウルを置いた状態でゲームを始める。

篝火タイルでできること:

  • 鍛冶屋アンドレ
    • 1ソウル消費してトレジャーデッキからカードを1枚引く。
    • キャラクターボードの装備カードをインベントリに戻す。装備カードにアップグレードカードが重ねてあれば重ねたまま動かす。
    • インベントリの装備カードをキャラクターボードの装備スロットに置く。プレイヤーの各ステータスが装備カードの各ステータス要求値と等しいか上回る必要がある。装備カードにアップグレードカードが重ねてあればそのステータス要求値も同様にチェックする。またアップグレードカードが重ねてあれば重ねたまま動かす。
    • 鎧カードに鎧アップグレードカードをつけるか外すかする。
    • 武器カードに武器アップグレードカードをつける。武器アップグレードカードは一度つけたら外せないことに注意。武器カード+アップグレードカードをインベントリに置くときは外れないように分かりやすく置く。
  • 火防女
    • キャラクターの各ステータスを上げる。現在のステータスから次のステータスに上げるとき、以下のようにソウルを消費する:
      • Base → Tier 1:2ソウル
      • Tier 1 → Tier 2:4ソウル
      • Tier 2 → Tier 3:8ソウル
      • 例:Base から Tier 3 に一気に上げるには2+4+8=14ソウルを消費する。
    • 1ソウル消費していずれかのキャラクターボード上の幸運トークンを表向きにする。
  • 篝火
    • パーティーが戦闘に敗北するか、プレイヤーが休息を選ぶかすると、篝火で休息効果を得ることができる。
      • 篝火スパークダイヤルの値を1減らす。
      • すべてのキャラクターボード上のエスト瓶トークン、ヒロイックアクショントークン、幸運トークンを表向きにする。
      • すべてのタイル上の遭遇カードを裏向きにする。(ヒント:休息効果で裏向きにした遭遇カードのあるタイルに進入したら通常通りに遭遇→戦闘を行うこと。)

探索

ゲーム中、パーティーはタイル四辺の出入口を通じて隣のタイルに移動できる。ただし戦闘中はタイル間を移動できない。裏向きの遭遇カードのあるタイルにパーティーが進入すると遭遇状態となり、遭遇カードを表向きにして敵との戦闘を開始する。敵との戦闘に勝利したら遭遇カードは表向きのまま置いておく。表向きの遭遇カードがあるタイルでは遭遇状態にならない。霧の入口のあるマップタイルで戦闘に勝利して遭遇カードを表にしたら、以降は遭遇状態でなければいつでもボス戦を開始できる。

パーティーが敗北するかプレイヤーが選ぶかして篝火で休息したら、すべてのタイルの遭遇カードを裏向きにする。裏向きの遭遇カードがあるタイルに進入したら再び遭遇状態になる。(ヒント:篝火で休息したら霧の入口の状態もリセットされる。ボス戦を始めるには再び霧の入口のあるタイルを攻略しなければならない。)

遭遇のセットアップ

敵と遭遇したら、そのタイルに敵モデルや地形トークンを配置して戦闘の準備をする。

(ヒント:1ゲーム中に同じタイルで何度も敵と遭遇することがあるため、前回の遭遇で配置した地形トークンが残っていることがある。その場合、配置済みの地形トークンが以下の状態であることを確かめる:

  • トークンはすべて樽の壊れていない面が上向きになっている。
  • トークンはすべて黄色い罠マークが上向きになっている。
  • 宝箱トークンは開いた宝箱の面が上向きになっている。(ヒント:つまり、一度開けた宝箱はパーティーが篝火で休息しても復活しない。)

  • 遭遇カードの情報をもとに、タイルに敵モデルと地形(墓石、樽、宝箱)トークンを配置する。
  • 遭遇カード下辺に罠マークが描かれているなら、使っていない罠トークンすべてを裏返してよく混ぜ、タイルの基本ノードに1個ずつ裏向きで置く。ただしタイルの出入口のある辺に隣接する基本ノードには置かない。

地形

地形には墓石、樽、宝箱、罠がある。

  • 墓石:モデルは墓石のあるノードに進入できない。
  • 樽:モデルは壊れていない樽のあるノードに進入できない。ただしキャラクターは樽を壊すことができる。キャラクターは1スタミナ消費することで樽のあるノードに(歩行または走行するか回避によって移動することで)進入できる。(ヒント:押し出しを受けたことにより移動して進入することはできない。)進入したら樽トークンの樽が壊れた絵柄を上向きにし、樽が壊れたことを表す。壊れた樽のあるノードには進入でき、スタミナは消費しない。
  • モデルは宝箱のあるノードに進入できない。宝箱はそのタイルのすべての敵を倒した後で開けられる。開けたらトレジャーカードデッキから2枚引く。引いたアイテムをいずれかのキャラクターが装備可能ならすぐに装備してもよい。装備しなかったカードは篝火タイルのインベントリに表向きで置く。
  • 罠:戦闘中、罠マークが上向きになった罠トークンのあるノードにキャラクターが進入したら、トークンを裏返して罠を発動する。罠にダメージが書かれていれば、キャラクターはそのダメージを受ける。キャラクターはダメージを防御できないが回避を試みることはできる。一度発動した罠は、その遭遇中は表のままにし、二度と発動しない。罠は敵によっては発動しない。

遭遇

XXX 翻訳中…

遭遇の基本

メモ:

  • そのゲームの初めての戦闘なら、最初に行動するキャラクターを好きに選ぶ。そうでなければ、初回行動トークンを持つキャラクターが最初に行動する。(ヒント:戦闘が終了したとき、最後に行動したキャラクターの次に行動するはずだったキャラクターは初回行動トークンを得る)。
  • 最初に行動するキャラクターはアグロトークンを得る。(ヒント:アグロトークンはドクロマークのトークン。 Aggro は「敵に狙われている状態」という意味。)
  • 戦闘を開始する。戦闘では1キャラクターが行動→すべての敵が行動→次のキャラクターが行動(時計回りの順)→すべての敵が行動……を繰り返す。
  • 敵をすべて倒し、キャラクターが誰も死んでいなかったらパーティーの勝利となる。キャラクターが1人でも死んだ時点でパーティーは敗北し、篝火タイルに戻って休息を行う。
  • 遭遇を開始したら、パーティーが勝利または敗北するまで戦闘をやめることはできず、そのタイルから他のタイルへ移動することはできない。

遭遇の終了処理

パーティーがすべての敵を倒し、どのキャラクターも倒されていないなら、パーティーは戦闘に勝利し、遭遇を終了する。いずれかのキャラクターが倒されたら、その時点でパーティーは戦闘に敗北し、遭遇を終了する。敗北した時点で篝火スパークダイヤルの値が0なら、プレイヤーはゲームに敗北し、ゲームを終了する。

遭遇を終了するとき、勝利しても敗北しても以下の処理を行う:

  • 最後に行動したプレイヤーの次の番のプレイヤーに初回行動トークンを渡す。
  • すべてのキャラクターボードの耐久バーに置かれたすべてのキューブを取り除く。
  • そのタイル上のすべての樽トークンを、樽の壊れていない面を上向きにして置く。
  • そのタイル上のすべての罠トークンを、黄色い罠マークの面を面を上向きにして置く。

勝利したらさらに以下の処理を行う:

  • ボスとの遭遇でなければ、プレイヤー人数×2ソウルをソウルキャッシュに置く。
  • ボスとの戦闘なら、篝火スパークダイヤルの現在の値×プレイヤー人数×1ソウルをソウルキャッシュに置く。
  • そのタイルに宝箱トークンがあれば、宝箱を開けてもよい。(「探索」の「地形」セクションを見よ。)

敗北したらさらに以下の処理を行う:

  • 以前の戦闘に敗北して落としたソウルトークンがいずれかのタイルに残っていれば、それをすべて破棄する。
  • 倒されたキャラクターはソウルを落とす。そのキャラクターがいたノードに、ソウルキャッシュにあるすべてのソウルトークンを置く。
  • すべてのキャラクターモデルを篝火タイルに移動する。
  • 篝火スパークダイヤルの値を1減らし、篝火による休息効果を得る。

落としたソウルは、そのタイルでふたたび遭遇したときに、いずれかのキャラクターがソウルトークンの置かれたノードに進入することで回収できる。回収したソウルトークンはすべてソウルキャッシュに置く。

戦闘の基本

XXX 翻訳中…

メモ:

  • 攻撃の対象は普通1つのノードの1体、または1つのノードの全員(味方同士、敵同士は攻撃し合わない)。ボスのみ複数ノードへの攻撃ができる。
  • 攻撃ダメージを防御または魔法抵抗によって軽減しダメージが0になっても攻撃はヒットした扱いになる。ヒットすれば押し出しなどの効果は受ける。
  • 攻撃は左右の手スロットに装備した武器を使って行う。武器を2つ装備していればそれぞれ1回ずつ攻撃できる。
  • 攻撃の回避が成功したらヒットした扱いにならない。
  • スタミナを消費すると耐久バーに左から黒キューブを置く。1スタミナにつき1個。
  • ダメージを受けると耐久バーに右から赤キューブを置く。1ダメージにつき1個。
  • 耐久バーに10個キューブが溜まるとキャラクターは倒される。一人でも倒されるとパーティーは敗北する。

押し出しはスタミナを消費しない。ボスは押し出されない。押し出し先はアクションしたモデルから最も遠い隣接ノード。候補が複数あればプレイヤーが好きに選ぶ。 敵の移動に押し出し効果がある場合、移動先ノードのプレイヤーキャラクターは押し出される先を選んで移動する。

コンディションは複数種類を同時に受けることがある。同一の効果は重複しない。コンディションを持つモデルの行動が終わったらコンディションを取り除く。また遭遇が終わったらキャラクターからコンディションを取り除く。 出血:攻撃されたら追加ダメージ2を受ける。一度攻撃を受けたら出血効果は解消される。 毒:行動の終わりに1ダメージを受ける。 凍傷:歩行、走行、回避の消費スタミナが1増える。敵が凍傷になったら、移動力の値を1減らす。 よろめき(stagger):武器アクションの消費スタミナが1増える。敵がよろめき状態になったら、攻撃力を1減らす。

キャラクターの行動

XXX 翻訳中…

キャラクターの行動開始時に以下の処理を行う。

  • スタミナを2得る。(=耐久バーから黒キューブを2個取り除く)
  • アグロトークンを得る。
  • 左右の手スロットと予備スロットの武器を入れ替えてもよい。アップグレードカードは(あれば)武器カードに重ねたまま動かす。

次に移動と攻撃を行う。どちらが先でもいいが、移動→攻撃→移動はできない。

キャラクターの移動には3種類ある。

  • 歩行:1行動中に1回だけ。スタミナ消費なしで1ノードに移動する。
  • 走行:1行動中に何度でも。1スタミナを消費して1ノード移動する。
  • 回避:敵の行動中に、キャラクターが攻撃を受けたら回避を試みることができる。移動したければ1ノード移動し、次に回避判定ダイスを振る。

(ヒント:移動は必ず隣接ノードを経由する。上記の移動のほかに、押し出し効果を受けてノードを移動することがある。)

攻撃は左右の手スロットに装備した武器を使い、最大1回まで行える。武器には何段階かの強さの攻撃方法を持つ。 [n] の数のスタミナを消費し、描かれた色と個数の攻撃判定ダイスを振って、出目の合計を攻撃ダメージとする。

XXX 攻撃ダメージの処理について……

攻撃のアイコンについて:

  • 黒、青、オレンジのダイスアイコン:攻撃判定ダイス。出目は黒<青<オレンジの順で強い。
  • 独自の射程(武器を振るアイコンと数字):攻撃によっては武器カードに描かれた基本の射程とは異なる射程を持つ。
  • シフト(十字アイコンと数字):シフトアイコンがダイスアイコンの前にあれば、最大で表示された数のノードぶん、攻撃の前に移動できる。シフトアイコンがダイスアイコンの後ろにあれば、同様に攻撃の後に移動できる。移動はスタミナを消費せず、歩行や走行としてカウントされない。
  • 範囲攻撃(●アイコン):攻撃対象の1ノードにいるすべての敵にダメージ。攻撃判定ダイスを振るのは1回だけ(=敵ごとに振らない)。
  • 遠距離武器(槍のアイコンと0):自分と同じノードにいる敵を攻撃対象にできない。主に槍と弓につく。
  • 連続攻撃(回る矢印のアイコンと数字):攻撃を複数回行う。1回ごとに攻撃方法を選んで攻撃判定ダイスを振る。

敵の行動

脅威レベルの高い敵から順に行動する。同レベルならプレイヤーが順番を選ぶ。(ヒント:脅威レベルは敵の行動カード左上の数字。)

敵の移動パターン(敵の行動カードの十字マークで表される):

  • 標的となるキャラクターを定める。
    • 十字マーク右上のアイコンが○:もっとも近いキャラクターを標的とする。
      • もっとも近いキャラクターが複数いる場合、次の条件を順に見てマッチするキャラクターを選ぶ:アグロトークンを持つ→挑発(Taunt)レベルが高い
    • 十字マーク右上のアイコンがドクロ:アグロトークンを持つキャラクターを標的とする。
  • 十字マークの上辺の数字ぶんノードを移動して標的に近づく、または下辺の数字ぶん標的から遠ざかる。
    • 近づいて標的と同じノードに到達するか、遠ざかってマップタイルの隅に接したらそれ以上移動しない。
    • 複数ノードを移動する場合、標的は最初に決めたキャラクターとする=移動1ステップごとに判定しなおすことはない。
  • 十字マーク左上のアイコンが盾(盾に数字なし):押し出し
    • まず敵と同じノードにいるキャラクターを押し出す。押し出しを受けたキャラクターはプレイヤーが好きに選んだ隣接ノードに動かす。(ヒント:敵の標的が最初から敵と同じノードにいたり、凍傷の効果などで敵の移動可能なノード数が0の場合も、この押し出しは発生する。)
    • 敵が1ノード以上移動する場合、1ノード移動して移動先のノードにいるキャラクターをすべて押し出し、移動可能なノード数ぶんこれを繰り返す。(ヒント:敵が複数ノードを移動するとき、同じキャラクターが何度も押し出しを受けることがありうる。)
  • 十字マーク左上のアイコンが盾(盾に数字あり):押し出しダメージ
    • 上記と同様に、まず敵と同じノードにいるキャラクターを押し出す。このときダメージは発生しない。
    • 敵が1ノード以上移動する場合、1ノード移動して移動先のノードにいるキャラクターをすべて押し出す。押し出しを受けたキャラクターはそれぞれ盾に書いてあるダメージの攻撃を受ける。キャラクターは防御または回避を選択できる。敵の移動可能なノード数ぶんこれを繰り返す。

メモ:

  • キャラクターが押し出しを受けたことによる移動はスタミナを消費しない。
  • 敵が標的のキャラクターと同じノードに到達してキャラクターを押し出したとき、敵の移動可能なノード数が残っていれば、標的に向かってさらに移動する。
  • キャラクターが押し出しダメージを回避するとき、まず回避によって1ノード移動することができる。回避に失敗した場合、押し出しによって敵から離れた方向にさらに1ノード移動する。

敵の攻撃

XXX 翻訳中…

敵の攻撃力は固定値。防御するプレイヤー側が相殺の度合いをダイスロールで決める。物理攻撃ならキャラクターの物理防御力で相殺し、魔法攻撃ならキャラクターの魔法耐性で相殺する。相殺した結果ダメージが0になっても押し出し効果や状態効果は通常通り受ける。

物理防御力を計算するには、キャラクターの左右の手スロットと鎧スロットに装備しているアイテムを見る。それらのアイテムカードの左下の盾アイコンに描かれた色と個数のダイスをまとめて振り、出目を合算した値が物理防御力になる。魔法耐性を計算するには、装備しているアイテムカードの左下、盾アイコンの右隣にある丸いアイコンを参照して、同様にダイスを振る。

キャラクターは防御をしない代わりに回避を試みることができる。まず1スタミナを消費する。移動したければ隣接ノードに移動してもよい。装備しているアイテムカードの回避アイコンを見てに描かれた個数の回避ダイスをまとめて振る。敵の遭遇カード右端の回避難易度を見て、出目が回避難易度の数値と等しいか上回れば回避に成功し、キャラクターはダメージも効果も受けない。回避に失敗すれば通常通りにダメージと効果を受ける。

ボスとの遭遇

XXX 翻訳中…

ボスの行動

XXX 翻訳中…

ボスの台座には十字の線が入っており、その延長線をもってマップタイルを4つの象限に区切る。象限の境目にいるキャラクターは両方の象限に属する扱いになる。キャラクターがボスと同じノードへと移動したら、直前にいた象限と同じ象限に属することとする。ボスのいるノードから離れるときは同じ象限内のノードに移動する。(ヒント:たとえば、ボスがいるノードに正面から入ったら離れるときは正面方向にしか移動できないということ。正面から背後に回り込むにはボスから離れたノードを大回りする必要がある。)

マップタイルの隅でボスがキャラクターを押し出してキャラクターが移動するとき、キャラクターが今いる象限の中に移動できるノードがなければ、壁沿いの好きな隣接ノードに移動する。

ボスを移動させるときはモデルの向きを常に意識する。台座の十字の延長線がノードを横切るように、つまりボスは8方向のいずれかを向くようにすること。ボスがキャラクターを標的にして近づくように移動する場合、まず標的のいるノードが正面の象限に収まるようにボスを向け、それから移動する。逆に標的から遠ざかるように移動する場合、まずボスの隣接ノードのうち標的からもっとも遠いノードが背面の象限に収まるようにボスを向け、それから移動する。(ヒント:バックする形になる。)

ボスの行動カードの移動マーク右上に標的アイコンがない場合、ボスは向きを変えずに移動する。

ボスの行動カードの移動マーク左下に時計回りの矢印アイコンがある場合、ボスはワープ移動する。ボスがワープ移動するとき、まずボスをタイルから取り除く。次にボスの移動の標的のいるノードにボスを置く。ワープ移動の間ボスの向きは維持すること。ボスがワープした先のノードにいるキャラクターは押し出しを受ける。このとき押し出しを受けたキャラクターは、通常のボスの押し出しと異なり、ボスの向きに関わらずどの象限の隣接ノードに移動してもよい。(ボスが頭上から落ちてきて向きに関係なく押し出されるイメージ。)

ボスの直前の行動カードには、ボスの攻撃の対象になる緑象限、攻撃の対象にならない黒象限、防御力が弱まる赤象限がある。赤象限に対する攻撃はロールするダイスを1追加する。

avr-gcc 6.2.0 で qmk_firmware のビルドに失敗したメモ

TL:DR; avr-gcc49 を使えばよい。

背景

Ergodox EZ というキーボードを所有しているのだが、これは qmk_firmware というファームウェアを書き込んで動作カスタマイズできる。 Mac でビルドするには

brew tap osx-cross/avr
brew install avr-libc
brew install dfu-programmer

cd /path/to/qmk_firmware/keyboard/ergodox_ez
make KEYMAP=$my_keymap

とする。

ビルドが失敗するようになった

avr-gcc のバージョンを6.2.0に上げたらビルドが失敗するようになった。エラーログは以下:

$ make KEYMAP=uasi

-------- begin --------
avr-gcc (GCC) 6.2.0
Copyright (C) 2016 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


Size before:
   text    data     bss     dec     hex filename
  18144      52     191   18387    47d3 ergodox_ez.elf


mkdir -p obj_ergodox_ez
Compiling C: ergodox_ez.c
avr-gcc -c -mmcu=atmega32u4 -gdwarf-2 -DF_CPU=16000000UL -DINTERRUPT_CONTROL_ENDPOINT -DBOOTLOADER_SIZE=512 -DF_USB=16000000UL -DARCH=ARCH_AVR8 -DUSB_DEVICE_ONLY -DUSE_FLASH_DESCRIPTORS -DUSE_STATIC_OPTIO
NS="(USB_DEVICE_OPT_FULLSPEED | USB_OPT_REG_ENABLED | USB_OPT_AUTO_PLL)" -DFIXED_CONTROL_ENDPOINT_SIZE=8  -DFIXED_NUM_CONFIGURATIONS=1 -DPROTOCOL_LUFA -DBOOTMAGIC_ENABLE -DMOUSEKEY_ENABLE -DMOUSE_ENABLE -
DEXTRAKEY_ENABLE -DNO_PRINT -DNO_DEBUG -DCOMMAND_ENABLE -DNKRO_ENABLE -DSLEEP_LED_ENABLE -DNO_SUSPEND_POWER_DOWN -DVERSION=518562f -Os -funsigned-char -funsigned-bitfields -ffunction-sections -fdata-secti
ons -fno-inline-small-functions -fpack-struct -fshort-enums -fno-strict-aliasing -Wall -Wstrict-prototypes -Wa,-adhlns=obj_ergodox_ez/ergodox_ez.lst -I. -I../.. -I../../tmk_core -I../../quantum -I../../qu
antum/keymap_extras -I../../quantum/audio -I../../tmk_core/protocol/lufa -I../../tmk_core/protocol/lufa/LUFA-git -I../../tmk_core/common -std=gnu99 -include config.h -MMD -MP -MF .dep/obj_ergodox_ez_ergod
ox_ez.o.d  ergodox_ez.c -o obj_ergodox_ez/ergodox_ez.o
In file included from ../../tmk_core/common/matrix.h:21:0,
                 from ergodox_ez.h:4,
                 from ergodox_ez.c:1:
/usr/local/Cellar/avr-gcc/6.2.0/lib/gcc/avr/6.2.0/include/stdint.h:9:26: fatal error: stdint.h: No such file or directory
 # include_next <stdint.h>
                          ^
compilation terminated.
make: *** [obj_ergodox_ez/ergodox_ez.o] Error 1

avr-gcc をダウングレードしたらビルドできるようになった

avr-gcc を4.9にダウングレードしたらビルドできるようになった。ダウングレードの手順は以下:

brew unlink avr-libc avr-gcc
brew install avr-libc49
brew link avr-libc49 avr-gcc49

npm パッケージの unpublish に関するゴタゴタの大まかなまとめ

(最終更新:3月24日16:50ごろ)

事件の流れ

何が問題だったのか

npm の仕様

  • パッケージの所有者がパッケージを unpublish できるようになっていること
    • メジャーなパッケージマネージャの多くは unpublish に相当する操作をユーザーに提供しない
    • 代わりとして unlist (NuGet)yank (Cargo) といった操作を提供することがある
    • unlist/yank されたパッケージはリポジトリの一覧には表示されなくなるが、依存解決中にそのパッケージをダウンロードすることは可能
    • 本当の緊急時のみリポジトリ管理者の手でパッケージが削除されることはある
  • unpublish されたパッケージのネームスペースを他人が乗っ取れるようになっていること
    • 同一バージョンの再 publish はできないものの、別のバージョンで悪意のあるコードを publish すると依存元パッケージを攻撃できる可能性がある

人的要因

  • 代理人と作者のやりとりにおいてお互いの態度がよろしくなかったこと
  • 法務関係の事態とはいえ、 npm 運営が作者の許可を得ずパッケージを unpublish したパッケージの所有権を移し替えたこと
    • npm のパッケージ名に関する紛争解決ポリシーによれば、ユーザー間で問題が解決できなければ運営が調停するとされる
  • 抗議のためとはいえ、作者が多数のパッケージを一度に unpublish したこと
    • 混乱を招くことは承知していたようだが、 left-pad に依存する babel まで壊れることは予測していなかったと思う
  • npm 運営が社内の合意もおろそかに unpublish の取り消しを実行したこと

関連記事

余談:

  • 一般的なパッケージマネージャのつくりに興味がある人にはこの記事がおすすめ。 Go のパッケージマネージャを新規設計する視点から問題領域などを分析してる:So you want to write a package manager — Medium
    • “パッケージ管理は厄介な領域だ。本当に厄介だ。表面上は純粋に技術的に解決可能と見える。そう考えて取り組んだ者は皆、避けがたい次なる結論に至る:ソフトウェアはおそろしい。人々はおそろしい。シナリオは無数にあり、何ひとつまともには動かない。証明可能なことに、何ひとつまともには動かない。人生とは逆巻くカオスとエントロピーの渦の中の無意味な摂動。”

感想

  • JS 界隈に単機能モジュールを多数組み合わせて使う風潮があるため被害が広がったなという感じ
  • unpublish 操作はユーザーに開放しないほうがいいと思う
    • npm は他のパッケージリポジトリと比べてパッケージ数が桁違いに多いため、 npm 社としては unpublish を依頼制にしたくないんだろうけど
    • パッケージ作者に無断で管理者がパッケージを削除することは、法に反するコンテンツを含む場合などはやむを得ないだろうが、今回のケースは微妙
  • Objective-C/Swift のパッケージマネージャ CocoaPods は Pods ディレクトリ(依存先パッケージのソースコードを集約するディレクトリ)をバージョン管理することを推奨している。こうすると万が一依存先パッケージが削除されても影響を受けない。デメリットもあるがよいプラクティスだと思う

ブコメ返信

id:teppeis

今回のケースではunpublishが禁止されても乗っ取りは防げるけどエコシステムの破壊は免れなかった。iOS詳しく知らないけどCocoaPodsはプラットフォーム限定できてビルド不要という違いがあるのでは。

ユーザーによる unpublish が禁止されていたとしたら、管理者権限での kik の unpublish によって依存関係が壊れることこそ免れないものの、その他多数のパッケージの突然の unpublish は為されず、被害は比較的小さく済んだはず。

CocoaPods で Pods ディレクトリのバージョン管理が現実的なのは、 Pods ディレクトリにパッケージのソースコードだけが保存されるから。ビルドは必要だが生成物は別のディレクトリに出力される。

ソースコードとプラットフォーム依存のバイナリを同じディレクトリに保存する npm や Ruby の Bundler などでは真似できなそう。

Mac の Safari のキャッシュから画像その他を取り出すメモ

(以下の内容は Safari 8.0.6 現在のもの)

~/Library/Caches/com.apple.Safari/fsCachedData に blob が保存されている。 file コマンドで画像かどうか判別して適当に拡張子をつけてやれば復元できる。

% file fsCachedData/000DFAD8-B02E-47A2-AFA0-36D985C47D20
(略)/000DFAD8-B02E-47A2-AFA0-36D985C47D20: PNG image data, 64 x 64, 8-bit/color RGBA, non-interlaced

Finder で blob ファイルを選ぶと上手いことプレビューしてくれるのでそれでもいい。

f:id:uasi:20150619104639p:plain

その他レスポンスデータなどは ~/Library/Caches/com.apple.Safari/Cache.db に記録されている。これはただの SQLite3 データベースファイル。 BLOB カラムには binary plist らしきものが入っている。

% sqlite3 Cache.db 'SELECT * FROM cfurl_cache_schema_version;'
104

% sqlite3 Cache.db .schema
CREATE TABLE cfurl_cache_schema_version(schema_version INTEGER);
CREATE TABLE cfurl_cache_response(entry_ID INTEGER PRIMARY KEY AUTOINCREMENT UNIQUE,     version INTEGER, hash_value INTEGER, storage_policy INTEGER, request_key TEXT UNIQUE,   time_stamp NOT NULL DEFAULT CURRENT_TIMESTAMP, partition TEXT);
CREATE TABLE cfurl_cache_blob_data(entry_ID INTEGER PRIMARY KEY, response_object BLOB, request_object BLOB,               proto_props BLOB, user_info BLOB);
CREATE TABLE cfurl_cache_receiver_data(entry_ID INTEGER PRIMARY KEY, isDataOnFS INTEGER, receiver_data BLOB);
CREATE INDEX request_key_index ON cfurl_cache_response(request_key);
CREATE INDEX time_stamp_index ON cfurl_cache_response(time_stamp);
CREATE INDEX proto_props_index ON cfurl_cache_blob_data(entry_ID);
CREATE INDEX receiver_data_index ON cfurl_cache_receiver_data(entry_ID);

cfurl_cache_response.request_key は URL の文字列。ただし末尾に '[' + request_host + ']' が付属している場合がある。

cfurl_cache_receiver_data.receiver_data は UUID の文字列(大文字ハイフン区切りの形式)。 fsCachedData ディレクトリに UUID を名前とするバイナリファイルが格納されている。

はてなブログのプロフィールに Qiita と Twitter のリンクを追加する

サイドバーのプロフィールを便利にしたかったのでしてみた。サイドバーには任意のリンクを表示する項目も追加できるが、場所を取るので今回は使わなかった。

f:id:uasi:20150331193721p:plain

このようにはてなIDの横に Qiita と Twitter のIDを並べることにした。プロフィール部分はユーザーがカスタマイズできるようになっていないため、 JavaScript でガッと書き換える。

はてなブログのダッシュボードを開き、「設定>詳細設定>headに要素を追加」に以下のコードを書いた。

<link href="//maxcdn.bootstrapcdn.com/font-awesome/4.3.0/css/font-awesome.min.css" rel="stylesheet">
<script type="text/javascript" src="//code.jquery.com/jquery-2.1.3.min.js"></script>
<script type="text/javascript">
// <!--
jQuery.noConflict();
jQuery(function() {
  jQuery('.hatena-module-profile a.hatena-id-link').after(
    ' / <a href="http://qiita.com/uasi">' +
    '<span class="fa-stack" style="font-size: 50%">' +
    '<i class="fa fa-square fa-stack-2x"></i>' +
    '<i class="fa fa-search fa-stack-1x fa-inverse fa-2x"></i>' +
    '</span>' +
    'uasi</a>' +
    ' / <a href="https://twitter.com/uasi">' +
    '<i class="fa fa-twitter"></i>' +
    'uasi</a>'
  );
});
// Qiita icon is adapted from http://qiita.com/hkusu/items/fda8d8178dd693f95f3c
// -->
</script>

うまくいったので満足。

なお Font Awesome の既存アイコンを重ねて Qiita のロゴ風にする技はFontAwesome - Font Awesome で Qiitaロゴっぽいアイコンを表現 - Qiitaを参考にさせていただいた。

Safari に Flash Player をインストールできないときはオフラインインストーラを使うとよさそう

SafariFlash Player プラグインをアップデートしろとせっつくのでインストールしようとしたが、何度やってもエラーが出る。

f:id:uasi:20150130103810p:plain

いろいろ試してもダメだったので別のページからインストーラをダウンロードしたらあっさりインストールできた。

Adobe Flash Playerの配布 | Adobe

↑このページの “DMGインストーラーのダウンロード”(.dmg 直リンク)からダウンロードした。

今回インストールできなかったのはバージョン16だったが、バージョン12か13のときもインストールできず、その次のバージョンのベータ版をインストールした覚えがある。

Adobe のフォーラムのスレッドを見るに、管理者権限のないユーザーがオンラインインストーラを使うと発生する問題のようだ。ベータ版はオフラインインストーラなのでうまくいったということか。


環境:

いろいろ試してダメだったこと:

  • Safari 以外のアプリケーションもすべて終了
  • Flash Player プラグインをアンインストール
  • ディスクユーティリティでアクセス権を修復
  • インストーラをディスクイメージから取り出してデスクトップに置く(→実行するとダイアログが空になる不具合が出た)

インストールに失敗したときのログ( ~/Library/Logs/FlashPlayerInstallManager.log ):

2015-01-30 10:35:23 +0900 [I]  IM: ---------- log start ----------
2015-01-30 10:35:23 +0900 [I]  IM: All install checks pass
2015-01-30 10:35:23 +0900 [W]  IM: Unexpected umask value for process: 0
2015-01-30 10:35:23 +0900 [I]  IM: User does not have any processes that need to be closed.
2015-01-30 10:35:23 +0900 [I]  IM: [install started]
2015-01-30 10:35:23 +0900 [E]  RA: Unable to launch FPInstallHelper. Error = 'launch path not accessible'

2015-01-30 10:35:23 +0900 [E]  RA: 
Attributes for '/var/folders/zz/zyxvpxvq6csfxvn_n0000000000000/T/FPInstallHelper':
 {
    NSFileCreationDate = "2015-01-23 21:28:30 +0000";
    NSFileExtensionHidden = 0;
    NSFileGroupOwnerAccountID = 0;
    NSFileGroupOwnerAccountName = wheel;
    NSFileHFSCreatorCode = 0;
    NSFileHFSTypeCode = 0;
    NSFileModificationDate = "2015-01-23 21:28:30 +0000";
    NSFileOwnerAccountID = 0;
    NSFileOwnerAccountName = root;
    NSFilePosixPermissions = 2541;
    NSFileReferenceCount = 1;
    NSFileSize = 22784;
    NSFileSystemFileNumber = 31520882;
    NSFileSystemNumber = 16777220;
    NSFileType = NSFileTypeRegular;
}

2015-01-30 10:35:23 +0900 [E]  RA: 
Attributes for '/var/folders/zz/zyxvpxvq6csfxvn_n0000000000000/T':
 {
    NSFileCreationDate = "2014-10-05 06:07:38 +0000";
    NSFileExtensionHidden = 0;
    NSFileGroupOwnerAccountID = 0;
    NSFileGroupOwnerAccountName = wheel;
    NSFileModificationDate = "2015-01-30 01:35:23 +0000";
    NSFileOwnerAccountID = 0;
    NSFileOwnerAccountName = root;
    NSFilePosixPermissions = 449;
    NSFileReferenceCount = 19;
    NSFileSize = 646;
    NSFileSystemFileNumber = 19103629;
    NSFileSystemNumber = 16777220;
    NSFileType = NSFileTypeDirectory;
}

2015-01-30 10:35:24 +0900 [E]  IM: [install failed: 30]
2015-01-30 10:35:24 +0900 [E]  IM: Install failed with error code: 30.
2015-01-30 10:35:24 +0900 [I]  IM: ----------  log end  ----------

.dev で終わる hostname のとき gem install が(ある条件で)失敗するようになった

追記:うまい要約を見つけたので貼っておく。


最近 .dev TLD が新設された影響か、 hostname が .dev で終わる手元のマシンで gem install するとコケるようになった:

$ hostname
foo.dev
$ sudo /opt/rbenv/versions/2.2.0/bin/gem install bundler --no-document
ERROR:  While executing gem ... (Gem::RemoteFetcher::FetchError)
    Errno::ECONNREFUSED: Connection refused - connect(2) for "your-dns-needs-immediate-attention.dev" port 443 (https://your-dns-needs-immediate-attention.dev/quick/Marshal.4.8/bundler-1.7.11.gemspec.rz)

具体的には次のいずれかの条件を満たす環境で再現する:

  • hostname が .dev で終わり、かつ /etc/resolv.conf の search フィールドが設定されていない
  • /etc/resolv.conf の search フィールドが dev を含む

1番目の条件は Ruby の Resolv ライブラリの挙動に由来する。 /etc/resolv.conf に search が設定されていないとき、 Resolv は hostname の TLD を search の値として扱うようになっている(resolv.rb の1010行目あたりを参照)。また RubyGems の名前解決の挙動とも関係する(この記事のコメントを参照)。

この問題を回避するには /etc/resolv.conf に適当な search hoge fuga を設定すればよい。ただし hoge fuga は dev を含まないこと。

search を設定できない事情があるなら hostname を変える。 TLD を含まないようにするかテスト用の TLD を使う。 RFC 2606 によれば、テスト用途に使える TLD は予約済みの4つのうち .test.example の2つである。このどちらかを使えばよい。

あるいは .x などの1文字の TLD が使えるかもしれない。仕様上は正しいが、これまでに1文字の TLD が登録されことはない。

参考:


ブコメ返信

(gem の source を FQDN にすればいいという指摘について) id:happy_siro こういうこと?

$ sudo /opt/rbenv/versions/2.2.0/bin/gem sources list
*** CURRENT SOURCES ***

https://rubygems.org./

だめっぽい。

$ sudo /opt/rbenv/versions/2.2.0/bin/gem install bundler --no-document
ERROR:  While executing gem ... (Gem::RemoteFetcher::FetchError)
    Errno::ECONNREFUSED: Connection refused - connect(2) for "your-dns-needs-immediate-attention.dev" port 443 (https://your-dns-needs-immediate-attention.dev/quick/Marshal.4.8/bundler-1.7.11.gemspec.rz)