2ch版いただきストリート作りませんか？

**326** · 03/12/04 06:46

夜中中、いただきストリートをやっていたんだけど
こんなにおもしろいボードゲームはないと思った。
２chのキャラクターを使ったいたストがあればもっと
個性的でおもしろいゲームが作れそうな気がするんだが
どう思う？意見を聞かせてくれ！

**295** · 2005/07/24(日) 23:05:53

誤爆っす。
すまん。

**名前は開発中のものです。** · 2005/07/25(月) 15:17:23

もちつけ ^^

◆EFBt/pII5Y · 2005/08/04(木) 20:13:20

ＡＢＣ
ＤＸＥ
ＦＧＨ

B＝上
D＝左
E＝右
G＝下
ACFH＝斜
Ｘ＝自分
とすると

DE
BG
AH
CF
DBEG
ACFH
これ以外に分岐パターンってありましたっけ？
貝がら島で考えて作っていたのですが、今のままだと応用が利かないので。

◆EFBt/pII5Y · 2005/08/04(木) 20:57:35

分岐なども>>287に載ってましたね。すいません。

**名前は開発中のものです。** · 2005/08/05(金) 02:30:41

>>298
制作お疲れです。
遅めですが、分岐点について提言を。２レスの長文です。すいません。
HSPに「ある文字列のx文字目の文字を得る関数」はありますよね？

日本列島の銀行のような十字路（左・下←→上・右のみ進行可能。３方向のうち２方向だけ進めるマス）を作ろうとすると、
「８方向＋方向転換可能状態」の全てに対し移動先定義をしなくてはならず、マップ制作時の定義設定が大変。
これは、思い切って「一方通行or来たマス以外の全ての方向に進める」定義しか作れないようにしてしまうと、一気に手間が９分の１に！
実害は上のような十字路が作れなくなるくらいです。
そうすると８方向＋転換状態の移動先定義を１マス９文字＝９ケタの数字で済ませられます。

まず、テンキー＝方向キーと考えます。「移動方角＝テンキーの数字」対応として、こんな風に。

「ある方向Pから（そのキーを押した結果マスに到達。4なら「左」キーの対角である右から、9なら左下から）来た場合、どの方角に進めるか」を移動先定義のP文字目に書きます。
例えば「下から来た場合（上ボタンを押してマスに来たので方向8）、次は左（方向4）にしか進めない」マスの時は、8文字目に「4」と書きます。
次に進める方向が2方向以上ある時は「5」。5は「分岐あり」を示します。
物理的に来る事ができない方向の定義は「0」。0を読み込んだら何らかのエラーがあったと扱います。
更にプレイヤーデータとして「次の移動方向」（最後の一歩の次は次ターンにかかる為、プレイヤー個人のデータとして管理。転換状態になったら5とする）と、
「直前にいたマスの座標（転換状態なら、直前にいたマスが関係なくなるので0とする。いたストGKの１マス戻るチャンスカードにも応用可）」を管理します。

**300** · 2005/08/05(金) 02:34:08

続き。

移動先定義は
1文字目＝右上から来た時に次に進める方角を数字で書く
2文字目＝上から来た時に・・・
...
5文字目＝転換状態の時に次に進める方角・・・
...
9文字目＝左下から来た時に・・・
で構成。「5」だった場合、次は来た方向以外の好きな方向に移動できると扱います。
（例：アメリカ大陸の本州・カジノの上の左空港マスなら「000455040」となります）
離れ小島のように方向転換が無効になるマスの場合、９文字全てを同じ移動方向に定義すればOK。ハワイのチャンスマスは左しか進めないので「444444444」です。

移動処理法は順にこんな風。１歩目は前ターン最後に変数更新ができている為、ＡＢを省略。サラリーなどの処理はＢの直後に。

Ａ方向Pボタンを押して移動しマスに到達。到達したマスの移動先定義を読み込む。
Ｂ読んだ定義のP文字目の文字を読み、新たな「次の移動方向」とする。「直前にいたマス」を更新。
Ｃ次の１歩は、次の移動方向が5以外（1～9）ならばその方向だけ。
　5ならば分岐点なので、８方向のうちマスが存在する方向に移動できる。
　ただし、「アメリカ大陸のラッキーなど、物理的に移動できない斜め方向にもマスがあるマス」に対応する為、チェック法は以下の通り。このチェックの中で「直前にいたマス」に進む方向を弾く。
　１　まず上下左右４方向に隣り合うマスを調べる。あれば移動可。
　２　続けて斜めの方向をチェック。マスAが存在しても、Aに隣り合い、かつ現在いるマスにも隣り合うマスがある場合は移動不可とする。条件外なら移動可。
　　　（方向1にあるマスは、方向4と方向2にマスがない場合のみ移動可）

こんな風に処理すれば、移動関連を全て数字で管理できるので、楽になるのでは（数値←→文字列の型変換が必要かも？）？

・・・役立たないかもしれない参考資料、いります？

◆EFBt/pII5Y · 2005/08/05(金) 15:53:59

ttp://gamdev.org/up/img/2996.zip
tabでチャット切り替え
株関係追加
2は2人、4は4人
同じexeじゃないと出来ない

>>300
どうも、いろいろ参考にさせていただいてます。
買い物料＝元買い物料×（1＋増資額÷元本×2）×変化倍率
この元買い物料ってのは何か基準があるのでしょうか？
今のところ　元本*15/100　で計算しています。

提案いただいた移動方法、完全には理解できてませんが
応用性があるので、とりあえず貝がら島でやってみます。
しばらく考えて判らなかったら、質問するかもしれませんがいいですかね？
方法としては自分が考えていたものとは、全く違うので目からウロコと言った感じです。

＞参考資料
よろしければお願いします。

**名前は開発中のものです。** · 2005/08/05(金) 16:22:00

まとめサイトないの？スクショ見たいんだけども。

**名前は開発中のものです。** · 2005/08/05(金) 21:43:26

>>302
こんな方法もある。各方向に16進の数字を割り当てて、
　上：01、右上：02、右：04、右下：08
　下：10、左下：20、左：40、左上：80
Y字に移動可能：右上＋下＋左上＝02＋10＋80＝92
X字に移動可能：右上＋右下＋左下＋左上＝02＋08＋20＋80＝AA
という表現をして、自分の来た方向のビットを抜いて
進める方向を決めるという方法だ。制限のない移動なら
これだけでOKだが、「直進しかできない」といった
移動制限用のあるマスではこのまま使えないので、
マスに移動制限用の関数を設定しておく。元ネタを
再現するだけなら1つのマップにつき4つ程度だから
大丈夫だが、新たにマップを作る場合は結構面倒だ。

だから、拡張性を考えるのなら、>>300と同じように
「来た方向」と「移動可能な方向」を用意して
ビット表記なりテンキー表記なりで列挙しておけば、
マップの移動に関しては大丈夫だろう。
（※2桁なので、データが>>300の表記の2倍になる）

