「トレジャー発掘！Diggers」サウンド製作ウラばなし　ファミコン編　その５

DeveloperBlog、Diggers、アプリ、サウンド、、、、、

■「ワギャンランド」どうしよ・・・

勢いに乗って「ワギャンランド」の耳コピ開始です。
・・・と思ったらいきなり「RP2A03」で不安な要素で上げていた自体に！

とにかく、スタッカートした音色がメインだし、アタックの緩やかなPAD系の音色もあるし・・・さらに冒頭のサンバホイッスルみたいな音とか。

ヤバい・・・とか言ってられないので「RP2A03」をいじくってみたのですが、どうにも埒が明かないので、このプラグインで再現するのはアッサリあきらめて、他の方法を考えます。

まずは「RP2A03」で４種類の矩形波と三角波を鳴らしてサンプリングを行い、PropellerHead ReasonのNN-XTというサンプラーに取り込んで再現する方針に変更することにしました。

A1～A6ぐらいでマルチサンプルにしてあげれば、そこそこ再現度は高いのではないでしょうか？

NN-XTで再現するうえで気を付けなければならないのは、※１”ポリフォニック”を１にして、いわゆるモノフォニックにしておくことと、※２”カットオフ、レゾナンス”のフィルターをかからないようにしておくことです。

3トラックにNN-XTを配置すれば、それぞれがモノフォニック音源のトラックで、合わせて3和音のいわゆるファミコン音源の雰囲気が出ると思います。

これで晴れてADSRもかけられるしモジュレーションも効く扱いやすいファミコン音源になりました。

いやぁ～ヨカッタヨカッタ・・・と耳コピを進めていたのですが、もう一つの懸案事項であるサンバホイッスルの再現という問題が残っていたのでした。
ということで次回につづく。

※１”ポリフォニック”一つの楽器で重複して鳴らせる音の数をポリフォニック数といい、１音だけだとモノフォニックとなります。
※２”カットオフ、レゾナンス”音をこもらせたり、明るくしたりできるパラメータのこと。

「トレジャー発掘！Diggers」サウンド製作ウラばなし　ファミコン編　その４

DeveloperBlog、Diggers、アプリ、サウンド、、、、、

■「ワルキューレの冒険」良い感じ？

SOCALABSの「RP2A03」を使ってさっそく「ワルキューレの冒険」を耳コピ開始です。

DutyCycleというパラメータで4種類の矩形波を切り替えることができて、三角波とノイズは別のパラメータがあって・・・ふむふむ一通りの音は出そうなのでゴリゴリ耳コピを進めてみると、なかなかクリソツにできあがりました！

ただ、「RP2A03」については不安な要素もいくつかあります。

第一に設定したパラメータをセーブできないという欠点があります。
（バグだと思う）
第二に※１”ADSR”がないのでスタッカートしたような音色やアタックの緩やかな音色が作れないというのも大きな欠点です。
第三に※２”モジュレーション”が効かないというのもMIDIで扱う上では大きな欠点でしょう。

※１　ADSRとはアタック、ディケイ、サスティーン、リリースの略で簡単に言うと音に表情をつけるパラメータのこと。
※２　モジュレーションとは音に揺らぎをあたえるパラメータのこと。

「トレジャー発掘！Diggers」サウンド製作ウラばなし　ファミコン編　その３

DeveloperBlog、Diggers、アプリ、サウンド、、、、、

■Cubaseの64ビット環境で使えるファミコン音源が無い？

まずは手始めにPSG音源、というかいわゆるファミコン音源ですね。

これについては「Magical 8bit Plug」というチップチューンで有名な音源があるので安心安心・・・と思っていたのですが！！

なんとCubaseの64ビット環境では32ビットプラグインはブラックリストに入れられていて使えないですと～！？

「Magical 8bit Plug」のHPによればMAC版は64ビット対応しているのですがWIN版はまだ対応が無いようです。

