【初心者】ｽﾚを立てる前にｺｺで質問を【Part25】

1 ：2013/02/16 〜 最終レス ：2013/07/11

疑問に思うことがあれば、スレを立てずに、まずはココで質問。
スレッドを立てる前にはローカルルールを読みましょう。
http://pc11.2ch.net/gamedev/
※ >>980 を踏んだ人は次スレ立てをお願いします。
【アップローダ・避難所・Wiki】
ゲーム製作技術板公式Wiki
http://hibari.2ch.net/gamedev/
ゲーム製作技術板公式アップローダ
http://gmdev.xrea.jp/
gamdev.orgが落ちるたびにあげてみるスレ
http://hibari.2ch.net/test/read.cgi/gamedev/1107022166

2 ：

>>1
乙

3 ：

【初心者向け書籍】
やさしいＣ＋＋
↓
ポインタが理解できない理由
↓←Ｃパズル
入門書の次に読む本(アルゴリズム)
↓
座標指定
↓
WinAPI32 グラフィック
↓
WinAPI32 サラウンド
↓

4 ：

2Dアクションゲームや2Dシューティングで左側にゴールがあると何か都合悪いんでしょうか？
プログラミングではなくゲームプレイに関してです。
マリオをはじめ、ほとんどが右側にゴールがあると思います。

5 ：

>>4
人間の本能がそうなってるから！
かどうか知らないけど慣れてるからじゃね

6 ：

>>4
いくつかの説がある。
・技術的な都合によりデータ構造が左上から右下に向かうようになっており、自然とゲームデザインもそれに従うようになった。あとは慣習。
・横書きの文章など、左から右に進むものが世の中に結構多いので、その慣習に従った。
・多くのアーケードゲーム筐体でレバーは左側にあり、自機も画面の左側にあった方が違和感が少ない。
いずれにしても、慣習ってのは重要みたいね。
ユーザインタフェースの入門書とか読んでも、最初に必ず「既存のものに従え」って書いてあるし。

7 ：

THANK YOU とかの文字列が背景にあるスクロールなんかでは右から左にスクロールすると読めないだろ。
あと人間は本能的に右を進むという認識になってるから、それの影響(それがあって文字列も右に進んでる)

8 ：

逆方向のゲームはいくつかあるね
プレイにあたってそれほど都合悪いところはない
ただし、慣習と違う、という点で都合が悪いとは言えるだろうね

9 ：

3Dのキャラメイキングはどのように作ったらいいですか？

10 ：

連投すいません
具体的にはMiiみたいなものを作りたいです

11 ：

自分のやりたいことを具体的に説明できるようになるのが最優先

12 ：

実際重要だね、それは

13 ：

まず2Dで福笑い作れ。 3Dはそれをテクスチャでやるだけ

14 ：

xml使ってデータの読込しようとしてるんですが質問です。
効率的なxmlの作り方ってないでしょうか？
いまは一回適当なインスタンス作ってシリアライズして書きだしたものの値を変えるってやってたんです
タグの打ち間違いなどの書式ミスなくすため。変ですかね？
かなり量が大量すぎて手作業で変えるのは骨が折れそうです。
ツール作るのが良策なんでしょうか。みなさんのやってる方法教えて下さい。
環境はC#です。

15 ：

xml を手作業で編集するのは無しだな
といっても自分の場合 csv みたいな簡単なフォーマットしか使わないから
xml 自体必要使わないんだけどね

16 ：

いまはグラフィカルなの作る能力がないのでコマンドプロンプトで表示のみの作ってたんですが、
そのせいで配列の各要素をタグで囲まなきゃならないようで困惑してたんです。
Tiledエディタで出力したマップの整数配列の各要素にタグつけするとか腱鞘炎になりそう。
もしゲーム用の環境に移したらちょっとはましになりそうなのでそれを待ってみます。
以前xna使ってたんですが、それは数字を空白で分けただけでよかったし。
いまは読み込みはせずテスト用にハードタイプして済まします。
pythonとかスクリプト言語使って生成するとかフォームアプリで入力支援するのもよさそうですが、
環境未定なので、xmlの構造が未定なので後回しにします。
ありがとうごいました。