これらは、>>287のサイトからの情報を元に作って
いるので、3以降に対応できるかは不明だ。詳しくは
中の人に聞いてくれ。＜丸投げ（ｗ

**304** · 2005/08/05(金) 21:48:25

>>302
元買い物料は、100G未満の店の「元本×10％」から
空き地改築後のコンビニ／木の店の「元本×20％」
まで10～20％の範囲になっており、元本が高額に
なればなるほど上がりやすい傾向がある。つまり
数式で決めるものではなくマップデータの初期値に
設定しておくものだろう。

ファミ通のいたストGKの攻略本には、これが
収益率（初期買物料÷初期お店価格）として
書かれており、戦略の一つとして扱われていた
ようだ。だから、計算式で統一するのは面白く
ないと個人的には思う。

>>287 の中の人のサイトを見て、ふと思ったよ。
言語覚えたての学生が作ったようなアプリを作るのに
時間を費やすより、仕様をがっちり固めて公開し、
時間がある人間に制作を任せてアドバイスに徹する
のがいい……そうは思わないか？>>300

◆EFBt/pII5Y · 2005/08/05(金) 23:47:19

>>303
次回うｐするときにHPにまとめ作っておきます。

>>304
買い物料は固定ではないようですね。
後でも修正できる箇所なんでしばらくは今のままでいきます。

>>300の移動方法ですが、
分岐マスのパターンって
通過時一方通行
通過時来た方向以外の複数
停止時すべての方向
停止時一方通行
停止時来た方向以外の複数
などいろいろ考えられるのでその辺のイメージが掴めません。
分岐以外は大体わかりました。
まあ、何とかやってみます。

**300（＝287の中の人）** · 2005/08/06(土) 01:03:17

昨日書いた、役立たないっぽい参考資料です。↓
http://tsukac.hp.infoseek.co.jp/sankou.html
ここからしか飛べません。しばらく残しておきます。

>>◆EFBt/pII5Yさん
更新お疲れです。いつかWinな知人にプレイさせてもらいます（笑）。
私も元買い物料比率は可変希望に一票。
分岐の処理法については、参考資料ページの最後に処理例があるので参考にしてみて下さい。

なお、ワープ・銀行停止などで転換状態にならない限りは、来た道をバックして進む事はできません。
サイコロを使い切って停止した次のターンも、転換状態にならなければ「連続して動いている」事は変わりません。「停止したらその場からバックできるマス」は銀行だけですが、銀行は止まれば転換状態になります。
なので、「移動中か転換可能か」だけを考え、
移動時：一方通行なのか、来た方向以外の複数に進めるのか
転換時：全ての方向に行けるのか、一方通行なのか
のみ考えればいいはず。
分からなければどしどし聞いて下さい。参考になれるのであれば頑張ります。

>>304さん
16進数を使う方法があったとは、全く思い付かなかったです。
いたスト３からの新マップは、動くマス・新たに生まれるマスが処理をややこしくしてます。
しかしそれらは作るのが大変なので無視すると、移動方向は基本的に「まっすぐor来たマス以外の全ての方向」だけなので対応可能ではないかと。
仕様を固めてアドバイスに徹するようにすれば、確かに楽です。
でも、必ず「作るのに時間を費やす人」が必要になりますから・・・
その側に立っている◆EFBt/pII5Yさんはやっぱりすごいです。

**名前は開発中のものです。** · 2005/08/06(土) 15:51:39

素材とかどうするのさ？
キャラは>>120がやるみたいだけど他にも必要でしょ。

**名前は開発中のものです。** · 2005/08/06(土) 16:16:48

一年前の書き込みに何言ってるんだか

**308** · 2005/08/06(土) 18:52:44

>>309
スマン気づかなかった。
現在進行形のスレなんで最近立ったのかと思ったんだが1年半以上前なんだな。

>>307
気になったんだが「まっすぐor来たマス以外の全ての方向」とあるけど
＿□
□□□
＿□
例えば上の様な形状で上下から来たら左右で左右から来たら上下に進行可能って場合対応できなくない？
そんな分かれ道ないかもしれないけどさ。

**名前は開発中のものです。** · 2005/08/06(土) 21:18:08

各マスに連番つけて、進行可能な8方向に
次のマス番、キャラの向き(+特殊移動)を付ける。
マス座標から移動距離等計算せんといかんけど
戻りやすくなるんじゃないか?

◆EFBt/pII5Y · 2005/08/06(土) 22:55:03

ttp://zxzxzxzxzx.hp.infoseek.co.jp/
年に数回しか更新をしないのでどうなるかわかりませんが、SS載せておきました。
ボードゲームというところです。

>>307
参考資料とても役立ちました。
理解できたつもりですが、間違ってたまま進めると最悪なので一応聞いておきますｗ
ttp://zxzxzxzxzx.hp.infoseek.co.jp/board/map.txt
貝がら島のデータですが、これであってますかね？

セーブについては、O2というのを利用してるのですが、仕様上同じメンバーで集まるのが
かなり大変そうなのでそこが問題なのです。
ルーム作成時に、ルーム名などを指定できれば目印などになりますが、現在はそれもできないので。
あとオフラインでやるなら本家いたストをやったほうが面白いので今のところ考えてません。
競売はオークションみたいですごい面白そうですね。

移動については方向決定以外はすべて自動になると思います。
今までのように一歩ごと進んだり戻れたりしても、結局たどり着ける場所は変わらないので意味ないですし。
個々で処理することになるので遅延が気になりますが、こればっかりは実際やってみないとわからないので。

**307=300** · 2005/08/06(土) 23:10:43

>>310さん
＞気になったんだが・・
例に挙げていただいたような「曲がる事しかできない十字路」はありませんが、
「右or上←→下or左」のように２つの方向しか進めない分岐は日本列島に存在しますし、私の提案だと対応できません。
これに対応しようとすると、８方向＋転換時に対し次に進める方角を全て定義する必要があり、マップを作る側の労力が一気に９倍に膨れ上がってしまいます。
そこで、ここは敢えてそういう分岐を作れなくしてしまったらどうか（１方向のみに進めるか、来た道以外全部OKか）、というのが300での提案です。

ただ、仕様によっては対処できるはず。マップを「組み込みのみ」にして、
「マップ数増加はアプリ作成者がバージョンアップした時のみ」に限定すれば、こういう分岐はプログラム内で条件設定をすればいいのです。
が、それだと「マップを自分で作る」事ができなくなってしまうので、プレイヤーとしての私の意見としては、ちょっとつまらないなぁ、と。

>>◆EFBt/pII5Yさん
SS設置乙です。あとで掲示板に出向きます。
貝がら島のデータは、大体合ってます。
気になるのは、銀行以外のマスの５文字目が5ではなく0なところ。
ワープカードで店に飛んだ時とか、銀行以外で転換状態になった時はどうするのか、と。

・・・ところで。
このアプリでは、マップの作成についてはどちらのイメージですか？

