etsavの日記： “The Blizzard Runners" rules 4
日記 by
etsav
このエントリは、 あたしが作成しようとしているゲーム“The Blizzard Runners”のルールを明示的に記述するために用意しました。 頻繁に加筆修正する事が予想されるため、 これまであたしが自らに課してきた、 『日記エントリの内容修正履歴は全て陽に記録しておく』というルールを、 このエントリに関しては適用致しません。 ご諒承下さいませ。
もちろんコメント大歓迎でございます～
○一日の流れ――未完走の各走者について：
- 休み処理――走者が休み状態なら
- 走者に対する全ての砲撃予約をキャンセル（生き埋め状態だから）。
- 残り休み日数を１日減らす。
- 次の走者へ
- 砲撃回避チェック――走者へ砲撃予約されているなら
- 走者のキャンプ地点が砲撃対象外地形なら、 走者に対する全ての砲撃予約をキャンセル。
- それ以外の地形の時 ice scale を持っていれば、 ice scale が残っている限り１枚消費毎に砲弾１発を無効化。
- 無効化されない砲弾が残っていれば被弾チェック
- 砲弾１発につき 1d6 で 5 以上を出した時に被弾。
- 被弾数 × 5 マイルだけキャンプ地点を後退。 ただし start または turning point を越えて後退する事は無い。
- 初期 Power 決定
- 初期 Power を 3d6 で決定。 これに現在のキャンプ地点の地形効果によるボーナスを加算。
- 行動コマンド受け付け開始
- 自発キャンプが行われるか、強制キャンプや休み状態になるまで繰り返す。
- 次の走者へ
○行動コマンド：
- View――前方確認
現在地点から +1 ～ +15 マイル先の地形を見る。 この時現在地点の地形の View コスト分だけ Power を消費（Power 消費は現在地点から移動しない限り最初の１回のみ）。
実装上 15 マイル分の同時表示が難しければ、 Near（+1 ～ +5 マイル）・Middle（+6 ～ +10 マイル）・Far（+11 ～ +15 マイル） のサブコマンドに分けてもよい。 当然この場合でも Power 消費は最初の一回のみ。
可能なら現在の地形効果による前進距離修正を行った上での、 各前進速度による到達可能範囲を提示する。 - Advance――前進
サブコマンドにより前進速度を選ぶ事が出来る。 選択した前進速度による基本前進距離に、 現在の地形による前進距離修正を受けた結果が最終的な前進距離となる。
ただし前進距離決定時に 1d6 で 6 が出た場合『ブリザード発生』となり、 キャンプ地点まで戻された上で強制キャンプとなる。
ブリザードが発生しなかった場合、 決定された距離だけ前進し、 地形進入処理を行う。
なお、前進地点が turning point および finish を越える場合は、 それぞれ turning point および finish に進入したものとする。 前進距離が丁度でなかったからといって、 戻されたり前進が無効になったりする事は無い。
各前進速度の消費 Power と基本前進距離は次の通り： - Walk―― Power 消費 1・基本前進距離 1d6（1 ～ 5 miles）
- Run ―― Power 消費 3・基本前進距離 1d6+5（6 ～ 10 miles）
- Rush―― Power 消費 5・基本前進距離 1d6+10（11 ～ 15 miles）
- Trap――罠の設置
現在地点の地形が snows であり、 かつ必要な消費 Power とアイテムがある場合、 罠を設置する事が出来る。 設置可能な罠の種別と消費 Power・アイテムは次の通り： - seed trap―― Power 1 / seed
- pit trap ―― Power 2 / shovel
- bomb trap―― Power 3 / shell
- Eat――食事
アイテム消費により Power を回復できる。 消費アイテムと回復 Power は次の通り： - seed―― Power +3
- egg ―― Power +5
- Inventory――アイテムリスト
実装上、所持アイテム数を常時表示できない場合、 アイテムリストを表示できるようにする。 - Camp――自発キャンプ
キャンプ地点を現在地点に確定し、その日の行動を終える。 現在地点が走者間戦闘禁止地形でなく、 かつ Power が 1 以上残っている場合、 同地点へ進入する他の走者への迎撃を行うか否かを選択できる。
○アイテム種別：
- seed―― Antarctic Cryptomeria の種
食べると一つにつき Power が 3 回復。
seed trap 設置の材料。
High Power Penguin の餌。 - egg―― High Power Penguin の無精卵
食べると一つに付き Power が 5 回復。
Antarctic Yeti の餌。 - shovel―― Blizzard Runner の主用武器
戦闘修正（弱）を得る。
pit trap 設置に使用。
pit trap の回避。
valley での雪崩からの回復期間（２日休み）を短縮（１日休み）。 - shell――大陸間滑空軌条砲の砲弾
戦闘修正（強）を得る。
bomb trap 設置の材料。
battery にて他の走者への砲撃予約に使用。 - silent boots―― Antarctic Yeti の肉球を使った消音ブーツ
Ice Dragon 出現チェックの回避。
valley での雪崩を防止。
glacier での滑落を防止。 - ice scale―― Ice Dragon の鱗
１枚につき砲撃１発分を無効化（自動消費）。
○地形種別：
- snows――普通の雪原
View コスト: 0 Power
前進距離修正: なし。
特筆事項: 罠の設置が可能。 - new snows――新雪原
View コスト: 0 Power
前進距離修正: 1/2 切り上げ。
特筆事項: なし。 - snowdrift――吹き溜まり
View コスト: 0 Power
前進距離修正: 1/3 切り上げ。
特筆事項: なし。 - woods――『南極杉』の林
View コスト: 1 Power
前進距離修正: なし。
特筆事項: なし。 - forest――『南極杉』の森
View コスト: 3 Power
前進距離修正: 1/2 切り上げ。
特筆事項: 砲撃対象にならない。 - crevasse――クレバス
View コスト: 0 Power
前進距離修正: なし。
特筆事項: １日休み（転落による）。 - hidden crevasse――隠れたクレバス
View コスト: 0 Power
前進距離修正: なし。
特筆事項: crevasse に準ずる。最初の走者が停止するまでは外見は snows と区別がつかない。 - bridge――クレバスに掛かった橋
View コスト: 0 Power
前進距離修正: なし。
特筆事項: 直前の前進速度 Walk/Run/Rush について 1d6 で 6/5/4 以上を出した場合 crevasse に準ずる。 - beach――海岸
View コスト: 0 Power
前進距離修正: なし。
特筆事項: Intelligent Penguin または High Power Penguin の出現チェック。 - hill――丘陵
View コスト: 0 Power
前進距離修正: なし。
特筆事項: Antarctic Yeti の出現チェック。 - mountain――山岳
View コスト: 0 Power
前進距離修正: 1/2 切り上げ。
特筆事項: Ice Dragon の出現チェック。ただし silent boots の消費によりチェックを回避できる。 - valley――峡谷
View コスト: 2 Power
前進距離修正: 1/2 切り上げ。
特筆事項: 直前の前進速度 Walk/Run/Rush について 1d6 で 6/5/4 以上を出した場合、２日休み（雪崩発生による）。ただし silent boots の消費により雪崩発生チェックそのものを防ぐ事が出来る。また雪崩発生時、shovel の消費で１日休みに短縮できる。 - volcano――火山
View コスト: 0 Power
前進距離修正: 1/2 切り上げ。
特筆事項: 1d6 で 5 以上を出した場合、hot spring に変化（噴火による）。 - hot spring――温泉
View コスト: 0 Power
前進距離修正: なし。
特筆事項: 強制キャンプ（オリハルコン鉱泉依存症発現による）。翌日の初期 Power に +6 ボーナス。走者間戦闘禁止。砲撃の対象にならない。 - glacier――氷河
View コスト: 0 Power
前進距離修正: 1/3 切り上げ
特筆事項: 直前の前進速度 Walk/Run/Rush について 1d6 で 5/4/3 以上を出した場合、連続する glacier の進行方向反対側の端まで滑落後、強制キャンプ。ただし silent boots の消費により滑落チェックそのものを防ぐ事が出来る。 - hut――小屋
View コスト: 0 Power
前進距離修正: なし。
特筆事項: 探索または休憩が可能。探索によりランダムにアイテム取得。休憩時は Power が 1d6 だけ回復。砲撃対象にならない。 - battery――大陸間滑空軌条砲陣地（南極戦役の遺跡）
View コスト: 0 Power
前進距離修正: なし。
特筆事項: shell 消費により砲撃予約可能。 - start / finish――スタート・ゴール地点
View コスト: 0 Power
前進距離修正: なし。
特筆事項: 走者間戦闘禁止。砲撃対象にならない。 - turning point――折り返し地点
View コスト: 0 Power
前進距離修正: なし。
特筆事項: 強制キャンプ。走者間戦闘禁止。砲撃対象にならない。
ゲーム製作本格始動ですね (スコア:1)
さすがに今からポケコンというわけにはいかないでしょうから、Win+DirectXとかJavaとかでしょうか。（ポケコンは昔PC-E500を使ってましたよ～)
ゲーム系のライブラリとしてSDL [libsdl.org](日本語解説 [risky-safety.org])というものがありまして、グラフィックやサウンドを簡単なAPI [libsdl.org]で使えます。Win,Msc,linuxなど多数のプラットホーム [libsdl.org]と開発言語 [libsdl.org]に対応していて比較的移植も楽そうです。
そういう僕はSDLは一昨年あたりちょっと使ってみましたが、クラスライブラリを作ってる途中 [srad.jp]で放置中です。
なんか最近大きなゲーム作ってないです。
最近完成させたのはWonderWitch用のピコピコゲームだったりして、しおしおです。
学生時代のようには時間とれませんが、これを機会に僕もなんか作ってみようと思います。
いやぁまだ前作を思い出してるだけの段階で (スコア:1)
Java にしようかと考えていたんですね。 リアルタイム性のほとんど無い双六ゲームですし、 元々がポケコン BASIC で動いてたものですから、 PDA クラスでもコアの部分は楽々動かせそうですから。 まぁ余程イフェクトに凝れば別ですけど、 そういうのは実装上分離しますし。 あと、 ちょっと Java Web Start [sun.com] を使ってみたいかなぁ、 なんて。
＃ 1480U / E500 はよい機械でしたよねぇ〔しみじみ〕。
でも、SDL ――まだ能書きをざっと読んでみただけなんですけど、 うぅ、 悩むなぁ…… どちらかといえばあたしは Java より C++ の方が得意なもので。 CodeWarrior でもコンパイルできるのかな？ ちょっと調べてみます。 情報ありがとうございます～
あとですね、 ソースの扱いをどうするかはまだ決めてないんですが、 少なくともゲームルールに関しては、 最終的に public domain 化出来ないかなぁって考えてます。 競う様に自分の機械にゲームを移植しまくってた、 雑誌投稿ソフト全盛期の雰囲気を、 少しでも取り戻したくて。
Re:いやぁまだ前作を思い出してるだけの段階で (スコア:1)
ターン制の部分を工夫すればネット対戦も出来るかもしれませんし。
（と、いいかげんなことを書いてみたり）
Java Web Startよさそうですよね。注目中 [srad.jp]です。
作ったゲームをいかに多くの人に遊んでもらうか考えると、インストールの容易さって重要だとおもいますので。Java Web Startは、基本システム(JRE込み)だけインストールしとけば、対応ソフトが簡単にインストール、アップデートできるのが良さそうです。
お手軽に実行というと、アプレットとかもお手軽なので、ちょっとかじってみましたが、肝心のゲームが完成していないです。
今だったら Flashが一番いいかもしれませんね。結構Flashのアクションゲームありますし。でも、作るの簡単なのかな。
SDLについてですが、VisaulC++のlibがリンクできれば、CodeWarriorでもとおりそうですが、この辺は良くわかりません。
少なくともCygwin上のgccでは使えるようです。
Re:いやぁまだ前作を思い出してるだけの段階で (スコア:1)
えーと、 決めました。 Java にします。
まず最初の段階として、 ゲームのコアの部分と、 検証用のコンソール UI を組み合わせてプロトタイプを完成させちゃいます。
何と言うかですね、 なるべく早く実際に動く物を作らないと、 また『呪い』に捕われてしまいそうで…… とにかく今手持ちの能力のみでも何かを完成させる事が出来るって、 自信を付けたいと言うか。
次の段階で UI 部を置き換えて、 アプレットか Java Web Start 対応アプリケーションかにします。 そこで第一段階の目標達成です。
で、 コアと UI は最初からストリームで通信する設計にしようかと。 えぇ、 『ネット対戦』というキーワードに魅せられちゃいました。 コア／UI それぞれをプロキシで包んで、 サーバ／クライアントにしちゃうって目論見です。 もしかしたらその時点でクライアント側を SDL を使って書き換えて、 派手なイフェクトとか付けてもいいかも。
＃ あーでも、あたしはサーバサイドの Java は全く知らないんですよねぇ。
＃ 必要な段階になる前に覚えなきゃ。