企画書も仕様書も作らないでゲーム製作って…
■ このスレッドは過去ログ倉庫に格納されています
>>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 ■ このスレッドは過去ログ倉庫に格納されています