本記事は広島大学 HiCoder＆ゲーム制作同好会GSD Advent Calendar 2024 21日目の記事です！
ちなみに執筆者は4日目にも記事を書いていました！ いわゆるネタ記事です！ みんなもあの記事を読んで「韻踏みしんどみモンスター」になろう！（ならなくていい）
自己紹介
if(time>=5:00&&time<12:00){
printf("おはようございます");
}else if(time>=12:00&&time<19:00){
printf("こんにちは");
}else if(time>=19:00&&time<24:00){
printf("こんばんは");
}else{
printf("寝ろ");
}以上、雰囲気だけで書いたC言語のコードでした。寝ろになった人は寝てください（アドカレの性質上その日の0時解禁のため、公開から最速で読みに来ると「寝ろ」になる罠。バグです）。
それ以外の方。どうも、リュースです！ 先代のGSD会長をやっていた現下っ端です。シナリオライターをメイン役職としていて、ギャグもシリアスも鬱もいけちゃうマルチクリエイター（自称）です。
今回はゆかたまつりやコミケに向けて行った「ドットテキスト」というゲームを作った時のレポという形で記事を書いていこうと思います。大規模制作とまでは行かないけど、全10名くらいが関わるくらいの規模のプロジェクトでした。まあよかったら読んでってくださいな。
「ドットテキスト」ってなんだよ！
ドットテキストとは、「GSDのシナリオライターの書いた物語をオムニバス形式でゲームとしてまとめた短編ノベルゲーム集」のことです。今年のゆかたまつり、大学祭にて遊んでいただいた方もいらっしゃるかも？ もしそうなら超ありがとうございます！
GSDのオリキャラである渚、雫を主人公としたさまざまな物語が楽しめる。
GSDシナリオライターによるオリキャラたちの冒険や戦いの物語を収録。
ちなみに今年のコミケではGSDも出店予定！
そのゲームディスクの中に本作品も含まれております！
日時、場所は「月曜日 西 こ14a」です！ ぜひ遊びに来てくださ～い！（今年はリュースも現地にいます！ 皆様と会えるのを楽しみにしております～！）
なんでドットテキストを作ることに？
まずはこの作品を作ることになった経緯をお話します。
端的に言えば「GSDシナリオライターの活躍の場を作るため」です。
……え、活躍の場ないの？ と思われた方。そういうわけではないんです。今までもシナリオライターとプログラマー等の他の役職と協力してゲームを作るという事例はありました。しかし、そもそも例年シナリオライターという役職の人間はGSDでは少なかったので、そういった事例もまれなケースでした。（シナリオ役職の人はいるけど1~2人しかいないとかそのレベル）
しかし、今年度になってシナリオライター職はまさかの盛り上がりを見せました。というのも、元々他の役職をやっていた人が「シナリオやるわ」って言って転職したり、「シナリオやりたい！」って人が入会してくれたりで、人数がぐっと増えたのです。かくいうリュースも転職組の一人なのであります。
新入生の子もシナリオライターで数人入ってくれたし、ではここからシナリオライターもチームを組んで色々ゲームを作っていこうぜ！
……となるはずでした。
はい、そうはなりませんでした。というよりはできなかったのです。何故か。
というのも、GSDでは5月~7月あたりで新入生の子たち向けのゲームジャムというのをやっているんですね。ここでは「GameSugoiDekita」というミニゲーム集に収録されるゲームを、新メンバーの子に作ってもらうというわけです。
……お気づきでしょうか。
そう！！ 「ミニゲームにはシナリオが介在する余地がない」のです！！！
まあでもね、こればっかりはしょうがないんです。プログラマーだって1年生で、ゲーム制作初挑戦なんだから。テキスト表示をして、立ち絵を出して……とかするの大変じゃないですか。だから最初は仕方ないんです。
……と、人数が少ないうちは割り切ることも出来ました。ですが今やGSDのシナリオライターは11人（2024/12/18現在）。割り切って放置できる人数じゃねえ！！ どうにかしなきゃ！！
……ということで話し合って生まれたアイデアが、「シナリオ版GameSugoiDekita」、つまり「ドットテキスト」だったのです。
前職のキャリアを活用せよ！
さて、アイデアが出ましたがどう実現するんでしょうか。
一番の悩みどころに見えるこれは、意外と早く結論が出ました（というより意見が通っちゃったというか）。
それは、「俺がウディタで作ったシステム使ったら実現できそうだからそれで行こうぜ」です。
ウディタとは「WOLF RPG エディター」の略称です。
WOLF RPGエディター公式サイト 【RPG作成フリーソフト】
○高度なRPG開発が可能な、無料のゲーム制作ツールです。
○作成したゲームは自由に配布･販売･コンテスト投稿などが可能。
○ｺﾓﾝｲﾍﾞﾝﾄを導入することで、ゲームシステムを無限に強化できます！
というのも、実はリュースはのGSDにおける前職は「ウディタ使いのプログラマー」でした。なので自前のシステムで、プログラミング知識やウディタ知識がほぼ無くても扱えるノベルゲーム制作ツールを生み出すことができたのです。どうやって作ったのか興味ある人は、去年のリュースが書いた以下の記事を読んでみてね！
[シナリオゲー作業簡略化！]WOLF RPG エディターでテキストファイルを読み込もう
このシステムを良い感じに改良することで、システム利用者はとりあえずシステムの仕様さえ理解できれば、「テキストファイルをいじるだけでノベルゲームが作れる！」という状況までもっていきました。
しかも元サウンドクリエイターのシナリオライターの先輩が「一人1曲なら書くよ」と言ってくれました。アツすぎでは？
これなら新入生たちもノベルゲームが作れる！ 暇じゃなくなる！
いざプロジェクト開始！
というわけで、シナリオライター達はこの「ドットテキスト」プロジェクトを、新入生向けゲームジャムの裏で進めていくことになりました。めざせゆかたまつりでの公開！
……が、これがなかなか大変でした。
まず予測が甘かった点として、「新入生はPC知識が少ないことが多い」ということです。
思い出してみてください。大学生になりたての自分は、どこまでPCについて詳しかったでしょうか？
まあそりゃ普通に詳しかったわって人もいると思います。でも個人的にはそうじゃない大学生が多いんじゃないかなと思っていますね。僕はそうでした（テキストファイルって言われて予想は出来るけど何か知らないだったり、拡張子による違いがよく分からなかったり、zipって何……？ ニュース？ とかそんなレベルでした）。
しかし、大学生たるものPCと向き合って生きていくもの。自ずと知識は身についているのです。そしてその自覚がなければ、無意識下のうちにそれを「誰もが知っていること」と思い込んでしまいます。その思い込みのまま作った「マニュアル」はまあ機能しませんでした。まあそもそも時間がなくて手抜き過ぎたというのもありましたが。そのため、結局は口頭でシステム導入について行ったり、システム更新、仕様説明をすることになりました。大変だった……
また、他にも反省点として「システム仕様が分かりにくかった」というのが挙げられます。
元々は自分のために作ったシステムだったので、自分さえ分かればいいやーの気持ちで実装をすっごいテキトーにやってた箇所が多くありました。
……そしてそれをロクに修正せずに本番仕様として配布しました。まじで反省しています。超わかりにくかっただろうなって。人に使わせるためのシステム作りを意識しないといけなかったなって。
まあこんな感じで若干グダグダとしながらプロジェクトを進行させていきました。
見るべきは シナリオライター だけでなく(5・7・5)
シナリオライター組の進捗を確認しながら、僕にはほかにも見るべき箇所がありました。そう、素材の依頼です。今回のシナリオはいわゆるスターシステムを採用しており、同一のキャラを元に各々が好きなような設定を盛り、そして物語を書くといった、まあざっくり言うとそういうやつです。
スターシステムを採用したのにも理由がありました。それはGSDの慢性的な素材班不足です。理想を言うのであれば、シナリオライター一人につきイラストレーター一人つけたいくらいなのですが、そんなことはGSDが逆立ちしたって出来ません。なんせ別のゲームジャムも並行してますからね。人手が足りないのです。それを解決するために、一人の力で素材提供が事足りるスターシステムを採用したのです。
しかし、依頼したのはいいものの、やはり個性豊かなシナリオライターたち。各々のシナリオでオリジナルのキャラを作成していました。想定通りではあるのですが、やはり立ち絵誰が描くの問題は、ある……
この時は超新星の如く現れた激強新入生イラストレーターに力を借りることで解決できました！（……いや、たまたまどうにかなっただけなんじゃ？）
また、イラスト関連で言えばタイトルイラストを提出1週間前まで完全に失念するというポカもしました。笑えないよ！
これも件の彼にどうにかしてもらいました。神……いや、統括としては終わってるんですけど！
締め切り&統合作業やばすぎ！！
そんなわけで全体的にダメそうな統括の下、プロジェクトは進行していきました。そして締め切り前夜。
……あれ？ シナリオ完成品が思ったより挙がってなくね？
そう！ 締め切り前夜になって、「まだ完成してなくて……」がそこそこ発生しました。ここでいう締め切りは、「ここで完成しないとやばいべ」の締め切りです。大ピンチではないか！！
結局彼らには直前ギリギリまで時間を使ってもらうことに。時刻は27時とか、30時とか……そういうレベルだったんじゃなかったかな！
そしてデータをもらって統合作業です。とはいえ、リュースの作ったシステムでは普通にファイルをもらってその素材をまとめ、そして実行できるようにちょちょっと調整するだけだったので、この作業についてはまあ楽な方でした。
……誤字脱字、画像の不備や選択肢遷移の不具合とかがなければな！！！
そう！ 統合作業で一番大変なのは、「作品の最終チェックも兼ねている」ところです。
そのため、通しでプレイしてまずい箇所がないかとか、セリフの名前が間違ってないかだとか、立ち絵はちゃんと出てるかとか……そういう確認をしないといけなかったのです。や、当たり前のことではあるのですが、これをちゃんとやるのってすごく大変なんです。分岐があるシナリオなら全パターン網羅しとかないとだし……
この確認作業については、提出前のチェックリストを制作すべきだと感じました。テキストの名前や立ち絵チェックとか、誤字脱字とか……そういうリストですね。そうすることでかなり手間を軽減できそうだなって思います。
ま、そんなこんなで徹夜もしながらなんとか形にすることが出来ました。苦しかったけど、完成品を見た時はすごい満足感を感じました。なにより、シナリオライターの新入生たちに「ゲームを作る経験」をさせてあげられたのが良かったと思います。
コミケに向けてもやるよ（改善点）
月日は流れ、9月。GSDはコミケ出店に応募することになりました。そこでシナリオライター達は何しよう？ となったわけです。そこで浮かび上がった案が「ドットテキスト第2弾」です。
プロジェクトの大筋は同じだったため、細かいことは省きますが、前回の反省を踏まえて動き方を変えた箇所がありました。
- シナリオライターでオリキャラ作る
- 締め切り設定を細かく（本文書上げを〇日まで、素材集め&完成を〇日までといった感じ）
- システムは前回からほぼ変えない（=途中でアプデいれまくったりしない）
- システム導入や、使い方をちゃんとマニュアル化
他にもあったような気がしますが、大体こんな感じ。ただ、締め切り設定に関しては正直そこまで意味をなしてなかったような気がします。結局書きあがってない子もいたし……
マニュアル化については良くも悪くも実りのある実践でした。自分が言わなくても導入作業ができるのはありがたかったです。しかし、マニュアル自体のクオリティの問題か、マニュアルについての質問が上がることがありました。これも前述の通り、「無意識化の知っている判定」だったのでしょう。
後は、シンプルに忙しいからなのか、作品を挙げるシナリオライターが少なかったのも問題点かもしれません。作品数が少ないのであれば、オムニバス形式でまとめる意味もなくなってしまいますし……それだったら各々でティラノビルダーでも使ったらよくない？ って話です。ぶっちゃけ僕のシステムって統合して1本のゲームに出来る！ という点以外はティラノの下位互換でしかないので……（まあ作品数で文句を言うならコミケ分にシナリオ出してない僕は何様だって話なんですけど）
まあ、内蔵されるシナリオ数は少ないけど、前よりはまだマシな進行ができたプロジェクトになったと思います。ちなみにタイトルイラスト忘れは今回もやらかしました。
無理させてごめんなイラスト班……リュース、お前は学習をしろ！！
次以降、こうしたらいいのでは？
ここからは次回以降に向けての改善点を列挙したいと思います。まあリュースももう学部3年生。そう遠くないうちに卒業です。次代のシナリオライターのためにも、改善点は残しておきましょうね。
- マニュアル改善
これは必須でしょう。ユーザー側だけでなく、統合側のマニュアルも必要です。「誰が見ても問題なく実行できる」を目標に書き直す必要がありそうです。 - 締め切りの厳密化
これはプロジェクトのまとめ側としての改善点です。余裕を持った日程を作り、それを厳密に守ってもらう（無理なく守れる）ことが大切そうです。また、そのために中間発表を設けるのが非常に有効であるのではとふんわり考えていたり。 - 必要素材のリスト化
これも必須でしょう。依頼する立場として、これがいる、あれがいるを脳内にとどめておくのは危険です。僕みたいにタイトルイラスト依頼を忘れてしまうから。
これをしっかりリスト化し、プロジェクト初期の時点で先に伝えておくことがマストになるでしょう。 - 素材のファイル名を揃える
これはここまで触れてこなかった部分ですが、地味に困った箇所でもあります。というのも、シナリオライターごとに素材やテキストファイルの名付け方が違うと、何が何だか分からないしどれが誰のかも分からなくなってしまうんですよね。それのせいで動作チェックや、素材の規約チェックがアホほど大変でした。複数人の素材を統合するタイプのプロジェクトでは、絶対にファイル名のルールを作った方がいいです。絶対に！！ - ウディタじゃなくてよくない？
これはシステムを作れる人がいればですが、そもそもウディタじゃなくてティラノで良くない？ というお話です。前述の通り、僕のシステムはティラノの下位互換です。そのため、使えて統合も出来るなら絶対ティラノの方がいいのです。まあUnityでもいいし……
可能なら使いやすいシステムに一新した方がいいかもしれません。そもそもこのシステムについて詳しいのが僕しかいないのもまずいです。システム改善したいってなった時に頼れるのが僕しかいないのはいかがなものでしょうか。よくないに決まっていますね。
まとめとめとめ
てなわけで、ざっくりとですがお話をまとめてみました。このドットテキストプロジェクトの統括は、なんも勉強とかせずにノリと雰囲気でやったものですので、ツッコミどころまみれだったと思います。ま、それが逆にリアリティを産んでていいんじゃないでしょうか！（適当）
というわけで駄文でしたが、こんなもんにしておこうと思います。ここまで読んでくださりありがとうございました。最後に「ドットテキスト」と韻を踏んで終わろうと思います。
そっとケーキ食お。
……コミケで待ってます！！
ありがとうございました！！