17 ：

>>16
C# XML ツリービュー で検索すれば結構出てくるぞ

18 ：

>>17
教えてくれてありがとうございます。
xmlの成形が正しいかなど構造を確認するときに使うのかな？

19 ：

Excel (相当するアプリ)を駆使して作れば、かなり楽に整形もチェックもできると思われ。　自分ならそうする。
XML関連のモジュール使うのもありだろうけど、意図したデータを作る、チェックするのに手間が数倍かかるな。
作業する人の性格にもよる。 中間言語や他の形式を中継するの嫌う人もいるし、正確さにコスト厭わない人もいる。
自分みたいに最悪バイナリや整形されてないデータを解釈する人もいれば、自前で単一言語で揃えたい人もいる。
ちなみに作業(労力コスト)効率だけでいえば、XMLは可読性と厳密性の点から悪い部類とだけ付記して終わる

20 ：

定期的に話題になるけど、XMLの優位性がいまいち分からない。
csvやiniを避けてxmlにするのはどんな場合なんだろ？

21 ：

動的に構造が変わるデータで、かつiniファイルだと表現しきれない部分（階層や属性など）があるときとか？
まあ、iniより複雑な構造が扱える形式は、XML以外にもチラホラあるけれど。

22 ：

>>20
構造化データを記録できるテキスト(SGML)ベースのドキュメント。
HTMLの普及のおかげで、なんとなく理解できる人が多い。
許容される内容がDTDで厳密に定められていて、例外の存在を許さない。
アメリカの軍事利用に採用(元々が軍事データの管理用)されるほど隙がない。
但し、プログラミングや直接の編集・目視での解析や理解は非常に面倒。

23 ：

単純に構造化データのシリアライズ（ファイル保存とロード）だけが目的なら、
現時点では普及率と利便性から JSON か YAML がお勧め
>>14 はなぜXMLを使う必要があるのかを明示するとこの話題はもっと盛り上がる

24 ：

あんまり深いこと考えてなくて、一時期xnaを使ってた名残です。
あれは確かxnaはデータはxmlなら用意されてるAPIで読み込めたはず（不確かですが。）で、
他のだとコンテンツプロセッサ自作する必要があったかと
いいと思ってるのは、XMLSerializer使ったらオブジェクトを単純に復元できたり
>>22さんの意の「目視が面倒」とは矛盾しますが、個人的にはわかりやすいと感じてたり。他のをそこまで知らなかっただけです
yamlはしらなかったんですが、視認はよさそうですね。
なぜxmlかといったらフレームワークのAPIがあった名残でしかないです。
どういう用途に使うかですが、RPG作ってましてマップやパラメータ情報などの他、
lvごとに使用可能技が増えるってのを表すのに、使おうとしてまして
かなりの数の入力と精度が求められると尻込みして>>14の書き込みになりました。
最初levelの最大値*skill数のbool配列で特定のレベル使えるかどうかのフラグ立てようとしてましたが、
返信描いてた時に、特定のレベルで新しく使用可能になるスキルをジグザグ配列に入れて1〜現在のレベルまでのを使用可能スキルを
足し合わせるようにすればもっと記述減ると気づきました。

25 ：

XML はあらゆるデータを厳密に記述することが可能なので
「メモリ上のバイナリデータをテキスト化」を考える上で
非常に都合がよいですね。
C#のプロパティパネルで表示されるような属性や型を持つ
複雑なインスタンスを保存するのであれば、Ｃ＃が機能として
持ってる XMLSerializer を使うのが正解ですね。
プログラミング言語のクラスデータを生で保存できるのは非常に強み。
>24 で書いてる用途については、List<List<bool>> のような
二次元で表現できるデータなので、記述と再利用方法で最も
利便性が高いのはCSV データとなり、そしてそれを編集
管理してエクスポートできるアプリとしては Excel を使うのが
無難でしょう。

