![見出し画像](https://assets.st-note.com/production/uploads/images/145178125/rectangle_large_type_2_92900f4e6519576a92cfd6e20083be4d.png?width=1200)
【ゲーム制作録】1ぷんスライム
こんにちは、tezumozuです。
まず最初に1つご報告がございます。
私がフリーゲーム公開サイトUnity roomにて公開している
フリーゲーム「1ぷんスライム」の総アクセス数 が1000回を突破しました!
(いぇーい!どんどん!ぱふぱふ!)
![](https://assets.st-note.com/img/1718610624479-MGgCBe8aGS.png)
制作に協力してくれた知人、ゲームを紹介し拡散てくださった方々、そして何よりプレイしてくださったたくさんの方々、誠に心からお礼申し上げます。
また、プレイしてくださっただけでなく、コメントや評価も入れてくださった方もおり、今後の制作の励みになり、感謝してもしきれないほどです。
今回はアクセス1000回突破を記念し、私自身の備忘録を兼ねて1ぷんスライムの制作過程についてゲームデザインを中心にまとめてみたいと思います。
おまけ
実際にレベルデザイン時に使用していたGoogleスプレッドシートです。
バランス調整時にメモせずいじったりした箇所があったりするので、技名や実際の数値や効果が異なる点がいくつかありますが、参考程度にご活用いただけると幸いです。
シート内で使用している略称
H …… HP
A …… 攻撃
B …… 防御
S …… 素早さ
M …… MP
制作動機
今回のゲーム制作のきっかけはUnityで制作されたゲームゲームを投稿できるフリーゲーム投稿サイト「unityroom」にて開催されている「1Week GAME JAM」でした。
![](https://assets.st-note.com/img/1718590049525-LkwpRBTxSk.png?width=1200)
「1Week GAME JAM」はUnityが使える環境があればだれでも参加できるイベントで、その名の通り、月曜の0時に発表されたお題を元に1週間でゲームを作り、投稿するゲーム制作のオンラインイベントです。
参加手続きはほぼなく、期間内にゲームを投稿するだけで簡単に参加できます。
![](https://assets.st-note.com/img/1718590620853-iE9t5KvCPc.png?width=1200)
そう、実はこの「1ぷんスライム」、本来は2024年3月18日~3月24日に開催された1Week GAME JAMへ投稿する目的で制作が始まった作品だったんです。
しかし、実際は工数が膨らみすぎ、制作に一か月もかかってしまい、結果イベントには参加できなくなってしまいました。
最終的にはゴールデンウイークの頭ごろに公開ができ、多くの人に遊んでもらえたので、結果オーライだったのですが少し悔しいところが残ります。
コンセプト
2024年3月18日~3月24日に開催された1Week GAME JAMにおける出題されたお題は「かわる」でした。
私は昔から育成ゲームとかシミュレーションとか一人でやる作業的なゲームが結構好きだったので今回のお題を見た時、「何かの育成モノ」にしようと即決しました。
しかし、育成ゲームでゲームジャム用のゲームを作るには
いくつか問題がありました。
・制作するのはミニゲーム
まず、ゲームがミニゲームであることです。
ゲームジャムへ投稿するゲームはミニゲームが基本です。
ましてや制作期間は1週間、私が普段遊ぶような大規模なゲームには絶対にできません。そのため、ミニゲームサイズで育成ゲームを楽しめるデザインにする必要がありました。
・育成パートが単調
次に育成ゲームでは育成パートが単調になってしまうことです。
育成ゲームは大抵の場合、育成パートと育成結果を披露するためのゲームポートがあります。
ポケットモンスターシリーズであれば、野生のポケモンを捕まえたり、野生のポケモンとバトルしてレベリングする育成パートとライバルやジムリーダー、悪のボス、チャンピオンといった強敵と対峙するストーリーパートに分かれます。オンライン対戦であれば、ポケモンをレベリングする育成パートとランクマッチを行う対戦パートです。
育成パートはそのあとのゲームパートの準備である関係上、どうしてもレベリングや数値の調整といった作業的な操作が多くなってしまいます。
つまり、育成ゲームは性質上、作業的で単調なシーンになりやすいですのです。
この性質が、すこぶるミニゲームと相性が悪いです。
ミニゲームは短時間でさっくりできるシンプルなゲームなのですが、
育成ゲームはむしろ真逆、ゲームの仕様を理解してじっくり遊ぶゲーム。
そのままミニゲームにするとプレイ時間が長くなり、短時間でプレイできません。
また、育成パートが単調なため、ミニゲームの感覚でプレイするとどうしても飽きやすくなってしまうでしょう。
そこでまず、こうした問題を解決するべく
私はゲームの要件を以下のようにまとめました。
・育成が単調な作業にならないこと
・育成ゲームの面白さを短時間で楽しめること
(すぐに育成結果を実感できること)
そして、この要件を満たすために考えたのが以下の2つのデザインです。
・1分で育成する
・クリックゲーで育成する
・1分で育成する
シンプルに短時間で育成し、できるだけすぐにゲームパートに移ることで、
単調な時間を減らすようにすることを考えました。
この1分で育成するというのがもう一つのデザインと相性がよく、
今回のゲームの中心となるコンセプトになりました。
・クリック連打で育成する
育成はどうしてもレベリングをしたり、ステータスを振ったりするにはどうしても単調な作業になることはさけられません。
そこで、育成時間に1分という制限時間を活かしてクリック連打をして育成するゲームにして、忙しさのある作業にして単調さを紛らわそうと考えました。
そしてこれらを合わせて、コンセプトを以下のようにまとめました
育成ゲームの面白さを1分で感じられるクリック連打育成ゲーム
ゲームデザイン
モチーフ・テーマ
「かわる」というお題から、姿形が変わる様子が想像しやすいスライムをモチーフに選びました。ここから、1分でスライムを育てる育成ゲームというイメージが固まっていきました。
また、スライムをモチーフにするところからファンタジー的な世界観が一番なじみがあるので、そこから剣と魔法の世界のような世界観にすることをなんとなく決めました。
(正直そこまでここは深く考えてないです。雰囲気です雰囲気)
(本当はここをもっとしっかり考えた方が絶対間違いなく100%良いゲームになるぞ!こんな雰囲気で決めるなんてみんなマネしちゃあダメだぞ!)
ゲームサイクル
さてコンセプトを元にゲームサイクルを考えます。
現時点ですでに育成ゲームなのである程度ゲームサイクルが固まっています。
![](https://assets.st-note.com/img/1719304151855-Ayan1wXKvT.png?width=1200)
育成パート、ゲームパート基本的にはこの2つのパートをいったり来たりすることになります。
ただ、今回はコンセプト的に育成ゲームの面白さを1分で感じられる必要がありました。
そこで育成パートとゲームパートの間にリザルトパートをはさむことにしました。
![](https://assets.st-note.com/img/1719304213555-H0ZVBBrMgB.png?width=1200)
リザルトパートはいわば育成パートの育成結果を簡易的に提示するためのパートです。つまり、育成ゲームのサイクルをゲームパートをはさまずに最短1分で回せるようにするためのパートです。
このパートではゲームパートを通さない分、視覚や聴覚といったビジュアルでプレイヤーに育成結果を示す必要がありました。
そこで、今回はポケモンの進化演出のようなシーンをこのパートに当てはめることにしました。
進化演出は育てた対象が進化し、見た目が変わることでそれだけでプレイヤーに育成の結果を簡易的に提示することができます。
つまり、育成方法によって姿が変わるようにして、進化の分岐だけでも楽しめるようにしようという作戦です。
これでゲームサイクルはまとまりました。
ここからはそれぞれのパートの肉付けになります。
各パートデザイン
それぞれの各パートごとにデザインをまとめます。
実はゲームパートのデザインをしたあたりから1週間で作り上げることをほぼ諦めています。どう考えても工数が多すぎでした。
・ゲームパート
育成結果を実感するために必要にとなるゲームパートです。
育成内容を決定するためにゲームパートがどのような内容か先に決定する必要があります。
ある程度育成パートで育成できる要素(パラメータなど)が必要となるので、今回はパラメータや技、ダメージ計算式などで柔軟に要素の足し引きがしやすいRPGのバトル風にデザインしてみました。
また、アニメーションやプログラムの処理的にもアクションゲームに比べて工数が少なそうというだなと考えたのもRPG風バトルを選んだ理由です。
(実際そんなことはなかったですが)
・育成パート
クリックゲー的な要素を入れた育成パートです。
1分という制約はコンセプトですでに決まっているのでそこに合うように育成パートをデザインします。
今回はサンドバッグをクリックして経験値をたくさん稼いで強くなるというシンプルな仕組みでデザインしました。
実際に育成パートをデザインした段階はあらかたゲームパートであるバトルの仕様を確定した後でした。
(育成の内容にかかわるのでゲームパートの仕様を決めないとデザインできません。)
・リザルトパート(進化パート)
進化演出のみのシンプルなパートです。
単純な進化演出だけでなく、ステータスなどや覚えた技などを確認できるようにし、そのあとのゲームパートへ進むか再度育成するか選べるようにして、がっつり遊ぶ人でも意味があるパートになるようデザインしました。
各システムのデザイン・レベルデザイン
ここからは実際のシステムのデザインやレベルデザインを煮詰めていきます。
バトルデザイン
一つ目のゲームの肝であるバトルデザインです。
制作の工数を減らすためシンプルなものを目指し、RPG風の戦闘、初代ドラクエのようなターン式をベースに状態異常や能力変化などを織り交ぜて設計しました。
先にバトルで必要なステータスや技で発生するバフや状態異常の種類などを大まかに決めます。
必要な要素をあらかた洗い出し、バトルの処理順(フロー)を確定するためです。
(実際はターン制の実装テストなどプログラムの試作と同時に進行させています。結構行き当たりばったりです。)
・ステータス
工数を少なくするため、ステータスはできるだけシンプルにしました。
HP:ヒットポイント、体力
MP:マジックポイント、技使用時のコストになるポイント
攻撃:ダメージ計算時に必要なポイント、攻撃側の力の強さを表す
防御:ダメージ計算時に必要なポイント、防御側の耐久を表す。
素早さ:先攻後攻を決めるためのポイント
もともとは「スタミナ」という育成時にのみ使用される専用のステータスもあったのですが、育成パートのテスト時に面白くなかったので不要にり消えました。
・バフ、状態
バトルで使用したいバフや状態異常を簡単に洗い出します。
全てじゃなくてもよくて、どういったタイミングで処理が必要になりそうかざっくり確認します。
特に状態異常は毒・猛毒などと眠り・麻痺などでは発動タイミングが違うのでそれぞれのタイミングを確認し、処理に落とし込む必要がありました。
【バフ】
・攻撃力バフ、デバフ
・防御力バフ、デバフ
・属性技威力バフ、デバフ
・属性耐性バフ、デバフ
・
【状態異常】
・毒、猛毒、ボム +(リジェネ、状態異常無効)
発動タイミング:各キャラクターの行動後
回復:毒、猛毒 発動後
・麻痺、睡眠、沈黙 + ( 消費MP半減、状態異常無効)
発動タイミング:各キャラクターの行動前
回復:毒、猛毒と同じ
これらを盛り込み、最終的に出来上がった1ターン分のフローは以下のようになりました。
![](https://assets.st-note.com/img/1719305711319-fU4MAXTWWu.png)
(シンプルとはいったい……)
行動前に発動する状態異常を「BeforeStatusEffect」行動後に発動する状態異常を「AfterStatusEffect」とし、それぞれ別物として設計しました。
それぞれの項目が英語なのはこの後のプログラミングでそのまま名称を使うためです。制作時に図を描くときは変数名やクラス名にそのまま使えるので英語で書くことがおすすめです。(分かんない単語はGoogle翻訳で十分なので)
実はこのバトルデザインではポケモンの処理順やダメージ計算式を結構参考にしています。むしろ、そのままのところも多いかもしれません。
今回採用したダメージ計算式は以下の通りです。
ダメージ = ( 技の威力 * レベル * バフ込み攻撃力 * 乱数 / ( バフ込み防御力 * バフ込み属性耐性 / レベル補正定数 ) +1
ほとんどポケモンのものと同じです。
レベル補正定数は育成時のバランス調整と合わせて実機プレイしながら地道に調整しました。(実数値は30です。)
この式は分解すると以下のようになります。
・攻撃側:技の威力 * レベル * バフ込み攻撃力 * 乱数
技の威力が上がればダメージ増、
レベルが上がればダメージ増、
攻撃力が上がればダメージ増、
乱数によってダメージが増減
・防御側:バフ込み防御力 * バフ込み属性耐性
防御力が上がればダメージ減、
属性耐性が上がれば属性技のダメージ減
・レベル補正定数
基準となるレベルを設定、
基準に対してレベルが高ければ高いほどダメージ増、
基準に対してレベルが低ければダメージ減
レベルが上がればダメージも上がるが、高いレベル同士で戦闘した場合、その分HPも上がるため、結果的にダメージがほどほどになる
・式全体:( 攻撃側 / 防御側 / レベル補正定数 ) + 1
必ずダメージが1以上になり、絶対に0にならない
攻撃側と防御側の数値が僅差でもほどほどにダメージが入る
(攻撃-防御だと、この場合、全くダメージが入らなくなる)
改めて分析するとすごくよくできた計算式ですよね。
個人的にはここまで本格的なバトルシステムを作ったのが初めてだったのですごく勉強になりました。
育成・進化
ゲームの2つ目の肝となる育成のデザインです。
レベルデザインも一緒に合わせて行います。
バトルシステムに合わせて育成部分をデザインしつつ、
ミニゲームサイズで十分に楽しめるバランスを目指します。
育成方法、レベルデザイン(育成)についてそれぞれまとめます。
・育成方法
育成パートのシステムデザインです。
今回はシンプルにクリック連打して経験値を稼ぎ、
レベルを上げるシステムにしました。
1分間で連打しながら育成をすることになるので、そこそこ忙しさが感じられる1分間にできるのではないかと思い、こういったシステムにしました。
さらに、レベルを上げることでスキルポイントが獲得でき、ポイントを消費することでそれぞれのステータスのレベルを上げ数値を伸ばすことができます。
![](https://assets.st-note.com/img/1719387415122-vnd8QJdbTX.png?width=1200)
どの操作にもクリックが必要になるようにしたので、レベルデザインでは、プレイヤーが1分間に何回クリックできるかが重要になります。
・レベルデザイン(育成)
育成のレベルデザインです。
まずクリック連打ゲーとして制作する以上、今回の制限時間である
1分間に人間がどの程度クリックできるか調べるところから始めます。
どうやら人の平均クリック速度は1秒間に6回程度らしいので、
1分間分、つまり平均360回を基準にレベルアップ+スキルポイント振り合わせて360回になるよう、うまく経験値テーブルを作成します。
実際のテーブルの調整は実際にテスト実装してクリックしてみたり、
育成後のステータスをある程度想定してダメージ計算などしながら調整をします。
テーブルが決まったら、進化の法則や技修得の法則を考えます。
・基本最も高いステータスによって進化先が決まる
例:最もステータスレベルが高いステータスがHP → スライムマン
・ただし、特定の条件を満たした場合のみ特殊な進化先になる。
例:
スライムのレベルが100、もしくはすべてのステータスのレベルが同じ
→ スタイム
一度もスライムのレベルやステータスのレベルを上げない
→ フハイム
ミニゲームなので進化の法則自体はシンプルにまとめました。
しかし、シンプルすぎても味気ないので不具合対策も兼ねて一部特殊な条件を満たした場合にのみ進化する特別な進化先を用意しました。
技はこの進化形態をベースに戦闘スタイルのコンセプトを考えてまとめます。
この場合、進化形態ごとに戦闘スタイルのコンセプトがあり、ステータスのレベルに応じてコンセプトに合った技を覚えられるようにするのが簡単です。
・技は各ステータスレベルに応じて対応した系統の技を習得できる。
攻撃力であれば攻撃系の技を習得、防御なら防御系の技を習得
しかし、ただ単純にそうするだけでは以下のような問題が発生します。
・一部のステータスだけ大きく伸びた扱いにくいキャラになってしまう可能性がある。(攻撃を伸ばして多くの攻撃系の技を覚えたのにMPが少なくて使いにくい、など)
・回復系の技などどの進化先でも使用したい基本的な技がある。
(状態異常を回復するために特定のステータスを一定まで上げなければいけない、など)
そこで、これを解決するために以下のような法則を追加しました。
・技をHP系とMP系の2系統に分ける
HPとMPのステータスレベルを比較したとき、
HPが多い場合、MP消費少な目の物理系(属性のない攻撃)の技を習得する、MPが多い場合、MP消費が多い代わりに弱点をつける魔法系(属性のある攻撃)の技を習得する。
MPの消費が激しい技はMPが多いときのみしか覚えられなくなる。
・HPとMPは戦闘用の技の代わりに、回復系の技が覚えられる
HPとMPで1つの系統、2つのステータスレベルの合計値を元に習得。
どの系統でも回復系の技を習得しやすくする
これらをまとめ、最終的に以下のようなコンセプトでまとまりました。
・HP型:スライムマン
高いHPを活かしつつ、攻撃、防御、妨害の3種の物理技をバランスよく使う
・MP型:エレメントスライム
高いMPを活かして多彩な攻撃、防御、妨害の3種の魔法技をバランスよく使う
・HP系攻撃型:モーニングスライム
物理技を中心にバフで火力を盛って一撃必殺で相手をしとめる
アタッカー
・MP系攻撃型:モーニングスライム
バフと弱点を突いて大ダメージを狙う
アタッカー
・HP系防御型:スライムメット
高い防御力を活かして耐久する
ディフェンダー
・MP系防御型:スライムメット
高い防御力で耐久しつつ、デバフや弱点をうまく活用して戦う
ディフェンダー
・HP系素早さ型:スライムケミカル
自身を毒にする代わりに強力な技を使う
テクニカルアタッカー
・MP系素早さ型:スライムケミカル
相手が状態異常の時に追加効果を得る技を駆使して戦う
テクニカルアタッカー
また、特殊な進化先は専用の強い技を持たせ、特別感を持たせています。
・スタイム
ステータスの代わりに自身のレベルを参照してすべての系統の技を覚える最強スライム。また、最強の専用技も持つ、ぶっ壊れスライム。
・フハイム
ステータスがランダム変化し、さらにそこからHPと攻撃を2倍にする強力な補正がかかるギャンブルスライム。
自身のHPを犠牲に強力な効果やダメージを与える専用技を覚える。
ここまで来たら、コンセプトを元に習得する技の内容と、習得に必要なステータスレベルの一覧を作成します。
せっかくいろいろな型に進化できるのでしっかりどの型でもクリアできるくらいには強くなるように目指しました。
特にバランス型の事を考え、通常の習得できる技はステータスレベル50前後になればほどほどの技が覚えられるようにしつつ、振り切った時にしっかりコンセプトに合った戦い方ができるようなレベルデザインにしました。
敵モンスター
スライム同様、コンセプトを持たせつつ、各スライムの長所を生かせるよう意識してデザインしました。
・イービルスライム:
コンセプト:基本の「き」
弱点:炎
通常攻撃に加えて状態異常やバフを使い基本的な戦い方をする敵
・スケルトン:
コンセプト:炎、攻撃的
弱点:氷
攻撃系バフをメインに使って攻撃的に戦う
プレイヤーの防御性能も下げてより大ダメージを狙ってくる
・ミミック:
コンセプト:氷、状態異常
弱点:雷
状態異常をメインに使う厄介な敵
想定以上に強くなりすぎたクソモンスター
実はリリース前に技「箱にこもる」をナーフした
・ゴーレム:
コンセプト:雷、防御的
弱点:炎
属性防御や防御力を上げる防御型モンスター
防御によりすぎて地味になってしまった。
・ドラゴン(ラスボス):
コンセプト:強い、超攻撃的
弱点:コメット、メテオ(実質弱点なし)
段階的に攻撃系のバフを自身に付与して大ダメージを狙う正統派ボス
HPが少なくなると大ダメージを与えてくる強力な技を使用する
弱点をそれぞれ分散し、各魔法の使いどころを用意したり、
ただ攻撃するだけでは勝てないような相手を用意して考えて戦う必要があるようにデザインしました。
正直モンスターの挙動のデザインは一部効果や状態異常強すぎたり、むしろ弱すぎたりでバランスが悪く、実はあまり気に入っていません。
特にゴーレムはただ固いだけのでくの坊感が否めません。
ここまできたら後はテストプレイしながら各々の技や敵のバランスを調整して、ゲームバランスを整えます。
制作工程
ゲーム制作時の制作手順をざっくりですが、まとめます。
大まかな流れは章立てと同じような流れなのですが、実際はかなり行ったり来たりしてデザイン・制作しています。
制作手順
1.コンセプト、テーマ、モチーフの選定
今回はお題「かえる」に合わせてそれぞれ考えました。
2.大まかなゲームデザイン
コンセプトに合わせて大まかなゲームサイクルをデザインします。
今回は育成パートとゲームパートをベースに育成ゲームの構図をミニゲーム風にアレンジしました。
画面設計
ここからはゲームデザイン以外で触れられていなかったところをざっくりまとめます。
ゲームのパートをベースにUnityのScene単位で画面を設計し、その後、各シーン内におけるUIの切り替による実装する画面をまとめました。
![](https://assets.st-note.com/img/1719306448247-odppu2onbg.png)
この図はUML図の図をベースにplantUMLというUML図を作るのに特化した言語を用いて作成しています。
他にもいろんなUML図が描けるので、
ご興味のある方はぜひ試してみてください。
コーディング・プログラミング
ゲームサイクルや画面遷移図を元に大まかにゲームがとりうる状態を各シーンごとにステートマシン図でまとめ、処理の全体像を把握します。
![](https://assets.st-note.com/img/1719306697443-MXCy0wPKAt.png)
そして各シーンでまとめたステートマシン図を元に大まかな処理の枠組みをコーディングします。
この時、アクティビティ図やユースケース図を使って処理の流れをまとめながら、クラス図でクラス設計を進めます。
作っている途中で仕様変更なんてざらにあるのでいきなり全部決めようとせずほどほどにまとめる程度に描きます。ただ、しっかり描いておく処理の流れや全体像がはっきりして制作効率が大きく上がるのでテキトー過ぎないよう注意します。
![](https://assets.st-note.com/img/1719307785673-gqUBqqzhtQ.png)
(クラス図ぐっちゃぐちゃで見せられるものじゃなかったです。ごめんなさい)
後はこれらの図を元に実際にゲームの枠組みとなるプログラムを作成していきます。
この順番でプログラムを作成するとゲームの状態(大まかな処理の流れ)から制作することになるので、全体像が把握しやすく、ゲームの流れ自体が変わらなければある程度、細かな仕様変更に柔軟に対応できて作りやすい気がします。
また、一気に全部作るのではなく、各シーンごとにテストしながら順を追って丁寧に作ると制作中にごっちゃにならずに済みます。
ゲームの枠組みができたら、いよいよ敵の挙動や技の仕様をプログラムとして制作、パラメータを入力し、ある程度まで完成させます。
試作・実験
今回は本格的なバトルシステムの制作が初めてだったので、バトルシステムは結構念入りにテストしながら作成しました。
1.戦闘シーンにおけるメインとなる状態遷移のテスト
2.各状態におけるサブ状態の遷移のテスト
3.バトルにおけるターンの切り替えテスト
4.バトルの一連の状態の遷移テスト
5.通常攻撃処理を使った戦闘終了時の状態遷移テスト
6.各状態異常や技のテスト
ここに書いた以外にも結構細かくテストしています。
(それにより、工数が増えに増え大変なことになったのですが)
その他のパートにける状態遷移のテストもしていたりします。
アクションゲームとか格闘ゲームとかではないのでアルゴリズム自体はシンプルなことが多くそこまで処理速度が重要なゲームではないのでゲームの状態遷移のテストがほとんどです。
UIデザイン
ある程度ゲームのコードが完成して来たらUIをデザインして画面の見た目をまとめます。本当は画面設計の段階でやりたいのですが、コードを書き上げられる自信がなかったのである程度完成が見込めるようになるこのタイミングで作りました。
最初はラフを適当な紙にでも書いてまとめ、その後Unityの標準アセットを使って仮組します。
![](https://assets.st-note.com/img/1719387748893-FTKt7YUpmr.png?width=1200)
![](https://assets.st-note.com/img/1719387770807-OdU1Y6WyYo.png?width=1200)
初期にはスタミナという仕様があったがその後削除した
仮組が終わったらillustratorやPhotoshopでUIを作成し、実装します。
![](https://assets.st-note.com/img/1719387894916-Gj4uKoxzSr.png?width=1200)
![](https://assets.st-note.com/img/1719387942613-QYiU0zfTBV.png?width=1200)
後はUIの実装に合わせてコードも追加し、マネージャ系のクラスから動的に変更できるようにして完成です。
イラスト
今回は知人の 殻沙糖(X:@Kaki_osatou)さんにゲーム内のイラストを描いていただきました。
UIの仮組時点で必要な画像のサイズがわかるので、それに合わせて画像の制作依頼をします。
今回のゲームはドラクエのような馴染み深い「剣と魔法の世界」的なファンタジーっぽい世界感を目指しているのでその旨を伝え、デザインしてもらいました。
またスライムは育成する対象なので、愛着が沸きやすいようにかわいいデザインにしてほしいということも伝えました。
![](https://assets.st-note.com/img/1719388870687-gcdHbNanTu.png?width=1200)
愛でたくなる可愛いスライム
![](https://assets.st-note.com/img/1719388892557-D0YuMLtVfh.png?width=1200)
いい感じにキモ可愛い
一部少し世界観からずれるかなと思うようなデザインもあるのですが、見た目の可愛さや面白さを重視して採用したイラストもあります。
![](https://assets.st-note.com/img/1719389049279-cgFsqI5ziy.png?width=1200)
![](https://assets.st-note.com/img/1719389080123-fihxdfANI3.png?width=1200)
この辺はイラストレータの方と話し合いゲームの方向性とうまく折衝していきます。
改めてイラスト作成、誠にありがとうございました。
サウンド
フリーのBGM・SE音配布サイト「魔王魂」様から音源をお借りして実装します。
視聴ができるので、イメージに合う音楽や効果音を探してダウンロードしてゲームに追加します。
実際に使用したBGM・SEの一例
勝利
・ジングル02
敗北
・アコースティック43
Evoシーン
ドラムロール
ワンポイント29
ジングル 9
Training
・システム 36 EXP
・システム 24 sutatus
・システム 37 Level
・システム39
・笛 01
また、BGM・SEの実装に合わせてゲーム内で音量を調節できる機能も一緒に実装しました。この辺になってくると作りこみの領域なので工数や技術力と相談になります。
反省点
図鑑機能が欲しかった
1分の育成パートを楽しむためのシステムがほとんどなく、せめて図鑑機能のようなものがあれば育成だけでも楽しむということがもっとできたんじゃないかと思いました。
スライムマン、エレメントスライムの個性がうすい
バランス型というコンセプトにしてしまったため、どのくらいステータスを盛れば程よく技が覚えられるのか知っていないと扱いにくい進化先になってしまいました。
ゴーレムの個性もうすい
敵のレベルデザインでも触れましたが、ただ固いだけのでくの坊感がでてしまいました。もう少し何かできなかったかと悔しい限りです。
進化パートからタイトルに戻る方法がわかりにくい
進化パートからタイトルに戻るための方法がわかりにくくなってしまった。
リザルト画面にタイトルに戻るためのボタンを置く方がよかった。
まとめ
今回は制作期間1か月で今まで一番時間をかけて制作したゲームになりました。特にバトルシステムなどは初めて制作することもあり、実装やバランス調整が凄く大変な開発でした。
今回はバランス調整に当たり、何度かプレイしながらそれぞれのパラメータを調整していったのですが、開発段階ではこうしたテストプレイの数がゲームの面白さに直結することを改めて実感しました。
特に特定のプレイヤー(がっつり遊びプレイヤーや、育成だけを遊びたいプレイヤーなど)を想定してテストプレイをすることが重要で、調整の方向性を決める判断材料にしていました。
そのため、調整には時間がかかってしまったのですが、多くの人に遊んでいただけたので悪くないバランスにはできたのかなと思っています。
今回は1週間で作る予定が1か月に伸びてしまい、ゲームジャムに応募できなかったので次回はしっかりできるようアセット制作と工数見積もりを勉強して再チャレンジしたいです。
あとがき
会社で働いてる中では自分で作品を仕上げるなんて夢のまた夢で、
自分の作品と思えるものを一つ作れたうえ、アクセス数も1000を突破し多くの人に遊んでいただくことができ、貴重な経験になりました。
まとめにも書きましたが、今回はゲームジャムの参加を逃してしまったのでまた次回1Weekの開催が決定したときにチャレンジしたいです。
改めて制作に協力してくださった方、動画などでゲームを紹介してくださった方、そしてプレイしてくださった皆様、誠にありがとうございます。
どうしても個人・少数人による製作であるため、大きなゲームは作るのが難しいですが、今後もnote同様、ゲーム制作もしっかり頑張っていきたいです。
有料エリアについて
前回から活動応援用の有料エリアを設定しております。
購入してもお礼のみで
特になにか得になる文章が書いてあるわけではありません。
あらかじめご了承ください。
活動を応援していただける場合のみご購入していただければと思います。
以下有料エリアです。
ここから先は
¥ 180
この記事が気に入ったらサポートをしてみませんか?