・（マップデータの書式を公開して）新マップはプレイヤー個人が自由に作れる。
・（マップデータの書式を公開せずorプログラム内に組み込んでしまい）アプリの中に組み込まれているもののみで、新マップは自由に作れない。

自由に作れるのであれば、マップ作成アシストアプリを手掛けてみたいです。

**名前は開発中のものです。** · 2005/08/06(土) 23:13:01

期待age

◆EFBt/pII5Y · 2005/08/06(土) 23:59:30

>>313
＞・（マップデータの書式を公開して）新マップはプレイヤー個人が自由に作れる。
こっちです。書式を公開と言うよりはマップエディタを公開という予定です。
貝がら島程度ならともかく、広いマップだと手打ちはつらいですし。
131 ◆1vWaymp0wsさんが作ってくれてましたが、現在の仕様と異なるので作っていただけるなら助かります。
テキスト形式のマップデータにコメント入れたものがあればいいですかね？
他に必要なものあれば書いてください。

**300** · 2005/08/07(日) 00:28:45

>>315
必要な書式が分かればどんな形でもOKです。
欲をいえば、
・生のテキスト形式マップデータ
・テキスト形式マップデータにコメントを入れたもの
・一般的な書式解説
の３つのテキストファイルが揃っていると大変助かります。
ただ、出来上がりまでに時間がかかるかも・・・　目標は９月終わりまでに・・・

**名前は開発中のものです。** · 2005/08/07(日) 00:33:10

チャンスカードのオリジナル案
引いたときにイベント起きるんじゃなくてカードをアイテムという形で貰って自分の出番のときに使える
駆け引き要素が強くなって戦略性が増すと思う

◆EFBt/pII5Y · 2005/08/07(日) 00:47:38

>>316
明日にでもうｐします。
時間的なことは全然構わないです。
こっちはいつ完成するかわからないですしｗ

オリジナル案の採用はきちんと土台が出来てから決めますが、大変ありがたいです。

**304** · 2005/08/07(日) 01:05:15

>>300＝>>287の中の人
横から見せてもらったが、かなり気合入ってた。
アプリをバカにしたような言い方をしてしまい、
すまなかった m(_ _)m　「実装に時間を費やす
より、他人が作っているところにアドバイスを
してもらうのが、有益な時間の使い方だ」と
言いたかっただけで、気を悪くしないでくれ。

>>315
マップは仕様だけ公開しておき、エディタは
他人に任せるのがいいと思う。>>315 にしか
できないことも多いだろうから、それだけに
集中してくれよ。

この辺を見るとアイディアや情熱を持っている
人間も少なくないだろう。
ttp://is-opc.hp.infoseek.co.jp/

**304** · 2005/08/07(日) 01:21:46

>>310
>>304の、16進2桁で、ワープ＋8方向から来た場合を
9つ並べる表記なら可能。その例なら、

上／下から来た場合：左＆右（40＋04＝44）に移動可能
左／右から来た場合：上＆下（01＋10＝11）に移動可能
ワープしてきた場合：上下左右（01＋10＋40＋04＝55）に移動可能

と表現できる。「来た方向」をテンキー表記で並べれば

01_02_03_04_05_06_07_08_09（テンキーの方向）
00_44_00_11_55_11_00_44_00（用意するデータ）

になる。ビット表記なら時計回りにデータが並ぶ。
アンダーバーは区切りにしただけで、実際は
18文字の16進数がマスの移動データになる。ここ
から2文字ずつ抜いていくことで移動方向を決める
ことができ、「二次元＋8方向＆ワープ」で
マップが表現されている限り、この表記で対応
できるはず。

上下左右：55だけを設定しておき、移動制限用の
関数でつぶす（＝来た方向＋進行方向のビットを
消す）方法もある。データが短くて済むが、関数を
個別に設定するのが面倒だし、マップデータから
方向を抜いてくる方が処理しやすかったりする。

◆EFBt/pII5Y · 2005/08/07(日) 11:37:24

ttp://zxzxzxzxzx.hp.infoseek.co.jp/board/mapdata.txt
ttp://zxzxzxzxzx.hp.infoseek.co.jp/board/scr.txt
上がテキスト形式マップデータにコメントを入れたもの
下がマップ作成に使ったソース
分かり難いかもしれませんが・・・

背景、店の名前、など他にもいろいろ必要なのですが、まだ手を付けてない場所なので入ってません。
また、今回の移動方法もそうですが、より良い方法があれば仕様の変更などもありえます。
現在は必要なデータを順に保存しているだけなので、
作っていただけるならすべての仕様をしっかり決めてからで構いません。
後で変更するのもお手数ですし。

＞気になるのは、銀行以外のマスの５文字目が5ではなく0なところ。
その辺もまだ手を付けていないので、追々考えます。

>>320
今回はとりあえず、>>300の方法で書いてしまいましたが、応用性はそちらのほうが高いようですね。

**名前は開発中のものです。** · 2005/08/07(日) 13:15:04

背景ってアニメーションだけどそんなの出来るのか

**名前は開発中のものです。** · 2005/08/07(日) 20:06:57

普通に並べると16行～22行になりますが
これ意味わからん

**300** · 2005/08/07(日) 22:33:02