26 ：

RPG作ってましてマップやパラメータ情報などの他、
lvごとに使用可能技が増えるってのを表すのに、使おうとしてまして
かなりの数の入力と精度が求められると尻込みして>>14の書き込みになりました。
ちなみに私が似たようなものを作ったときは
マップは byte[][] なデータ列。
今風なら List<List<short>> を生データとして保持する専用クラス。
パラメータ情報なんかはキャラクタ判定関係の全ての機能を押し込んだ
クラスを作って、習得レベル管理は Dictionary<string,int> の
スキル名→習得レベル 辞書を使って大小判定させますね。
スキル名の並び処理が必要であれば、別の並び管理用のリストを作るなり、
ListDictionary の特性を使って楽をするかなどありますね。
このあたりは効率より、どのような処理をしたいか？ 処理が必要か？ を
考えて逆に使える手法を探っていく必要がありますね。
私は最初から完全な仕様を決めて作りこむタイプなので、バイナリでやっちゃいますがｗ

27 ：

構造化データのシリアライズをしようと思って、
仮に、
csv
JSON・YAML
xml
の3つが候補になったときに、
JSON・YAMLを知らなくて、xmlの経験があれば、
xmlを選んでしまうこともあるかも知れない

28 ：

くっ、よもや俺様がここまで追い詰められるとは…仕方ない、これが奥の手だ喰らえ
みたいな感じでしぶしぶ持ち出すのが XML

29 ：

それでもXMLなら・・・XMLならきっと何とかしてくれる
というくらいの期待株ではなくて、仕方なく使うのはなんでなんだろうな

30 ：

奥の手を出してしまうと勝っても顔に×印の痕が残ってしまうからだ

31 ：

>>29
果てしなく面倒くさいだけで本当は使いたくないのに
それしか選択肢がないからだろ？

32 ：

単に他の選択肢を知らないとかじゃ

33 ：

言葉遊びをする訳じゃないけど
知らない物は選びようがないんじゃあ・・・

34 ：

他の選択肢というが、XMLと互換な記述言語か汎用なライブラリって何かあるのか？

35 ：

>>34
XML自体は極めて高機能な仕様だけど、ゲーム制作においては規模が大きすぎるってだけよ。

36 ：

XMLと互換の意味がよくわからないけど例えば
CSV、TSV、JSON、YAML、MessagePack、S式、BSON、LTSV、TOML・・・
途中から知名度がアレだけどまあ腐るほどあるよ

37 ：

で、その中でゲーム向きで記述がわかりやすくて習得が容易なやつはどれ？
とか諸々考え出すと、もうこれでいいやってなる

38 ：

こういうのはだいたい配列とかに値をつっこんでライブラリに渡すだけだから習得もクソもない
ライブラリも一部を除けばよほどマイナーな言語でも使っていない限り揃ってるよ

39 ：

そう考えると、CSVかiniで済むことも多いんだよな。暗号化とかは別にしてもさ。

40 ：

正直どれ選んでも大差ないね
通信とかDBがからむと圧縮率とか圧縮速度とかで差別化できるんだけどゲームだとそうでもないし

41 ：

習得のためのノウハウがwebに沢山転がってるか、ってのは
割と重要かもね
慣れた人なら自力で、リファレンスといくつかのTIPSがある状態からでも、
使いこなすかもしれんけど、そうでない初心者も多いわけで

42 ：

>>40
じゃあXMLでいいや、新しく無駄なライブラリの使い方覚えるの面倒だし
ってなる

43 ：

逆にXMLのデメリットってなんだ？

44 ：

CSVファイルやINIファイルに比べると解析が面倒くさい

45 ：

XMLファイルを作るのが面倒くさい。
csvならexcel使えるし。

