企画書も仕様書も作らないでゲーム製作って…

何考えてるの？

2get

行き当たりばったりなゲーム製作もいいじゃない

個人なら別にいいがな。

他人に頼らなきゃならんほど落ちぶれてない

他人に迷惑かけなければな。
というか、企画書も仕様書も電子データで良いじゃん。

今どきは、ゲームは金にならないんだから、
好きなようにやらせてやれ。

３ＤはもうForzaとグランツーが競ってればよくて、
その他のものは２Ｄで十分なんだな。

個人製作が多いこの板で何いってんだろうね>>1は

企画書も仕様書も頭の中にちゃんとあるさ。
出力？誰にみせるんだそんなもの。

仕様書かかないと途中で
「あーあそこ、こう書けばよかった」ってのが続いて１からやり直したくなる

１からやり直せばいい

釣り針が小さいな

プログラムソースが仕様書だ。

べんりな　よのなかに
なったものよのう

３日もあれば完成するミニゲームにいちいち仕様書なんていらんでしょ？
長期間かかるゲーム？
そんなもんこの板の住民がつくれるわけないだろ？

大規模ゲーだとしても個人で作る分には仕様書なんていらんし
作ってる時間自体がムダだ。
多人数プロジェクトはやる気のないやつばかりで仕様書があっても成功しない。
だいたいゲーム作る前から仕様書おこせるやつに仕様書は要らない。
あとから仕様を確認するために必要？誰が確認するんだよ？

よって仕様書はいらない。

仕様書があれば成功するという事は無い。

仕様書があれば、少しは身が安全なだけだ。
（身の安全　≠　成功）

仕様書があればプログラムを完成させられるとは限らないが
プログラムを最後まで完成させられない奴はたいてい仕様書を書いていない

ゲーム会社でも仕様書なんて言い方するんだな知らなかったわｗ

普通に言うと思うぞ、仕様って。

ゲームとは言えソフトウェアに変わりはないし
設計だって必要なんだからさ。

まあ、本能や脊髄に依存する分、
仕様変更の頻度はすごいだろうけど。

ゲームの仕様書は作るけど、関連するプログラムの仕様書はソースコードと一体化させるだろ、今時は。
ビジネス系ではまた別かもしれないが。

仕様書と覚書きみたいなメモって同じなの？別物？

一人プロジェクトでやってる場合は覚書はそのまま仕様書になるが
複数人だとルールの共通化が必要なため本人しか分からない覚書程度では要件を満たさない

>>10-11
1からやり直すのもまた勉強になるよな。
ど〜ゆ〜状況で1からやり直すべきかが、だんだん分かってくる。
まあ、変更前のデータは常に残す必要があるけどな。
あと、小まめなモジュール化やオブジェクト化も必須だな。同じ
状況が発生した場合に同じデータが使い回せるようになってくる。

サヴァン症候群の人だと仕様書要らないのかな

>>24
関係者が全員サヴァンならいらないかもねｗ

関係者が全員サヴァンならコミュニケーションが不可能な気がする

「一週間で判る・サヴァンと仕事するためのたったの2e256箇条」

技術的な観点から、よりゲームを面白くする内容を提案するのは大歓迎。
仕様書をみたせばいいなんて後ろ向きなことは、Windows用のビジネスアプリ書いてるようなろくでなしに任せておけばいい。
ゲームプログラマはアーティストなんだ。

だから完成しない商品が多いんだなｗ

全部のゲームが完成してたら大変なことになるよ
９割以上が未完成で終了するからこそ
完成したゲームが多少くそでも尊いのさ
仕様書なんかいらない

ToDoリストって仕様書なの？

なんでそう思ったんだい

最近はキャラとマップだけ変えて
あとはおんなじなゲームが多いらしいから、
仕様書や企画書は、既存のものを使いまわしてるのかねぇ？

ノベルなら、仕様書がなくても、シナリオがあれば作れるんだろうね。

そういう経営者は多いよ。
シナリオとCGと音楽が出来たらゲームが完成すると思っている人。
もうね、アホかと。

ノベルのプログラミングなんてすぐ完成する

>>34
俺はそれでよかったなぁ
むしろ、それができてない会社のゲームって買いたくない
ここ数年でそれをキチンと守ってるのってテイルズぐらいじゃない？

>>35
完成させるだけならな。UIとかエフェクトとか凝ったことを始めるととたんに面倒臭くなる。

いくらシナリオとCGと音楽がよくても、UIが酷いとか、ロードの嵐とか
ロード時間長いとか、バグ満載とか、フリーズ多発じゃどうしようもないもんな

