TOP カテ一覧 スレ一覧 100〜終まで 2ch元 削除依頼
ZUN
（・∀・）RPGの基本世界設定（・∀・）
こんなツールがほしい！
絵が描けない人間が素材を作るスレ
【25周年】ロックRレクションを作ろう
■吉里吉里／ＫＡＧ／ＴＪＳ雑談質問スレ■その31
ネトゲの作り方
ゲームクリエイターの人格って・・・
マザー2.5を作ろうぜ！
今年はプログラムを勉強してみるよ
【CGI】ゲームつくってるんだけど【RPG】
- 1 ：2015/02/14 〜 最終レス ：2017/12/31
- アドバイスくれ
ダウンロード不要
http://cron-quest.appspot.com/server/title.cgi
- 2 ：
- げ、スレ立てミスった これノーカンね
- 3 ：
- vipのスレ落ちてしまった(´･ω･`)
- 4 ：
- ノーカン？
- 5 ：
- ノーカウントの略
- 6 ：
- vipにスレ立ててもすぐ落ちるからこっちでやるわ
- 7 ：
- くそつまらん
何を作りたいのかさっぱりわからんしもっと作りこんでから出直して来い
- 8 ：
- ここからだらだら適当に作りこんでいくのさ アイデア募集
- 9 ：
- ただいま装備システムは作りかけだ
使えるのは回復アイテムだけ
あとゲームが更新されてもURLは変わらないが、ここで何が変わったのか告知するよ
- 10 ：
- 仕事たまってて今月は進みそうにない（・３・）
- 11 ：
- 画面サイズを1024x768から800x600に小さくしたんだが、解像度はこんなもんだよね
- 12 ：
- スマフォ前提にすればもっと小さくコンパクトに済むぞ
- 13 ：
- スマホはもっとでかいけどな
- 14 ：
- 画面は大きいほど、たくさんの項目を表示できるんだが
画面が大きいほど、小さいスマフォを切り捨てる必要があるのだ
画面の縦幅をもっともっと長くして、縦にスクロールしてもらうというのも
昔のCGIゲームではよくあったと思うが、操作性が悪くなりそうで悩むところだな
- 15 ：
- >>13
解像度は上がってるけど scale の概念入ってるから、
iPhone6 の 1080x1920 でも、制作コンテンツのサイズは 414x736 でしかないよ。
フォントのレンダリングや高解像度画像が精細に描画されるだけ
- 16 ：
- 解像度が大きくなってもスマフォ自体は小さいから１ピクセルが小さくなるのね？
そうなると２つの選択肢があるな
・拡大表示される前提で解像度を小さくしてフォントやUIも小さくする（スマフォ向き）
・縮小表示される前提で解像度を大きくしてフォントやUIを大きくする（PC・タブレット向き）
どちらにせよ、画面レイアウトはせまくなるんだな
- 17 ：
- ▼戦闘の処理を修正した
主人公１０ターン連続攻撃 → 敵１０ターン連続攻撃みたいなのが頻発したので、
主人公と敵が交互に攻撃するように、乱数の偏りを抑えた
- 18 ：
- つまらなすぎて死ぬかと思った
せめてflashで作ろうよ
- 19 ：
- Flash/Flexを先月別件でやってて丁度いいから使いたいんだが、
Android/iPhoneで動かなくなったらしい
GWTを使うか他に良い方法が無ければJSを直接書く、
もしくはモバイルを切り捨てる
- 20 ：
- Haxeとかどうだ
- 21 ：
- Haxeは未経験だが面白そう でも気をつけるべき問題点は幾つかある
まずFlash AS3で試した感じ、IDEのFlashDevelopは作りが悪く、
コード補完はEclipseの半分も効かない、あと最新版は有名なバグもってて
コンパイル前に毎回コンパイルキャッシュをクリーンする必要があり、面倒くさい
（これは我慢できる）
もうひとつは、Haxeは複数のプラットフォームに出力可能らしいが、
Haxe自体の開発・サポート・運営状況などを一通り調べておく必要がある
Flash出力は力を入れているが、JS出力は5年以上放置されているとかあるとまずい
APIリファレンスもちゃんとしたのがあるのかも気になる
でも面白そうだから、下調べの結果次第では採用してみるよ
- 22 ：
- うーん…10年以上前にCGIでRPG作ってた（利用者数はユニーク数千人程度）けど、
今はHTML5も発達してるんだしCGIで作る必要を感じないなあ…
とりあえずUIを全面的に見なおして、処理部分もいちいちダルいのでなんとかしたほうがいいかなと思う
- 23 ：
- 課題はたくさんあるな まずは何からやっていこうかしらん
- 24 ：
- >>16
PC・モバイル環境両方で同じゲームをやるのかという疑問はさておいて
両方にやってもらいたいって言うならレスポンシブデザインにでもしたらどうかな
後やはり一操作ごとにページ移動が挟むのはあまりにも作りが古く煩わしい
ブラウザにやらせる処理量としてもユーザの視覚的な意味でもよろしくない
古いブラウザゲーを想起させるノスタルジー狙いでもない限りはDOM操作にでも変えた方がいいのではないかと思う
- 25 ：
- 画面遷移についてだが、Ajaxでシームレスに通信するのと、
サーバーとやりとりしないでクライアント側で全部やる２つの方法どちらかで解決できる
たぶん最終的には後者でflashゲームみたいにするから、HaxeとかTypeScriptを調査している
レスポンシブデザイン、モバイルは縦長画面とかは保留（余裕があればやってみるよ）
その辺は製作がある程度進んでからやらないとゲーム仕様の変更に対応しずらい
俺的には、ゲームの進行とかパラメータを考えてから操作性とか見た目を整えたい
いまのところ、とりあえず1ダンジョンでザコ敵を殴るだけ何とかできたって感じで、
目的とか他にすることなんにもないしな
- 26 ：
- altJSはTypeScriptがかなり有力らしい
でも未来のなさそうなHaxeの方がずっと作りが優れている
標準SDKにCanvasとWebGLのバインディングも含まれていて面倒な環境設定もゼロだった
ただし公式APIドキュメントが真っ白なのが後々ネックになりそう
それでもフロントJavaScript化するならHaxe使うと決めたぜ
- 27 ：
- HP(パラメーターの方)はどんどん減っていくの？
配布してみれば？
- 28 ：
- いまのところ、アイテムで回復するか、死亡すると全回復する
前にvipでスレを立てたとき、「宿屋を作らずに、時間の経過で回復する」
という案を誰かがだしてくれて、そうしようと思うのだが、それにはまず
セーブ機能が必要だな
配布するというのはブラウザゲームでなくすということかな？
ブラウザゲームのままでもセーブ機能を作るのはそれほど手間ではないよ
まずはデータベースを使わずに、クッキーにデータを全部突っ込むんだ
データベースが必要になるとしたら通信対戦とかなんだろうけど、
流石にそれはまだまだ先のことになるな
- 29 ：
- 書き込めん
- 30 ：
- Herokuを調査した かなり使いにくいことが分かった
しばらくはGAEの無料枠を続けることにした
- 31 ：
- レスポンシブデザイン云々という話もあったから
とりあえずモバイル用の320x480画面を用意してみた
（俺、いまだにスマフォもってないからサイズ比率とか分からん）
システムとかUIは、大画面（PC/タブレット） or 小画面（スマフォ）で
片方がある程度できてからもう片方に対応したい
それでPC向け画面を先にやるつもりだったけど、
逆にスマフォサイズを先にやった方が、
テストしてくれる人の環境を選ばなくて良いかも！
http://1-dot-cron-quest.appspot.com/mobile/index.html
- 32 ：
- まずシーン構成とそれぞれの画面でのメニュー項目を考えて配置することを考えたほうがいいかもね
すごく小さなものでいいから、遊べる状態にしたものを完成させてみたほうがいいかと思う
ゲーム内容によるけどブラウザゲーの場合はスマホへの対応は大して難しくないので、
そこは今はまだ意識しなくてもいいと思うよ
- 33 ：
- あと、オンラインで交流する要素もないので、localStorageかCOOKIEでデータ保存させる場合は、
ユーザー名とパスワードでの登録はやめたほうがいいと思う
パスワードなんていちいち覚えてないという人も多いし、
登録作業があることでプレイしやすさの印象が変わります
サーバー側でデータを保存する場合は、ブラウザ毎にユニークIDを割り振って、
もしデータの移行の必要がある場合はデータ移行用のURLを発行したほうがスムーズかと
まあ絶対にダメというわけでもないので、参考程度に
- 34 ：
- 開発環境とかが二転三転していて、なかなかゲームの内容に進めないぜ
- 35 ：
- この状態で迷ってるんじゃ完成は無理だな
- 36 ：
- 怨念乙
- 37 ：
- >>33
＞ユーザー名とパスワードでの登録はやめたほうがいいと思う
たしかにセーブに使ってないから消しとく
名前はとりあえず"主人公"に固定する
- 38 ：
- 自作ＵＩの練習中、DOM APIでいくか、Canvas APIでいくか見当がつかん
http://gyazo.com/d922f2beedbb290109fe89cc659e0f08
とりあえず旧方式のまま、ＰＣ向け画面のロジックを土日あたりに進めてみっか
- 39 ：
- 将来的にでもスマホ対応を考えてるなら、マルチウィンドウはあまり必要なさそうには思う
- 40 ：
- お絵描きはこの辺で一端打ち切り
http://gyazo.com/850694456542e663d7ca536eee510864
- 41 ：
- 成果としては、色合いに見当がついてきたところかな
絵が無い場合、明るい画面だとますます殺風景に見えるんで黒いスキンでいこう
あるいはフリー素材を使うほうが無難なんだろうけど、
芸がないからあんまり使いたくないんだよね
http://gyazo.com/3812c82433769501c160e9c28f8a0991
- 42 ：
- タイトルページだけ更新
before
http://gyazo.com/c18ad1d7fd4fafcfacb313fbf6e58eb2
after
http://gyazo.com/346302251a2dccb1f55f4cdc65a279cc
- 43 ：
- ▼更新
・登録ページを削除した（タイトル→町）
・町のデザインを変えた
before http://gyazo.com/c39bd897fde32261f5ff105012f4bdfb
after http://gyazo.com/a49c975acf8a6e752e90f47f81b3538f
- 44 ：
- >>39
お店の商品を並べるとき、たぶんスクロールバーが必要になる
- 45 ：
- ブラウザのＣＳＳキャッシュで古いデザインで表示されて
どうしようかと思ったけど、一度F5押したら直った
HTMLにはキャッシュしないように書いたのだが、やっかいよのう
- 46 ：
- 今日はスキンの置き換えだけで終わってしまいそう
小さなことだけど、結構面倒くさいのよね
- 47 ：
- >>44
スクロールバーとマルチウィンドウの問題は全く別だよ
- 48 ：
- ▼更新
全部のページのスキンの更新完了
ゲームロジックはまた来週にもちこし
- 49 ：
- 操作性がダルいのはFlashとかJavaScriptにしても変わらない気がするんだよね
ゲームパッド無しでRPGとかやってられんな
- 50 ：
- >>49
そりゃ単にお前の操作に対する概念が固定化してるからだろ
いちいちサーバーサイドで処理するのとローカルで処理することのレスポンスの違いに対して
インターフェースの問題を持ってくるというのは筋違いもいいところ
- 51 ：
- むしろゲームパッドのほうがだるい
スマホみたいな操作性ができるといいね
- 52 ：
- 家庭用ゲーム機しかやらないからＰＣ・モバイルゲーム研究したほうがいいかもな
でもゲームにハマって戻ってこない可能性があるからやめとくぜｗ
昨日思いついたんだが、ダンジョン・戦闘だけ放置ゲーっぽくしようかなと思ってる
30秒操作しないと勝手に行動を選択してしまうシステムとかどうよ？
- 53 ：
- とりあえずＵＩをもう少し整える
- 54 ：
- >>52
というか、もしサーバーで処理させるなら、行動選択部分をばっさりカットした方がいい
ユーザーにはストレスにしかならんし、
なるべく送信→結果の手順を少なくしないと、サーバーの負担が洒落にならなくなるよ
なのでFlashやhtml5でやった方がいいのよ
スマホ対応する気ならhtml5一択だけど
待機時間設けて勝手に行動選択よりも、行先だけ選んで結果を表示するくらいほうがいいかもしれない
- 55 ：
- ▼更新
背景に画像をおく実験中
背景は真っ黒の方がむしろ洗練されている感じがするな
http://gyazo.com/a49c975acf8a6e752e90f47f81b3538f
http://gyazo.com/1aa1037d5776ee26b1fdf24f00d8118b
http://gyazo.com/d35028d27d6a42bda298b43a2c2f3f4a
http://gyazo.com/4ac3b44ac3d761f0c4e2b6d4ca517682
http://gyazo.com/899b1a9c921947e9c58c6804cc23c847
- 56 ：
- >>54
javascript化しても雑魚連戦でクリックかちかちやるのはだるそう
特にボタンが左側にあると操作性が悪い
＞待機時間設けて勝手に行動選択よりも、
＞行先だけ選んで結果を表示するくらいほうがいいかもしれない
昔のＣＧＩゲームだと1日1回だけとか30分置きに探索できるとか
アクセスを減らす要素が含まれていたけど、そーいう話なんすかねえ
- 57 ：
- >>56
サーバーサイドで処理する場合、単にCPUの負荷の問題もあるけど、
同時接続数制限も考えないといけないのよ
クリック数が多いことによる操作性の悪さはシステムとUI設計の問題なので、また別なのさ
もし俺が作るならブラウザゲーでクリック数多いようには設計しない
>昔のＣＧＩゲームだと1日1回だけとか30分置きに探索できるとか
昔の場合はサーバーのスペックの問題もあるんだけど、
俺の「結果を表示するくらい」っていうのは必ずしもそれだけじゃなくて、
サーバー側で処理をしたら、結果表示にウェイトを設けて、
いかにもリアルタイムに処理しているかのように見せるような手法も含んでの話ね
つまり、「○○はXXを攻撃して▲▲のダメージ」みたいなのを一気にずらずらと表示するんじゃなくて、
受け取った結果を１つの行動毎に区切って表示してアニメーションさせれば、
ユーザーから見るとその場で処理されているように演出することができるわけね
- 58 ：
- >>57
なるほど、話が飲み込めてきた
その場合、トレードオフとしてダンジョンや戦闘時の細かい戦術などは操作できず、
町で道具などをそろえて、あとはムービーを眺めているだけのゲームになるわけね
少し前にB100っていうフリーゲームやってたんだけど、
あのゲームはそこんところよく考えて作られているんだな
- 59 ：
- >>58
そうそう
簡略化するための手法の一つなので、どこまでやるかは自分で決めればいい
ただ、ブラウザゲー、特にCGIゲームの場合は、移動や戦闘時のコマンドを
逐一受け付けて処理するのはあまり向いてないかなとは思う
- 60 ：
- 考え中
ムービー化にはモンスターやエフェクト、効果音の素材にしっかりしたものが
必要不可欠で、素材関係で行き詰る可能性があるんだよな
難しい判断だ
- 61 ：
- アニメーションっていうのは、そこまできちんとしたものじゃなくていいんだよ
攻撃のエフェクトと、モンスターまたは画面が揺れる、
またメッセージがスクロールしたりウェイトを置いて更新するというのも立派なアニメーションの一つなので
ただ、エフェクトが１種類しかないとやっぱり寂しいし、
モンスターの種類もなるべく多いほうがいいというわけで、
どうしてもこだわりがあるというのでなければ、無料素材を使うケースが多くなる
- 62 ：
- フリー素材を見てたんだけどね
やはりモンスター素材を導入するとフリー素材の場合、
製作に柔軟性がなくなって素材の都合に縛られるのが嫌だな
（サイトごとに絵柄の違いとか考えるとすごく限られてしまう）
テキスト主体のゲーム＋モンスター描かれた背景スチル（固定1枚）とかで
なんとかならないかなと思いつつ、既存ゲームを調査みるわ
- 63 ：
- 描けるなら自分で描いたほうがいいと思うよ
フリー素材ってだけでやらない人も多いしね
そこらへんは時間などもみつつ配分すればいいんじゃないかな
- 64 ：
- モンスターは戦闘時に揺らしたり傾けたりすればいいので、一枚で全然大丈夫だよ
なんならダメージ与える毎に画面フラッシュでも特に問題ない
- 65 ：
- そうか。スライムでもスケルトンでも何でもドラゴンの絵ひとつで済むならそれでいこうかな
- 66 ：
- 一枚絵って意味だけど、それでいきたいなら別にいいんじゃないか
お前のゲームなんだし
- 67 ：
- やったけど、RPG愛がまったく感じられないな・・・
プログラムとか以前の問題では。
- 68 ：
- Canvas APIで置き換え中（時間かかりそう）
- 69 ：
- 正直なところ、サーバー側で全部やって、javascriptは使いたくなかったんだよね
それを前提にした自作ツールを使ってゲームを作ることが企画の意義のひとつだったのだ……
- 70 ：
- サーバーサイドで全部やるのも自由だろ
効率的ではないし演出も限られるけど
- 71 ：
- 安いタブレット買ってきた（Android Nexus7）
ＰＣとたいして変わらないと思ってたが、
横にしたときにディスプレイがかなりワイドなんだな
解像度の縦横の比率はもうよく分からないから、
とりあえずプラットフォームはPCのみでやる
あとタブレットの操作感としてはボタンの感度がいまいち良くないね
ボタン画像が大きくても操作性が悪いという話はここからきているのかな？
- 72 ：
- タブレットの件を訂正するよ
横に長いのではなく、横向きだと画面サイズ以上にスケール（拡大表示）するみたい
逆に縦向きだと画面内に収めようと縮小表示される
従ってタブレット/スマフォでは縦向きＵＩでデザインしないといかんのだと思う
- 73 ：
- まずviewportとかを勉強した方がいいかもね
もし画面をスクロールしないのが前提なら、正直縦持ちでも横持ちでもどっちでもいいよ
スクロールする前提なら縦のほうがいい
ボタンの画像が大きいからといって操作性が悪いということにはなりません
他のゲームを色々やってみるのがいいかも
- 74 ：
- >>73
viewportタグがあるんだね。おかげで謎が解けたよ
initial-scaleを設定すると横長状態でも拡大されなくなって
画面内にすべてが収まるようになった
＞ボタンの画像が大きいからといって操作性が悪いということにはなりません
そうではなくて、通常ならボタンが大きければ押しやすくて操作性が高いはずなんだけど、
タブレットの感度が悪いからボタン操作自体の数を減らしたほうが良いのかなと思ったのだ
こちらの買ったタブレットが2年古いモデルのアンドロだから、iPadとかだとまた違うかもしれんね
- 75 ：
- >>74
操作性とデバイスの問題はまた別なのさ
そのデバイスでレスポンスが悪いからということで、操作性が悪いということにはならんわけね
操作性が悪いという場合は、単にUIデザインや処理工程の見直しを考えたほうがいい
たとえば、今動かして見てないからわからないけど、
多分サーバーサイドで全部を処理しようとすると、
メイン→装備ボタン→装備一覧→装備決定とか
メイン→クエストボタン→クエスト一覧→キャンセルしてメインとか、
その辺りの画面遷移もサーバーで処理して応答して…となると、無駄が多いわけね
それならメイン画面内に装備画面やクエスト画面も同時に仕込んで非表示にして、
装備ボタンを押した時に装備画面に切り替える、
クエストボタンを押したらクエスト一覧に切り替えるといったようにするのがまだベターなのね
なので、処理工程を減らすのは「ボタンの反応が悪いから」ではないということです。
スマホ用にもブラウザゲーが出てる（古い方のNexus7で十分動く）から、
それらをやっていいところ、悪いところを考えていくのがいいと思うよ
- 76 ：
- >>1が羨ましい
俺もこういうの作ろうとしてクライアント側がHTML 5+JavaScript,サーバー側がJavaのものをwebソケットで繋げて動かそうとしてるんだけど全然webソケット動かせない
- 77 ：
- >>76
サーバー側がJAVAでソケット開くなら、リアルタイム要素があるってことかな？
どの程度の規模を想定しているかにもよるけど、いきなりそこから入るとしたら厳しそうには思うな
- 78 ：
- そうそう、リアルタイム。まずリアルタイムチャットを作ろうとしてwebソケットで挫折
http://tyrano.jp
このブラウザアドベンチャゲー風の開発環境で交流重視の似非RPGチャット作ったら面白いんじゃないかなと思った
この開発環境のJS上で敵と殴りあうバトルも一度作ったからRPGにすることも充分できることは確認済み
仕事でwebソケットを使ったJavaにも触れているからいけるはず、と思ってたんだけど一から作るの難しい
入門サイトの「ね、簡単でしょ？」感についていけない
- 79 ：
- 非リアルタイムでもいいから、サーバー側の処理システム自分で設計して作ったことはある？
しかし、ティラノって結構色々できるんだなあ
わりとつかいやすそうだね
- 80 ：
- 変わったもの作ってるんだね
websocketで問題あるなら定期的にクライアント側からajaxリクエスト投げたらいんじゃね？
- 81 ：
- こっちはポストバックという方法でやっていたんだが
タブレットだと同じ自宅無線wifiでもＰＣと比べてめっちゃ遅いな
- 82 ：
- タブレットでフリゲを遊んでます(^q^)
よくあるインフレＲＰＧで、まあこういうのを作るのが無難だということですな
……何かひとつ変わったものを作りたくなってきた
- 83 ：
- あまり関係ないが、GAE無料枠でアップローダーをつくっていた
そっちはもう少しで完成する
- 84 ：
- よしとりあえず最低限できたので完成ということにして
またゲーム製作再開するぜ
http://direct-links.appspot.com/upload/index.html
- 85 ：
- 今日は久しぶりに進めたけど次の更新までまだまだかかる はあ〜
- 86 ：
- >>76の人は動くようになったのかな？
web.xmlがServlet3.0以前だと3.0以降のAPI(WebSocketとか)が動かなかった気がする
こっちはGAEでManaged VMの設定をして最新のjava8を動かそうとしたけど遂にできなかった
java7+servlet2.5でも困るわけじゃないが時間が無駄になるとがっくりするよな
- 87 ：
- タブレットで拡大・縮小率がおかしいのは、スケールをこっちで操作するのではなく、
ＣＳＳの構造を変えたら直った
ちょいと"インフレＲＰＧクエスト"というゲームにハマってたんだけど、
俺はもう少し世の中の流行に逆らって変わったことをすべく調査中
- 88 ：
- ちょっと更新した
これといってアイデアも出ないし、昔の作りそこないもろもろを再利用して適当に作るわ
あとjavascriptはhaxeを使わずに直接書くことにした
- 89 ：
- ☆ 日本の核武装は絶対に必須ですわ。☆
http://www.soumu.go.jp/senkyo/kokumin_touhyou/index.html
☆ 日本国民の皆様方、2016年7月の『第２４回 参議院選挙』で、改憲の参議院議員が
3分の2以上を超えると日本国憲法の改正です。皆様方、必ず投票に自ら足を運んでください。
私たちの日本国憲法を絶対に改正しましょう。☆
- 90 ：
- せっかくsageてたのに
- 91 ：
- こっそり再開中。店とか装備選択画面てめんどくさいのな
やる気しないときは簡略化システム考えるほうがモチベ的によさそう
- 92 ：
- URLの末尾を少し変更(.cgi->.html)
そもそもサーブレットはCGIと関係ないしな
http://cron-quest.appspot.com/server/title.html
- 93 ：
- これはクライアントサイドで処理しないとどうにもならんわ
画面遷移がうざすぎる
- 94 ：
- どうしたものかな。Haxe+CanvasAPIとかも考えたけど、結局面倒くさくなって放置だし
- 95 ：
- とりあえずこのまま続行ということで
そのうち誰かにガラっと作り直してもらうさ
- 96 ：
- 変な時間に眼が覚めてしまったのでちょい作業
上の方で自動戦闘にするという案を出してもらったけど
どうせJavascriptやクライアントで書き直すなら普通のコマンド戦闘がいいな
まずはザクっと叩き台をつくらんとね
- 97 ：
- 対戦とか協力プレイを考えたらネットワークの都合上、
クライアントソフト化は不可避かもしれんね
html5でサーバー介さずにクライアント同士で通信できたような気もするけど
- 98 ：
- 地味に更新した
- 99 ：
- >>92
BGMは無いわ、淡々と進むだけだわで、
まるでゲームブックをわざわざパソコンでやってる感じで
すっげーつまんねーけど、
遥か昔はこんな感じのゲームでもみんな楽しんでたんだろうなあ
と思うと許せるわ。
- 100 ：
- まあ作り直し前提ということで大目に見てちょ
昔の定期更新型RPGとかボードゲームも意識していたけど、
そういうのは諦めたほうが良さそうやね
100〜のスレッドの続きを読む
超能力開発ソフト「マインドシーカー」
enchant.js
ゲームエンジンを作る
オリジナル格ゲー作ろうぜ！！！
ゲーム作ろう
【ストア】ステマ業者と登録料ビジネス・2【stema】
cocos2d-x Part2
コンソールゲーム
廃人から立ち直るためにゲーム製作
【UD→BOINC】ゲーム製作中にがん解析4【@gamedev】
--------------------
【訃報】「ＫＡＲＡ」元メンバー ク・ハラさん死亡 自殺か 東日本大震災直後、個人で1億ウォン寄付と韓国事務所当時発表 ★12
LPGA of JAPAN 日本ツアー 305
しんのすけみたいに、スロ板版108のレバーON奥義作ろうぜ！
【朗報】 チーム8 鈴木優香ちゃん、聖夜にコスプレえちえち オパイ配信をしてしまうw w w w w w w w w w w w w w w w w w w
【まったり専用】あんさんぶるスターズ！避難所 Part.5【愚痴禁止】
シューグー
Blythe総合 1159体目
＊＊＊SP単発ドラマ総合スレ24＊＊＊
【全てが】コストコ好きな奥様173【特大】
【さらば白塚&深尾】十両互助会第4席【基内閣へ】
なんJパチンコパチスロ部★491
つーか、OSってつくれないのか?
●●●この動画の今江３●●●
「 高すぎるだろクソが！！」と思いながら買っているもの [324064431]
【中国ドラマ】トキメキ！弘文学院
〓〓（モツ）煮込みの旨い店２〓〓
【パヨクそっくり】韓国、反日運動が自分達のクビを締めていることに気が付き、「反安倍」運動にシフトwww
懐かしのドリフコント（鉄道ネタ限定）
スーパーボウル観戦オフ
スター・ウォーズ Episode9 スカイウォーカーの夜明け Star Wars: The Rise of Skywalker 83
TOP カテ一覧 スレ一覧 100〜終まで 2ch元 削除依頼