どーも、ラディアスリーの中村です。
今回は、ラディアスリーで開発中の「おーくしょんパーティ！」のアプリ版のことを書いてみようと思います。
今までアナログゲームとしての「おーくしょんパーティ！」について書いてきましたが、スマホアプリの開発も同時に進行しています！
アプリ開発の場合、私が最初に仕様書として書くのが画面遷移図と各画面の概要です。
このあたりは人によって違うんでしょうが、あくまでも私の場合ということで。
こんな感じで画面のつながりと、各画面に含まれる要素をざっくりと洗い出してます。
ついでにざっくりした仕様なんかも書いちゃったり。
これ、以前紹介した Confluence 上で Draw.io を使って書いてます。
ここで書ききれないような仕様については、別途 Confluence で別ページに記述するようにしています。例えば、データベースの構成とか、通信シーケンスとか…。
最初にこれらの仕様書を書いた時には、アナログ版と全く同じ仕様を再現するように書いていました。
しかし…いざ書いてみると、アプリとしては非常にテンポが悪そうだということがわかりました。
こりゃヤバい。。
どういうことかというと、アナログでは順番に手番を処理していくわけですが、アプリ版だと、どうしても待っている時間が長くてだれてしまうんですね。
１回の手番(ラウンド)を30秒とかに制限したとしても、自分以外の3人がプレイしているのを最大1分30秒も待つ事になってしまいます。
これはいかにも長い。長すぎる。
皆さん、こんなに待たされたらゲームやる気なくなりません？？
ということで、アナログ版とアプリ版でルールを変更する事にしました。
そしてアプリ用ルールを検討した結果、これが結構ガラっと変わることに…。
詳細は次回！
ということで、今回はこれにてッッ！
乞うご期待ッッ！！
サウンド担当の伊佐と申します。
よろしくお願いします。
ゲーム体験において、グラフィクスやゲームシステムとともに非常に重要なファクターとして存在しているサウンド。
その「ゲームサウンド」について、これから何回かに分けてお話していこうかと思います。
昨今、スマホのゲームなどでは大手ゲームデベロッパーの作品以外ではサウンドは非常に軽視されている風潮が見られます。
なかには、サウンドがほとんどなくて「スマホをミュートしてたっけ？」と勘違いした作品すらあったぐらいです。
スマホゲームを開発しているような小さなゲームデベロッパーでは、iOSとAndroidをターゲットにしてUnity等のゲームエンジンで作成する場合が多いと思います。
iOSとAndroidの2種類作ればOKと思っていたのが、OSのバージョンや画面解像度、ビルド環境など、結構な数のマルチデバイス対応に追われることになり、グラフィクスや通信周りのプログラムに投資しているうちにリリースのデッドラインが近づいてサウンドにまで手が回らない。
というのが実情だったりするのではないでしょうか？
予算が少ないとか、開発期間が少ないとか、そもそも開発メンバーが少ないとか、いろいろあるのでしょうが・・・
ではどうすれば良いのか？
だったら「予算も期間もメンバーも増やせばよくね？」と思うかもしれませんが、それでは話が終わってしまうので、開発規模が小さくてもサウンドまで手が回る制作フローみたいなものを考えてみましょう。
ゲーム開発においてサウンドの発注はほとんどの場合「サウンドリスト」によって行われます。
プランナーもしくはディレクターから発注されることが多いですが、ようはゲーム全体を把握しているスタッフが、ゲームに必要なサウンドをリストアップしてサウンドの発注リストを作成することになります。
例として最近流行りのカードバトルゲームのバトルシーンの「サウンドリスト」を作成してみました。
最低限必要な情報はこのようなものでしょう。
あとはファイルフォーマットの指定で「 44.1khz 16bit の .wavファイルと.oggファイル mono でも stereo でも構いません。」みたいな１文があればOKです。
さぁ、出来上がった「サウンドリスト」をサウンド担当者に渡せば、ステキなサウンドが出来上がってくるまで待っていれば良い・・・というわけではありません。
従来、映画やアニメ等の映像制作の現場では「音入れ」といって編集済みの映像にBGMや効果音、アフレコを行ってようやく作品が出来上がるという、ポストプロセスに属する分野でも最後の工程と考えられています。
アフレコ作業時に絵がないということもあるそうですが、大抵は出来上がった映像に「音入れ」するわけです。
ゲームに置き換えてみるなら、絵も動きも出来上がった状態から音を作ることになりそうですが、お察しの通りゲーム開発の現場でそのような作りができることは奇跡に近いでしょう。
「サウンドリスト」にプラスして「ゲームフロー図」や「キャラ設定表」「絵コンテ」動きのわかる「ムービー」等、サウンド担当者が作業時にイメージしやすい資料を共有する・・・が正解です。
一見サウンドとは関係ないようにも思えますが、「絵」や「動き」や「演出」に対して音をつける訳ですから、もっとも重要な要素とも言えます。
つまり、ゲーム開発の作業フローを考えるなら、小規模な開発であっても上記のような資料を開発メンバーで共有することが「サウンドまで手が回る」開発の一助になると考えます。
特にサウンドを外注する場合は、期間や予算の関係から、イメージが合わないといって簡単にリテイクを出したりすることが難しいので、実は資料を作るというプリプロセスが大事だったりします。
今回はこの辺で・・・
次回は上記のサウンドリストを元に作成したデモ音源を交えつつ「SE作成」のお話です。
どーも、ラディアスリーの中村です。
今回は、前回確率を計算してみるか…なんて書いたので、実際に計算をしてみようという話です。
まず、2D6のそれぞれの出目が出現する確率についてです。
まぁこんなのはググれば一発で出て来そうですが一応…。
6面体のダイスを2つ振ると6面x6面となって、36パターンの出目があります。
一つを赤、一つを青のサイコロとして考えるとわかりやすいと思いますし、これくらいなら全パターン書き出してしまってもいいかもですね。
よし、書いちゃおう。
とまぁこうなるわけでして、各出目を数え上げると確率は以下のようになります。
で、各キャラのスキル値(2D6の出目)と確率は以下のようになります。
スキル値はそれぞれ2種類あるので、それぞれの出現確率を足したものがスキルの発動率になってます。
さて、次にPriestのスキルが成功する確率です。
7以上が成功なので、ここだけ見れば出目7～12の確率を足した 21/36 になります。
スキル発動の後の成功率 ですから、これをかけ算して がPriestのスキル成功率ということになりますね。
なので、こんな感じ。
1回発生するまでの平均ラウンド数は成功確率の逆数なので、例えば Priest A だと 1296 / 231 を計算すればいいことになります。
この表を見ると、1クエストが最大8ラウンドなので、1クエスト中に1度は成功するということになり、なかなかどうして丁度いいくらいの確率かと。
Priest が複数いると結構いい感じのパーティになりそうな予感…。
もう一つ計算してみましょう。
Wizard のスキルで加算される判定値です。
2つの出目の低い方を採用するわけですから、どちらかに1が出れば1ですし、どちらかに2が出て1がない場合は2…という風に数え上げていくと、こんな感じ。
例によって赤いダイスと青いダイスに分けて考えるとわかりやすいでしょう。
と、全部の出目を並べて数えると各加算値の出現確率は
2D6を振って低い方の目を採用すると大体3回に1回は1の目が出るんですねぇ…。
そして、スキル発動率をかけ算すると、それぞれの出現確率がわかります。
見た感じ、いかにも確率が低いように思いますが、発動さえすれば必ず1以上のプラスが得られるので実はそんなに悪いスキルではないと思います。
とまぁこんな感じで確率を計算してみるとバランス調整に役立つと思います。
…とか言いながら調整終わってから計算してるんですけど。反省。
結構面倒くさかったけど、改めてこうやって数値化してみるとテストプレイの実感が裏付けられたような感じで、思いのほか有効でした。
ということで、今回はこれにてッッ！
どーも、ラディアスリーの中村です。
今回は、開発に使っているツールについて書いてみようかと思います。
開発に使っているツールと言っても
とかいう話ではなくて、ドキュメンテーションとか進捗管理の話です。
で、今回のメインテーマですが、Confluence と JIRA です。
アプリ開発とかでは使ってるところが多いんじゃないかと思うんですが、これってアナログゲーム開発の世界でも一般的なんですかね？
知っている人も多いと思いますが、知らない人向けに書きますので「もう運用しとるわッ」って方はスルーを…じゃなくて軽くでも目を通してもらえたら嬉しいなぁ…。
まずは Confluence から。
https://ja.atlassian.com/software/confluence
これですね。
まぁ、なんでしょう。wikiみたいなもんですかね。それ以外の使い方もできるだろうけど。
ラディアスリーではクラウドのサービスを使っています。
自社でサーバーを用意する必要がないので運用が楽です。
それに10ユーザーまでなら 月額10$ なので安い！
10人で使ったら一人当たり 100円/月 くらいですよ！子供のお小遣いでも運用できそうですね。
簡単な使い方しかしていないので、wikiっぽい使い方にしかなっていませんが、それでも便利ですよ。
「おーくしょんパーティ！」の開発で使っているのが Roadmap Planner と Draw.io という2つのマクロです。
Confluence ではマクロで機能追加ができます。あらかじめ使えるものもありますし、Atlassian Marketplace for Confluenceで公開されているものもあります。Draw.ioはマーケットからインストールしました。(無料！)
Roadmap Planner では大まかなスケジュールの線を引いています。こんな感じ↓
Draw.io はデジタル版の画面遷移図とか通信シーケンスを書いたりしています。こんな感じ↓
ダイアグラム記述のためのマクロですが PowerPointっぽく使うこともできるので、結構使い出があると思います。
https://ja.atlassian.com/software/jira
もう一つの JIRA ですが、こちらはアジャイル開発用のツールですね。
こちらも10人までなら月10$。安ッッ！
普通はアプリ開発とかで使うんでしょうかね。でも今はアナログ版の「おーくしょんパーティ！」の開発で使っています。こんな感じ↓
こういったツールを使わない場合でも、どういった作業が残っているのかリストアップしたりはすると思いますが、どれだけ終わったのか視覚的にわかりやすいのと、メンバー全員がどこでも確認できるというクラウドの便利さがあるので愛用しています。
ホワイトボードに付箋を貼っているのと変わりないですが、場所によらず確認できるメリットがあるのでこっちの方がいいかな、と。
一番左にあるのがこれからやる作業、左から2番目にあるのがやっている作業、3番目が終わってみんなの確認中、一番右に行くと完全に終わった作業、という仕分けです。
各作業 (課題とかチケットと言います) の列を移動させるのはドラッグ＆ドロップするだけなので簡単です。
「おーくしょんパーティ！」の開発では大体2週間で1区切り (スプリントと言います) としています。その間にやるべき作業のリストだけがこの画面に現れるので、今何をすべきかはっきりしてわかりやすく、迷子にならず作業に集中できていい感じです。
あ、ちなみに FUJISAWA ってのはプロジェクトのコードネームです。東海道五十三次を驀進中。ラディアスリーの前身のサークル時代から続いているので途中からスタートしている感じになっちゃってます。
アナログ版もデジタル版も、こんな感じで周辺ツールを使いながら開発しています。もしこういったツールを使っていないという方は試しに使ってみてはどうでしょうか。
ということで、今回はこれにてッッ！
どーも、ラディアスリーの中村です。
前回の続きで「おーくしょんパーティ！」のスキルを改良していったことについて書いてみようと思います。
前回、 Priest のスキルが弱いってところで説明が終わっていました。
注目の Priest のスキルですが、Paladin と同じようにミッションをクリアするスキルとしました。
ただ、Paladin は発動すれば破棄というペナルティはあるものの100%クリアできるのに対して、Priest はスキル発動後にさらにダイスロールで成否を決めます。
ゾロ目だと成功！って感じ出ますよね。
…なんですが、やってみると明らかに成功率が低すぎる。
スキル発動はしやすいようにスキル値を設定していましたが、発動後の成功確率が 1/6 となっているので、4人プレイの1クエストでもこのスキルが成功することがないことがザラという…。
方向性は悪くなさそうだったんですが、これはなんとかしなければ。。。
あと、何気に変わっているのが Wizard と Thief のスキルです。
Wizard はガッツリ変わってしまってますが、従来の「キャラ1枚を選んでこのターンの間ステータスを倍にする」だと、ステータスが低いキャラばかりを取得している場合、なんの救済にもならないんですよね。
そのため、ダイス目を直接加えられるようにしました。
ただ、1D6(6面体ダイス1個って意味です) を直接加えるとかなり強い。そこで武藤が提案したのが、2つ振って低い方を使うという方式。
確かに過去やったTRPG(テーブルトークRPG) とかでこういうダイスロールあったわ〜…ということで採用。
なかなかいいスキルに仕立て上りました。
Thief については、必ずしも現時点で所持金が多い人が有利というわけでもないので、奪う相手を選べるようにしました。
これだと、もしかしたら2位狙いという消極的な作戦も生まれるかもしれませんが。
しかし、100Gというのがあまりにも強い。
1度発動すると、奪われた側は-100G、奪った側は+100Gということで、両社間では都合200Gの差がつくんですよね。
クエストの1位報酬が500Gとしているので、いかにもバランスが悪そうです。
未だ問題があった Priest のスキルですが、いっそ発動したら半分以上は成功としても良いのかと思い、思い切って2D6で7以上とすることにしました。
ちゃんと計算してないんですが、4ラウンドに1度くらい発動成功する感じかと思います。(…ちゃんと計算しろって話ですよね。。。今度計算してみるか…。)
この思い切った修正はかなりいい塩梅で、これを正式採用としました。
そして Thief については 100G 奪うというところを 50G に変更しました。
こちらもなかなかいい感じだったので、この辺りが落とし所かな、と。
スキルの改良については、これで終了としました。
ただ、スキル値はやはり調整しないと出やすさや有効度が適切ではない、と。
例えば Wizard のスキルは ダイス目が高い時に発動しても、すでにクリアしている可能性が高いので、そういうケースでは嬉しくない。だから低い目で発動するように調整する必要があるよね、とか。
そのため、スキルはそのままでも、さらに何度かスキル値の調整が入って最終形となりました。
ちょっと長くなりましたが、こんな変遷を経て最終データに到達しました。
なかなかいい感じになったんじゃないかと思いますがどうでしょう？(といっても未発売のゲームについて感想を求めてもしょうがないですよね…。)
ということで、今回はこれにてッッ！
どーも、ラディアスリーの中村です。
今回は、「おーくしょんパーティ！」のスキルを改良していったことについて書いてみようと思います。
ゲームのルールについては、最初からほぼ変更なく大丈夫そうだったのですが、問題となったのはスキル。
実は一番最初の試作ではスキルがなかったんです！
最初にプレイした時に、各キャラの性格付けがステータスの偏りだけで個性が乏しい感じがするということで、スキルをつけようということになりました。
面白いアイディアで良かったのですが、逆にそのスキルが曲者で、各キャラのスキルの強さに偏りがあるとオークションで競り落とせてもガッカリ…なんてことも。
出来るだけ状況に応じて良し悪しが生まれるようにするために、スキルの強さの印象を出来るだけ同じレベルにしたくて苦労しました。
なんと！過去データを振り返ってみたら最初は Paladin がいなかったんですねぇ。
そして、Fighter のスキルは最初から変わらず対戦相手のどれか1キャラを無効にするスキルのままでした。
この時のテストプレイでは、Priestが弱い！ってことで一致しました。
そして、スキル値が1種類しかなく(TypeA = 6, B=5, C=4, D=3)、スキルがほとんど発動しない、というところ。
本来スキルは低いダイス目だった時の救済になるように、低い数値にしていたんですが、結局そこからいくつか数をプラスできたところでミッションクリアはできない…というような状況も多く、効果的なスキルにならなかったんですね。
Paladin登場！もう少し毛色の違うスキルを作ってみようと新たなキャラを作りました。
そして、スキル値を2種類にしてスキルが発動しやすくしたのもこのタイミングでした。
Paladinは普通に強かった！ 使えるスキルって感じで投入成功でした。調査系ミッションに効かないとか、使うと死ぬとかリスクもあるのでバランスも悪くないかな、と。
そして改良ポイントのPriestスキルはというと…なんだか全然違うものになってしまいました。
これは、Fighterが対戦相手のステータスに、Wizardが自分のダイス目に、Thiefが対戦相手のゴールドに働きかけるものであるので、それ以外のものに働きかけるスキルだといいんじゃないかと思ったからでした。
そして、自分がクリアできないミッションを変更したり、対戦相手が簡単に突破できそうなミッションを変更して邪魔したりといった使い方でプレイに幅が出るんじゃないか…と。
しかしやってみると…やっぱりPriest弱い！と。
ミッションに挑戦してダイスを振った後にミッションを交換するので、どうやっても勝ち目がないミッションが残されていると最良のケースでも1ターン無駄になってしまうんですね。
そして、その1ターン遅れをとるというのがかなりゴール順位に影響してしまうので、あまり嬉しくない…。
さて、どうしたものか……。
ちょっと長くなってきたので、後篇に続く…
ということで、今回はこれにてッッ！