【ウディタ】WOLF RPGエディター　其の28

1 ：11/11/01 〜 最終レス ：11/11/25

RPGツクール系よりは手がかかる分、比較的細かい所まで作り込む事ができます。
RPGツクールでは物足りないけど、プログラミングはちょっと……という方にお勧めです。
次スレは>>980が立てて下さい。
■WOLF　RPGエディター公式サイト
ttp://www.silversecond.com/WolfRPGEditor/
■開発者サイト　SilverSecond
ttp://www.silversecond.net/
■エディター説明書
ttp://www.silversecond.com/WolfRPGEditor/Help/
■WOLF RPGエディターWiki
ttp://www.silversecond.com/WolfEditorWiki/
■WOLF RPG エディター パーフェクトガイド
ttp://www.silversecond.com/WolfRPGEditor/Guide/
■第三回公式ウディタコンテスト＜終了＞
ttp://www.silversecond.com/WolfRPGEditor/Contest/
前スレ
【ウディタ】WOLF RPGエディター　其の27
http://hibari.2ch.net/test/read.cgi/gamedev/1316611044/
関連スレ　ｳﾃﾞｨﾀ初心者質問ｽﾚWOLF RPGｴﾃﾞｨﾀ-
http://hibari.2ch.net/test/read.cgi/gamedev/1275717753/
以下、公式サイトから抜粋。
○高度なRPG開発が可能な、完全無料のRPG製作ツールです。
○作成したゲームは自由に配布したり、コンテストに投稿することが可能です。
　 また本ソフトを持たない人でもプレイが可能！ファイル暗号化も完備！

2 ：

【関連サイト】
◆ウディタ新聞
ttp://www4.atword.jp/wolfrpg/
◆ウディフェス＜終了＞
ttp://www36.atwiki.jp/wodifes/
◆非公式ウディタコンテスト-Wodicon-＜終了＞
ttp://www39.atwiki.jp/wodicon/
◆Sunsoften　（ツクール規格の画像素材をWOLF RPGエディター用に変換するツール「tkool2WOLF+｣を配布。）
ttp://www.silversecond.com/WolfRPGEditor/Data/Rikka/
◆WOLF　RPGエディター（ウディタ）製作・雑談・共有板 - したらば掲示板＜廃墟＞
ttp://jbbs.livedoor.jp/sports/22994/
◆【Wolf RPG エディター】　ウディタ技術解説Wiki - livedoor Wiki＜更新停止中＞
ttp://wiki.livedoor.jp/woditor/
【動画】
●WOLF RPGエディター紹介動画
ttp://www.youtube.com/watch?v=pSXfsSqrPBI
●第二回 WOLF RPGエディターコンテスト トップ10動画
ttp://www.youtube.com/watch?v=q2WdD4nMe9g
●第三回ウディコン トップ10動画
ttp://www.youtube.com/watch?v=FRJzOKltd-w

3 ：

10/27にウディタ2が正式公開されました。
変更点を知りたい方は以下のサイトを御覧ください。
◆エディター更新履歴
http://www.silversecond.com/WolfRPGEditor/ReleaseLog.html
◆ウディタ2.00に迫る！
http://wikiwiki.jp/piporpg/?%A5%A6%A5%C7%A5%A3%A5%BF2.00%A4%CB%C7%F7%A4%EB%A1%AA

4 ：