ということで慌てて調べた結果、SOCALABSの「RP2A03」というプラグインが64ビット環境でも動きそうです。

「トレジャー発掘！Diggers」サウンド製作ウラばなし　ファミコン編　その２

DeveloperBlog、Diggers、アプリ、サウンド、、、、、

■音源ごとに製作スタイルを変える

「トレジャー発掘！Diggers」ではレトロゲームのキャラクターたちのグラフィックをなるべく当時の雰囲気を出して再現するというものなので、サウンドについてもレトロな雰囲気を重視して3つの音源で鳴っているものに絞ってみました。

・PSG音源（ファミコン＝「ワルキューレの冒険」「忍者じゃじゃ丸くん」など）
・波形メモリ音源（アーケード＝「ゼビウス」「スカイキッド」など）
・FM音源（アーケード＝「源平討魔伝」「ワンダーモモ」など）

まずは8ビットとかチップチューンとか言われるジャンルでもおなじみのファミコン音源の耳コピを開始しましょうか。

「トレジャー発掘！Diggers」サウンド製作ウラばなし　ファミコン編　その1

DeveloperBlog、Diggers、アプリ、サウンド、、、、、

■カタログIPオープン化プロジェクトってことは・・・

はい、ついにリリースされました「トレジャー発掘！Diggers」のサウンド製作ウラばなしを連続モノ風に始めてみようかと思います。

この作品は、バンダイナムコさんが行っているカタログIPオープン化プロジェクトというものに参加しておりまして、「マッピー」や「ドルアーガの塔」、「ディグダグ」などバンナムその他のIPを使って2次創作をするという素晴らしい企画でして、欲張りにも開放されている全39タイトルを網羅したゲームとなっております。

コレ幸いに、というわけではありませんが伝説のあの曲やこの曲を大手を振って耳コピしても良いし、アレンジしても良いんでしょう？と意気込んでサウンド製作に取り掛かることになりました。

ということでファミコン編からスタートです

【素数ガール】この尊いアプリが出来るまで

DeveloperBlog、アプリ、素数ガール

どーも、ラディアスリーの中村です。

今回は、加藤と話しているうちに妙に盛り上がってリリースまでしてしまった素数ガールが出来たいきさつを書いてみました。

 

素数ガール

iOS / Android 共に公開されてます～。よしなに。

(ゲームマーケット前にこんなん作っちゃってるから忙しくなるんだっていう。)

 

さて、妙に盛り上がったいきさつというか、そのあたりのことについてつらつら書いてみようかと思います。

 

何の気はなしに休憩時間に話していた流れで、新しい企画についての話になり、「数を素因数分解したいんだよ。(加藤)」という謎の展開に。

そこで少し考えてみたところ、素因数分解していくよりも単純に素数かどうか判定するだけくらいのもののほうがいいんじゃないか？となりまして。

でも、それだけじゃさすがに面白くないよね…と。

 

そこで出てきた案が、「間違えると女の子になじられる」というカオス。

これは……全素数界が震撼するアプリが誕生しそうだぜ…。

 

さらに、

  • リワード広告でもらえるのが素数
  • ゴールド素数、シルバー素数、ブロンズ素数

なんていうキーワードも生まれてきました。

リワードでもらえるのが素数…？な…　何を言っているのか　わからねーと思うが…。

ブロンズ素数…？ペガサスローリング…！

 

はい。もうカオスすぎて意味不明ですね。

でもまぁここまでの企画概要だったらすぐ作れるだろうということで、開発に着手。

でも案の定、作っているうちに

  • 正解した素数はリストで確認できる
  • 女の子が2人いる
  • 途中で女の子が増える
  • 女の子には好感度があって、好感度によって言葉が多少変わる

などの欲求が発生してきました。

 

なんだか書いてみたらただの変態おじさんみたいになってるな…。

(私たちは健全なおじさんです！のはず。。。)