>>321（◆EFBt/pII5Yさん）
テキスト仕様公開ありがとうございます。大体理解できました。
まずは作成アプリの原型が全くできていないと話にならないので(^^;、この仕様を参考に頑張ってみます。
で、ありがとうございますついでに失礼ながら・・・
できましたら、「今回掲載いただいたテキスト形式マップデータからコメントを抜いたもの」もいただけますと大変助かります・・・

というのは、「見やすいように,や半角スペース入ってますが実際は数値のみ」となっている部分の解釈に若干苦しんでます。
例えばマス目データ１行目は、カンマが入ってスペースだけ消えた
x,x,4,4,x,x,x,x,x,4,4,x,x
（xはデータを書き出す時に-1にします）が正しいのか、カンマが入らず、スペースも消える
xx44xxxxx44xx
が正しいのか。
休日・銀行の表記が10・11になっていて、ただ文字をつなげると解釈がおかしくなりそうなので、前者が正しいものと考えますが・・・

>>320（304さん）
この形式だと、どんな分岐にも完璧に対応できますね。
階段とか動くマスとか宇宙星雲の複雑仕様は、この際（軌道に乗るまでは）採用しなくていいと思いますし。
素晴らし過ぎて私の案はもはや形無し（笑）。
元いたマスを弾くチェックをアプリ側ではなくマップデータ側に持たせる（マップ作成の段階で最初から行けないように設定してしまう）と、
分岐や強制一通などの方向チェック処理を一本化してしまえるので、アプリ側も楽ができそう。
作成アプリ側で分岐の設定をアシストする機能をつければ、分岐設定もそれほど大変にはならなそうです。
最初に言ってしまった労力９倍はどう考えても嘘だ(^^;

>>323
このマップを、ただ普通に座標から再現すると、横１３×縦７マスのボードに角張った丸のような形が２つ繋がったマップになります。
この「ボードのマスの数」の事を言っているのだと思います。
それを、画面上だけは本来の座標の位置から４分の１マス×単位分だけずらして表示できる仕様なのですよね？>>◆EFBt/pII5Yさん

◆EFBt/pII5Y · 2005/08/07(日) 23:26:58

>>323
17～23の間違えでした。

>>324
ttp://zxzxzxzxzx.hp.infoseek.co.jp/board/map.zip
これが実際使用してるマップデータです。
テキスト形式ですが、保存してるデータをテキストにしただけで、
実際あのように保存されてる訳ではありません。すいません。
保存方法は配列をサイズ指定して保存し、保存位置にサイズを足す。
次の配列をサイズ指定して保存位置から保存し、保存位置にサイズを足すの繰り返しです。
サイズは書いた通りです。
区切りはカンマではなく数値配列は1つ4バイトなので、1つの要素を4バイトで保存。
これで読み出せてるので、そのはず。
上手く説明できないのですが、こんな感じです。
使用してるデータを保存方法と同じように読み出せばおｋです。

移動はやはり>>320の方法のが良いみたいですね。
理解能力がないので読んだだけではイメージ沸きませんがやってみます。
折角提案頂いた>>300の方法を利用しないのは申し訳ないです。

マスの表示方法はその通りです。

**名前は開発中のものです。** · 2005/08/07(日) 23:47:15

>>287氏はmacって書いてあるだろ。zipで上げてどうする。

**300** · 2005/08/08(月) 01:01:32

>>326さん
いや、zipで上げていただいたのは大丈夫です。Macもzipは解凍できます。

>>325
追加UPありがとうございます。なるほど、一定の書式を持ったバイナリファイルだったのか・・・
ただテキストファイルを読み込んでそれでOK、という訳ではなかったんですね。
それで最初にソースを添付して下さった訳ですな。
ようやく必要事項などが理解できました。

すいません、アプリを作ろうとしていた言語がREALbasicという、Macの中でもマイナーな環境なもので（取り柄はWinアプリが作れる事）、
HSPの開発の流れを良く分かっていませんでした・・・

◆EFBt/pII5Y · 2005/08/08(月) 01:23:06

>>327
すいません、こちらの説明不足でした。
内容はご理解されたようですね。
他にも縮小マップのサイズなどもマップに持たせるべきですね。
固定サイズだと画面を埋め尽くしてしまうの可能性があるので。
その辺は規格をしっかり固める必要がありますね。

**名前は開発中のものです。** · 2005/08/08(月) 09:34:44

すごい複雑な意見がたくさん出てますが、
上下左右を検索で道があればそちらに進む
道がなければ斜め4方向を検索して道があれば進む
こうすれば簡単だと思います。
ちなみに4方向以上の分岐ってないんですか？
もしあるなら今の方法では無理じゃないでしょうか。

**300** · 2005/08/08(月) 23:25:00

>>328（◆EFBt/pII5Yさん）
小マップのサイズ調整は、もちろんマップデータに組み込む事もできますが、マップデータ側ではなくアプリ側で処理すべき項目のような気がしますね。

マップ画面作成の一環として行なうもので、話はそれほど難しいものでもなく、
「マップが画面上で、縦あるいは横で一定以上のスペースを使っている場合、小マップ１マスのサイズをいくつに、それ以下ならいくつにする」
などと扱えばいいはず。
処理イメージとしては、
各マスについて「表示位置（マップデータ上の座標×80＋差分×20＝各マスの右下の画面上における座標）の最大値」を取る。
全マスの中で最大値を取るとマップ領域の右辺・下辺になるので、
その値の大きさによって小マップのマスの大きさを決定する。

どうするかはお任せです。

>>329さん
その方法だと真っ直ぐしか進めない十字路には対応できないです。
それを対応しようとすると、少しややこしくなってしまうのは致し方ない。
５方向の分岐は、こんな風に、
　■■
■□■
　■
マスの配置が奇妙になってしまうので存在しませんが、>>320の方式だとこれにも対応できますね。
画面上でずらして表示できる仕様と上手く合わせて使えば新機軸のマップも作れるかも？

**304** · 2005/08/08(月) 23:57:41

>>324
これも貴方が公開した元の仕様がなければ、
決して思いつかなかった方法だから、これ
からもアイディアをどんどん形にしていって
もらいたい。こういう部分はいたスト自体に
精通してないと思いつかないからね。

階層をまたぐ階段やワープはマスに表示上の
Z座標（「4分の1マス×単位分」と同類）を
持たせてそれを使い、内部の計算では座標
マップを平面的に参照すれば大丈夫だろう。
ttp://tsukac.hp.infoseek.co.jp/itasutofu/map.html

宇宙星雲は、角はL字に設定し、内側は
01_02_03_04_05_06_07_08_09（方向）
00_01_00_04_55_40_00_10_00（データ）
の「ワープ以外は直進のみ」とする。外側は
T字に移動可能としてワープならそのままで、

サイコロの出目＝残りの目：来た方向を除いたL字
サイコロの出目＞残りの目：直進のみに変更

という現在のプレイヤー情報から移動方向を
決定する。

動くマスは、初期配置と別に現在のXY座標を
持たせ、それをスイッチでずらしていけば
再現できそう。エリアと座標の情報を別に
しておけば表面的な違いだけだろう。

◆EFBt/pII5Y · 2005/08/08(月) 23:59:08

移動に関しては、>>300や>>304からヒントを得て、少し違った方法を考えました。
正直言えば、プログラム側の処理を楽にしたいだけですが・・・。
しかし、その方法では5方向の分岐の場合、「5方向中2方向に移動可」という条件には対応できません。
なのでマップにはある程度の制限を設ける予定です。

**300** · 2005/08/09(火) 00:02:25

連投すいません。330補足。
一応、私のイメージした処理手順の参考資料、おいておきますね。

http://tsukac.hp.infoseek.co.jp/sankou3.txt

もしマップデータ側に組み込むのであれば、この処理で値が出せます。

◆EFBt/pII5Y · 2005/08/09(火) 00:12:23

>>331
その方法は>>330を読む限り完璧っぽいのですが、
実際そのデータを使って移動させる方法が良い方法思い付かないのです。
プログラム側で行ってる処理を書こうにも上手く説明できないできそうもないですし・・・。
なので>>304に比べると劣りますが、楽な方法を考えました。

>>333
どうもありがとうございます。
熟読しておきます。

**304** · 2005/08/09(火) 00:30:25

>>325 ◆EFBt/pII5Y
マップなんだけど、テキスト形式で読める
ようにするのがいいと思う。マップを制作
してもらう場合、バイナリ形式とは扱い
やすさが違うし、Web上でそのまま公開
できるのも利点だろう。

どうしてもテキスト形式で扱えないなら
コンバーターでも経由して読み込み、
データそのものはテキスト形式で提供
＆公開してもらうことをお勧めする。これ
だけのものを作れる実力があるんだし、
ぜひ対応させてくれよ…。なっなっ？

縮小マップは>>330の意見に賛同したい。
計算すれば得られる同じ内容のデータを
複数持つのは無駄だと思うんだ。

>>332
自分のデータに「方向」を持たせて、
「方向」×2番目から2文字抜き出した
ものが移動可能な方向――という処理は
難しいかな？戻る場合は、座標マップから
計算してもいいし、たどった経路を記録
してそれを使う方法でも大丈夫だと思う。
>>304 の方法なら制限もないし、90度
回ってもジグザグに移動しても、対応
できる柔軟性があるんだけどな……。

**300** · 2005/08/09(火) 01:16:52

うむむ、３連投。◆EFBt/pII5Yさんが混乱してきていなければいいんですが(^^;
ご自分のペースでゆっくり作って下さい。

>>331（304さん）
そう言っていただけて恐縮です。では早速、私ならこうする！　を（笑）。

階層をまたぐ階段・ワープはそれほど難しいものではなかったりするかも。
マップデータの「余っている部分」を使うと新定義書式を追加せずとも、書式解釈の拡張でできます。もはや荒技ですが。
余っている部分が0でなくてもいい、というのが条件で、あらかじめ階段マスの「物件価格」に当たる部分に新たな移動先のx座標、
「所属エリア」に当たる部分に移動先のy座標を書くのがポイント。

移動中に到達先のマスの種類をチェックし（銀行かどうかをチェックするのと同じようなもの）、
到達先が階段ならそのマスの「物件価格・所属エリア」を読む。
読んだ値を新たな到達先のx・y座標として流用し、そちらに移動させる。
階段は店ではないので、物件価格・所属エリアは本来は必要のないデータのはずですが、必要のない事を逆用して別用途で使ってしまおう、と。
ワープマスは、歩いている最中→止まった後になるだけで同じ処理。

>>335
分かった！　私がコンバーターも一緒に作ればいいんだ（笑）！
元々作成の途中経過をセーブ・ロードする機能はつけるつもりでしたし。
書式はひとまず最初に上げていただいたmapdata.txtに準じます。
あとはアプリからバイナリ出力とテキスト読み込み機能の部分を分離したものを別公開すればいいだけ。
もっとも、テキストを読み込むとゲームが自動起動する機能をつけるとなると、◆EFBt/pII5Yさんにお願いするしかなくなるのですが。

・・・HSP言語のテキストファイルを扱う能力って、どんなものなのだろう。
こういうデータを読み込む場合、「カンマ区切りの文の中から、何単語目を取り出す」ような命令がないと辛いですが、
少なくともMac版HSP言語リファレンスには、そういう関数がなかった・・・
もしかしてバイナリ形式を使っているのは、そこがネックだったからですか？>>◆EFBt/pII5Yさん

◆EFBt/pII5Y · 2005/08/09(火) 01:34:10

とりあえず、ファイル形式のレスだけでも。
マップデータはすべて配列で読み出してるため、プログラム側の処理は1行で済むのです。
しかし、テキストだと非常に面倒になってしまいます。（簡単な方法もあるのかも知れませんが）
そういった理由で今の形式になってます。

**名前は開発中のものです。** · 2005/08/09(火) 07:47:55

>>336
　","で区切られたCSV形式のデータなら、csvstr命令(要hspda)で各データを配列に
展開することができます。\nで区切られているのならノートパッド命令で楽に扱えますが。

**名前は開発中のものです。** · 2005/08/09(火) 10:42:08

>>335
バイナリでも配布は可能でしょ。
メモ帳などで直接書き込んでいくならともかく
専用のアプリを作っているようなので
テキストである利点は見つからない気がする。

**304** · 2005/08/10(水) 02:28:26

>>339
うんうん、コードの違いもなければ変換の
必要もないし、そのままの形で読み込める
バイナリはいいよな。アプリ側からすれば
便利なことこの上ない。アップロードする
際に設定を間違えなければファイルが壊れる
こともないし、圧縮して配布すればこんな
心配も不要だ。もちろんバイナリで配布が
不可能なんてことはない。

だが、バイナリはそのままでは編集しにくい。
この場合、既存もしくは新規のマップを作成
するためのエディタだが、もし作ったマップで
アプリを実行した時に座標か店舗情報の設定に
ミスが見つかった場合を考えてくれ。

バイナリ形式のファイルなら普通、エディタを
起動、編集・保存して再度アプリを実行する。
これは通常のバイナリエディタでも可能だが、
恐らく専用のエディタが必要な人がほとんど
だろう。だが、テキスト形式で保存していた
場合はどうだろう。ミスの見つかった座標や
数値を任意のエディタで簡単に編集でき、
『メモ帳などで直接書き込んでいく』場合に
該当すると思うんだ。

これはテキストである利点と言えないか？

**名前は開発中のものです。** · 2005/08/10(水) 06:29:41

>>340
利点うんぬんは別として安易に書き換えられるのは問題かと。
誤って変更された場合ゲームの結果がおかしくなってしまう。
もちろん作者やエディタ作者もわかっていると思うが一応書いておく。

**初診さ** · 2005/08/10(水) 09:05:25

3D化を激しく希望!!!!
今のﾓﾅｰは正直ｷﾓｲよ。

**名前は開発中のものです。** · 2005/08/10(水) 11:26:56

これってどうやって開始するの？
通信ができませんって出るよ

**名前は開発中のものです。** · 2005/08/10(水) 13:36:01

>>343
o2b7.lzh落として展開
o2b7\bin\l_server.exe起動
is_2.exeまたはis_4.exe起動

これで分からなかったら過去レス嫁

**名前は開発中のものです。** · 2005/08/10(水) 20:28:56

交差転用データを作ったらいいかも
0なら普通の道1なら交差点という風に
で交差点のマスにとまったら交差転用移動方向データを読み出す
データを二重にしなきゃいけなくなるが・・・

**名前は開発中のものです。** · 2005/08/10(水) 20:31:07

test鯖立てます
明日くらいまで
203.110.96.205

**名前は開発中のものです。** · 2005/08/10(水) 20:34:37

>>346
2と4どっち起動すればいいの？

**名前は開発中のものです。** · 2005/08/10(水) 20:36:49

連投ｽﾏｿ
>>342
敷居が高くなってしまいそう。キャラは仮じゃないのかな。

**名前は開発中のものです。** · 2005/08/10(水) 20:38:11

portって何番ですか？

**名前は開発中のものです。** · 2005/08/10(水) 20:39:00

4です

**名前は開発中のものです。** · 2005/08/10(水) 20:55:36

>>349
30009っぽい

**名前は開発中のものです。** · 2005/08/10(水) 21:12:51

ロビー入れたけど人いねえ

**名前は開発中のものです。** · 2005/08/10(水) 21:40:34

>>346に入れない。

**名前は開発中のものです。** · 2005/08/10(水) 23:06:07

ひといない

**300** · 2005/08/13(土) 00:56:58

336で書いた「テキストマップデータ→バイナリへのコンバーター」が少し出来上がったので、とりあえず公開してみます。
http://tsukac.hp.infoseek.co.jp/sankou.html
の構造を少し変えて、ここに掲載しました。

バイナリマップの方は、「実験マップ」を解凍してできたmap2.bin（名前が「map」である必要があったら直して下さい）を、
現状の「datフォルダ内のmap」に差し換えると、レイクマウンテンっぽいマップが出来上がるはずです。

アプリの方はまだWin機でテストができていない為、非公式公開とさせていただきます。
どんな障害が起きるか分かりませんが（レジストリなどはいじらないはずなので、致命的な障害は起きないと思います）、
それでも使ってみたい、人柱になってやるぜ（笑）！　という方は「マップコンバーター」からどうぞ（332KByte）。

**304** · 2005/08/13(土) 03:18:44

>>344
>>259 の配布サイトを見て登録が必要なのかと
思ってスルーしてたが、>>344 を見て誤解だと
気づいた。ありがとう。もし同じ勘違いをして
いる人間が居たら、安心して遊んでほしい。
必要なファイルをそろえたら、あとはオフライン
でも大丈夫だった。

>>◆EFBt/pII5Y
システム自体は古い作品をベースにしても問題
ないと思うが、メニューの階層や選択方式は
いたストSP準拠にできないものだろうか。
「はい／いいえ」が多すぎると感じた。あと、
周回の単位が「周」ではなく「週」になって
いるのが気になった。

>>355
人柱の結果をアップした。これは想定の範囲内？
ttp://gamdev.org/up/img/3028.zip

それと、70文字くらいで改行入れてもらえると
テキストが見やすくなっていいと思う。

**名前は開発中のものです。** · 2005/08/13(土) 22:20:59

ポートあけて鯖立ててみました
203.110.100.80
is_4
起動時間はパソコンが止まるまで

**300** · 2005/08/13(土) 22:31:10

ところで◆EFBt/pII5Yさん。
ゲームアプリ内で、実際に扱える縦横幅・エリア数の領域はどれくらいでしょうか？
一応こちらのエディタでは縦横３０マス、１８エリアという、既存マップの最大値より少し大きいくらいに設定するつもりです。
これ以上いける、あるいはこれ以下しかできない、などありますか？

>>356
人柱ありがとうございます。SS見ました。大体想定の範囲内です。
ひとまずはWin機で正しく動く事と、ゲームで読み込めるデータを一応作れる事が分かればいいレベルでしたので。
これでマップエディタ本編制作の足掛かりになります。
改行を入れるべきなのは、ドキュメント群の事でしょうかね。
次のVer.の時にHTMLで作るか（書式の解説が少ししやすくなるので）、素直に改行を加えるか、どちらか対応します。

>>341
エディタ作者側から遅レス。
ファイルの状態になっている「プレイ前の」マップデータをバイナリエディタなどでいじられるのは、
作者側からしたら防ぎようがないので軽視していい問題のような。
バイナリの方がいじられる確率が下がるのは確かですが。
むしろ「通信相手のプレイヤー全員が同じマップデータでスタートするシステム」を用意するのが重要。
メモリでアクティブに動いている「プレイ中の」データがいじられては問題ですが、
それこそ専門のアプリが必要でしょうし、そこまでの手間をかける人がどれだけいるか。

私としては、マップデータはテキストの方がいいですね。
テキストだと手直しも簡単ですし、書式を覚えているとマップエディタを使うより素早く作れる場合もあります。
既存のマップデータを敢えていじってサラリー・店舗価格などが全部１０倍のバブリーないたストや、
逆に全部２分の１のデフレいたストが比較的簡単に作れて面白かったりするかなぁ、と（笑）。

**名前は開発中のものです。** · 2005/08/13(土) 22:41:10

>>357
今繋いだけど他に人居たのに反応なかったよ。
おそらくルームとロビーのチャットは全く別物のようだね。

お盆だから作者居ないのかな？

**名前は開発中のものです。** · 2005/08/13(土) 23:46:35

繋いでチャットしたりするのは問題なし。
roomに入れなかったりするがこれは2と4の違いの問題？

**名前は開発中のものです。** · 2005/08/14(日) 22:42:02

カタンのような生産性があるゲームがいいな

**名前は開発中のものです。** · 2005/08/15(月) 11:45:39

>>1は逃げたのか？

**名前は開発中のものです。** · 2005/08/16(火) 01:09:14

まとめサイト
まだ～

**名前は開発中のものです。** · 2005/08/16(火) 01:28:02

>>363
gamedevにはないから>>312のサイトがまとめなんじゃない？

◆EFBt/pII5Y · 2005/08/16(火) 15:36:50

ttp://zxzxzxzxzx.hp.infoseek.co.jp/board/is.zip
移動方法変更
特定の相手へのチャットを
/名前文字列（スペースがいらない）
に変更
増資限度額
店舗数により買い物料変動（エフェクトなし）

>>355のレイクマウンテンもきちんと表示されるはずです。
ただし、移動方法が変更されてるのでサイコロ振るとエラーになります。
移動のテストをするので、人が居そうなときに鯖立てます。

マップサイズは縦横50、エリア20あれば十分だと考えてます。
現在はサイズ上限なし、エリア8です。
あとマップサイズ*80を超える表示は出来ません。
左端のマスを左にずらすなど。
マップファイルは配布された状態から弄らないものと考えてますので、
弄ったら故意とみなし、対策などはしない予定です。
テキスト、バイナリの件ですが今の所変更する予定はありません。
上に書いたように、ファイルそのものを弄ることは禁止にするつもりですし、
それよりも優先的に手を付けるべき箇所があるので。

◆EFBt/pII5Y · 2005/08/16(火) 15:41:14

移動方法の変更点
1～9の他にA～Iを使用
Aなら1には進めない
Bなら2には進めない
Hなら8には進めない
Iなら9には進めない

5番目の値は停止後、移動するときのみ使用
0は分岐なし
1なら来た方向を含むすべての方向に進める
2なら来た方向を除くすべての方向に進める
3なら直前の移動方向に従う
この方法では5という値は使用しません。

例えば、貝がら島の銀行は"103010709"となり、
"C0I030A0G"とすると常にL字型の分岐になります。

**名前は開発中のものです。** · 2005/08/16(火) 19:04:43

特定の相手へのチャットってのが意味不明。送っても自分に帰って来る。

**名前は開発中のものです。** · 2005/08/16(火) 21:38:06

>>355の結果
ttp://gamdev.org/up/img/3032.jpg

**300** · 2005/08/16(火) 22:55:45

>>366
バージョンアップお疲れです。
次回のコンバーターのバージョンアップ時に
・移動データに使用できる文字の範囲の調整
・マップ縦横幅とエリア数の上限設定
・表示可能幅超過時の警告
の対応をします。
が、５０マスは作成アプリの画面領域が厳しい＆色の数も厳しいので、ひとまずは３０マス＆１８エリアで作ります。
それ以上欲しければ自分でテキストデータを書いて変換してくれ、と逃げる(^^;

移動方法については、こちらは決定に対応するのみなのですが、微妙にイメージしにくいなぁ・・・
一部例を挙げるので回答をお願いします。これが分からないとマップ作成アプリが作れないので。

・「停止後＝方向転換可能状態になった次のターン１歩目」という解釈ですか？　それとも違う状態ですか？
・フリーウェイの銀行右側のマークマス（真っ直ぐのみの完全一通、方向転換可能時のみ選択可能）は
　020416080
　ですか？
・日本列島の銀行（下・左←→上・右、方向転換可能時は全て選択可能）は
　0F0H1B0D0
　ですか？
・日本列島の北陸すぐ左のチャンスマス（右斜め方向←→左斜め方向、方向転換可能時は全て選択可能）は
　C0A010I0G
　ですか？
・ハワイのチャンスマス（離れ小島仕様、転換可能時も左しか進めない）はどのように書きますか？

**300** · 2005/08/16(火) 23:07:42

>>367
私は試せないので分かりませんが・・・
自分が密談をしたい相手（「プレイヤー１」とする）に密談メッセージを送りたい場合、
送りたいメッセージの前（後？）に「/プレイヤー１」とつけると、

・自分は送ったメッセージが（入力した通りに）表示される。
・プレイヤー１は届いたメッセージが表示される（密談メッセージである事を明示しているかも？）
・その他のプレイヤー（プレイヤー２・３）はメッセージのやり取りがあった事が表示されず、メッセージも分からない

となるのでは？

これは、>>368のSSみたいに、同名のプレイヤーがいた場合はどうなるのかなぁ・・・

◆EFBt/pII5Y · 2005/08/16(火) 23:53:19

＞・「停止後＝方向転換可能状態になった次のターン１歩目」という解釈ですか？　それとも違う状態ですか？
状態に関係なくサイコロを振って一歩目ということです。
＞・ハワイのチャンスマス（離れ小島仕様、転換可能時も左しか進めない）はどのように書きますか？
040000000
その他の質問はその通りです。

移動の制限を書いておくと
分岐は4つまで
移動できる方向は

通過時
一方通行
来た方向を除いた全方向
来た方向と一方を除いた二方向（4分岐時）

停止後（サイコロ振って一歩目）
全方向
来た方向を除いた全方向
直前の移動方向に従う

これ以外はできません。

つまり
■□■
□□□
■□■
この場合、通過時は「一方通行」で停止後は「来た方向と一方を除いた二方向」という分岐はできません。

この移動方法に問題があったらご指摘お願いします。

◆EFBt/pII5Y · 2005/08/17(水) 00:04:47

＞特定の相手へのチャット
オンラインゲームによくある密談というやつです。
>>370の通りですが、2人だと普通のチャットと変わらないのでわからないと思います。
見た目の判断としては文字列が()で括ってあります。あとロビーでは使えません。

名前の重複問題もあるので、色指定か、番号指定にするかもしれません。
そもそも小規模ゲームでこの機能に意味があるのかわかりませんが、自己満足というやつです。

マップサイズは３０マス＆１８エリアで構いません。

今はワープを一切考えずに作ってます。
もちろん複数階層のマップなども。

**名前は開発中のものです。** · 2005/08/17(水) 00:39:38

>>1には２chキャラとあるが、それに拘らず萌えキャラも欲しい
ぶっちゃけ２人集まるのすらきついほど過疎ってるのが現状だ
だが萌えキャラ出せばそれだけで興味を持つ人も出るはず
それと進行役はあやかで頼む

**名前は開発中のものです。** · 2005/08/17(水) 12:43:47

移動中にズレがあるね。
ラグって言うのかな？

**名前は開発中のものです。** · 2005/08/17(水) 13:23:02

足りない分をCPUで補うとかできないの？

**名前は開発中のものです。** · 2005/08/17(水) 14:44:48

スレタイに惹かれてやってきたけど
完成してんの？これ

**名前は開発中のものです。** · 2005/08/17(水) 15:17:14

>>375
そんな大変なこと頼むなよ

その代わり４人じゃなくてもできるならいいじゃないの？
まあ２人だとあれだが
３人、ならまだゲームになると思うぞ

**300** · 2005/08/17(水) 18:54:43

>>371
うーん、問題・・・
移動可能方向がイメージしにくいのが最大の問題と言えなくもない(^^;;
・・・すいません。回答をいただいて何なのですが、ハワイのチャンスマスのデータが何故「040000000」になるのかが未だに理解できていません(^^;;;
確かに歩きの場合は上からしか来れませんが、そもそもこのマスにはワープしないと来れません。
ワープ後＝停止状態からなので、ここで移動方向の指定がないと、どの方向に移動できるのか分からないと思うのですが・・・

実際のゲームでは、止まった時と通過する時とで移動可能な方向が違うマスは、
止まると方向転換可能になる銀行マスを除くと「宇宙星雲の四隅以外の端マス」だけです。
実際に自作マップを作るにしても、そんなトリッキーな移動方向を作りたがる方って、それほどいないのでは？
そんなマスの為だけにわざわざ停止後の移動設定をするのもどうかという気がしますねぇ・・・

そこで！　１つこんなものを作って来ました。
いわゆる「304方式」（勝手に名付けて申し訳ないですが）の処理を実際にHSPで書くとこうなる、という具体例です。
304さんの意図する処理法は、大体こんなものかと思うのですが。

（処理解説）http://tsukac.hp.infoseek.co.jp/sankou5.html
（ソース）http://tsukac.hp.infoseek.co.jp/sankou5-2.html

ざっと言語リファレンスを調べただけでソースを書いてしまったので、
一部文法ミスがあるかもですが、参考にしてみてくだされ。

**名前は開発中のものです。** · 2005/08/17(水) 20:05:50

テストできないみたいなので書いておくけど移動は分岐以外はすべて自動移動。
>>今進んだ道をキャンセルして１歩戻る
これは実装済み。

◆EFBt/pII5Y · 2005/08/17(水) 21:59:40

>>363-364
簡単な説明とSSがあるだけですが、一応まとめと考えてます。
SSは随時更新する予定です。

>>373
俺は>>1じゃないのですが、おそらく2chキャラというのはAIの意味でしょう。
COM戦はないのでAIは作りませんが、キャラ（個性）は在ってもいいかなと思います。
2ch版とありますが、特に2chに拘るつもりはありません。
絵に関しては、描けないのでどうにもなりませんが、最悪は自分で描こうかと思ってます。

>>374
遅延対策としてターン中のプレイヤーには0.2～0.5秒のウェイトをかけています。
この辺の調整が必要なので、テストをする予定です。

>>375
上のような理由で無理です。

>>376-377
完成度は自分でもまだ不明。
2人はローカル用と考えてます。
1台で3つも4つも起動できる環境はそうそうないと思うので。

>>378
停止状態＝方向転換可ですよね？
まあ、ハワイの場合は時計周りのようですが。
その辺は内部で処理しているので、問題ないです。
>>372にも書きましたが、現在はワープなどは考えてないので、実際どうなるのかは
その時にならないとわかりませんが。

**名前は開発中のものです。** · 2005/08/17(水) 22:10:44

ん？テストってどうやんの？

**名前は開発中のものです。** · 2005/08/18(木) 00:39:09

ttp://f7.aaa.livedoor.jp/~nekoko/imgboardphp/src/1069858089722.gif
この素材とかどうよ？2chだし規格も同じっぽい。

**名前は開発中のものです。** · 2005/08/18(木) 15:22:19

10株売り出来るのは嫌だな。
何かしら別の条件を考えるべき。

◆EFBt/pII5Y · 2005/08/18(木) 21:56:58

ttp://zxzxzxzxzx.hp.infoseek.co.jp/board/is.zip
増資による株価変動を追加
バグ修正

移動テストしたいのでよろしければ協力お願いします。
今回新たにうｐしたexeで接続してください。
接続方法は127.0.0.1を
222.0.70.221
に変更してください。
3人集まったらテストします。
集まらなかったら日を改めてまたいつか。

>>381
上に書いたようにやります。

>>382
その画像なら変更はすぐできますが、規約がないので勝手に使っていいのかが不明です。

>>383
細かいルールは後々考えます。
10株売りは個人的に嫌いなので賛成です。

**名前は開発中のものです。** · 2005/08/18(木) 22:27:24

やりこみゃわかるが、10株売り無いとゲームがものすごく単調化するぞ。
基本的にいたストルールを採用するべきかと。
嫌いだったら開始時にそのテーブルで禁止してほしいな。

**名前は開発中のものです。** · 2005/08/18(木) 22:32:25

>>384
この板過疎ってるから、テストすらなら他板にも協力を求めた方がよいと思うよ。
ネトゲ関係とかvipとかなら協力してくれそうじゃない？

>>355のマップ見て思ったけど、マークが4つ以上のマップには対応してないね。

◆EFBt/pII5Y · 2005/08/18(木) 22:45:48

>>385
その辺のバランスが難しそうですね。
もちろんルールは幅広く設定できるようにする予定です。

>>386
全く集まらないようでしたら、考えないと駄目ですね。
最終的に4人でやるゲームなので、4人でテストできないとどうしようもないので。
マークはすべてを貝がら島をベースに作っていたため忘れてました。

◆EFBt/pII5Y · 2005/08/18(木) 23:05:53

ttp://zxzxzxzxzx.hp.infoseek.co.jp/board/is3.zip

これです

◆EFBt/pII5Y · 2005/08/18(木) 23:45:40

テスト協力どうもありがとうございました！
データの送受信に関しては問題なしでしたね。
2回連続でバグ発生は大変申し訳ないです。
次回うｐまでに原因を突き止め直しておきます。

**300** · 2005/08/18(木) 23:51:40

>>384（◆EFBt/pII5Yさん）
ふむ・・・　完全一通は、歩いた時に必要な部分だけ書いて、あとは「0」で埋めておけばいい・・・　のかな。
ただ、「ワープして来た、などで方向転換可能になった状態からの歩き方を定義する方法」は早いうちから決めておいた方がいいですよ？
これを考慮に入れないと、絶対に困る事になります。
例えば、今の方法だといたスト３・ホラーハウスの一部のマスの進み方に対応できなかったりするかもしれない訳で・・・
http://homepage1.nifty.com/tsukac/itast/kouryaku/street3a06.html
参照。白抜きマーク（変わるマークマス）は分岐３点ですが、このマスでチャンス１番を引いて転換可能になっても左下には移動不可です。
このマスのデータはどう書きます？

>>386
マークが５つ必要なマップというのもどうなんでしょう・・・
ただ、マークを３つ以下しか採用しないマップというのは、逆に「あり」なのかも。
もちろんサラリー額を低くするのが前提ですが。
>>355のテストデータは、単純に私が書式を間違えたままアップしてしまったものです(^^;
本当は銀行の２つ下の四角マークは、ただのカードマスにしたかったんですが、間違えた(^^;

>>383　>>384（◆EFBt/pII5Yさん）
１０株売りは、プレイヤーが唯一、自発的かつ確実に相手の資産を落とす事ができる手段です。
これを完全になくしてしまうと、それこそ運だけゲーになりかねないです。
また、サイコロ前の株売りをできなくする事も、自発株売りと強制株売りで株価の下がり方を変えるのも、問題が多数。
そこで、単純な解決策っぽいものを１つ。
「株売買時の株価変動幅も定義できるようにする」。
マップデータの基本データ部を拡張し、株売買時の株価上下幅をマップデータ内で定義できるようにするもの。実装は簡単なはず。
上昇８％、下降６％にするだけでも大分違うと思います。
・・・本当は、目標金額や破産人数とかこの辺りの数値なんかは、ロビーでゲーム開始前に設定を変えられるとベストなんですがね・・・

**300** · 2005/08/18(木) 23:53:47

微妙に間違えた・・・

最初の>>384は、>>380で。
宛てている方は同じですが、一応・・・

**1234** · 2005/08/18(木) 23:54:21

先ほどはどうも。
スーファミ版2を知ってから十年以上、ネット対戦できるなんて感慨深い感じでした。
300さんのページなんか印刷して暗記するくらい読んでましたよ。

すごろくとしての移動部分はかなりいい具合でした。

まあ、プログラムのほうはさっぱりなんで人柱くらいしかできませんが。

◆EFBt/pII5Yさん、そしてサポートの300さん応援してますよー。

◆EFBt/pII5Y · 2005/08/19(金) 00:50:10

>>390
そのマスから、来ることが出来ないマスであれば、
たとえ方向転換可能であっても内部で進めないように処理してあります。
パッと見ただけなので、じっくり見てみて無理っぽかったら考えます。
ワープに関しては、今試してる所ですが、かなり難しそうです。

＞マークが５つ必要なマップというのもどうなんでしょう・・・
トランプ+★のことだと思ったのですが、そんなのなかったでしたっけ？

10株売りとかその辺はじっくり考えて決めます。
サイトに書いたように、すべての仕様をパクるのはやばそうなので
ルール設定を細かくして、基本は完全なオリジナルにする予定です。
そういった訳で、いたストそのままというわけにはいかないと思います。
ロビーで部屋を作るとき、こういうルールでやりますよって設定できればよいのですが、
o2の仕様ではできないため、定員が揃ってから決めるという形になるかと。

>>392
どうもありがとうございました。
お時間が合えば、またよろしくお願いします。

**名前は開発中のものです。** · 2005/08/19(金) 01:16:10

ttp://game10.2ch.net/test/read.cgi/netgame/1103952787/
ここで宣伝しておきました。

**名前は開発中のものです。** · 2005/08/19(金) 12:38:34

FFDQいたストだと分かれ道の方向転換が自由にできるよね？
あれはハメが回避しやすくて戦略的だと思ったんだが、
オプションでこのへんもいじれるとうれしい。