〜ＦＡＱ〜
Ｑ　○○は作れますか？
Ａ　ウディタはかなり自由度の高いエディターです。大抵の事はできるので、後はあなたの腕次第です。
　 　まずは説明書を読んで、分からない所が出て来たらなるべく具体的に質問しましょう。
Ｑ　ツクールの素材を使いたいです。
Ａ　ツクールRTPに入っている素材やRTP改変素材はエンターブレインの規約上ウディタでは一切使えません。
　 　規約に問題がなくてツクールの規格に合っている素材を使いたい場合は、tkool2WOLFを使いましょう。
Ｑ　何か企画やろうぜ！
Ａ　企画の発案は大歓迎です。ただし、スレ住人が少ないので満足行く結果が得られるとは限りません。
　 　現在 WOLF　RPGエディター（ウディタ）製作・雑談・共有板 に移動した企画もあります。
Ｑ　厨がウザイんだけど…
Ａ　スルーするのが一番です。もしもあなたが菩薩のような心を持っているとしても、優しく導く相手と場所は選びましょう。
Ｑ　〜があったら良いと思うんだけど…？
Ａ　公式サイトの要望スレッドに書きこみましょう。きっと願いは叶います。
　　（http://www.silversecond.com/WolfRPGEditor/BBS_patio.cgi?mode=view&no=95）
Ｑ　非公式ウディコンはいつ開催ですか？
Ａ　不定期に開催ですので誰かが主催者に名乗り出るのを待つか自分が主催者になりましょう。
　　※決して投げ出さない強い心を持っていると良いでしょう。
Ｑ　コンテスト（作品）の感想は書き込んでいい？
Ａ　レビューがある場合はそこへ無い場合はここへ書き込んで問題無いです。
　　ただし、有益なスレにするため「〜の処理が良かった。」など機能に関する感想が望ましいです。
◎まずは、完成させることが重要です。
　完成（仮）→投稿→感想をもらう→修正→完成（仮）→……
　の流れが望ましいでしょう。この流れであればとりあえず作品は完結し作成の軌跡が残ります。
　その軌跡を辿り新たな作品の礎にしても良いでしょ

5 ：