小さいことでも手抜きが積み重なると、プレイやめたくなるほどのストレスになるし
細かいところまでつくりこむと、それだけでも時間かかったりすると思う

うんげ

仕様書や企画書とか
全部俺の頭の中に入ってるから問題ない

進捗状況表ぐらいは作った方が良いのでは？

自分のやりたいやり方でやれ

人に仕事を頼まないなら要らないな。

自分のための備忘録でいいなら文字通り備忘録で済むしな
ドラッカーブームに毒された人とかなら自分用進行管理表作ってウダウダやってるのかもしれないけど

他人を巻き込むのに企画書も仕様書も作らないから問題にしてるんでね？

まあ、作らないんじゃなくて、妄想が甘すぎて作れないんだろうけどな。
妄想を並べるのは簡単だが、積み上げるのは大変だから。
とりあえず、ＲＰＧ作りたいのにモンスター一覧表すら無いのはどう思うよ？

モンスターの一覧なんて最後の最後だろｗ

RPGの原型であるTRPGのルールブックを100回読み直してこい！

テーブルトークRPG自体が、テーブルトークゲームの単なる一ジャンルに過ぎないのに何いってんだ？
いつも思うが、RPGにまつわる議論で劣勢に立つと、テーブルトークRPGを引き合いにだすやつってなんなの？
懐古趣味や権威主義なのか、それとも先に登場した物の名前出せば反論されないと思ってる単なる阿呆なのか。

ルールブック読んだらモンスターの一覧が書かれたのがいつなのかわかるのか？ｗ

まあ、モンスターをウリにしたいんならいいんじゃないの？

妄想でも積み上げれば一冊の本になるぞ、って事だ。
モンスターが出来上がるぐらいの頃には、ほとんど妄想は組み上がっている。

一冊の本にもならない程度の妄想で、RPGを作れると思うな！

設定厨かｗ
企画書って言ってるのにモンスターリスト書いちゃうようなアホは使い物にならんｗ

そのテーブルトークのルールブック書いた人が
まずいきなりモンスターリストの製作から始めたんだと思ってるなら
相当な重症だ。

仕様書も含まれてるだろ。それとも何か？モンスターリストは仕様書に含まれないと？

モンスターリストの優先順位は極めて低いって言ってんだろｗ
そんなの作る前にやるべきことが山ほどある

ここで大事なのは妄想を組み上げることじゃなくて、現実に動くCRPGを作ることだもんな
最初からD&Dみたいな設定組み上げて作ろう！なんて野望抱いても、挫折する可能性は高い
趣味でつくるRPGなんだから、まずは小規模でも実現可能なレベルで始めるほうがいいよ

同意
まがりなりにも作るほうが建設的

設定は舞台の土台だからな
これがいい加減だと足もとが脆い

凄いマジレスすると、
積み上げるものがないから大丈夫。

家に喩えるならモンスターリストは瓦

設定を細かく作るのは良いけど
ゲーム上で必要のない設定の説明はいらない
設定を作ったから見せたくなるのかも知れんがややこしくなるだけ

土台はシステムだろ

モンスターとゲームシステムから見えてくるゲーム世界というのもあるわけで
実はどれを最初に作らなければならないという事は無かったりする。

システムが要求する設定やデータのみを作っても良いし
設定やデータの一部を採用してシステムをくみ上げても良い。
ある程度テーマを絞り込んで明確なイメージをもっておかないと
ゲームシステムを設計しようがない部分もあるし。

一見すると作ってるゲームにとって無駄に見える設定でも、他のゲームに
流用できたりする事があるから、設定先行で作っていっても無駄には
ならない事が多いしね。

ひとりで作る分には、アイディアメモや、ネタ帳で十分だと思うけどね。

人様にも見せられるように形式を整えなくても良いけど、自分で考えた
設定やアイディアを忘れてしまう可能性があるし、実際書き出してみると、
矛盾してたりする場合もあるので、整理は必要だと思う。

あとは、実際作って動かしながら詰めていけばいいし。

多人数で作る場合は大変だと思うよ。
コミュニケーションが最大の問題になるので、その辺はきっちりやらないと
まずいだろうし。

例えば、グラフィックと本来の世界観がかけ離れるとか良くあることで、
少人数で作っている俺も苦労しているくらいで。
（下手すると、絵師の表現したい世界観になってしまうから）

>>66
＞（下手すると、絵師の表現したい世界観になってしまうから）
わかる……。
世界観全く考えずに絵師の好みで書き始めたりね。
なぜそれで駄目なのか開き直ることもあるから困る……。

個人製作だと作ってる途中に企画や仕様が変わるからイラネ

