夜中中、いただきストリートをやっていたんだけど
こんなにおもしろいボードゲームはないと思った。
２chのキャラクターを使ったいたストがあればもっと
個性的でおもしろいゲームが作れそうな気がするんだが
どう思う？意見を聞かせてくれ！
2ch版いただきストリート作りませんか？
■ このスレッドは過去ログ倉庫に格納されています
1326
03/12/04 06:46ID:D1wkthci317名前は開発中のものです。
2005/08/07(日) 00:33:10ID:D8H76SIY チャンスカードのオリジナル案
引いたときにイベント起きるんじゃなくてカードをアイテムという形で貰って自分の出番のときに使える
駆け引き要素が強くなって戦略性が増すと思う
引いたときにイベント起きるんじゃなくてカードをアイテムという形で貰って自分の出番のときに使える
駆け引き要素が強くなって戦略性が増すと思う
319304
2005/08/07(日) 01:05:15ID:oc41e6p7 >>300＝>>287の中の人
横から見せてもらったが、かなり気合入ってた。
アプリをバカにしたような言い方をしてしまい、
すまなかった m(_ _)m 「実装に時間を費やす
より、他人が作っているところにアドバイスを
してもらうのが、有益な時間の使い方だ」と
言いたかっただけで、気を悪くしないでくれ。
>>315
マップは仕様だけ公開しておき、エディタは
他人に任せるのがいいと思う。>>315 にしか
できないことも多いだろうから、それだけに
集中してくれよ。
この辺を見るとアイディアや情熱を持っている
人間も少なくないだろう。
ttp://is-opc.hp.infoseek.co.jp/
横から見せてもらったが、かなり気合入ってた。
アプリをバカにしたような言い方をしてしまい、
すまなかった m(_ _)m 「実装に時間を費やす
より、他人が作っているところにアドバイスを
してもらうのが、有益な時間の使い方だ」と
言いたかっただけで、気を悪くしないでくれ。
>>315
マップは仕様だけ公開しておき、エディタは
他人に任せるのがいいと思う。>>315 にしか
できないことも多いだろうから、それだけに
集中してくれよ。
この辺を見るとアイディアや情熱を持っている
人間も少なくないだろう。
ttp://is-opc.hp.infoseek.co.jp/
320304
2005/08/07(日) 01:21:46ID:oc41e6p7 >>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だけを設定しておき、移動制限用の
関数でつぶす（＝来た方向＋進行方向のビットを
消す）方法もある。データが短くて済むが、関数を
個別に設定するのが面倒だし、マップデータから
方向を抜いてくる方が処理しやすかったりする。
>>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だけを設定しておき、移動制限用の
関数でつぶす（＝来た方向＋進行方向のビットを
消す）方法もある。データが短くて済むが、関数を
個別に設定するのが面倒だし、マップデータから
方向を抜いてくる方が処理しやすかったりする。
ttp://zxzxzxzxzx.hp.infoseek.co.jp/board/mapdata.txt
ttp://zxzxzxzxzx.hp.infoseek.co.jp/board/scr.txt
上がテキスト形式マップデータにコメントを入れたもの
下がマップ作成に使ったソース
分かり難いかもしれませんが・・・
背景、店の名前、など他にもいろいろ必要なのですが、まだ手を付けてない場所なので入ってません。
また、今回の移動方法もそうですが、より良い方法があれば仕様の変更などもありえます。
現在は必要なデータを順に保存しているだけなので、
作っていただけるならすべての仕様をしっかり決めてからで構いません。
後で変更するのもお手数ですし。
＞気になるのは、銀行以外のマスの５文字目が5ではなく0なところ。
その辺もまだ手を付けていないので、追々考えます。
>>320
今回はとりあえず、>>300の方法で書いてしまいましたが、応用性はそちらのほうが高いようですね。
ttp://zxzxzxzxzx.hp.infoseek.co.jp/board/scr.txt
上がテキスト形式マップデータにコメントを入れたもの
下がマップ作成に使ったソース
分かり難いかもしれませんが・・・
背景、店の名前、など他にもいろいろ必要なのですが、まだ手を付けてない場所なので入ってません。
また、今回の移動方法もそうですが、より良い方法があれば仕様の変更などもありえます。
現在は必要なデータを順に保存しているだけなので、
作っていただけるならすべての仕様をしっかり決めてからで構いません。
後で変更するのもお手数ですし。
＞気になるのは、銀行以外のマスの５文字目が5ではなく0なところ。
その辺もまだ手を付けていないので、追々考えます。
>>320
今回はとりあえず、>>300の方法で書いてしまいましたが、応用性はそちらのほうが高いようですね。
322名前は開発中のものです。
2005/08/07(日) 13:15:04ID:UGnp9QSo 背景ってアニメーションだけどそんなの出来るのか
323名前は開発中のものです。
2005/08/07(日) 20:06:57ID:BrYppW08 普通に並べると16行〜22行になりますが
これ意味わからん
これ意味わからん
324300
2005/08/07(日) 22:33:02ID:DeRmvwAL >>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さん
テキスト仕様公開ありがとうございます。大体理解できました。
まずは作成アプリの原型が全くできていないと話にならないので(^^;、この仕様を参考に頑張ってみます。
で、ありがとうございますついでに失礼ながら・・・
できましたら、「今回掲載いただいたテキスト形式マップデータからコメントを抜いたもの」もいただけますと大変助かります・・・
というのは、「見やすいように,や半角スペース入ってますが実際は数値のみ」となっている部分の解釈に若干苦しんでます。
例えばマス目データ１行目は、カンマが入ってスペースだけ消えた
x,x,4,4,x,x,x,x,x,4,4,x,x
（xはデータを書き出す時に-1にします）が正しいのか、カンマが入らず、スペースも消える
xx44xxxxx44xx
が正しいのか。
休日・銀行の表記が10・11になっていて、ただ文字をつなげると解釈がおかしくなりそうなので、前者が正しいものと考えますが・・・
>>320（304さん）
この形式だと、どんな分岐にも完璧に対応できますね。
階段とか動くマスとか宇宙星雲の複雑仕様は、この際（軌道に乗るまでは）採用しなくていいと思いますし。
素晴らし過ぎて私の案はもはや形無し（笑）。
元いたマスを弾くチェックをアプリ側ではなくマップデータ側に持たせる（マップ作成の段階で最初から行けないように設定してしまう）と、
分岐や強制一通などの方向チェック処理を一本化してしまえるので、アプリ側も楽ができそう。
作成アプリ側で分岐の設定をアシストする機能をつければ、分岐設定もそれほど大変にはならなそうです。
最初に言ってしまった労力９倍はどう考えても嘘だ(^^;
>>323
このマップを、ただ普通に座標から再現すると、横１３×縦７マスのボードに角張った丸のような形が２つ繋がったマップになります。
この「ボードのマスの数」の事を言っているのだと思います。
それを、画面上だけは本来の座標の位置から４分の１マス×単位分だけずらして表示できる仕様なのですよね？>>◆EFBt/pII5Yさん
>>323
17〜23の間違えでした。
>>324
ttp://zxzxzxzxzx.hp.infoseek.co.jp/board/map.zip
これが実際使用してるマップデータです。
テキスト形式ですが、保存してるデータをテキストにしただけで、
実際あのように保存されてる訳ではありません。すいません。
保存方法は配列をサイズ指定して保存し、保存位置にサイズを足す。
次の配列をサイズ指定して保存位置から保存し、保存位置にサイズを足すの繰り返しです。
サイズは書いた通りです。
区切りはカンマではなく数値配列は1つ4バイトなので、1つの要素を4バイトで保存。
これで読み出せてるので、そのはず。
上手く説明できないのですが、こんな感じです。
使用してるデータを保存方法と同じように読み出せばおｋです。
移動はやはり>>320の方法のが良いみたいですね。
理解能力がないので読んだだけではイメージ沸きませんがやってみます。
折角提案頂いた>>300の方法を利用しないのは申し訳ないです。
マスの表示方法はその通りです。
17〜23の間違えでした。
>>324
ttp://zxzxzxzxzx.hp.infoseek.co.jp/board/map.zip
これが実際使用してるマップデータです。
テキスト形式ですが、保存してるデータをテキストにしただけで、
実際あのように保存されてる訳ではありません。すいません。
保存方法は配列をサイズ指定して保存し、保存位置にサイズを足す。
次の配列をサイズ指定して保存位置から保存し、保存位置にサイズを足すの繰り返しです。
サイズは書いた通りです。
区切りはカンマではなく数値配列は1つ4バイトなので、1つの要素を4バイトで保存。
これで読み出せてるので、そのはず。
上手く説明できないのですが、こんな感じです。
使用してるデータを保存方法と同じように読み出せばおｋです。
移動はやはり>>320の方法のが良いみたいですね。
理解能力がないので読んだだけではイメージ沸きませんがやってみます。
折角提案頂いた>>300の方法を利用しないのは申し訳ないです。
マスの表示方法はその通りです。
326名前は開発中のものです。
2005/08/07(日) 23:47:15ID:xITz3APv >>287氏はmacって書いてあるだろ。zipで上げてどうする。
327300
2005/08/08(月) 01:01:32ID:rkeTqnYU >>327
すいません、こちらの説明不足でした。
内容はご理解されたようですね。
他にも縮小マップのサイズなどもマップに持たせるべきですね。
固定サイズだと画面を埋め尽くしてしまうの可能性があるので。
その辺は規格をしっかり固める必要がありますね。
すいません、こちらの説明不足でした。
内容はご理解されたようですね。
他にも縮小マップのサイズなどもマップに持たせるべきですね。
固定サイズだと画面を埋め尽くしてしまうの可能性があるので。
その辺は規格をしっかり固める必要がありますね。
329名前は開発中のものです。
2005/08/08(月) 09:34:44ID:+oIrkncQ すごい複雑な意見がたくさん出てますが、
上下左右を検索で道があればそちらに進む
道がなければ斜め4方向を検索して道があれば進む
こうすれば簡単だと思います。
ちなみに4方向以上の分岐ってないんですか？
もしあるなら今の方法では無理じゃないでしょうか。
上下左右を検索で道があればそちらに進む
道がなければ斜め4方向を検索して道があれば進む
こうすれば簡単だと思います。
ちなみに4方向以上の分岐ってないんですか？
もしあるなら今の方法では無理じゃないでしょうか。
330300
2005/08/08(月) 23:25:00ID:rkeTqnYU >>328（◆EFBt/pII5Yさん）
小マップのサイズ調整は、もちろんマップデータに組み込む事もできますが、マップデータ側ではなくアプリ側で処理すべき項目のような気がしますね。
マップ画面作成の一環として行なうもので、話はそれほど難しいものでもなく、
「マップが画面上で、縦あるいは横で一定以上のスペースを使っている場合、小マップ１マスのサイズをいくつに、それ以下ならいくつにする」
などと扱えばいいはず。
処理イメージとしては、
各マスについて「表示位置（マップデータ上の座標×80＋差分×20＝各マスの右下の画面上における座標）の最大値」を取る。
全マスの中で最大値を取るとマップ領域の右辺・下辺になるので、
その値の大きさによって小マップのマスの大きさを決定する。
どうするかはお任せです。
>>329さん
その方法だと真っ直ぐしか進めない十字路には対応できないです。
それを対応しようとすると、少しややこしくなってしまうのは致し方ない。
５方向の分岐は、こんな風に、
■■
■□■
■
マスの配置が奇妙になってしまうので存在しませんが、>>320の方式だとこれにも対応できますね。
画面上でずらして表示できる仕様と上手く合わせて使えば新機軸のマップも作れるかも？
小マップのサイズ調整は、もちろんマップデータに組み込む事もできますが、マップデータ側ではなくアプリ側で処理すべき項目のような気がしますね。
マップ画面作成の一環として行なうもので、話はそれほど難しいものでもなく、
「マップが画面上で、縦あるいは横で一定以上のスペースを使っている場合、小マップ１マスのサイズをいくつに、それ以下ならいくつにする」
などと扱えばいいはず。
処理イメージとしては、
各マスについて「表示位置（マップデータ上の座標×80＋差分×20＝各マスの右下の画面上における座標）の最大値」を取る。
全マスの中で最大値を取るとマップ領域の右辺・下辺になるので、
その値の大きさによって小マップのマスの大きさを決定する。
どうするかはお任せです。
>>329さん
その方法だと真っ直ぐしか進めない十字路には対応できないです。
それを対応しようとすると、少しややこしくなってしまうのは致し方ない。
５方向の分岐は、こんな風に、
■■
■□■
■
マスの配置が奇妙になってしまうので存在しませんが、>>320の方式だとこれにも対応できますね。
画面上でずらして表示できる仕様と上手く合わせて使えば新機軸のマップも作れるかも？
331304
2005/08/08(月) 23:57:41ID:BRbVxpr0 >>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座標を
持たせ、それをスイッチでずらしていけば
再現できそう。エリアと座標の情報を別に
しておけば表面的な違いだけだろう。
これも貴方が公開した元の仕様がなければ、
決して思いつかなかった方法だから、これ
からもアイディアをどんどん形にしていって
もらいたい。こういう部分はいたスト自体に
精通してないと思いつかないからね。
階層をまたぐ階段やワープはマスに表示上の
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座標を
持たせ、それをスイッチでずらしていけば
再現できそう。エリアと座標の情報を別に
しておけば表面的な違いだけだろう。
333300
2005/08/09(火) 00:02:25ID:4Fukq1SD 連投すいません。330補足。
一応、私のイメージした処理手順の参考資料、おいておきますね。
http://tsukac.hp.infoseek.co.jp/sankou3.txt
もしマップデータ側に組み込むのであれば、この処理で値が出せます。
一応、私のイメージした処理手順の参考資料、おいておきますね。
http://tsukac.hp.infoseek.co.jp/sankou3.txt
もしマップデータ側に組み込むのであれば、この処理で値が出せます。
335304
2005/08/09(火) 00:30:25ID:YYsTfEJ4 >>325 ◆EFBt/pII5Y
マップなんだけど、テキスト形式で読める
ようにするのがいいと思う。マップを制作
してもらう場合、バイナリ形式とは扱い
やすさが違うし、Web上でそのまま公開
できるのも利点だろう。
どうしてもテキスト形式で扱えないなら
コンバーターでも経由して読み込み、
データそのものはテキスト形式で提供
＆公開してもらうことをお勧めする。これ
だけのものを作れる実力があるんだし、
ぜひ対応させてくれよ…。なっ なっ？
縮小マップは>>330の意見に賛同したい。
計算すれば得られる同じ内容のデータを
複数持つのは無駄だと思うんだ。
>>332
自分のデータに「方向」を持たせて、
「方向」×2番目から2文字抜き出した
ものが移動可能な方向――という処理は
難しいかな？戻る場合は、座標マップから
計算してもいいし、たどった経路を記録
してそれを使う方法でも大丈夫だと思う。
>>304 の方法なら制限もないし、90度
回ってもジグザグに移動しても、対応
できる柔軟性があるんだけどな……。
マップなんだけど、テキスト形式で読める
ようにするのがいいと思う。マップを制作
してもらう場合、バイナリ形式とは扱い
やすさが違うし、Web上でそのまま公開
できるのも利点だろう。
どうしてもテキスト形式で扱えないなら
コンバーターでも経由して読み込み、
データそのものはテキスト形式で提供
＆公開してもらうことをお勧めする。これ
だけのものを作れる実力があるんだし、
ぜひ対応させてくれよ…。なっ なっ？
縮小マップは>>330の意見に賛同したい。
計算すれば得られる同じ内容のデータを
複数持つのは無駄だと思うんだ。
>>332
自分のデータに「方向」を持たせて、
「方向」×2番目から2文字抜き出した
ものが移動可能な方向――という処理は
難しいかな？戻る場合は、座標マップから
計算してもいいし、たどった経路を記録
してそれを使う方法でも大丈夫だと思う。
>>304 の方法なら制限もないし、90度
回ってもジグザグに移動しても、対応
できる柔軟性があるんだけどな……。
336300
2005/08/09(火) 01:16:52ID:4Fukq1SD うむむ、３連投。◆EFBt/pII5Yさんが混乱してきていなければいいんですが(^^;
ご自分のペースでゆっくり作って下さい。
>>331（304さん）
そう言っていただけて恐縮です。では早速、私ならこうする！ を（笑）。
階層をまたぐ階段・ワープはそれほど難しいものではなかったりするかも。
マップデータの「余っている部分」を使うと新定義書式を追加せずとも、書式解釈の拡張でできます。もはや荒技ですが。
余っている部分が0でなくてもいい、というのが条件で、あらかじめ階段マスの「物件価格」に当たる部分に新たな移動先のx座標、
「所属エリア」に当たる部分に移動先のy座標を書くのがポイント。
移動中に到達先のマスの種類をチェックし（銀行かどうかをチェックするのと同じようなもの）、
到達先が階段ならそのマスの「物件価格・所属エリア」を読む。
読んだ値を新たな到達先のx・y座標として流用し、そちらに移動させる。
階段は店ではないので、物件価格・所属エリアは本来は必要のないデータのはずですが、必要のない事を逆用して別用途で使ってしまおう、と。
ワープマスは、歩いている最中→止まった後になるだけで同じ処理。
>>335
分かった！ 私がコンバーターも一緒に作ればいいんだ（笑）！
元々作成の途中経過をセーブ・ロードする機能はつけるつもりでしたし。
書式はひとまず最初に上げていただいたmapdata.txtに準じます。
あとはアプリからバイナリ出力とテキスト読み込み機能の部分を分離したものを別公開すればいいだけ。
もっとも、テキストを読み込むとゲームが自動起動する機能をつけるとなると、◆EFBt/pII5Yさんにお願いするしかなくなるのですが。
・・・HSP言語のテキストファイルを扱う能力って、どんなものなのだろう。
こういうデータを読み込む場合、「カンマ区切りの文の中から、何単語目を取り出す」ような命令がないと辛いですが、
少なくともMac版HSP言語リファレンスには、そういう関数がなかった・・・
もしかしてバイナリ形式を使っているのは、そこがネックだったからですか？>>◆EFBt/pII5Yさん
ご自分のペースでゆっくり作って下さい。
>>331（304さん）
そう言っていただけて恐縮です。では早速、私ならこうする！ を（笑）。
階層をまたぐ階段・ワープはそれほど難しいものではなかったりするかも。
マップデータの「余っている部分」を使うと新定義書式を追加せずとも、書式解釈の拡張でできます。もはや荒技ですが。
余っている部分が0でなくてもいい、というのが条件で、あらかじめ階段マスの「物件価格」に当たる部分に新たな移動先のx座標、
「所属エリア」に当たる部分に移動先のy座標を書くのがポイント。
移動中に到達先のマスの種類をチェックし（銀行かどうかをチェックするのと同じようなもの）、
到達先が階段ならそのマスの「物件価格・所属エリア」を読む。
読んだ値を新たな到達先のx・y座標として流用し、そちらに移動させる。
階段は店ではないので、物件価格・所属エリアは本来は必要のないデータのはずですが、必要のない事を逆用して別用途で使ってしまおう、と。
ワープマスは、歩いている最中→止まった後になるだけで同じ処理。
>>335
分かった！ 私がコンバーターも一緒に作ればいいんだ（笑）！
元々作成の途中経過をセーブ・ロードする機能はつけるつもりでしたし。
書式はひとまず最初に上げていただいたmapdata.txtに準じます。
あとはアプリからバイナリ出力とテキスト読み込み機能の部分を分離したものを別公開すればいいだけ。
もっとも、テキストを読み込むとゲームが自動起動する機能をつけるとなると、◆EFBt/pII5Yさんにお願いするしかなくなるのですが。
・・・HSP言語のテキストファイルを扱う能力って、どんなものなのだろう。
こういうデータを読み込む場合、「カンマ区切りの文の中から、何単語目を取り出す」ような命令がないと辛いですが、
少なくともMac版HSP言語リファレンスには、そういう関数がなかった・・・
もしかしてバイナリ形式を使っているのは、そこがネックだったからですか？>>◆EFBt/pII5Yさん
とりあえず、ファイル形式のレスだけでも。
マップデータはすべて配列で読み出してるため、プログラム側の処理は1行で済むのです。
しかし、テキストだと非常に面倒になってしまいます。（簡単な方法もあるのかも知れませんが）
そういった理由で今の形式になってます。
マップデータはすべて配列で読み出してるため、プログラム側の処理は1行で済むのです。
しかし、テキストだと非常に面倒になってしまいます。（簡単な方法もあるのかも知れませんが）
そういった理由で今の形式になってます。
338名前は開発中のものです。
2005/08/09(火) 07:47:55ID:zNyLIjHl339名前は開発中のものです。
2005/08/09(火) 10:42:08ID:dDR8LOXt340304
2005/08/10(水) 02:28:26ID:UqlRroAW >>339
うんうん、コードの違いもなければ変換の
必要もないし、そのままの形で読み込める
バイナリはいいよな。アプリ側からすれば
便利なことこの上ない。アップロードする
際に設定を間違えなければファイルが壊れる
こともないし、圧縮して配布すればこんな
心配も不要だ。もちろんバイナリで配布が
不可能なんてことはない。
だが、バイナリはそのままでは編集しにくい。
この場合、既存もしくは新規のマップを作成
するためのエディタだが、もし作ったマップで
アプリを実行した時に座標か店舗情報の設定に
ミスが見つかった場合を考えてくれ。
バイナリ形式のファイルなら普通、エディタを
起動、編集・保存して再度アプリを実行する。
これは通常のバイナリエディタでも可能だが、
恐らく専用のエディタが必要な人がほとんど
だろう。だが、テキスト形式で保存していた
場合はどうだろう。ミスの見つかった座標や
数値を任意のエディタで簡単に編集でき、
『メモ帳などで直接書き込んでいく』場合に
該当すると思うんだ。
これはテキストである利点と言えないか？
うんうん、コードの違いもなければ変換の
必要もないし、そのままの形で読み込める
バイナリはいいよな。アプリ側からすれば
便利なことこの上ない。アップロードする
際に設定を間違えなければファイルが壊れる
こともないし、圧縮して配布すればこんな
心配も不要だ。もちろんバイナリで配布が
不可能なんてことはない。
だが、バイナリはそのままでは編集しにくい。
この場合、既存もしくは新規のマップを作成
するためのエディタだが、もし作ったマップで
アプリを実行した時に座標か店舗情報の設定に
ミスが見つかった場合を考えてくれ。
バイナリ形式のファイルなら普通、エディタを
起動、編集・保存して再度アプリを実行する。
これは通常のバイナリエディタでも可能だが、
恐らく専用のエディタが必要な人がほとんど
だろう。だが、テキスト形式で保存していた
場合はどうだろう。ミスの見つかった座標や
数値を任意のエディタで簡単に編集でき、
『メモ帳などで直接書き込んでいく』場合に
該当すると思うんだ。
これはテキストである利点と言えないか？
341名前は開発中のものです。
2005/08/10(水) 06:29:41ID:LUs1Xdsa342初診さ
2005/08/10(水) 09:05:25ID:oJJHu6md 3D化を激しく希望!!!!
今のﾓﾅｰは正直ｷﾓｲよ。
今のﾓﾅｰは正直ｷﾓｲよ。
343名前は開発中のものです。
2005/08/10(水) 11:26:56ID:eXMsZiz2 これってどうやって開始するの？
通信ができませんって出るよ
通信ができませんって出るよ
344名前は開発中のものです。
2005/08/10(水) 13:36:01ID:4kje4v2F345名前は開発中のものです。
2005/08/10(水) 20:28:56ID:HgKPR21/ 交差転用データを作ったらいいかも
0なら普通の道1なら交差点という風に
で交差点のマスにとまったら交差転用移動方向データを読み出す
データを二重にしなきゃいけなくなるが・・・
0なら普通の道1なら交差点という風に
で交差点のマスにとまったら交差転用移動方向データを読み出す
データを二重にしなきゃいけなくなるが・・・
346名前は開発中のものです。
2005/08/10(水) 20:31:07ID:HgKPR21/ test鯖立てます
明日くらいまで
203.110.96.205
明日くらいまで
203.110.96.205
347名前は開発中のものです。
2005/08/10(水) 20:34:37ID:uu2Z9uI5 >>346
2と4どっち起動すればいいの？
2と4どっち起動すればいいの？
348名前は開発中のものです。
2005/08/10(水) 20:36:49ID:uu2Z9uI5349名前は開発中のものです。
2005/08/10(水) 20:38:11ID:HgKPR21/ portって何番ですか？
350名前は開発中のものです。
2005/08/10(水) 20:39:00ID:HgKPR21/ 4です
351名前は開発中のものです。
2005/08/10(水) 20:55:36ID:L7OnKy8q >>349
30009っぽい
30009っぽい
352名前は開発中のものです。
2005/08/10(水) 21:12:51ID:eXMsZiz2 ロビー入れたけど人いねえ
353名前は開発中のものです。
2005/08/10(水) 21:40:34ID:pTcIHPmE >>346に入れない。
354名前は開発中のものです。
2005/08/10(水) 23:06:07ID:6E0YEoG8 ひといない
355300
2005/08/13(土) 00:56:58ID:zULkqbBR 336で書いた「テキストマップデータ→バイナリへのコンバーター」が少し出来上がったので、とりあえず公開してみます。
http://tsukac.hp.infoseek.co.jp/sankou.html
の構造を少し変えて、ここに掲載しました。
バイナリマップの方は、「実験マップ」を解凍してできたmap2.bin（名前が「map」である必要があったら直して下さい）を、
現状の「datフォルダ内のmap」に差し換えると、レイクマウンテンっぽいマップが出来上がるはずです。
アプリの方はまだWin機でテストができていない為、非公式公開とさせていただきます。
どんな障害が起きるか分かりませんが（レジストリなどはいじらないはずなので、致命的な障害は起きないと思います）、
それでも使ってみたい、人柱になってやるぜ（笑）！ という方は「マップコンバーター」からどうぞ（332KByte）。
http://tsukac.hp.infoseek.co.jp/sankou.html
の構造を少し変えて、ここに掲載しました。
バイナリマップの方は、「実験マップ」を解凍してできたmap2.bin（名前が「map」である必要があったら直して下さい）を、
現状の「datフォルダ内のmap」に差し換えると、レイクマウンテンっぽいマップが出来上がるはずです。
アプリの方はまだWin機でテストができていない為、非公式公開とさせていただきます。
どんな障害が起きるか分かりませんが（レジストリなどはいじらないはずなので、致命的な障害は起きないと思います）、
それでも使ってみたい、人柱になってやるぜ（笑）！ という方は「マップコンバーター」からどうぞ（332KByte）。
356304
2005/08/13(土) 03:18:44ID:obyz3S/m >>344
>>259 の配布サイトを見て登録が必要なのかと
思ってスルーしてたが、>>344 を見て誤解だと
気づいた。ありがとう。もし同じ勘違いをして
いる人間が居たら、安心して遊んでほしい。
必要なファイルをそろえたら、あとはオフライン
でも大丈夫だった。
>>◆EFBt/pII5Y
システム自体は古い作品をベースにしても問題
ないと思うが、メニューの階層や選択方式は
いたストSP準拠にできないものだろうか。
「はい／いいえ」が多すぎると感じた。あと、
周回の単位が「周」ではなく「週」になって
いるのが気になった。
>>355
人柱の結果をアップした。これは想定の範囲内？
ttp://gamdev.org/up/img/3028.zip
それと、70文字くらいで改行入れてもらえると
テキストが見やすくなっていいと思う。
>>259 の配布サイトを見て登録が必要なのかと
思ってスルーしてたが、>>344 を見て誤解だと
気づいた。ありがとう。もし同じ勘違いをして
いる人間が居たら、安心して遊んでほしい。
必要なファイルをそろえたら、あとはオフライン
でも大丈夫だった。
>>◆EFBt/pII5Y
システム自体は古い作品をベースにしても問題
ないと思うが、メニューの階層や選択方式は
いたストSP準拠にできないものだろうか。
「はい／いいえ」が多すぎると感じた。あと、
周回の単位が「周」ではなく「週」になって
いるのが気になった。
>>355
人柱の結果をアップした。これは想定の範囲内？
ttp://gamdev.org/up/img/3028.zip
それと、70文字くらいで改行入れてもらえると
テキストが見やすくなっていいと思う。
357名前は開発中のものです。
2005/08/13(土) 22:20:59ID:7S4YG4xR ポートあけて鯖立ててみました
203.110.100.80
is_4
起動時間はパソコンが止まるまで
203.110.100.80
is_4
起動時間はパソコンが止まるまで
358300
2005/08/13(土) 22:31:10ID:zULkqbBR ところで◆EFBt/pII5Yさん。
ゲームアプリ内で、実際に扱える縦横幅・エリア数の領域はどれくらいでしょうか？
一応こちらのエディタでは縦横３０マス、１８エリアという、既存マップの最大値より少し大きいくらいに設定するつもりです。
これ以上いける、あるいはこれ以下しかできない、などありますか？
>>356
人柱ありがとうございます。SS見ました。大体想定の範囲内です。
ひとまずはWin機で正しく動く事と、ゲームで読み込めるデータを一応作れる事が分かればいいレベルでしたので。
これでマップエディタ本編制作の足掛かりになります。
改行を入れるべきなのは、ドキュメント群の事でしょうかね。
次のVer.の時にHTMLで作るか（書式の解説が少ししやすくなるので）、素直に改行を加えるか、どちらか対応します。
>>341
エディタ作者側から遅レス。
ファイルの状態になっている「プレイ前の」マップデータをバイナリエディタなどでいじられるのは、
作者側からしたら防ぎようがないので軽視していい問題のような。
バイナリの方がいじられる確率が下がるのは確かですが。
むしろ「通信相手のプレイヤー全員が同じマップデータでスタートするシステム」を用意するのが重要。
メモリでアクティブに動いている「プレイ中の」データがいじられては問題ですが、
それこそ専門のアプリが必要でしょうし、そこまでの手間をかける人がどれだけいるか。
私としては、マップデータはテキストの方がいいですね。
テキストだと手直しも簡単ですし、書式を覚えているとマップエディタを使うより素早く作れる場合もあります。
既存のマップデータを敢えていじってサラリー・店舗価格などが全部１０倍のバブリーないたストや、
逆に全部２分の１のデフレいたストが比較的簡単に作れて面白かったりするかなぁ、と（笑）。
ゲームアプリ内で、実際に扱える縦横幅・エリア数の領域はどれくらいでしょうか？
一応こちらのエディタでは縦横３０マス、１８エリアという、既存マップの最大値より少し大きいくらいに設定するつもりです。
これ以上いける、あるいはこれ以下しかできない、などありますか？
>>356
人柱ありがとうございます。SS見ました。大体想定の範囲内です。
ひとまずはWin機で正しく動く事と、ゲームで読み込めるデータを一応作れる事が分かればいいレベルでしたので。
これでマップエディタ本編制作の足掛かりになります。
改行を入れるべきなのは、ドキュメント群の事でしょうかね。
次のVer.の時にHTMLで作るか（書式の解説が少ししやすくなるので）、素直に改行を加えるか、どちらか対応します。
>>341
エディタ作者側から遅レス。
ファイルの状態になっている「プレイ前の」マップデータをバイナリエディタなどでいじられるのは、
作者側からしたら防ぎようがないので軽視していい問題のような。
バイナリの方がいじられる確率が下がるのは確かですが。
むしろ「通信相手のプレイヤー全員が同じマップデータでスタートするシステム」を用意するのが重要。
メモリでアクティブに動いている「プレイ中の」データがいじられては問題ですが、
それこそ専門のアプリが必要でしょうし、そこまでの手間をかける人がどれだけいるか。
私としては、マップデータはテキストの方がいいですね。
テキストだと手直しも簡単ですし、書式を覚えているとマップエディタを使うより素早く作れる場合もあります。
既存のマップデータを敢えていじってサラリー・店舗価格などが全部１０倍のバブリーないたストや、
逆に全部２分の１のデフレいたストが比較的簡単に作れて面白かったりするかなぁ、と（笑）。
359名前は開発中のものです。
2005/08/13(土) 22:41:10ID:6UYOshNh360名前は開発中のものです。
2005/08/13(土) 23:46:35ID:oo1RarPk 繋いでチャットしたりするのは問題なし。
roomに入れなかったりするがこれは2と4の違いの問題？
roomに入れなかったりするがこれは2と4の違いの問題？
361名前は開発中のものです。
2005/08/14(日) 22:42:02ID:nLfd1VHU カタンのような生産性があるゲームがいいな
362名前は開発中のものです。
2005/08/15(月) 11:45:39ID:tjOHAo4+ >>1は逃げたのか？
363名前は開発中のものです。
2005/08/16(火) 01:09:14ID:58vhbWrL まとめサイト
まだ〜
まだ〜
ttp://zxzxzxzxzx.hp.infoseek.co.jp/board/is.zip
移動方法変更
特定の相手へのチャットを
/名前文字列（スペースがいらない）
に変更
増資限度額
店舗数により買い物料変動（エフェクトなし）
>>355のレイクマウンテンもきちんと表示されるはずです。
ただし、移動方法が変更されてるのでサイコロ振るとエラーになります。
移動のテストをするので、人が居そうなときに鯖立てます。
マップサイズは縦横50、エリア20あれば十分だと考えてます。
現在はサイズ上限なし、エリア8です。
あとマップサイズ*80を超える表示は出来ません。
左端のマスを左にずらすなど。
マップファイルは配布された状態から弄らないものと考えてますので、
弄ったら故意とみなし、対策などはしない予定です。
テキスト、バイナリの件ですが今の所変更する予定はありません。
上に書いたように、ファイルそのものを弄ることは禁止にするつもりですし、
それよりも優先的に手を付けるべき箇所があるので。
移動方法変更
特定の相手へのチャットを
/名前文字列（スペースがいらない）
に変更
増資限度額
店舗数により買い物料変動（エフェクトなし）
>>355のレイクマウンテンもきちんと表示されるはずです。
ただし、移動方法が変更されてるのでサイコロ振るとエラーになります。
移動のテストをするので、人が居そうなときに鯖立てます。
マップサイズは縦横50、エリア20あれば十分だと考えてます。
現在はサイズ上限なし、エリア8です。
あとマップサイズ*80を超える表示は出来ません。
左端のマスを左にずらすなど。
マップファイルは配布された状態から弄らないものと考えてますので、
弄ったら故意とみなし、対策などはしない予定です。
テキスト、バイナリの件ですが今の所変更する予定はありません。
上に書いたように、ファイルそのものを弄ることは禁止にするつもりですし、
それよりも優先的に手を付けるべき箇所があるので。
移動方法の変更点
1〜9の他にA〜Iを使用
Aなら1には進めない
Bなら2には進めない
Hなら8には進めない
Iなら9には進めない
5番目の値は停止後、移動するときのみ使用
0は分岐なし
1なら来た方向を含むすべての方向に進める
2なら来た方向を除くすべての方向に進める
3なら直前の移動方向に従う
この方法では5という値は使用しません。
例えば、貝がら島の銀行は"103010709"となり、
"C0I030A0G"とすると常にL字型の分岐になります。
1〜9の他にA〜Iを使用
Aなら1には進めない
Bなら2には進めない
Hなら8には進めない
Iなら9には進めない
5番目の値は停止後、移動するときのみ使用
0は分岐なし
1なら来た方向を含むすべての方向に進める
2なら来た方向を除くすべての方向に進める
3なら直前の移動方向に従う
この方法では5という値は使用しません。
例えば、貝がら島の銀行は"103010709"となり、
"C0I030A0G"とすると常にL字型の分岐になります。
367名前は開発中のものです。
2005/08/16(火) 19:04:43ID:UfQU3qDH 特定の相手へのチャットってのが意味不明。送っても自分に帰って来る。
368名前は開発中のものです。
2005/08/16(火) 21:38:06ID:O+nBsptD >>355の結果
ttp://gamdev.org/up/img/3032.jpg
ttp://gamdev.org/up/img/3032.jpg
369300
2005/08/16(火) 22:55:45ID:HIG/RJGw >>366
バージョンアップお疲れです。
次回のコンバーターのバージョンアップ時に
・移動データに使用できる文字の範囲の調整
・マップ縦横幅とエリア数の上限設定
・表示可能幅超過時の警告
の対応をします。
が、５０マスは作成アプリの画面領域が厳しい＆色の数も厳しいので、ひとまずは３０マス＆１８エリアで作ります。
それ以上欲しければ自分でテキストデータを書いて変換してくれ、と逃げる(^^;
移動方法については、こちらは決定に対応するのみなのですが、微妙にイメージしにくいなぁ・・・
一部例を挙げるので回答をお願いします。これが分からないとマップ作成アプリが作れないので。
・「停止後＝方向転換可能状態になった次のターン１歩目」という解釈ですか？ それとも違う状態ですか？
・フリーウェイの銀行右側のマークマス（真っ直ぐのみの完全一通、方向転換可能時のみ選択可能）は
020416080
ですか？
・日本列島の銀行（下・左←→上・右、方向転換可能時は全て選択可能）は
0F0H1B0D0
ですか？
・日本列島の北陸すぐ左のチャンスマス（右斜め方向←→左斜め方向、方向転換可能時は全て選択可能）は
C0A010I0G
ですか？
・ハワイのチャンスマス（離れ小島仕様、転換可能時も左しか進めない）はどのように書きますか？
バージョンアップお疲れです。
次回のコンバーターのバージョンアップ時に
・移動データに使用できる文字の範囲の調整
・マップ縦横幅とエリア数の上限設定
・表示可能幅超過時の警告
の対応をします。
が、５０マスは作成アプリの画面領域が厳しい＆色の数も厳しいので、ひとまずは３０マス＆１８エリアで作ります。
それ以上欲しければ自分でテキストデータを書いて変換してくれ、と逃げる(^^;
移動方法については、こちらは決定に対応するのみなのですが、微妙にイメージしにくいなぁ・・・
一部例を挙げるので回答をお願いします。これが分からないとマップ作成アプリが作れないので。
・「停止後＝方向転換可能状態になった次のターン１歩目」という解釈ですか？ それとも違う状態ですか？
・フリーウェイの銀行右側のマークマス（真っ直ぐのみの完全一通、方向転換可能時のみ選択可能）は
020416080
ですか？
・日本列島の銀行（下・左←→上・右、方向転換可能時は全て選択可能）は
0F0H1B0D0
ですか？
・日本列島の北陸すぐ左のチャンスマス（右斜め方向←→左斜め方向、方向転換可能時は全て選択可能）は
C0A010I0G
ですか？
・ハワイのチャンスマス（離れ小島仕様、転換可能時も左しか進めない）はどのように書きますか？
370300
2005/08/16(火) 23:07:42ID:HIG/RJGw ＞・「停止後＝方向転換可能状態になった次のターン１歩目」という解釈ですか？ それとも違う状態ですか？
状態に関係なくサイコロを振って一歩目ということです。
＞・ハワイのチャンスマス（離れ小島仕様、転換可能時も左しか進めない）はどのように書きますか？
040000000
その他の質問はその通りです。
移動の制限を書いておくと
分岐は4つまで
移動できる方向は
通過時
一方通行
来た方向を除いた全方向
来た方向と一方を除いた二方向（4分岐時）
停止後（サイコロ振って一歩目）
全方向
来た方向を除いた全方向
直前の移動方向に従う
これ以外はできません。
つまり
■□■
□□□
■□■
この場合、通過時は「一方通行」で停止後は「来た方向と一方を除いた二方向」という分岐はできません。
この移動方法に問題があったらご指摘お願いします。
状態に関係なくサイコロを振って一歩目ということです。
＞・ハワイのチャンスマス（離れ小島仕様、転換可能時も左しか進めない）はどのように書きますか？
040000000
その他の質問はその通りです。
移動の制限を書いておくと
分岐は4つまで
移動できる方向は
通過時
一方通行
来た方向を除いた全方向
来た方向と一方を除いた二方向（4分岐時）
停止後（サイコロ振って一歩目）
全方向
来た方向を除いた全方向
直前の移動方向に従う
これ以外はできません。
つまり
■□■
□□□
■□■
この場合、通過時は「一方通行」で停止後は「来た方向と一方を除いた二方向」という分岐はできません。
この移動方法に問題があったらご指摘お願いします。
＞特定の相手へのチャット
オンラインゲームによくある密談というやつです。
>>370の通りですが、2人だと普通のチャットと変わらないのでわからないと思います。
見た目の判断としては文字列が()で括ってあります。あとロビーでは使えません。
名前の重複問題もあるので、色指定か、番号指定にするかもしれません。
そもそも小規模ゲームでこの機能に意味があるのかわかりませんが、自己満足というやつです。
マップサイズは３０マス＆１８エリアで構いません。
今はワープを一切考えずに作ってます。
もちろん複数階層のマップなども。
オンラインゲームによくある密談というやつです。
>>370の通りですが、2人だと普通のチャットと変わらないのでわからないと思います。
見た目の判断としては文字列が()で括ってあります。あとロビーでは使えません。
名前の重複問題もあるので、色指定か、番号指定にするかもしれません。
そもそも小規模ゲームでこの機能に意味があるのかわかりませんが、自己満足というやつです。
マップサイズは３０マス＆１８エリアで構いません。
今はワープを一切考えずに作ってます。
もちろん複数階層のマップなども。
373名前は開発中のものです。
2005/08/17(水) 00:39:38ID:2uIcbpmd >>1には２chキャラとあるが、それに拘らず萌えキャラも欲しい
ぶっちゃけ２人集まるのすらきついほど過疎ってるのが現状だ
だが萌えキャラ出せばそれだけで興味を持つ人も出るはず
それと進行役はあやかで頼む
ぶっちゃけ２人集まるのすらきついほど過疎ってるのが現状だ
だが萌えキャラ出せばそれだけで興味を持つ人も出るはず
それと進行役はあやかで頼む
374名前は開発中のものです。
2005/08/17(水) 12:43:47ID:LSGhwXXp 移動中にズレがあるね。
ラグって言うのかな？
ラグって言うのかな？
375名前は開発中のものです。
2005/08/17(水) 13:23:02ID:XdgHYVGL 足りない分をCPUで補うとかできないの？
376名前は開発中のものです。
2005/08/17(水) 14:44:48ID:em0Ua/rd スレタイに惹かれてやってきたけど
完成してんの？これ
完成してんの？これ
377名前は開発中のものです。
2005/08/17(水) 15:17:14ID:IovTFdan378300
2005/08/17(水) 18:54:43ID:ULyEWc+1 >>371
うーん、問題・・・
移動可能方向がイメージしにくいのが最大の問題と言えなくもない(^^;;
・・・すいません。回答をいただいて何なのですが、ハワイのチャンスマスのデータが何故「040000000」になるのかが未だに理解できていません(^^;;;
確かに歩きの場合は上からしか来れませんが、そもそもこのマスにはワープしないと来れません。
ワープ後＝停止状態からなので、ここで移動方向の指定がないと、どの方向に移動できるのか分からないと思うのですが・・・
実際のゲームでは、止まった時と通過する時とで移動可能な方向が違うマスは、
止まると方向転換可能になる銀行マスを除くと「宇宙星雲の四隅以外の端マス」だけです。
実際に自作マップを作るにしても、そんなトリッキーな移動方向を作りたがる方って、それほどいないのでは？
そんなマスの為だけにわざわざ停止後の移動設定をするのもどうかという気がしますねぇ・・・
そこで！ １つこんなものを作って来ました。
いわゆる「304方式」（勝手に名付けて申し訳ないですが）の処理を実際にHSPで書くとこうなる、という具体例です。
304さんの意図する処理法は、大体こんなものかと思うのですが。
（処理解説）http://tsukac.hp.infoseek.co.jp/sankou5.html
（ソース）http://tsukac.hp.infoseek.co.jp/sankou5-2.html
ざっと言語リファレンスを調べただけでソースを書いてしまったので、
一部文法ミスがあるかもですが、参考にしてみてくだされ。
うーん、問題・・・
移動可能方向がイメージしにくいのが最大の問題と言えなくもない(^^;;
・・・すいません。回答をいただいて何なのですが、ハワイのチャンスマスのデータが何故「040000000」になるのかが未だに理解できていません(^^;;;
確かに歩きの場合は上からしか来れませんが、そもそもこのマスにはワープしないと来れません。
ワープ後＝停止状態からなので、ここで移動方向の指定がないと、どの方向に移動できるのか分からないと思うのですが・・・
実際のゲームでは、止まった時と通過する時とで移動可能な方向が違うマスは、
止まると方向転換可能になる銀行マスを除くと「宇宙星雲の四隅以外の端マス」だけです。
実際に自作マップを作るにしても、そんなトリッキーな移動方向を作りたがる方って、それほどいないのでは？
そんなマスの為だけにわざわざ停止後の移動設定をするのもどうかという気がしますねぇ・・・
そこで！ １つこんなものを作って来ました。
いわゆる「304方式」（勝手に名付けて申し訳ないですが）の処理を実際にHSPで書くとこうなる、という具体例です。
304さんの意図する処理法は、大体こんなものかと思うのですが。
（処理解説）http://tsukac.hp.infoseek.co.jp/sankou5.html
（ソース）http://tsukac.hp.infoseek.co.jp/sankou5-2.html
ざっと言語リファレンスを調べただけでソースを書いてしまったので、
一部文法ミスがあるかもですが、参考にしてみてくだされ。
379名前は開発中のものです。
2005/08/17(水) 20:05:50ID:PeY/R6SN テストできないみたいなので書いておくけど移動は分岐以外はすべて自動移動。
>>今進んだ道をキャンセルして１歩戻る
これは実装済み。
>>今進んだ道をキャンセルして１歩戻る
これは実装済み。
>>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にも書きましたが、現在はワープなどは考えてないので、実際どうなるのかは
その時にならないとわかりませんが。
簡単な説明とSSがあるだけですが、一応まとめと考えてます。
SSは随時更新する予定です。
>>373
俺は>>1じゃないのですが、おそらく2chキャラというのはAIの意味でしょう。
COM戦はないのでAIは作りませんが、キャラ（個性）は在ってもいいかなと思います。
2ch版とありますが、特に2chに拘るつもりはありません。
絵に関しては、描けないのでどうにもなりませんが、最悪は自分で描こうかと思ってます。
>>374
遅延対策としてターン中のプレイヤーには0.2〜0.5秒のウェイトをかけています。
この辺の調整が必要なので、テストをする予定です。
>>375
上のような理由で無理です。
>>376-377
完成度は自分でもまだ不明。
2人はローカル用と考えてます。
1台で3つも4つも起動できる環境はそうそうないと思うので。
>>378
停止状態＝方向転換可ですよね？
まあ、ハワイの場合は時計周りのようですが。
その辺は内部で処理しているので、問題ないです。
>>372にも書きましたが、現在はワープなどは考えてないので、実際どうなるのかは
その時にならないとわかりませんが。
381名前は開発中のものです。
2005/08/17(水) 22:10:44ID:2rkLRWRi ん？テストってどうやんの？
382名前は開発中のものです。
2005/08/18(木) 00:39:09ID:wZLkrjly ttp://f7.aaa.livedoor.jp/~nekoko/imgboardphp/src/1069858089722.gif
この素材とかどうよ？2chだし規格も同じっぽい。
この素材とかどうよ？2chだし規格も同じっぽい。
383名前は開発中のものです。
2005/08/18(木) 15:22:19ID:Cpwgii/H 10株売り出来るのは嫌だな。
何かしら別の条件を考えるべき。
何かしら別の条件を考えるべき。
385名前は開発中のものです。
2005/08/18(木) 22:27:24ID:+3Q0ljv1 やりこみゃわかるが、10株売り無いとゲームがものすごく単調化するぞ。
基本的にいたストルールを採用するべきかと。
嫌いだったら開始時にそのテーブルで禁止してほしいな。
基本的にいたストルールを採用するべきかと。
嫌いだったら開始時にそのテーブルで禁止してほしいな。
386名前は開発中のものです。
2005/08/18(木) 22:32:25ID:T3tjhoCw ttp://zxzxzxzxzx.hp.infoseek.co.jp/board/is3.zip
これです
これです
テスト協力どうもありがとうございました！
データの送受信に関しては問題なしでしたね。
2回連続でバグ発生は大変申し訳ないです。
次回うｐまでに原因を突き止め直しておきます。
データの送受信に関しては問題なしでしたね。
2回連続でバグ発生は大変申し訳ないです。
次回うｐまでに原因を突き止め直しておきます。
390300
2005/08/18(木) 23:51:40ID:k4F+NpDz >>384（◆EFBt/pII5Yさん）
ふむ・・・ 完全一通は、歩いた時に必要な部分だけ書いて、あとは「0」で埋めておけばいい・・・ のかな。
ただ、「ワープして来た、などで方向転換可能になった状態からの歩き方を定義する方法」は早いうちから決めておいた方がいいですよ？
これを考慮に入れないと、絶対に困る事になります。
例えば、今の方法だといたスト３・ホラーハウスの一部のマスの進み方に対応できなかったりするかもしれない訳で・・・
http://homepage1.nifty.com/tsukac/itast/kouryaku/street3a06.html
参照。白抜きマーク（変わるマークマス）は分岐３点ですが、このマスでチャンス１番を引いて転換可能になっても左下には移動不可です。
このマスのデータはどう書きます？
>>386
マークが５つ必要なマップというのもどうなんでしょう・・・
ただ、マークを３つ以下しか採用しないマップというのは、逆に「あり」なのかも。
もちろんサラリー額を低くするのが前提ですが。
>>355のテストデータは、単純に私が書式を間違えたままアップしてしまったものです(^^;
本当は銀行の２つ下の四角マークは、ただのカードマスにしたかったんですが、間違えた(^^;
>>383 >>384（◆EFBt/pII5Yさん）
１０株売りは、プレイヤーが唯一、自発的かつ確実に相手の資産を落とす事ができる手段です。
これを完全になくしてしまうと、それこそ運だけゲーになりかねないです。
また、サイコロ前の株売りをできなくする事も、自発株売りと強制株売りで株価の下がり方を変えるのも、問題が多数。
そこで、単純な解決策っぽいものを１つ。
「株売買時の株価変動幅も定義できるようにする」。
マップデータの基本データ部を拡張し、株売買時の株価上下幅をマップデータ内で定義できるようにするもの。実装は簡単なはず。
上昇８％、下降６％にするだけでも大分違うと思います。
・・・本当は、目標金額や破産人数とかこの辺りの数値なんかは、ロビーでゲーム開始前に設定を変えられるとベストなんですがね・・・
ふむ・・・ 完全一通は、歩いた時に必要な部分だけ書いて、あとは「0」で埋めておけばいい・・・ のかな。
ただ、「ワープして来た、などで方向転換可能になった状態からの歩き方を定義する方法」は早いうちから決めておいた方がいいですよ？
これを考慮に入れないと、絶対に困る事になります。
例えば、今の方法だといたスト３・ホラーハウスの一部のマスの進み方に対応できなかったりするかもしれない訳で・・・
http://homepage1.nifty.com/tsukac/itast/kouryaku/street3a06.html
参照。白抜きマーク（変わるマークマス）は分岐３点ですが、このマスでチャンス１番を引いて転換可能になっても左下には移動不可です。
このマスのデータはどう書きます？
>>386
マークが５つ必要なマップというのもどうなんでしょう・・・
ただ、マークを３つ以下しか採用しないマップというのは、逆に「あり」なのかも。
もちろんサラリー額を低くするのが前提ですが。
>>355のテストデータは、単純に私が書式を間違えたままアップしてしまったものです(^^;
本当は銀行の２つ下の四角マークは、ただのカードマスにしたかったんですが、間違えた(^^;
>>383 >>384（◆EFBt/pII5Yさん）
１０株売りは、プレイヤーが唯一、自発的かつ確実に相手の資産を落とす事ができる手段です。
これを完全になくしてしまうと、それこそ運だけゲーになりかねないです。
また、サイコロ前の株売りをできなくする事も、自発株売りと強制株売りで株価の下がり方を変えるのも、問題が多数。
そこで、単純な解決策っぽいものを１つ。
「株売買時の株価変動幅も定義できるようにする」。
マップデータの基本データ部を拡張し、株売買時の株価上下幅をマップデータ内で定義できるようにするもの。実装は簡単なはず。
上昇８％、下降６％にするだけでも大分違うと思います。
・・・本当は、目標金額や破産人数とかこの辺りの数値なんかは、ロビーでゲーム開始前に設定を変えられるとベストなんですがね・・・
3921234
2005/08/18(木) 23:54:21ID:+3Q0ljv1 先ほどはどうも。
スーファミ版2を知ってから十年以上、ネット対戦できるなんて感慨深い感じでした。
300さんのページなんか印刷して暗記するくらい読んでましたよ。
すごろくとしての移動部分はかなりいい具合でした。
まあ、プログラムのほうはさっぱりなんで人柱くらいしかできませんが。
◆EFBt/pII5Yさん、そしてサポートの300さん応援してますよー。
スーファミ版2を知ってから十年以上、ネット対戦できるなんて感慨深い感じでした。
300さんのページなんか印刷して暗記するくらい読んでましたよ。
すごろくとしての移動部分はかなりいい具合でした。
まあ、プログラムのほうはさっぱりなんで人柱くらいしかできませんが。
◆EFBt/pII5Yさん、そしてサポートの300さん応援してますよー。
>>390
そのマスから、来ることが出来ないマスであれば、
たとえ方向転換可能であっても内部で進めないように処理してあります。
パッと見ただけなので、じっくり見てみて無理っぽかったら考えます。
ワープに関しては、今試してる所ですが、かなり難しそうです。
＞マークが５つ必要なマップというのもどうなんでしょう・・・
トランプ+★のことだと思ったのですが、そんなのなかったでしたっけ？
10株売りとかその辺はじっくり考えて決めます。
サイトに書いたように、すべての仕様をパクるのはやばそうなので
ルール設定を細かくして、基本は完全なオリジナルにする予定です。
そういった訳で、いたストそのままというわけにはいかないと思います。
ロビーで部屋を作るとき、こういうルールでやりますよって設定できればよいのですが、
o2の仕様ではできないため、定員が揃ってから決めるという形になるかと。
>>392
どうもありがとうございました。
お時間が合えば、またよろしくお願いします。
そのマスから、来ることが出来ないマスであれば、
たとえ方向転換可能であっても内部で進めないように処理してあります。
パッと見ただけなので、じっくり見てみて無理っぽかったら考えます。
ワープに関しては、今試してる所ですが、かなり難しそうです。
＞マークが５つ必要なマップというのもどうなんでしょう・・・
トランプ+★のことだと思ったのですが、そんなのなかったでしたっけ？
10株売りとかその辺はじっくり考えて決めます。
サイトに書いたように、すべての仕様をパクるのはやばそうなので
ルール設定を細かくして、基本は完全なオリジナルにする予定です。
そういった訳で、いたストそのままというわけにはいかないと思います。
ロビーで部屋を作るとき、こういうルールでやりますよって設定できればよいのですが、
o2の仕様ではできないため、定員が揃ってから決めるという形になるかと。
>>392
どうもありがとうございました。
お時間が合えば、またよろしくお願いします。
394名前は開発中のものです。
2005/08/19(金) 01:16:10ID:P9PicSe8 ttp://game10.2ch.net/test/read.cgi/netgame/1103952787/
ここで宣伝しておきました。
ここで宣伝しておきました。
395名前は開発中のものです。
2005/08/19(金) 12:38:34ID:V60Ji4oU FFDQいたストだと分かれ道の方向転換が自由にできるよね？
あれはハメが回避しやすくて戦略的だと思ったんだが、
オプションでこのへんもいじれるとうれしい。
あれはハメが回避しやすくて戦略的だと思ったんだが、
オプションでこのへんもいじれるとうれしい。
396名前は開発中のものです。
2005/08/19(金) 16:44:14ID:Ml5l66+X398386
2005/08/19(金) 21:25:28ID:rhN4On78399名前は開発中のものです。
2005/08/20(土) 09:07:47ID:6nT5M+96400名前は開発中のものです。
2005/08/20(土) 21:13:29ID:uDoxOwBO 192.168.0.1
24時くらいまで起動してます
24時くらいまで起動してます
401304
2005/08/20(土) 21:42:28ID:kzNeTZxb >>400
テストを手伝ってくれようとする意気込みは
買うけど、残念ながらそのIPアドレスでは
他人は参加できない。詳しく言うとそれは
「プライベートIPアドレス」という名前で、
これらは外部から参照できないんだ。
10.xx.xx.xx
172.16.xx.xx〜172.31.xx.xx
192.168.xx.xx
ブロードバンドルーターなどを使わず、
インターネットに直接つながっているパソ
コンなら、コマンドプロンプトなどから
ipconfig （Windows2000/XP）
winipcfg （Windows95/98/Me）
と入力すると、他人からも接続できる
「グローバルIPアドレス」がわかる。
直接つながってない場合は、proxy
サーバーから情報を調べるWebサイトや
IPアドレスを表示するCGIのサンプル
ページなどへアクセスすればいい。
ただし、IPアドレスがわかっても恐らく
他人と通信するためにポートを開くという
特別な作業が必要だろうから、気軽に
テストすることはできないと思う。
テストを手伝ってくれようとする意気込みは
買うけど、残念ながらそのIPアドレスでは
他人は参加できない。詳しく言うとそれは
「プライベートIPアドレス」という名前で、
これらは外部から参照できないんだ。
10.xx.xx.xx
172.16.xx.xx〜172.31.xx.xx
192.168.xx.xx
ブロードバンドルーターなどを使わず、
インターネットに直接つながっているパソ
コンなら、コマンドプロンプトなどから
ipconfig （Windows2000/XP）
winipcfg （Windows95/98/Me）
と入力すると、他人からも接続できる
「グローバルIPアドレス」がわかる。
直接つながってない場合は、proxy
サーバーから情報を調べるWebサイトや
IPアドレスを表示するCGIのサンプル
ページなどへアクセスすればいい。
ただし、IPアドレスがわかっても恐らく
他人と通信するためにポートを開くという
特別な作業が必要だろうから、気軽に
テストすることはできないと思う。
402304
2005/08/20(土) 22:28:24ID:kzNeTZxb >>378
言いっぱなしのアイディアに具体的な
解説とコードの提示までしてもらって
恐縮です m(_ _)m 移動データを読み
出しの状況に応じて入れ替えるのは
何も問題ないと思います。テンキー
表記でもビット表記でもそれ以外でも
データの質は変わりませんからね。
もしこれがこの制作物の手助けになる
というのなら本望です。
>>393 ◆EFBt/pII5Y
移動に関しては、考えてる方法で元ネタを
再現できそうですか？問題なければ自分の
やりやすい方法で実装するのが一番。
でも、もし難しいのだったら、>>300 の
サイトで提案している座標マップで内部の
移動を行い、表示上の移動は移動元と
移動先のマスが持つ距離を歩数で割って
アニメーションしながら動かせば楽に
なりますよ。これなら、移動方向制限も
移動時の描画も難しいことはせずに済む
はずですから。
言いっぱなしのアイディアに具体的な
解説とコードの提示までしてもらって
恐縮です m(_ _)m 移動データを読み
出しの状況に応じて入れ替えるのは
何も問題ないと思います。テンキー
表記でもビット表記でもそれ以外でも
データの質は変わりませんからね。
もしこれがこの制作物の手助けになる
というのなら本望です。
>>393 ◆EFBt/pII5Y
移動に関しては、考えてる方法で元ネタを
再現できそうですか？問題なければ自分の
やりやすい方法で実装するのが一番。
でも、もし難しいのだったら、>>300 の
サイトで提案している座標マップで内部の
移動を行い、表示上の移動は移動元と
移動先のマスが持つ距離を歩数で割って
アニメーションしながら動かせば楽に
なりますよ。これなら、移動方向制限も
移動時の描画も難しいことはせずに済む
はずですから。
403名前は開発中のものです。
2005/08/21(日) 01:15:55ID:2orVmfJT404 ◆EFBt/pII5Y
2005/08/21(日) 14:18:35ID:0+TnpLMy ttp://zxzxzxzxzx.hp.infoseek.co.jp/board/is.zip
競売を追加
数値入力をカーソルからテンキーに変更
競売の流れ
売り手が店を選択
誰も買えない場合銀行が買い取り
買い手が購入選択
誰も入札しない場合銀行が買い取り
入札額を決める
一番高い人が落札
同額の場合早い人が落札
1発勝負のほうが緊張感があっていいかなと思ったので、こうしました。
露天→仮店舗といった、ランクアップは現在物件数で計算してるため、金額は関係ありません。
2店舗以上なら変動画面が表示されます。
SSに簡単な説明付けて更新しました。
>>402
まだ、ワープの実験中なんでそれが出来てからといった感じです。
早めに書いておけば、多少は集まるかもしれないので、今から宣言。
is_2.exeでの、競売は競う相手がいないので、買うか買わないかだけです。
3人以上でテストをしたいと思ってますので、よろしければ協力お願いします。
開始前にもう一度書き込みます。
競売を追加
数値入力をカーソルからテンキーに変更
競売の流れ
売り手が店を選択
誰も買えない場合銀行が買い取り
買い手が購入選択
誰も入札しない場合銀行が買い取り
入札額を決める
一番高い人が落札
同額の場合早い人が落札
1発勝負のほうが緊張感があっていいかなと思ったので、こうしました。
露天→仮店舗といった、ランクアップは現在物件数で計算してるため、金額は関係ありません。
2店舗以上なら変動画面が表示されます。
SSに簡単な説明付けて更新しました。
>>402
まだ、ワープの実験中なんでそれが出来てからといった感じです。
早めに書いておけば、多少は集まるかもしれないので、今から宣言。
is_2.exeでの、競売は競う相手がいないので、買うか買わないかだけです。
3人以上でテストをしたいと思ってますので、よろしければ協力お願いします。
開始前にもう一度書き込みます。
405名前は開発中のものです。
2005/08/21(日) 15:55:13ID:EuHMdUcS そんなに大変ならワープなしでいいじゃん。
いたストの面白い所はワープじゃないんだからさ。
いたストの面白い所はワープじゃないんだからさ。
406名前は開発中のものです。
2005/08/21(日) 19:46:38ID:rjiC90d+ 株を買うを選ぶと買わないと進めません。
改善してほしいです。
改善してほしいです。
407 ◆EFBt/pII5Y
2005/08/21(日) 21:04:34ID:0+TnpLMy408zxcv
2005/08/21(日) 22:11:27ID:30M9BOxI やってないけど、乙。
さっきも言ったけど1時間待って
3人しか集まらないのが今の現状だ。
ちょっとの変更で更新したり、
テストしようってのはどうかと思う。
完成してから来いとは言わないが
無意味な更新が多いのも事実。
宣伝が足りなかったりと原因は多々あるだろうけど
そんなのは後からどうにでもなる。
完成しないことには話が進まないんだ。
厳しいようだけど期待してるからこそだと思ってくれ。
さっきも言ったけど1時間待って
3人しか集まらないのが今の現状だ。
ちょっとの変更で更新したり、
テストしようってのはどうかと思う。
完成してから来いとは言わないが
無意味な更新が多いのも事実。
宣伝が足りなかったりと原因は多々あるだろうけど
そんなのは後からどうにでもなる。
完成しないことには話が進まないんだ。
厳しいようだけど期待してるからこそだと思ってくれ。
409300
2005/08/21(日) 22:17:23ID:H2QW92na >>407
動作テスト頑張って下さい。
入札制の採用、もしかして私の提言からですか（笑）？ だとしたら、大変光栄です。ありがとうございます。
一発勝負の方が時間もかからず、いいと思いますね。
ワープ情報というのは、「ワープの行き先」ですかね？ この定義法については提言あり。
一度>>336で書きましたが、「あるワープマスで移動できる先は、必ずただ１つのマスに固定されている」ので、
現在、店である時にしか使用しない事になっているであろう、
「元本」・「エリアNo.」の部分を上手く使うと、専用配列を増やす必要がありません。
ワープ先の取得は店のデータを読むのとほぼ同じ処理になるので、新規配列を作るよりも楽。
例：座標(5,8)にワープするワープマス（このマスの座標は8,7）がある場合
「元本」の座標（8,7）のデータ部分に5、「エリアNo.」の座標（8,7）に8を入れます。
実際にこのマスに止まったら（止まったマスがワープマスなら）、
新x座標をそのマスの「元本」から読んだ値、新y座標をそのマスの「エリアNo.」から読んだ値にします。
こういう定義法を提言するのは、ワープマスの数によってマップデータの長さが変わってしまう事を防ぐ為です。
ワープ先だけ別定義で用意すると、その分だけマップデータを追加しなければなりません。
既存マップデータの未使用部分を使用する方法だと、データの数値が変わるだけなので、マップデータの容量は変わりません。
この方法の欠点は特定のマスにワープするチャンスカードに対応できない事。
実はいたストSPでは、銀行行きを除いて、この種類のカードがなくなっていたりします。
なお、データの長さが変わらないようにすると、ゲーム前に正しいマップデータかチェックする事ができるようになります。
つまり、最初の８バイト（＝マップの縦横幅）を読んだ結果から算出されるマップデータの長さと、実際の長さが合わなければ、
このバイナリデータは正しいマップデータではない、とできます（次回のコンバーターVer.アップ時に試験的に実装予定）。
>>405
ワープできないと、良くも悪くも、離れ小島マップが作れないですよ？
動作テスト頑張って下さい。
入札制の採用、もしかして私の提言からですか（笑）？ だとしたら、大変光栄です。ありがとうございます。
一発勝負の方が時間もかからず、いいと思いますね。
ワープ情報というのは、「ワープの行き先」ですかね？ この定義法については提言あり。
一度>>336で書きましたが、「あるワープマスで移動できる先は、必ずただ１つのマスに固定されている」ので、
現在、店である時にしか使用しない事になっているであろう、
「元本」・「エリアNo.」の部分を上手く使うと、専用配列を増やす必要がありません。
ワープ先の取得は店のデータを読むのとほぼ同じ処理になるので、新規配列を作るよりも楽。
例：座標(5,8)にワープするワープマス（このマスの座標は8,7）がある場合
「元本」の座標（8,7）のデータ部分に5、「エリアNo.」の座標（8,7）に8を入れます。
実際にこのマスに止まったら（止まったマスがワープマスなら）、
新x座標をそのマスの「元本」から読んだ値、新y座標をそのマスの「エリアNo.」から読んだ値にします。
こういう定義法を提言するのは、ワープマスの数によってマップデータの長さが変わってしまう事を防ぐ為です。
ワープ先だけ別定義で用意すると、その分だけマップデータを追加しなければなりません。
既存マップデータの未使用部分を使用する方法だと、データの数値が変わるだけなので、マップデータの容量は変わりません。
この方法の欠点は特定のマスにワープするチャンスカードに対応できない事。
実はいたストSPでは、銀行行きを除いて、この種類のカードがなくなっていたりします。
なお、データの長さが変わらないようにすると、ゲーム前に正しいマップデータかチェックする事ができるようになります。
つまり、最初の８バイト（＝マップの縦横幅）を読んだ結果から算出されるマップデータの長さと、実際の長さが合わなければ、
このバイナリデータは正しいマップデータではない、とできます（次回のコンバーターVer.アップ時に試験的に実装予定）。
>>405
ワープできないと、良くも悪くも、離れ小島マップが作れないですよ？
410300
2005/08/21(日) 22:29:38ID:H2QW92na411300
2005/08/21(日) 22:37:58ID:H2QW92na >>408
作り手から言わせて頂くと、後々バグが大量に見つかると直すのが大変なのです。
とはいえ、人が集まらないことにはどうしようもないので、オンラインテストはもうやめます。
今後は、大幅な変更があったときのみ、公開することにします。
>>409
入札制度は面白そうなので利用させて頂きました。
入札額が9999Gまでと制限されてますが、十分でしょう。
ttp://homepage1.nifty.com/tsukac/itast/kouryaku/streetg04.html
その方法だと、このような処理は出来ない気がします。
これもワープとして処理しようと思っているので、その辺をどうしようか考え中です。
ご提案頂いた方法が一番だと思いますが。
>>411
ご指摘ありがとうございます。うｐしました。
作り手から言わせて頂くと、後々バグが大量に見つかると直すのが大変なのです。
とはいえ、人が集まらないことにはどうしようもないので、オンラインテストはもうやめます。
今後は、大幅な変更があったときのみ、公開することにします。
>>409
入札制度は面白そうなので利用させて頂きました。
入札額が9999Gまでと制限されてますが、十分でしょう。
ttp://homepage1.nifty.com/tsukac/itast/kouryaku/streetg04.html
その方法だと、このような処理は出来ない気がします。
これもワープとして処理しようと思っているので、その辺をどうしようか考え中です。
ご提案頂いた方法が一番だと思いますが。
>>411
ご指摘ありがとうございます。うｐしました。
413名前は開発中のものです。
2005/08/22(月) 08:19:36ID:5xLlrSct 曲が必要になったら呼んで下さい。
いたスト好きなので、このスレからは目が離せません。
いたスト好きなので、このスレからは目が離せません。
414300
2005/08/22(月) 10:35:50ID:2TiRAs5z 朝っぱらからこんにちは(^^;
昨日の訂正。
>>409
最初の８バイト（＝マップの縦横幅）
→最初の３６バイト（＝マップの縦横幅とエリア数）
でした。エリア数によってデータの長さが変わっている仕様だったのを忘れていました(^^;
>>412
制限は9999Ｇであれば、大抵は事足りるでしょう。ただ、「常に9999Ｇ」だとしたら問題。意図的に破産できてしまいます。
「現金＋株の合計値」が本家の制限（その競売によって店売りになる金額は出せない）なので、それに準じてもいいかと。
この場合、終盤は上限が５ケタを超える事になります。
で、上下左右の無限ループの方法ですが、これは提言する方法で簡単。
マップの端に当たるマスの１つ先にトンネルマス（到達すると、対応するトンネルマスにワープ。本家の階段と同じようなもの）
を設け、>>336に書いた「階段マス」の処理をすればOK。
具体的には、>>409の
「実際にこのマスに止まったら（止まったマスがワープマスなら）」
を「実際にこのマスに到達したら（到達したマスがトンネルマスなら）」
と置き換えて考えて下さい。
昨日の訂正。
>>409
最初の８バイト（＝マップの縦横幅）
→最初の３６バイト（＝マップの縦横幅とエリア数）
でした。エリア数によってデータの長さが変わっている仕様だったのを忘れていました(^^;
>>412
制限は9999Ｇであれば、大抵は事足りるでしょう。ただ、「常に9999Ｇ」だとしたら問題。意図的に破産できてしまいます。
「現金＋株の合計値」が本家の制限（その競売によって店売りになる金額は出せない）なので、それに準じてもいいかと。
この場合、終盤は上限が５ケタを超える事になります。
で、上下左右の無限ループの方法ですが、これは提言する方法で簡単。
マップの端に当たるマスの１つ先にトンネルマス（到達すると、対応するトンネルマスにワープ。本家の階段と同じようなもの）
を設け、>>336に書いた「階段マス」の処理をすればOK。
具体的には、>>409の
「実際にこのマスに止まったら（止まったマスがワープマスなら）」
を「実際にこのマスに到達したら（到達したマスがトンネルマスなら）」
と置き換えて考えて下さい。
415名前は開発中のものです。
2005/08/22(月) 12:50:44ID:5QxyaKCI 2ch版いただきストリート作りませんか？
http://ex11.2ch.net/test/read.cgi/news4vip/1124682242/
vipにスレ立ててきた
1時間後には落ちてるだろうなｗｗｗｗｗ
http://ex11.2ch.net/test/read.cgi/news4vip/1124682242/
vipにスレ立ててきた
1時間後には落ちてるだろうなｗｗｗｗｗ
>>413
大変ありがたいです。よろしくお願いします。
>>414
その先に1マスと言うことは
■＝なにもない
□＝マス
■□■←ここが最上段
■□■
■□■
例えば、このような場合、
■■■←ここにトンネルマスを用意
■□■←ここが最上段
■□■
■□■
このように、最上段を1つ下げて、上に何もない列を加えると言った感じでしょうか？
実は上左の端の列は、マスが無い列というのは出来ないようにしてあるのです。
それよりも問題は、ムーンシティーのようなマップって、継ぎ目なく無限に続くんですよね。
今の描画方法だとこれは無理なので、とりあえず普通のワープと階層のみということで考えます。
ワープ後の転換状態は増資の配列が余ってるので、これをマップデータに埋め込もうと考えてます。
毎度のように、プログラム側の処理を楽にしたいだけなんですけどね。
>>415
見たところゲームと関係ない板のようですが？
個人的には、こことHPだけでやって、それで集まらなきゃ別にいいやって考えです。
大変ありがたいです。よろしくお願いします。
>>414
その先に1マスと言うことは
■＝なにもない
□＝マス
■□■←ここが最上段
■□■
■□■
例えば、このような場合、
■■■←ここにトンネルマスを用意
■□■←ここが最上段
■□■
■□■
このように、最上段を1つ下げて、上に何もない列を加えると言った感じでしょうか？
実は上左の端の列は、マスが無い列というのは出来ないようにしてあるのです。
それよりも問題は、ムーンシティーのようなマップって、継ぎ目なく無限に続くんですよね。
今の描画方法だとこれは無理なので、とりあえず普通のワープと階層のみということで考えます。
ワープ後の転換状態は増資の配列が余ってるので、これをマップデータに埋め込もうと考えてます。
毎度のように、プログラム側の処理を楽にしたいだけなんですけどね。
>>415
見たところゲームと関係ない板のようですが？
個人的には、こことHPだけでやって、それで集まらなきゃ別にいいやって考えです。
■ このスレッドは過去ログ倉庫に格納されています