46 ：

作成に関してはツール作ればいいと思うけどねえ
ただ、そうするとあれこれ実装しないといけないから面倒くさいんだよな

47 ：

sqlite使おうぜ

48 ：

XMLを使うということはデータ構造が複雑であるということであり
構造が複雑であるということはバグが入り込む余地が大きいということであり
データである以上、最終的には目視でチェックできるということが大きな利点であり
無駄なメタ情報を垂れ流すXMLを避けるというのは経験あるぷろぐらまにとって当然の選択である

49 ：

XMLパーサーなんかいくらでも有るだろ
XML作成はVisualStudioのエディタで
DTDとかXMLスキーマがあればコード補完も出来る
まあJSONとかSQLiteとかでも良いんじゃね

50 ：

XMLは人が書くものじゃないでしょ
あれはプログラムで生成するものだよ
俺は、.NET FrameworkのXMLSerializerクラスを使って
ゲーム内の設定(キー設定とか)を保存するためにXMLを使用してる

51 ：

プログラミングする際に先にテストコードを書くことを全く理解できない奴が結構いるもんな。
ツールとかで視覚化したりバリデーションして楽をする(この点も理解してくれん)ことを避けて、
いつまでも人力でやるのが楽で確実だと思い込んでる(しかもそれができることがスキルだと)。

52 ：

著作権問題がよくわからん。
商用じゃなきゃ背景とかネットから拾ったものでもいいんですかね？

53 ：

>>52
商用だろうが非商用だろうが原則アウト。
使用可能なものは配布サイトやreadmeにきちんと書いてあるから読みなさい。

54 ：

>>53
わかりました。すばやい回答ありがとうございます。

55 ：

Mantis や RedMine を、
サーバ知識・環境のない個人が
無料（あるいは低価格レンタル）に近い形で使うのは無理かな？
離れた人と同人活動しているんだけど、デバッグがはかどらない。
GoogleDocs のスプレッドシートでバグリストを共有するのも不便。

56 ：

>>55
http://en.wikipedia.org/wiki/Comparison_of_open_source_software_hosting_facilities
http://ja.wikipedia.org/wiki/OSS%E3%83%9B%E3%82%B9%E3%83%86%E3%82%A3%E3%83%B3%E3%82%B0%E3%82%B5%E3%83%BC%E3%83%93%E3%82%B9%E3%81%AE%E6%AF%94%E8%BC%83

57 ：

>>56
ありがとう、でもちょっと何が書かれてるのかわかんない。ごめん。
教えてもらったページ経由で、
Google 系の simplebugtracker ってのでも良いかなと思ったんだけど、
GAE が出てきて断念。

何か、もう少しアホでも気軽に使えるのないのかな。
My Redmine が良さげに見えたんだけど、高すぎて手が出ない。
毎月 2000 円くらいなら頑張れるんだけどｗ
いちど BTS を味わうと、エクセル管理には戻れん、、、

58 ：

Made in GAPAN 歩 〜Ayumu〜ってスレ違い、板違いですか？

59 ：

ちょっと別な場所で聞いてみるわ。
レスくれた人ありがとう。

60 ：

何故だ
無料でGitやMercurialのリポジトリが使えて
Wikiやバグトラッキングが付いてくるのなんか山ほどあるのに

61 ：

同人だとプライベートリポジトリが持てないとたるいんじゃない？ Mercurialなら一個持てるけど
使ったことないけどGitoriousみたいなクローンってどうなのよ

62 ：

あ、GithubとBitbucketの話だと勘違いしてた。忘れて///

63 ：

何でBitBucketを使うんじゃダメなんだ？
プライベートリポジトリも持てるしバグトラッキングもついてくる

64 ：