私はこれはネタアプリというものに属するんじゃないかと思ったのですが、加藤いわく、素数を扱った真面目で高尚なアプリであるとのこと。

 

結果どんなアプリになったのか気になる方は是非ダウンロードして遊んでみてください！

無料なので…是非。

素数ガール

 

なお、素数って何？な人にはホントに意味不明なアプリだと思います。

焦った時は素数を数えて落ち着くタイプの人には刺さる！…かもしれません。

 

ということで、今回はこれにてッッ！

【おーくしょんパーティ！】アプリ開発の環境とか手順とか

DeveloperBlog、Unity、アプリ、おーくしょんパーティ！

どーも、ラディアスリーの中村です。

今回は、おーくしょんパーティ！のアプリ版の話です。

(ゲームデザインではなく、開発寄りの話になってます。)

 

使っている(or 使う予定)ものをざっと羅列してみると

  • クライアントサイド
    • Unity
  • サーバサイド
    • AWS EC2
    • AWS Cognito
    • AWS Lambda
    • AWS DynamoDB
    • docker

とまぁこんな感じでしょうか。

(もっと詳しい話は多分加藤が書いてくれるんじゃないかと…。)

ちなみに、EC2上で稼働するサーバー側アプリケーションは javascript で記述しています。

DynamoDB は DynamoDB local というのがあるので、それを利用する予定ですが、現時点では Redis を使っています。そのうち DynamoDB に切り替え予定。

 

開発はプログラマが複数いる(現状は加藤と私の2人)という状況なので、EC2上で動作させてデバッグなんてことはできませんし、いきなり EC2 と Unity で通信して動作確認なんてこともデバッグしづらくて大変そうです。

ということで、各開発者のローカル環境でデバッグが出来るように、 docker を使ってローカルにも同じ環境が簡単に作れるようにしています。(私じゃなくて加藤が整えてくれたんですが。)

 

で、実際どんな感じに開発をすすめているの？というのが、こちら。

開発段階１ : サーバアプリの実装

とりあえず javascript でぺこぺこ書いていきます。

開発段階２ : テストクライアントの実装

html + javascript でサーバアプリと通信して簡単な表示と操作が出来るものを作ります。

ここまで進むと、chrome などのブラウザから localhost にアクセスして、ローカル環境で起動したサーバアプリとのやりとりが出来るようになります。

ここで動作確認をしてバグを修正し、一通り機能が揃ったら git で共有できる状態です。

大体こんな画面になってます。

サーバ側

ログがびろびろと吐き出されています。

大半がどんなデータが送られてきて、どんなデータを送ったかのログですね。

まぁこんな画像を見せられてもわけわからないでしょうが、雰囲気だけ…。

 

テストクライアント側

ビジュアルはなく文字ベースのものなので、わかりにくいですが必要な情報は見れるように作られています。

クエストの内容とか、各プレイヤーの所持金や所持キャラクターなどが表示されているのがわかるかと思います。

ちなみに、画像はクエスト中で、1人目のプレイヤーが1つ目のミッションをクリアした状態ですね。

ここを作りこんで時間をかけてもあまり意味がないので、この程度でよしと割り切っちゃってます。

 

開発段階３ : クライアントの実装

Unity を使って、テストクライアントで行っていた挙動を作りこんでいきます。

UI なども載せてわかりやすくしていきます。が、まだデザイナ陣が入っていないのでプログラマが適当に用意した画像になっちゃってます。

まぁ、素材の差し替えは後でいくらでもできるので、気にせず雰囲気を出す程度にしておきます。

こんな感じの画面ですね。

テストクライアントと同じ状況を Unity で表示している画像になりますが、こちらの方がビジュアル的にわかりやすくなっているんじゃないでしょうか。

後は各画面を作りこみつつ、サーバ側に不備があれば修正 → テストクライアントで確認 → Unity で実装 という繰り返しです。

