企画書も仕様書も作らないでゲーム製作って…
■ このスレッドは過去ログ倉庫に格納されています
他人に迷惑かけなければな。
というか、企画書も仕様書も電子データで良いじゃん。 今どきは、ゲームは金にならないんだから、
好きなようにやらせてやれ。
3DはもうForzaとグランツーが競ってればよくて、
その他のものは2Dで十分なんだな。
企画書も仕様書も頭の中にちゃんとあるさ。
出力?誰にみせるんだそんなもの。 仕様書かかないと途中で
「あーあそこ、こう書けばよかった」ってのが続いて1からやり直したくなる 3日もあれば完成するミニゲームにいちいち仕様書なんていらんでしょ?
長期間かかるゲーム?
そんなもんこの板の住民がつくれるわけないだろ?
大規模ゲーだとしても個人で作る分には仕様書なんていらんし
作ってる時間自体がムダだ。
多人数プロジェクトはやる気のないやつばかりで仕様書があっても成功しない。
だいたいゲーム作る前から仕様書おこせるやつに仕様書は要らない。
あとから仕様を確認するために必要?誰が確認するんだよ?
よって仕様書はいらない。 仕様書があれば成功するという事は無い。
仕様書があれば、少しは身が安全なだけだ。
(身の安全 ≠ 成功) 仕様書があればプログラムを完成させられるとは限らないが
プログラムを最後まで完成させられない奴はたいてい仕様書を書いていない ゲーム会社でも仕様書なんて言い方するんだな知らなかったわw 普通に言うと思うぞ、仕様って。
ゲームとは言えソフトウェアに変わりはないし
設計だって必要なんだからさ。
まあ、本能や脊髄に依存する分、
仕様変更の頻度はすごいだろうけど。
ゲームの仕様書は作るけど、関連するプログラムの仕様書はソースコードと一体化させるだろ、今時は。
ビジネス系ではまた別かもしれないが。 一人プロジェクトでやってる場合は覚書はそのまま仕様書になるが
複数人だとルールの共通化が必要なため本人しか分からない覚書程度では要件を満たさない >>10-11
1からやり直すのもまた勉強になるよな。
ど〜ゆ〜状況で1からやり直すべきかが、だんだん分かってくる。
まあ、変更前のデータは常に残す必要があるけどな。
あと、小まめなモジュール化やオブジェクト化も必須だな。同じ
状況が発生した場合に同じデータが使い回せるようになってくる。 >>24
関係者が全員サヴァンならいらないかもねw 関係者が全員サヴァンならコミュニケーションが不可能な気がする 「一週間で判る・サヴァンと仕事するためのたったの2e256箇条」 技術的な観点から、よりゲームを面白くする内容を提案するのは大歓迎。
仕様書をみたせばいいなんて後ろ向きなことは、Windows用のビジネスアプリ書いてるようなろくでなしに任せておけばいい。
ゲームプログラマはアーティストなんだ。 全部のゲームが完成してたら大変なことになるよ
9割以上が未完成で終了するからこそ
完成したゲームが多少くそでも尊いのさ
仕様書なんかいらない 最近はキャラとマップだけ変えて
あとはおんなじなゲームが多いらしいから、
仕様書や企画書は、既存のものを使いまわしてるのかねぇ?
ノベルなら、仕様書がなくても、シナリオがあれば作れるんだろうね。
そういう経営者は多いよ。
シナリオとCGと音楽が出来たらゲームが完成すると思っている人。
もうね、アホかと。 >>34
俺はそれでよかったなぁ
むしろ、それができてない会社のゲームって買いたくない
ここ数年でそれをキチンと守ってるのってテイルズぐらいじゃない? >>35
完成させるだけならな。UIとかエフェクトとか凝ったことを始めるととたんに面倒臭くなる。 いくらシナリオとCGと音楽がよくても、UIが酷いとか、ロードの嵐とか
ロード時間長いとか、バグ満載とか、フリーズ多発じゃどうしようもないもんな
小さいことでも手抜きが積み重なると、プレイやめたくなるほどのストレスになるし
細かいところまでつくりこむと、それだけでも時間かかったりすると思う 仕様書や企画書とか
全部俺の頭の中に入ってるから問題ない 自分のための備忘録でいいなら文字通り備忘録で済むしな
ドラッカーブームに毒された人とかなら自分用進行管理表作ってウダウダやってるのかもしれないけど 他人を巻き込むのに企画書も仕様書も作らないから問題にしてるんでね? まあ、作らないんじゃなくて、妄想が甘すぎて作れないんだろうけどな。
妄想を並べるのは簡単だが、積み上げるのは大変だから。
とりあえず、RPG作りたいのにモンスター一覧表すら無いのはどう思うよ? RPGの原型であるTRPGのルールブックを100回読み直してこい! テーブルトークRPG自体が、テーブルトークゲームの単なる一ジャンルに過ぎないのに何いってんだ?
いつも思うが、RPGにまつわる議論で劣勢に立つと、テーブルトークRPGを引き合いにだすやつってなんなの?
懐古趣味や権威主義なのか、それとも先に登場した物の名前出せば反論されないと思ってる単なる阿呆なのか。 ルールブック読んだらモンスターの一覧が書かれたのがいつなのかわかるのか?w まあ、モンスターをウリにしたいんならいいんじゃないの? 妄想でも積み上げれば一冊の本になるぞ、って事だ。
モンスターが出来上がるぐらいの頃には、ほとんど妄想は組み上がっている。 一冊の本にもならない程度の妄想で、RPGを作れると思うな! 設定厨かw
企画書って言ってるのにモンスターリスト書いちゃうようなアホは使い物にならんw そのテーブルトークのルールブック書いた人が
まずいきなりモンスターリストの製作から始めたんだと思ってるなら
相当な重症だ。 仕様書も含まれてるだろ。それとも何か?モンスターリストは仕様書に含まれないと? モンスターリストの優先順位は極めて低いって言ってんだろw
そんなの作る前にやるべきことが山ほどある ここで大事なのは妄想を組み上げることじゃなくて、現実に動くCRPGを作ることだもんな
最初からD&Dみたいな設定組み上げて作ろう!なんて野望抱いても、挫折する可能性は高い
趣味でつくるRPGなんだから、まずは小規模でも実現可能なレベルで始めるほうがいいよ 設定は舞台の土台だからな
これがいい加減だと足もとが脆い 凄いマジレスすると、
積み上げるものがないから大丈夫。 設定を細かく作るのは良いけど
ゲーム上で必要のない設定の説明はいらない
設定を作ったから見せたくなるのかも知れんがややこしくなるだけ モンスターとゲームシステムから見えてくるゲーム世界というのもあるわけで
実はどれを最初に作らなければならないという事は無かったりする。
システムが要求する設定やデータのみを作っても良いし
設定やデータの一部を採用してシステムをくみ上げても良い。
ある程度テーマを絞り込んで明確なイメージをもっておかないと
ゲームシステムを設計しようがない部分もあるし。
一見すると作ってるゲームにとって無駄に見える設定でも、他のゲームに
流用できたりする事があるから、設定先行で作っていっても無駄には
ならない事が多いしね。 ひとりで作る分には、アイディアメモや、ネタ帳で十分だと思うけどね。
人様にも見せられるように形式を整えなくても良いけど、自分で考えた
設定やアイディアを忘れてしまう可能性があるし、実際書き出してみると、
矛盾してたりする場合もあるので、整理は必要だと思う。
あとは、実際作って動かしながら詰めていけばいいし。
多人数で作る場合は大変だと思うよ。
コミュニケーションが最大の問題になるので、その辺はきっちりやらないと
まずいだろうし。
例えば、グラフィックと本来の世界観がかけ離れるとか良くあることで、
少人数で作っている俺も苦労しているくらいで。
(下手すると、絵師の表現したい世界観になってしまうから) >>66
>(下手すると、絵師の表現したい世界観になってしまうから)
わかる……。
世界観全く考えずに絵師の好みで書き始めたりね。
なぜそれで駄目なのか開き直ることもあるから困る……。 個人製作だと作ってる途中に企画や仕様が変わるからイラネ >>66-67
俺もわかる
そうなると仕上がりの品質関係なく使えないんだよな
人の話を聞かずプライド高い奴ほどその傾向が強い気がする 文庫のカバーなんかでも、原作の描写と違うキャラ絵を描く人とかいるし
仕事でも、自分が描きたいもの優先しちゃう絵師はざらにいる感じがする >>70
数回ミーティングしたけど俺以上の熱意の持ち主
いったい何に期待してるのかわからんが周りがドン引き状態
何を言ってもこっちの内容がそいつに伝わらない
死亡フラグ立ち始めてるんで企画倒れとか外道手段選ぶか迷ってる
>>71
そんな仕事するばかりするやつに継続的に依頼したいか? リーダー・企画・シナリオのL、プログラマのP、
絵師のA、絵師・音楽のSがノベルゲームを作ろうとしていました。
最初に、LはPにシステムの設計を行うよう言いました。
Pは各担当の意見を聞いて要件を決めました。
しかしPの作成する仕様はL、Aが納得できるものにならず、
なかなか決まりません。
何度も打ち合わせを重ねるのは無駄と判断したLは、
各担当が実物を作ってから修正する、という方針を定めました。
そして開発開始から2か月後LとAは、
P、Sの二人と連絡が取れなくなりました。
二人がいなくなってしまったのはなぜでしょうか。 ゲームシステムの仕様は、まずリーダー企画が作らなきゃダメだろ。
なんでプログラマーに投げるんだよ。 >>76でも問題ないですが、答えは「自分の担当を誤ったため」です。
企画は基本設計、
リーダー(マネージャー)は調整、
プログラマは実装・内部設計 が本来の仕事です。
Lはいわゆる日本型リーダーの行動(指示・強制)だけをしてしまいました。
Pは内部設計どころか基本設計、さらにはその手前の段階
(意見を聞く事)まで行ってしまい、企画という担当が消えました。
AはSと同様の立場でLと同じ行動をしてしまいました。
Sは基本設計に関与せず適切な立場でしたが、三人の行動に混乱しました。
結果として全員が立場と目標を見失いました。
そしてここからはフィクション、ありそうな話です。
話半分に聞いてください。
プログラムは一から作成した方が簡単という事が多々あるようで、
Lの方針は上級者のプログラマだけで行うような手法だそうです。
仕様作成も設計もしないのに、変更の労力を考慮しないLに、
Pが強い嫌悪感を抱いた…かもしれません。
繋がりの強い人間は、消えるときも一緒である傾向にあります。
Sは各成果物のためにもらったシナリオ、世界観が曖昧な事に、
怪しい空気を察知していました。
しかしながら友人ほど明確な理由はない…かもしれません。
以上です。 誰も見たことのない革新的なものならともかく、ノベルだろ?
システム仕様なんかほぼ出尽くしてるのに、
>Pの作成する仕様はL、Aが納得できるものにならず
とは、一体どんな要求がなされたのか、とても興味があるなw 最近読んだLuaの本にゲームに詳細な仕様書がないのは作ってみないと面白いかどうかわからないところが大きいっぽい
よく考えると普通のソフトでもこの仕様クソと思ってても変えられないこと多くて、ある意味ソフトの完成度を追求するには逃げになるんだよな、仕様書って 仕様書を書くことと、仕様を変更することには全く関係がないけどな
一々書くのが面倒くさいor最初から仕様書を書く能力がないのを無理に言い訳してるだけだろ タスクレベルの粒度で何を作るのか決まっている状態、
もしくは何にするのか選べる状態にまで仕様を落とし込んでいると、
作業に対する精神的作用、つまりモチベーションに違いが出る。 俺も失敗した>企画書がゆるくて…
緩い子、不憫な子 悪化リーンwww 「ノベルゲー作ろう。演出いろいろ工夫したいから自前システムで」
「俺PGやるわ。バックログと既読スキップはどうする?」
「いらないいらない。いると思ったらまた言うから」
「(…このアホどうしてくれよう)」 ロジックやアルゴリズムの整理する時、
自分用にExcelにまとめる事はよくある あとRPGやADV的な物作るとき、
場所とフラグとプレイヤーの想定状態の相関整理するのに、
マインドマップ的な便宜上の地図書くことはよくある あと、クラスや関数の量が多くなった時、
後付けでリストアップした表作って、その処理が担当する範囲と責任の整理する事もよくある 書き込む内容も一旦表にする癖つけた方がいいんじゃないか 企画書は見たことあるけど、
仕様書なんてメモ書きか口頭w
だから何も残らんwソースだって作った当人が居なくなれば
大抵わからなくなるんだしw
企業でさえそれw 担当者が残っていなかったら出版者に頼んで攻略本のデータを読ませてもらいます 「企画書や仕様書なくてもゲームはつくれるよ」
「企画書や仕様書ないとゲームがつくれないよ」
言ってるのが、企画者かプログラマかで印象がちがう まさにウチの会社がそう
売れる気でいるよ・・・
ガチ同人レベルにも届いてないよ・・・
subversionやgitすら使ってないよ・・・
タスクランナーやバグトラッカも勿論だよ・・・
外観もソースの中身もダサダサでセンス無いよ・・・ >>97みたいなやつが一番クソなんだよなあ
てめえの働いてる会社をボロカス言うんなら
辞めたら?
ボロカス言うくせにそこを捨てる根性も無ければ、
給料だけをせしめようとする卑しく、さもしい人間。
会社からしたら、お前は要らない
さっさと く た ば れ だよ オープンソース開発とかなら話は別だが
受け持ちが完全に切り分けられててある程度少人数なら
バージョン管理なくてもなんとかなるでしょ、昔は実際そうやってたわけだし どこの零細企業だ
というか今時どんな少人数のチームでもバージョン管理ぐらいするだろw どこのデータがどれだけ変わったかすら分からなくなったプログラムなんて、
手をつけるなんて考えるのもおぞましいブラックボックスだぞ バージョン管理されておらず、ユニットテストもない
(テスト出来るだけのユニット化がされていない)
ソースなんてリファクタリングも無理だから一から作り直したほうが
早いだろうなあ
まあゲームなんてライフサイクル短いだろうから作りっぱなしも有り
かも知れないけどね アップデートでデータ読めなくなったら親の敵のごとく嫌われるけどな 申請だしてメモリ管理台帳に記載して領域を割り当ててもらうから
混乱はないはずなのに勝手に未使用領域認定して他人が使ってる事が稀によくある ちゅーか趣味グラマーでユニットテスト出来る人なんているんか
そもそもテストしよう!なんて発想にならず、思いついた物を好きなようにかいてるだけ
が9.9割くらいだろう 俺が今までに何度バージョン管理導入をエヴァって来たと思っているんだ…泣 まーバージョン管理はエディタのCtrl+Zのアンドウがもっと長い期間で行える、程度で
考えてればいいんじゃねーかな、最初の内は
開発チームが慣れてくれば自然にルールも出来上がってくるよ ユニットテストはあれだ、
例えば自機を動かすとかそんなものにまで書く必要は全く無い
だって動かして見りゃわかるんだものw
だが例えばボードゲームのコンピュータ側が次の最善手を導き出すモジュールが
あったとして、そのモジュールがいくつものサブモジュールで複雑に構成されている、
とする
そんなとき、個々のサブモジュールが正しく動作するかをどうやって担保するか?
また問題が発生した場合にそれらに対しどのようなテストを行ったか?
を従来の結合済みのモジュールのブラックボックステストやコードレビューなどで
果たして拾いきれるか?
で考えていくと良いと思う
もちろんこれはユーザーテストのテスト仕様書のようなものではなく、
開発者側の自発的なものが望ましい あと本題の企画書っていうかドキュメントを書けないってのはアレね、
イメージを固めるっていうか表現する術を知らないだけじゃないかな?
だからゲームの企画者ってのは簡単な漫画のプロット書けるだけの絵心とか
簡単なモックアップを作れるだけのプログラミング能力は欲しいところだよね
別にペーパープロトタイピングでもいいしホワイトボードに落書きしたのを
デジカメでパチリしたのでもいいんだよ、完成イメージが伝われば 自分がどこにいて 目的地がどこで どういう経路を選ぶか
地図を見ながら決める という時のために
「地図」として使える部分だけはしっかり書くべき 机上の空論で上手くいかないモノが、実際に上手く行くはずがない 作る目的
市場の動向、環境
自分たちの得意技
目的が達成された後、社会がどう変わるか
オリジナルのポイント
懸念点
プラン、対象、利益目標、スケジュール
仕様は別紙参照
こんな書き方したらつまらんやろ。
なんでつまらんかと言うと企画したいが糞やから。
上記を淡々とA4一枚にまとめて一目瞭然にする。
それでも行けると思ったら、最低損益分岐点まで行く。 たまに、最初は採用されなかった企画で。
他に採用された企画が途中で失敗だと気が付き、
急遽間に合わせで採用になる事がある。
開発費を貰いたい企画なのか、ノリで作った企画なのか、売れるモノの企画なのか。 スレタイ通りのドリーマーに遭遇した!
パクリのみで脳内構成された仕様は、漏れ放題
探求心の欠片もないのに、何で造りたいと思うw 簡単にお金が稼げる方法興味ある人だけ見てください。
グーグル検索⇒『来島のモノノリウエ』
5QS9QT5OZO ■ このスレッドは過去ログ倉庫に格納されています