すみません質問です。
Javaなんですが以下のコードを実行したら
speedの数値によって明らかに角度が違ってしまいます。
何が悪いのでしょうか？
理想的にはどのspeedでも同じ角度にしたいのですが…
double dx = Math.cos(angle * RAD) * speed;
double dy = Math.sin(angle * RAD) * speed;
int lx = (int)Math.round(dx);
int ly = (int)Math.round(dy);
x += lx;
y += ly;

65 ：

>>64
intに変換するから悪い。どう見てもroundで必要な情報がごっそり削られてる。

66 ：

>>65
でも座標を渡す描画メソッドがintなので一旦intにしないといけないんです…
前にC言語で同じようなコードを書いた時は普通に暗黙キャスト？で問題なかったんですが…
Javaだと型に厳しいみたいでintへのキャストが必須みたいなんですが。
あとroundを使ってるのはこれをしないと
280°とかでも270°と同じ移動量にしかならず
なんだかかなり大雑把な角度指定しか出来ないので…
どうすればいいんでしょう…

67 ：

>>66
例えばspeedが3とかだとするじゃん。
cos, sinは-1〜1までの値だから、
dx, dyは-3〜3までの7つの整数になる。組み合わせは7 x 7 = 49通り。これだと360度表現できるわけないな。
dx,dyの組み合わせが360通り以上になるようにするにはspeedが30以上必要なわけ。
だからspeedを常に30以上にしておけば割と正確なんじゃないの。
……という冗談はさておき、座標は常にdoubleで持っておいて、描画メソッドに渡すときだけintにすれば
多少マシになると思う。
それ以上の精度が欲しければ毎ターン決められたdx, dyを加算するような方式をあきらめる必要があるのでは。

68 ：

>>67
やっぱ精度を保つにはspeedを高くするしかないんですね。
言われたことを参考にしながら頑張ってみます。
ありがとうございました！

69 ：

>>67
確かに別にx,y座標をdoubleで保持して
メソッドに渡す時だけintにキャストするようにしたら
かなり精度アップしました！
これで十分です。ありがとうございました！
考えてみたら常にintへのキャストで情報失われるから当然
別途高精度な値を保持してないとマズイですよね…
なんというバカなミス…

70 ：

次に似たようなケースに遭遇しても対応できるようになったと考えればいい
いい勉強になったじゃないの

71 ：

>>70
そうですね。ありがとうございました！

72 ：

同じミスを経験したことがある人は多いだろうしなｗ

73 ：

さらに一年後忘れて同じミスするんだぜ

74 ：

せめて座標を画面に吐かせるだけの頭があれば

75 ：

SpriteStudioは高いので他探しているのですが、
無料または1万円未満の範囲だとSpriterくらいですか？

76 ：

Spriter
http://brashmonkey.com/
DragonBones
http://dragonbones.github.com/
Xprite
http://studioyu.net/xpr/index.html
Spine
http://esotericsoftware.com/
Umotion 2D
http://www.nuoxygen.com/tools/umotion2d/umotion2d.php

77 ：

Wizardryや、かまいたちの夜１のような絵が動かない、
個人製作でも手が届くゲームを一人で作りたいんだけどまったくの素人です。しかもR
音楽は自作してるので、それを活かせる自作ゲームを作りたいと思いました。人に聴いてもらえる+自分の脳内を描いたゲームの世界に引き込める・知ってもらえるなんて最高じゃんと
ゲーム製作の際、何から学べばいいですか？何か製作に必要なソフトとかあるのでしょうか？（数万円程度なら出せます
まじでプログラム言語とかも知らないです

78 ：

Dungeon Craft
http://uaf.sourceforge.net/screenshots.html
LiveMaker
http://www.livemaker.net/
Yuuki! Novel
http://page.freett.com/yuukiex/yuukinovel.html

79 ：