一通り仕上がったら、実際に AWS 上で起動して確認します。こうなると複数のプレイヤーで実際に遊べるようになります。

そして実際に遊んでみて、改修する必要があるところを確認したり、バランス調整をしたりしていきます。

 

まだまだ開発途中でカチッとしたビジュアルが見せられず恥ずかしいですが、プログラマだけで進めている開発初期段階ってこんなもんですよね…？(誰に問いかけているのか自分でもわかりませんが。)

ということで、今回はこれにてッッ！

【おーくしょんパーティ！】アプリ版とアナログ版の違い(2)

DeveloperBlog、アナログゲーム、アプリ、おーくしょんパーティ！

どーも、ラディアスリーの中村です。

前回、アプリ版とアナログ版の大きな変更点について書きましたが、キャラクターのスキルについては書けていなかったので、そのあたりを書いてみたいと思います。

 

まずはアナログ版のスキルのおさらい。

  • Fighter : 対戦相手の好きなキャラ1枚を裏返して1ターン無効にする
  • Wizard : サイコロを2つ振って低い方の目を判定値に加える
  • Priest : サイコロを2つ振って7以上出たらミッションをクリアする
  • Thief : 対戦相手を1人選び 50G 奪う
  • Paladin : このキャラを破棄して戦闘系ミッションをクリアする

そして、これをアプリにそのまま適用しようとすると、

  • Fighter → いずれかの対戦相手を選択するという手間がかかってしまう
  • Wizard → そもそもサイコロがないのでどう扱えばいいのかわからない
  • Priest → そもそもサイコロが…
  • Thief → 対戦相手を選択…
  • Paladin → そのまま使えそうかな？

となってしまい、ほぼ使えません。

 

そこで、ガラッと内容を変更してしまうことにしました。

  • Fighter : 他の全てのプレイヤーのステータスを5秒間半減させる
  • Wizard : 5秒間 AGI 以外のステータス を倍にする
  • Priest : 自分にかかった Fighter スキルを打ち消す
  • Thief : 5秒間 AGI (移動速度)を半減する代わりにミッションをパスできる(ミッションクリアとは判定されない(報酬は得られない))
  • Paladin : このキャラクターを消滅させる代わりに、交戦中の戦闘ミッションをクリアする

こんな感じ。狙いとしてはこんな感じ↓。

  • Fighter → 他プレイヤーの邪魔スキルという性質を変えずに、手間を削減
  • Wizard → 自分を強化するスキルの性質を変えずにアプリに適用できるように
  • Priest → 回復役のイメージでスキルを刷新
  • Thief → 隠れてコソコソするイメージのスキルに変更 (ハイド・イン・シャドウ！)
  • Paladin → そのまま

 

でもこればっかりは実装してみてテストプレイしないと狙い通りかわからないですねぇ。

アナログ版もスキルの調整にかなり時間をかけましたし、アプリ版も同じ感じになるんじゃないかな…と。

 

何はともあれ、スキルを大幅に見直すということが必要であることがわかり、スキル変更の方向性も見えてきました。

ということで、今回はこれにてッッ！

【おーくしょんパーティ！】アプリ版とアナログ版の違い

DeveloperBlog、アナログゲーム、アプリ、おーくしょんパーティ！

どーも、ラディアスリーの中村です。

前回、アプリ版ではダウンタイムが長過ぎてゲームにならないだろうということで、アプリ版ではかなりルール変更をしたということを書きました。

今回はその続きで、どんなルール変更をしたのか詳しく書いていこうと思います。

 

最大の変更点…それは、クエストフェイズを手番順にプレイする形ではなく、同時進行出来るようにしたことです。

逆にオークションフェイズは、そもそも同時に金額を書いて同時にオープンするルールなので、そこはそのままいけそうだな、と。