>>66-67
俺もわかる
そうなると仕上がりの品質関係なく使えないんだよな
人の話を聞かずプライド高い奴ほどその傾向が強い気がする

その絵師は真面目に協力する気がないだけでは

文庫のカバーなんかでも、原作の描写と違うキャラ絵を描く人とかいるし
仕事でも、自分が描きたいもの優先しちゃう絵師はざらにいる感じがする

>>70
数回ミーティングしたけど俺以上の熱意の持ち主
いったい何に期待してるのかわからんが周りがドン引き状態
何を言ってもこっちの内容がそいつに伝わらない
死亡フラグ立ち始めてるんで企画倒れとか外道手段選ぶか迷ってる

>>71
そんな仕事するばかりするやつに継続的に依頼したいか？

日本語マチガエマーシタ

リーダー・企画・シナリオのＬ、プログラマのＰ、
絵師のＡ、絵師・音楽のＳがノベルゲームを作ろうとしていました。

最初に、ＬはＰにシステムの設計を行うよう言いました。
Ｐは各担当の意見を聞いて要件を決めました。

しかしＰの作成する仕様はＬ、Ａが納得できるものにならず、
なかなか決まりません。
何度も打ち合わせを重ねるのは無駄と判断したＬは、
各担当が実物を作ってから修正する、という方針を定めました。

そして開発開始から2か月後ＬとＡは、
Ｐ、Ｓの二人と連絡が取れなくなりました。

二人がいなくなってしまったのはなぜでしょうか。

LとAが使えないから

ゲームシステムの仕様は、まずリーダー企画が作らなきゃダメだろ。
なんでプログラマーに投げるんだよ。

その疑問が答え。

>>76でも問題ないですが、答えは「自分の担当を誤ったため」です。

企画は基本設計、
リーダー(マネージャー)は調整、
プログラマは実装・内部設計　が本来の仕事です。

Ｌはいわゆる日本型リーダーの行動(指示・強制)だけをしてしまいました。
Ｐは内部設計どころか基本設計、さらにはその手前の段階
　　(意見を聞く事)まで行ってしまい、企画という担当が消えました。
ＡはＳと同様の立場でＬと同じ行動をしてしまいました。
Ｓは基本設計に関与せず適切な立場でしたが、三人の行動に混乱しました。

結果として全員が立場と目標を見失いました。

そしてここからはフィクション、ありそうな話です。
話半分に聞いてください。

プログラムは一から作成した方が簡単という事が多々あるようで、
Ｌの方針は上級者のプログラマだけで行うような手法だそうです。
仕様作成も設計もしないのに、変更の労力を考慮しないＬに、
Ｐが強い嫌悪感を抱いた…かもしれません。

繋がりの強い人間は、消えるときも一緒である傾向にあります。
Ｓは各成果物のためにもらったシナリオ、世界観が曖昧な事に、
怪しい空気を察知していました。
しかしながら友人ほど明確な理由はない…かもしれません。

以上です。

誰も見たことのない革新的なものならともかく、ノベルだろ？
システム仕様なんかほぼ出尽くしてるのに、

>Ｐの作成する仕様はＬ、Ａが納得できるものにならず

とは、一体どんな要求がなされたのか、とても興味があるなｗ

ケースだけ見てれば良いと思うよ
類似性は多々

【ゲーム制作】サスペンスギャルゲー　『フクロマンス』　第二章　【スタッフ募集】
http://ex14.vip2ch.com/test/read.cgi/news4gep/1302080425/

最近読んだLuaの本にゲームに詳細な仕様書がないのは作ってみないと面白いかどうかわからないところが大きいっぽい
よく考えると普通のソフトでもこの仕様クソと思ってても変えられないこと多くて、ある意味ソフトの完成度を追求するには逃げになるんだよな、仕様書って

仕様書を書くことと、仕様を変更することには全く関係がないけどな
一々書くのが面倒くさいor最初から仕様書を書く能力がないのを無理に言い訳してるだけだろ

タスクレベルの粒度で何を作るのか決まっている状態、
もしくは何にするのか選べる状態にまで仕様を落とし込んでいると、
作業に対する精神的作用、つまりモチベーションに違いが出る。

なるほど

俺も失敗した＞企画書がゆるくて…
緩い子、不憫な子　悪化リーンwww

「ノベルゲー作ろう。演出いろいろ工夫したいから自前システムで」
「俺ＰＧやるわ。バックログと既読スキップはどうする？」
「いらないいらない。いると思ったらまた言うから」
「（…このアホどうしてくれよう）」

ロジックやアルゴリズムの整理する時、
自分用にExcelにまとめる事はよくある