素人が出来るものといえば、　「ＲＰＧツクール」
このツールを使って、ＲＰＧじゃなくてアドベンチャーゲームに仕立てる。
戦闘が無くて、物語を主人公が進めてゆく。
各種メディアは、フリーのものが入手できる
操作は、設定値を変えるだけ
必要な物は、シナリオ（物語のストーリー）、これはあなたが考える。
これなら容易であり、挫折も少ないだろう。
いったん完成したならば、改良するのです。
メディアをオリジナルに変更したり、サブストーリーを追加したり。

80 ：

>>79
なるほど。ありがとう

81 ：

放物線で狙撃する動き（角度固定）
ttp://hakuhin.jp/as/shot.html#SHOT_02_01
このサンプルの dx, dy を求める式を使って射撃ゲームに使おうと思うんですが、
どうも遠いと飛びすぎて、近いと届かない状況です。
どう調整したらいいでしょうか。
落下最初の１秒が 200ドットなので g=200 としたりしてますが問題ないですよね？

82 ：

計算式理解してるか？

83 ：

というか当たり前だよね？
現実世界で速く投げれば遠くへ飛ぶし、遅く投げれば近くに落ちる。
もちろん角度とか（あるいは重力とか）を変えれば別だけども。

84 ：

あ、いや、そういうことじゃないのか。なんかこっちが混乱してきた。

85 ：

あとリンク先読み直してて気付いたが、
地球上だと最初の1秒で落ちる距離って確か5mくらいだから、200ドットでg=200はおかしいと思う

86 ：

g（重力加速度）って、画面下に行けば行くほどgが加算されるってことでないの？
g=200なら最初の1Fは200px、2F目は400px

87 ：

そりゃあ、>>81の書いたコード中の計算式が何かおかしいんでしょ。
力学の方程式解いたら発射速度がバシッとでる筈なんだし。

88 ：

コンピュータは計算通りに結果を出します。
ですから、あなたのプログラムコードに間違いがあると思われる
現実の大砲などは、空気抵抗や風の影響も必要でしょうけど
物理の方程式などは、
弾道計算や斜方投射で検索してください。

89 ：

最初に1/2する意味が分からなかったけど、平均を取ってるんですね。
だから重力加速度は400ドットか。
だけど、dtを調整するから変わらず。
砲台の設定がマップの縮小で、単純なベクトルになってると思ったんですが
どうやら設定が大きければ大きいほどパワーが大きくなるようで、
それで飛びすぎていたようでした。
dy が MAX-10 のときに３秒で落下
dy が MAX-37 のときに200ドット上がって２秒で落下
dy を上記で固定したときにdは単純な比例ではなく、次のような関係でした。
subx = x1 - x0
dx = (0.09 * abs(subx) - 0.00003 * subx^2 )
dx = (0.085 * abs(subx) - 0.000036 * subx^2 ) * 3 / 2
ちなみにゲームはこれです。
ttp://www.badeggsonline.com/

90 ：

なんていうか、落下運動(等加速度運動)の方程式分かってる？
落下位置は時間の二乗に比例するのは分かる？
その類は付け焼刃だと直ぐ詰むから、ちゃんと基礎固めた方が良いよ。

91 ：

＞落下位置は時間の二乗に比例するのは分かる？
比例しねえよ。
アホか。

92 ：

えっ

93 ：

質問者が小学生か中学生かもしれんだろ

94 ：

いちおう理系プログラマ経験ありの無職ひきこもりなんですがね
助言ありがとうございました。
現状
X軸上の目標にほぼ当たるように調整しました。
しかし、高さが変わるとさっぱり。
たぶん、方向×パワーでの調整をしないとだめなんでしょう。
ゲームツールとしては実用になりそうなんで十分です。
・・・ t の計算前に調整したのは失敗かな。

95 ：