そして、ショッピングフェイズ(アイテムを購入するフェイズ)は手番が関係するのでこれも省いてしまい、アイテム自体を無くしてしまう事にしました。

 

もう少し詳しく説明していきます。

こんな感じで、画面下部にパワーメーターを設置することにしました。

メーターをタップすると、その時のパワーと AGI に応じて自分のコマが進んで行く想定です。

例えば、ゾーンとゾーンの間の距離を100として、自分の AGI が 20、メーターが50% だとすると、その時は10進む事になって、ゾーン間の1/10 を踏破したことになります。

そして、ミッションに到達した時は、メーターのパワーと必要なステータス値に応じて達成値が溜まっていき、ミッションクリア値を越えた時にミッションをクリアした事になります。

アクションっぽい感じですね。アナログ版とはだいぶ違いますが、デジタルにはデジタルの良さがあるということで。

 

各ゾーンのミッションはある程度近づくまでは自由に選択可能で、有利なミッションを選択してもいいですし、他のプレイヤーが狙っていないミッションを選択してもいいことにしました。

複数プレイヤーが同じミッションを選択した場合、同時にそれぞれが達成値を溜めていき、先にクリア値を越えた側がミッションクリアしたこととして、クリア報酬が与えられます。

先にミッションをクリアされてしまったプレイヤーはその時点で先には進めますが、クリア報酬がもらえないという仕様にしました。

このミッション周りの仕様により、他のプレイヤーとの駆け引きが生まれる事を期待しています。

例えば、どのミッションも苦手ミッションだった場合、誰かの後をついて行きクリアしてもらうといったプレイも考えられそうです。クリア報酬は貰えませんが、その先で有利な展開が待っていそうならそういう選択肢も生まれるのかな、と。

 

これらの仕様により、絶対にクリア出来ないクエストというのはなくなるので、救済措置であったアイテムがなくなってしまっても問題なさそうです。

 

 

今回は、一番大きな変更点について説明してみました。

次回はスキルの変更点について書いてみようかと思います。

ということで、今回はこれにてッッ！

【おーくしょんパーティ！】アプリ版！

DeveloperBlog、アプリ、おーくしょんパーティ！

どーも、ラディアスリーの中村です。

今回は、ラディアスリーで開発中の「おーくしょんパーティ！」のアプリ版のことを書いてみようと思います。

 

今までアナログゲームとしての「おーくしょんパーティ！」について書いてきましたが、スマホアプリの開発も同時に進行しています！

 

アプリ開発の場合、私が最初に仕様書として書くのが画面遷移図と各画面の概要です。

このあたりは人によって違うんでしょうが、あくまでも私の場合ということで。

こんな感じで画面のつながりと、各画面に含まれる要素をざっくりと洗い出してます。

ついでにざっくりした仕様なんかも書いちゃったり。

これ、以前紹介した Confluence 上で Draw.io を使って書いてます。

ここで書ききれないような仕様については、別途 Confluence で別ページに記述するようにしています。例えば、データベースの構成とか、通信シーケンスとか…。

 

最初にこれらの仕様書を書いた時には、アナログ版と全く同じ仕様を再現するように書いていました。

しかし…いざ書いてみると、アプリとしては非常にテンポが悪そうだということがわかりました。

こりゃヤバい。。

 

どういうことかというと、アナログでは順番に手番を処理していくわけですが、アプリ版だと、どうしても待っている時間が長くてだれてしまうんですね。

１回の手番(ラウンド)を30秒とかに制限したとしても、自分以外の3人がプレイしているのを最大1分30秒も待つ事になってしまいます。

これはいかにも長い。長すぎる。

 

皆さん、こんなに待たされたらゲームやる気なくなりません？？

 

ということで、アナログ版とアプリ版でルールを変更する事にしました。

そしてアプリ用ルールを検討した結果、これが結構ガラっと変わることに…。

 

詳細は次回！

ということで、今回はこれにてッッ！

乞うご期待ッッ！！