　　　　　　 ／.⌒ヽ
　　　 　 ／　　　　.＼　　　
　　　 ../　　　　　 ヽ.　＼　　
　　　 (./　　　　　　 ヽ.　）　
　　　 /　　　　　　　　l"　
　　 .ﾉ　　　　　 　 　　l　　　>>1乙
　　 l 　●　　　●　　..|　
　　 l　　　一　 　　　　|　　
　　 ヽ.._____ 　 　 　 _,ノ　　
.　　 丿ﾉ　ﾉ 丁丁￣l＼　
　 . く_(__（＿（_._」____）ノ

6 ：

　　　　　　　　　 ＿∧ww∧_　　　　　　　　　 　 　　　　 ＿∧ww∧_　　　　　　　　　 　　　　　　＿∧ww∧_
　　　　　　　　／　　　　　　　＼　　　　　　　　 　　　　／　　　　　　　＼　　　　　　　　 　　　　／　　　　　　　＼　
　　　　　　 ／　　　　　 　　　 　＼　　　　　 　　　　／　／＼　　／＼　＼　　　　　 　　　　／　／･＼　 ／･＼ ＼
　　　　　／　　　￣￣　　￣￣　　＼　　　　　　 ／　　　　　　　　　　　　　＼　　　　 　　／　　　￣￣　　￣￣　　＼
　　　　＜ 　　　　（＿人＿）　　　　　 ＞　　　⊂ 　　　　（＿人＿）　　　　　　⊃　　　＜ 　　　　（＿人＿）　　　　　 ＞
　　　　　＼　　　　 　　　　 　　　　 ／　　　　　　＼　　　　 　　　　 　　　　 ／　　　　　 ＼　　　　 ＼　　　|　　　　 ／
　　　　　　 ＼　　　　 　　 　　　 ／　　　　　　 　　 ＼　　　　 　　 　　　 ／　　　　　　 　　＼　　　　 ＼＿|　　　／
　　　　　　　　ヽ.._____ 　 　 　 _,ノ　　　　　　　　　　　 ヽ.._____ 　 　 　 _,ノ　　　　　　　　　　　 ヽ.._____ 　 　 　 _,ノ
.　　　　　　　　 丿ﾉ　ﾉ 丁丁￣l＼.　　　　　　　　 　　 丿ﾉ　ﾉ 丁丁￣l＼.　　　　　　　　 　　 丿ﾉ　ﾉ 丁丁￣l＼
　 . 　　　　　　く_(__（＿（_._」____）ノ　 . 　　　　　　　　く_(__（＿（_._」____）ノ　 . 　　　　　　　　　く_(__（＿（_._」____）ノ

7 ：

>グラデーション
本体添付のヘルプにはないだけか
公式サイトのヘルプはチェックしてなかったわ
よく考えればこっちの方が更新早いよな

8 ：

エフェクトの描画座標シフトかな？

9 ：

<GRADX-999-274>コレか

10 ：

>>1
乙
>>6
懐かしいｗ

11 ：

999(白)から274(緑)への　X軸方向のグラデーションかな。
ちなみに000だと黒になる

12 ：

どうせなら16進で000000からFFFFFFにすればいいのに

13 ：

久々に>>6を見て吹いたｗｗ

14 ：

公式のスレって何周期でID変わってんだろ
1ヶ月とかそこいら？

15 ：

気が向いたとき

16 ：

回線による
固定の人はずっと固定
だけど、そんなの気にするのは問題発言垂れ流して晒されたバカだけでいいよ

17 ：

すうさんのところの講座読み終わったレベルの初心者だけど、基本システム改造って難易度高いのな…
顔グラをちょっと動かすのすら上手くいかなくて、諦めて顔グラ自体に余白つけて無理矢理位置調整したｗ

18 ：

たとえ無理矢理でも動きゃ正義さ！
自分で代わりの方法考えられるなら解析や対応する力はあるって事だし、あとは触ってるうちに改造できるようになると思う

19 ：

>>17
無理矢理やったみたいだが
理解を深めるためにも「顔グラ」で検索してみることをおすすめする

20 ：

前スレでも言ってた人いたけど基本システム改造より一から自分で組んだ方が簡単だよ
あのいりくんだ内容を一瞬で理解して
理想通りに改造しようってんだからそりゃ難しく感じて当然なんだよ
基本システムとかそもそもマップ空中にウィンドウもなく文字浮かぶだけだったのから
何年も改良重ねて出来上がったものなんだから
それを一瞬で理解しようというのは厳しいに決まってるさ

21 ：

セーブ機能周りも基本システムだよね？
他は自分で都合良いように組めるけど、セーブはちょっとややこしい

22 ：

>>20
その論法だと同等のものを自作するのには同様の年月がかかることになる
改造したいって事は現状の基本システムには不満があるって事だろ？
だったら、さらに時間がかかることになる
初心者にそれを薦めていいのか？
他人のコモンに手を入れるのが難しいって点は同意だが
それをする事でウディタの動作への理解が深まるのは確かだ
だから、とりあえず基本システム改造って手はアリだと思う
すでにRPGとしては動くものなわけだからモチベも維持しやすい
もちろん、あんまり高望みはするべきではないけどな

23 ：

シンプルなもんならそんなに時間かからんよ　あっちはツール部分も手を加えて他の事もやってんだぞ？

24 ：

>>22
基本システムが複雑な理由の一つは、様々な制作者・環境を考慮した作りになってるから
使わない人には無駄でしかない部分もあるし、これが自分の為だけのシステムになった場合かなりスリムになると思うよ

25 ：

基本システムほどきちんとしてなくても無理やり動かせればいいわけだし

26 ：

>>22
さらに時間がかかるかどうかは求める方向次第だろう
仮に基本システムが中央（空データ）から東に30歩進んだものと仮定する
自分が求めるものが南東の方向にあった場合
あとは南に進むだけだから基本システムの位置からスタートした方が早い
（基本システムの改造）
だけど自分の求める方向が西の方向にあった場合
東に進んでる３０歩分が遠回りになってしまう
この場合基本システムを使わない方で
中央（空データ）から進んだ（作った）方が早い

27 ：

>>23-26
レスサンクス
たくさんついててびっくりしたわ
諸兄の指摘はごもっとも
書き方がまずかったのは認める
だから相手の求めるもののレベルが見えない状況だったから
いきなり自作を薦めてもって思っただけ

28 ：

だからは無視してくれ orz

29 ：

基本システム読み解くのは難しいが、作業量は自作のほうが多くなるだろうな
>>26の話はすでにRPGじゃなくてSTGが作りたいとかって人の場合だな
RPGの雛形使ってもあんま意味ないっていう

30 ：

>>26の話って例えは西になってるけど
東に10歩分のシステムならやっぱりゼロから自作した方が早い
って話なんだよね
基本システム2だとコモンが名前呼び出しになっててリカバリも簡単だから
理解が深まるまでは改造でちまちまやった方がいい気はするんだが
作りたいシステムに持ってく過程が余りにも長いとモチベは落ちるわな

31 ：

そもそもアイテムとか元々がゴチャゴチャしてるからな
武器防具道具は一括してしまうだけですごく簡単になる

32 ：

>>30
かりに初心者が作りたがってる物が基本システムに限りなく近かったとしても、
他人のコモンを読み解く　＝　自分でコモン組めるくらいの知識が必要
だから大抵は難易度が自作＜改造になるのよ
基本システムも所詮はコモンであって、ツクールのDBのように変数理解して無くても弄れる簡単な代物じゃないからこそ
「基本システム弄るよりゼロから作った方が簡単だし勉強になる」と盛んに言われるわけ

33 ：

作り方は参考になるんだけど
それを改造する気にはならないわ

34 ：

>>32
難しいな
巡りまわるの近づくと話し声が聞こえてくるシステム
作ろうとしてるけどわりと難しい

35 ：

構造化された実装を読み解く事は出来ても思い付けない人
は結構いる気がする

36 ：

>>34
めぐめぐのは見てない（新verで追加とかされた？）から分からんが
まず頭上に吹き出し表示するイベント作って、範囲拡張したらダメなん？

37 ：

基本システムと同レベルの自作RPGって武神くらいしか思いつかない・・

38 ：

めぐめぐと魔神器もあったか

39 ：

>>35
むしろDB拡張すると細かい点全部弄らんとダメだから基本システムは完全に構造化して欲しい

40 ：

魔神器は当時初めて見たときかなり衝撃的だったんだよね
デフォ素材をあそこまで効果的に活かしたシステムをよく作ったものだと思ったよ
インターフェイスもシンプルなレベルでかなり高クオリティでまとまっていたし
ウディタやVXのようなチビホコグラは好きじゃなかったけど考え方を変えさせられたゲームだった

41 ：

>>40
作者自画自賛乙

42 ：

このスレの20%以上はryuさん信者もしくわryuさん含む多神教だと思うぞ

43 ：

とりあえず自演乙って言っておけばOKでしょ

44 ：

シンボルだかなんだかの成長値上下させるシステムでヘタ打ってクリア断念したけど割と良かったと思うよ
魔剣使いに一番適してるのがデフォルトのノーマルだったとは…

45 ：

>>34
ページを利用して表示すれば良し。
�@起動条件:プレイヤー接触　接触すれば�Aに移動
�A起動条件:並列実行　吹き出し表示。プレイヤーの座標が範囲を越えた場合�@に戻す
ここでポイントは�@の接触範囲より�Aで�@に戻す範囲のほうを広く取る事
これはあくまでセリフ用のMAPイベント。

46 ：

>>45
そういう構造なのか
参考にする

47 ：

全部DBで管理すればえぇやん

48 ：

>>47
残念ながらほぼDBで管理できるが、意外に一部通常変数やらが必要だったりする。と自作システム作っている人が言ってみる。

49 ：

たしかに次元変数的な利用しない限りは通常変数を使ったほうがいいだろうと使い続けて行くうちに
あれ？これDBで管理してほうがよかったんじゃね？
ってことはあることはある

50 ：

>>47
一部通常変数もいらないだろ、特定範囲をチェックするコモン一つ立ててしまえば
そのコモン内の変数使えば済むだけの話あとはDBの設定次第じゃないか
DB内は該当MAP、座標XYもしくはイベントID　吐かせる台詞の設定だけ十分つくれるよ

51 ：

おっと間違えた>48

52 ：

好みの問題だな
管理しやすい方を選べばいい
俺はマップで完結させられる処理はマップでやった方がいい派

53 ：

好みも糞もDB管理の方が汎用性高いのは確定的に明らか

54 ：

動けばよかろうだろ…いやらしい

55 ：

ありがちな最初の森の構造でさえクソ迷ってしまう　ｔｓｋｔ

56 ：

>>53
汎用性高い≠管理し易い

57 ：

・DBで管理できるよ
・通常変数必要じゃね？
・いや、DBでいける
こういう、できる・できないの方法論の話が出ると必ず
好み云々言い出す人間が出てくるのが不思議でしかたがない
使う人間の好き嫌いの話ははじめから論点ではない

58 ：

はいはいDB管理最強
↓次の話題どうぞ

59 ：

>>50
実際に作れば分かるんだけど
セリフを吹き出しする人物の数だけ並列実行が必要だからな
残念だけどMAPイベントで制御するしか無いんだわ。

60 ：

>>59
さすがにそれはないわ
>>50はマップも座標(かイベントID)もDBで管理するって言ってんだから
人物の分だけループ回してデータベースを読めば済む話
>>57
俺はどっちでも「できる」んだから好きな方でやれって言っただけ

61 ：

性能の話をしてるのにWINDOSとMACをいきなり好みで選べって言い出すバカに似てるよね(´・ω・`)

62 ：

どの方法でもできてやり方選ぶだけならそりゃ後は好みになるよ
この方法ではできないって言ってる人がいるけど
そう言う人が存在してることや実際不可能があるかは関係なく
発言者自身が複数方法で可能と信じてるから好みが出てくるんじゃないの

63 ：

>>60
すまん一番大事な「同時に」が抜けてたわ。
何人もが同時に吹き出し表示の場合コモンで制御するのは無理あるだろ
範囲だけ並列実行させてで吹き出しピクチャ表示は呼び出し起動にするつもりか？
吹き出しのピクチャの消去はどうすんだよ。
ディレイで消すつもりか。実際としてうまくいかんぞ
範囲外抜けて消すほうが自然なんだよ。

64 ：

どっちが汎用性高いとかはどうでも良いよ
マップイベントでこういう風にすれば出来るよっていう情報と、
それならDBでこういう風に管理する事も出来るよっていう情報が出ただけで充分
>>63
同時に二箇所以上で喋らせるつもりで話してた貴方と
一箇所のつもりで話してた>>60とじゃそりゃ話が食い違って当然なのに
「ピクチャ消去どうすんだよ」って喧嘩腰に言われても困る
一箇所ならDBでも問題ないんでしょ？

65 ：

複数表示はデータ番号からピクチャ番号決めればいけるでしょ？
消去の方は、表示する際にピクチャ消去されてるかどうかチェックしてる？

66 ：

いや、汎用性の高さの話してるんだけど？

67 ：

つーか　その吹き出しコモンのMAPイベントを複数作るとき元のイベントコピーして量産するだろうから
それコモン化しちゃえば？ってだけなんだがね

68 ：

組み方なんて動けばいいんだから、何でもいいっしょ。
そんな事考える前に完成させたやつが勝者。

69 ：

「できる」「できない」ｎ話になると、どっちでも最終的には「できる」から
じゃあそれじゃ意味がないから汎用性を考えようって話なのに
自分の好みとか何でも良いとかアホだろｗｗ思考放棄すんなよ

70 ：

>>64
そもそも複数だろうが一箇所だろうが不都合はないんだよね
コモン制御する場合、主人公と人物の相対座標求めるんだから、
ピクチャー消去にもそれを使ってやればいいだけ

71 ：

汎用性の申し子かお前はｗ
そもそも出来る出来ないの話で意見が食い違ってたんだから
両方で出来るならそりゃDBの方が汎用性は高いだろうよ
だから汎用性は関係ない、好きな方選べばってなってんのに

72 ：

んや、好みの問題だよ
現実的にマップイベント全く使わず全部DB管理とか可能かも知れんが普通は絶対やらない
それで完成させられる人が他の方法を思いつかないなんてありえない
あえてそれでするのは好み以外の何者でもない

73 ：

>>70
俺の頭だとどういう風にやれば良いとか明確に見えてないけど
やろうと思えば出来るんだな
というか二人で意見してるのかと思ったら
マップイベントでしか無理だと勘違いしてた人と、
DBでも出来るけどマップイベント派っていう人と
DBのが楽だからDBが良いよって人がいたんだな

74 ：

>>71
お前はくりしちゅの上田かｗ

75 ：

プログラマーorスクリプターってのは合理的に概念を構造化する生き物であるべきなのは明白で
そこに好みとか何でもいいとか不確定要素を選択する人はプログラミングには向いてない
わりとマジで
あとマップイベントと通常変数とDBで話がごっちゃになってるのは秘密な

76 ：

全てコモンとDBでやれよって奴はオブジェクト指向派で、
通常変数使えよって奴は「実はオブジェクト指向ってしっくり来ないんです！」派だな

77 ：

>>75
Perlの理念とか見るとそうでもないよ

78 ：

そろそろ2.01出してくれんのかな
結構目立つバグが溜まってきてるんだが

79 ：

>>75-77
まじめに考えることができるやつがプログラマーになるのはほんとに勿体無いよ
数は高卒と専門に履いて捨てるほどあるしな

80 ：

>>75
それってどの点を合理的だと捉えるで変わらないか？
ウディタの場合、コモンの構造を合理化するのも大事だが、
シナリオ部分の作成効率を合理化するのも大事だと思うぞ？
今回の場合、
シナリオが本来受け持つ部分までDBに背負わせることになるわけで
作業動線はどうしても悪くなる
マップイベントをコピったり削除したりするだけで済むところが
DB操作しなくちゃまともに動かないなんて効率悪いだろ？

81 ：

お前ら話食い違いすぎワロタ

82 ：

みんな自分の考えてる議題で他の人も話してると思ってるからね

83 ：

そもそもどこがこの話のスタート地点なのかから食い違ってる

84 ：

>>45「こういう方法があるよ」
>>47「（どうせコピペで増やすなら）DBでええやん」
>>48「通常変数必要じゃね」
>>50「いんや、DB次第っしょ」
>>52「好みの問題」　←（？）
有意義な技術面の流れを「好みの問題」と相対主義的な考えで
バッサリと断ち切るのは本当に勘弁してほしい
DBの方が良いという意見に反論があるなら最初から>>80みたいな反論をすればいい
好みの問題と論点を変えてしまうからややこしい

85 ：

>>84
>>34の結果を>>53であなたが宣言したようにDB管理で組むと想像してくれ
実際に組まなくていいから、どういう方法で実現するつもりなのか説明して欲しい

86 ：

好みの問題って言ってる人は>>34に対するアドバイスの締めとして言ってるのかな？
まあその先の議論をする事を止める必要もないさね

87 ：

方法については>>50までで答えがでてる
好みの問題はできるようになった人が自分で判断すればいいってだけだろう
>>53で汎用性のはなしがでてきておかしくなった

88 ：

>>87
うん、だからだよ
汎用性のこの人が他人に説明できる程度に理解できてるのか物凄く気になってる

89 ：

俺の発言が発端なのは自覚してた
暇すぎていろいろと構いすぎたすまん
言いたい事は>>87が言ってくれてるのでもう黙る

90 ：

盛り変えすんだが
好みうんぬん汎用性うんぬんじゃなく
並列実行コモンでのDBから読み込んでループしての一括管理は無理。非現実
まず"個別"のフレーム管理が出来ないじゃん。
範囲外に出て消してすぐ範囲内に入っての表示は不自然だから間隔をあけるだろ。
個別に並列イベントを作っておけばページを戻す直前にウェイトをいれたら済む話だけどどうすんの？
ゲーム内の時間やイベントのフラグによって内容変えたいと思うだろうけど
条件分岐作りまくって対応させんのか？ページ増やせば済む話なんだけど
実際に作るともっと粗が出るだろうよ。
視覚的な管理のしやす、負荷、仕事量、拡張性からの観点からみても駄目だろ

91 ：

おまそそおまなか

92 ：

そんな略し方初めて聞いた

93 ：

>>88
こういう表示をしたい、という話でAとBの処理方法があるという話が出ました
(↑この段階で>>34への答えは終了)
誰かはAがやりやすいと言いました
誰かはBがやりやすいと言いました
どっちが使いやすいの？と誰かが聞きました
誰かは人によると言いました
誰かは好み次第だよと言いました
(でもそれだと納得しないようです)
好みの話は>>34には言ってないよ　話ごっちゃにしてないか？

94 ：

>>87
＞好みの問題はできるようになった人が自分で判断すればいいってだけだろう
そのとおり、自分で判断すればいいだけだ
>>52は各人が自分で判断すればいい事をわざわざ言及するから不自然なの
要するにID:6jezSpm0は本音ではDB云々に反論したいわけだ（実際>>80で反論してるしね）
「俺はマップ派」とか付け加えてるのがいい証拠
>>85
コピペ基本で、必要に応じて雛形改造じゃ一つの変更で作業量が膨大になる
DBならタイプ数増やして専用コモン弄ればそれで済む
これを汎用性が高いと言っとるの

95 ：

とりあえず複雑に捉え過ぎて頭がパンクしてるのはわかった

96 ：

とりあえずこの流れみて
これからウディタやってみようって思う人はいないだろーね
こうしてますますニッチ化が進行していく、と

97 ：

>>96
ニッチ言いたいだけだろ

98 ：

２ちゃんの専用スレ見てからソフト使ってみようって人も少ないと思うけどな

99 ：

別にニッチ化とやらでもいいじゃない
使いたい奴が使うさ

100read 1read

1read 100read

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