rot = 45　// 仰角　左下原点
xn, yn　　// 砲台、目標の画面座標
dx, dy　　// 砲台の向きとパワー 左下原点　　　←これが砲弾の初期ベクトルと一致すると思ったのがそもそもの間違いでした。
引数(rot, x0, y0, x1, y1, var dx, var dy)
// 初期値
g = 400
dt = 0.05　　　　// 画面座標を g * dt するとほぼ砲台ベクトルになる
PI = 3.14159
// 計算
rot = (-1) * signum(x1 - x0) * (90 - rot) - 90
rad = rot * PI / 180　// 角度からラジアンに変換
subx = x1 - x0　　　　// x方向のターゲットとの距離
suby = y1 - y0　　　　// y方向のターゲットとの距離
suby = (-1) * suby　 // 座標変換
// 画面座標を砲台比率に調整
subx2 = 80 + subx * 1.3 - sqrt(subx * subx * 0.4)　　　　// x軸上でほぼ当たる
suby = suby * (subx2 / subx)
subx = subx2
// 到着時間（フレーム数）を求める （サンプルのまま）
t = (-1) * (2 * subx * sin(rad)) / (cos(rad) * g * dt) + (2 * suby / (g * dt))
t = sqrt(abs(t))
dx = subx / t　　　　　　　　　　　　　// x方向の移動量を求める
dy = dx / cos(rad) * sin(rad)　　　　// y方向の移動量を求める

96 ：

>>95
画面座標を砲台比率に調整、ってのが何をやりたいのかさっぱりわからん。
>>81のサンプルじゃないよね。
こっちで一からエクセルで計算式作ったら、
ターゲットがy<xの座標である限り、確実にヒットしたぞ？
>>91
x=(-1/2)gt^2　は「xはtの二乗に比例する」って表現するんだ。
こんな下らん事で興奮してると禿げるぞｗ

97 ：

FPSを作っているのですが
エイムアシストってどういう風な仕組みですか？
敵に照準が近づくのはどれくらいなのでしょうか？

98 ：

チートツール作ってるの？

99 ：

＞敵に照準が近づくのはどれくらいなのでしょうか？
どれくらいの意味がわからん。
単純に、注視点と目標のベクトルの外積が一定以内なら、
強制的にレクティル（射線）を目標に合わせるとか。

100read 1read

1read 100read
TOP カテ一覧 スレ一覧 2ch元 削除依頼 ▲

なぜVBは扱いが低いのか (195)
Ruby でなんかゲームつくる (118)
【SB】Shooting Game Builder ver16【ｼｭｰﾃｨﾝｸﾞ】 (199)
ゲーム製作に役立つ資格をとるスレ (116)
★★★ゲームの技術を見破るスレ★★★ (195)
Cでブロック崩しを作りたい (172)
--log9.info------------------
日立市・高萩市・東海村のパチンコ店情報 (163)
【駅から】パラツッォ志村２【５秒】 (970)
ガーデン東浦和被害者友の会 (377)
千葉市ビッグスクエア (101)
見附ダイナム見附店スレ (422)
【福岡】HINODE大野城【南部】 (408)
【R】女性店員のコスが可愛い店情報交換スレ (452)
秋津のパチンコ屋 (359)
【八王子】駅前⇒⇒⇒１ぱち専用スレ�@●○● (167)
【品川】スーパーハリウッド　グランド情報【1】 (632)
【八王子】四谷デルタ♪本日のお勧めは何処？ (175)
【あきる野・青梅】いらっしゃいませ♪オリキャバ (216)
2010年・おまえらいくら勝った(負けた）?　公表スレ (122)
福岡フェイス前原part12 (260)
【古河】野木ライブガーデン【小山】 (205)
ジャック＆ベティ市川店（笑） (131)
--log55.com------------------
旧型カローラフィールダー　Part4
【W212】メルセデス・ベンツＥクラス 41【S212】
【日産】デュアリス Part57【DUALIS】
【NISSAN】日産セレナC27 PART27【SERENA】
ルノースポール《》ph19《》RS
【プジョー】プジョー総合 Part48【Peugeot】
【HONDA】4代目(RB3-4)オデッセイVer.34【ODYSSEY】
【ホンダ】2代目インサイトオーナー限定スレVer.34