Help us understand the problem. What is going on with this article?

なんちゃってプロジェクト管理:RPGツクール系で分業をやってみた

More than 1 year has passed since last update.

まずはじめに

この方法が良いとは思ってませんが、当時大学生サークルでゴリゴリ開発していた時の色々な反省点を踏まえ、今風に調整して公開してます。

  • こういう方法があるよ!
  • こんなんどうよ?

とかバンバンください!

概要

こういう作りになってる背景をちょっとだけ。
メンバーは以下のとおり

私:一応代表やらせてもらってます。RGSS時代に一度挫折したけど今回帰ってきた出戻りスクリプター
F君:絵も文も書けるナイスガイ、そしてツクラー。スクリプトもちょっと書けるよ!
I君:ADVメインのツクラー。素材は凝る。UI作る能力がハンパない
S君:非ツクラー。難しい事は分からんが何でもやります。メインは動画・マンガの人
J君:デジ塗り専門。背景とかもバッチリ!

やたらとシナリオ書きたい人が多いサークルですが、彼らのやりたい事を考慮しつつ、うまいこと作成していく

担当

PM:私
スクリプト:私
マップデザイン・クリエイト:I君
ADVパート:みんな
RPGパート:私
デバッガ:みんな

素材とか色々ありますが、ややこしくなるのでここでは省きます。

なんちゃって例

qiita_RPGMV.png

使い方と各コメント

基本的には開発環境でガッツリ、ある程度安定版を出せればテスト環境に移行していく。
ドキュメント整理も立派な仕事なので、各担当者に徹底させるようにすると、「締め切りに間に合わない時に代表がキャッチアップできる」というメリットがある。
当日、会場に行ってプレスする羽目にならないように普段から進捗管理を心がけよう。

「今、困ってる事はない?」

root

なんかあった時のために置いてる。
なんでこういう作りにしようと思ったのかは覚えてないけど、root以下をまるっとコピペする方法が当時はなかった気がする。今もない?

環境別

当時やってなかったけど、これをやらなかった所為でファイルが管理出来なかった。
完成版とテスト版のマップがどれか分からないので、マップ名に[本番]とか書いてた気がする。
->この対応自体はやるだろうけど、親フォルダがどこにあるのかわからなくなるので、予め対応すると探すのが劇的に楽になる。

バージョン管理

このバージョン管理の目的はいつエターナっても適当に切り上げられるようにするための措置。
個人開発だとポシャって非公開で良いんだけど集団開発しているとポシャった時のフォローが大変。
完成していなくても公開はしよう、という意見は絶対出てくるのでサークルの空中分解を防ぐのに大きく貢献してくれる。
当然、学生時代にそんな事に気が回らなかったので頑張って手作業で動くところまで復旧して空中分解を阻止していた過去が…。

テスト環境のバージョン

テスト環境の場合、赤ペン先生のごとくあーでもないこーでもないとバグが見つかる。
基本的にその処理さえ動けばいいや、という作り方をしているダメな設計のプログラマーがプレゼン中にバグを披露するという恥ずかしい事態に陥りやすいための措置。
RPGパートをスクリプト屋以外の人間が分業していたら意味はあると思う。

ある程度形になってきた時に開発者一同が気晴らしに自分のゲームをしたい時にも使える。

テスト環境:デバッガー/おかしく

テスト環境:デバッガー/おかしくなったら作りなおす
作りなおしたりバージョンを差し替える時は場所移動の変更をお忘れなく。
よく忘れるのはデスルーラの移動先設定。デスルーラってマップを作ってそこで飛ばす方法が良いかもしれない。

シン・タイトル

デフォルトのタイトル画面でも良いんだけど、RPGMVの細かいの見てると色々いじれそうなので別に作ってみた。
凝りだすといつまでたっても終わらないのはcatsystem2とかYU-RISとかあの辺のADVエンジンで経験済み。
デザインやりたいスクリプト屋なら凝る可能性を憂慮してここでは分けてみた。

マップのエンカウントの有無・シンボルエンカウント

これはマップの広さに関わってくる。
VX時代からでも描画関連で色々な問題があったのに、MVで問題にならないわけがない。
対象のマシンスペックを考慮してしっかりと定義しておくこと。

ADVパート

ぶっちゃけバージョンを分ける必要はない。が、ノンプログラマー的にはちょっとカッコ良く見えるらしい。
テンションを上げるための努力をするのも代表の仕事だ。

プレゼン・MTG

これがあるとチャットワークスなりスカイプなりの会議が捗る。
議題にするファイルを予め入れて、それらが動くような形に設定してプロジェクト自体を配布するのが良い。

ついでに、プレゼンで使った時点のプロジェクトはどこかに持っておくようにしよう。
それがそのままバックアップに使える。

デプロイ

VXまでは容量削減のため、開発プロジェクトを保存しておきデプロイプロジェクトは本番環境以外ごっそり削って、デプロイしたファイルを使って通しプレイをする、というのが当たり前だった。
MVもあんまり変わらない気がしているが…

結局のところ

ツクラーあるある対策は一部盛り込んだつもりですが、そのチームのクセを見ぬいて最適化してあげるのが一番良いでしょう。
この形は私のサークルではある程度まとまりが取れていたので、この形にしていました。

ぶっちゃけ

ソロで開発したほうが楽な事が目立つかも知れない…

読了後いいね!をお願いします。

どれだけの方に読んでもらっているか知りたいので、お手数をおかけしますがご協力いただけると嬉しいです。

nomurasan
ノンプログラマーがシステムを作るには?を本気で考える元業務系Webアプリ屋系セキュリティデータサイエンティスト。 そろそろオートメーション・API(で)クリエイターになりたいおとしごろ。 https://www.slideshare.net/ssusered50fb 記事等は配属先やクライアント等の意見ではなく個人の考察によるものです。 一応念のため書いておきますが、無断での転載厳禁。
https://www.wantedly.com/users/18437113
Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away