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

土台はシステムだろ

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

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

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

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

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

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

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

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

>>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のアンドウがもっと長い期間で行える、程度で
考えてればいいんじゃねーかな、最初の内は

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

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

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

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

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

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

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

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

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

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

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