あとRPGやADV的な物作るとき、
場所とフラグとプレイヤーの想定状態の相関整理するのに、
マインドマップ的な便宜上の地図書くことはよくある

あと、クラスや関数の量が多くなった時、
後付けでリストアップした表作って、その処理が担当する範囲と責任の整理する事もよくある

書き込む内容も一旦表にする癖つけた方がいいんじゃないか

こんなもの複数人数で製作するときに必要なだけだろ

ぼっちでも仕様書は書いた方がいいよ

企画書は見たことあるけど、
仕様書なんてメモ書きか口頭ｗ

だから何も残らんｗソースだって作った当人が居なくなれば
大抵わからなくなるんだしｗ

企業でさえそれｗ

担当者が残っていなかったら出版者に頼んで攻略本のデータを読ませてもらいます

「企画書や仕様書なくてもゲームはつくれるよ」
「企画書や仕様書ないとゲームがつくれないよ」
言ってるのが、企画者かプログラマかで印象がちがう

まさにウチの会社がそう

売れる気でいるよ・・・

ガチ同人レベルにも届いてないよ・・・

subversionやgitすら使ってないよ・・・

タスクランナーやバグトラッカも勿論だよ・・・

外観もソースの中身もダサダサでセンス無いよ・・・

潰れてないんだからすごいじゃない

>>97みたいなやつが一番クソなんだよなあ
てめえの働いてる会社をボロカス言うんなら
辞めたら？

ボロカス言うくせにそこを捨てる根性も無ければ、
給料だけをせしめようとする卑しく、さもしい人間。
会社からしたら、お前は要らない
さっさと く た ば れ だよ

とっくに見切ったけど？

オープンソース開発とかなら話は別だが
受け持ちが完全に切り分けられててある程度少人数なら
バージョン管理なくてもなんとかなるでしょ、昔は実際そうやってたわけだし

うわあ・・・

どこの零細企業だ

というか今時どんな少人数のチームでもバージョン管理ぐらいするだろｗ

どこのデータがどれだけ変わったかすら分からなくなったプログラムなんて、
手をつけるなんて考えるのもおぞましいブラックボックスだぞ

バージョン管理されておらず、ユニットテストもない
（テスト出来るだけのユニット化がされていない）
ソースなんてリファクタリングも無理だから一から作り直したほうが
早いだろうなあ

まあゲームなんてライフサイクル短いだろうから作りっぱなしも有り
かも知れないけどね

アップデートでデータ読めなくなったら親の敵のごとく嫌われるけどな

申請だしてメモリ管理台帳に記載して領域を割り当ててもらうから
混乱はないはずなのに勝手に未使用領域認定して他人が使ってる事が稀によくある

ちゅーか趣味グラマーでユニットテスト出来る人なんているんか
そもそもテストしよう！なんて発想にならず、思いついた物を好きなようにかいてるだけ
が9.9割くらいだろう

俺が今までに何度バージョン管理導入をエヴァって来たと思っているんだ…泣

まーバージョン管理はエディタのCtrl+Zのアンドウがもっと長い期間で行える、程度で
考えてればいいんじゃねーかな、最初の内は

開発チームが慣れてくれば自然にルールも出来上がってくるよ

ユニットテストはあれだ、
例えば自機を動かすとかそんなものにまで書く必要は全く無い
だって動かして見りゃわかるんだものｗ

だが例えばボードゲームのコンピュータ側が次の最善手を導き出すモジュールが
あったとして、そのモジュールがいくつものサブモジュールで複雑に構成されている、
とする

そんなとき、個々のサブモジュールが正しく動作するかをどうやって担保するか？
また問題が発生した場合にそれらに対しどのようなテストを行ったか？

を従来の結合済みのモジュールのブラックボックステストやコードレビューなどで
果たして拾いきれるか？

で考えていくと良いと思う

もちろんこれはユーザーテストのテスト仕様書のようなものではなく、
開発者側の自発的なものが望ましい

あと本題の企画書っていうかドキュメントを書けないってのはアレね、
イメージを固めるっていうか表現する術を知らないだけじゃないかな？

だからゲームの企画者ってのは簡単な漫画のプロット書けるだけの絵心とか
簡単なモックアップを作れるだけのプログラミング能力は欲しいところだよね

別にペーパープロトタイピングでもいいしホワイトボードに落書きしたのを
デジカメでパチリしたのでもいいんだよ、完成イメージが伝われば

自分がどこにいて　目的地がどこで　どういう経路を選ぶか
地図を見ながら決める　という時のために
「地図」として使える部分だけはしっかり書くべき