中村 良 のすべての投稿

中村 良 について

副社長 兼 エンジニア ゲームデザイン・設計・クライアントプログラム・サーバプログラム(少々)・デザインデータの仮素材作成など結構いろいろやります。 会社運営関連の社内システム整備などもやったりと下っ端感が半端ない40代男性。

【おーくしょんパーティ!】カードの天地について悩む

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

今回は、まだまだアナログゲーム素人の私たちがカードデータ入稿直前に思い悩んだことについてです。

 

おーくしょんパーティ!のカードは横型のカードになっています。

こんなのね↓。

 

で、表と裏をこういう形で天地を合わせたい、と。

 

 

入稿用のテンプレートは縦型だったので、カードの天地を合わせて、こういう形のデータにするのか?と思ったんですが…

 

縦型のテンプレートなので、下辺が地となって合わさるのではなかろうか?ということで、正解はこっちなのでは?と。

 

地の辺を合わせてひっくり返すと、本来地として一致させたい辺が合わさるのはこの向きのデータになるのでは…と。

(わからない場合は、手元の紙で地側にしるしをつけてひっくり返したりするとわかるかと思います。)

 

と、こんなことを話していたら、そもそもカードの天地をこういう形で合わせること自体が正しいのだろうか?という疑問が…。

どういうことかというと、カードが裏で置かれていて、それを表にひっくり返す時に人間はどちら向きにひっくり返すのが自然なのだろうか?ということです。

…話のつながりがわからないですね…。

もう少し詳しく説明します。

カードの天地が最初に言っていた形で印刷されていたとすると、カードをひっくり返す時に横方向にひっくり返すと天地が正しいおもて面が出てきます。

しかし、縦方向にひっくり返すと…

合わさった地側が上に移動するのでこういった結果に…。

 

逆にカードの表と裏で天地が逆になっているカードであれば、

さっきとは逆で横方向にひっくり返すと天地が正しくなくなってしまいます。

 

では、どちらのデザインが正しいんでしょうか…?

デザインという意味合いでは表も裏も天地が揃っている方が気持ちがいい気がします。

ではUX観点ではどうなのか?

(UXはユーザーエクスペリエンスのことです。ここでは使い勝手の良さとかそんな意味合いですかね。)

人間が手なりでカードをめくる時、縦横どちらの方向にめくるのが一般的なのか?

はたまた、短辺方向・長辺方向のどちらの方向にめくるのが一般的なのか?

右利きの人と左利きの人ではめくりやすい方向が違うのか??

 

自分でカードを裏返してみればみるほど、どっちが正しいのかわからなくなってしまい…結論としては、デザイン観点での天地合わせをしておけばいいのでは?ということになりました。

 

このあたりについてアナログゲーム界隈では明確に何か結論が出ていたりするもんなんでしょうか?

もし知っているよ、という方は教えていただけたらありがたいです。

 

なんだかモヤっとした結論になってしまいましたが、今回はこれにてッッ!

【おーくしょんパーティ!】自前でパッケージング作業

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

今回は、おーくしょんパーティ!の箱詰めに関する話です。

(ちょっと嘘です。今回は箱詰めの前段階の話です。)

 

パッケージングを自分でやる…?正気の沙汰とは思えない…。とお思いかと思いますが、やっぱりやってもらうと原価がね。

ということで、自分たちで空き時間を少しずつ使ってパッケージングしています。

 

今回は箱詰めではなく、その前段階の小物を小袋に入れる作業です。

使う小袋はコチラ。

小さいのと大きいのがありますが、小さいのはダイスとコマを入れる袋で、大きいのはマーカーペンを入れる袋です。

 

まず、ダイスとコマを入れます。が、入れ忘れや色の重複などのミスを避けるためにこんな用紙を用意してみました。

(こういうのは普通にやられているものなんでしょうかね?)

適当に Illustrator でデータを作ってプリンタで印刷したものを適当に切っただけの簡単なものです。

まず、このシートを並べます。

対応するところにそれぞれのコンポーネントと小袋を置いていきます。

コンポーネントを置くときに、コマにぐらつきがないか、とか、ダイスに異常がないかなどを軽くチェックしていきます。

あとは並べたものを小袋に詰めて行って完了です。

 

マーカーペンも同様に…なんですが、念のため1本1本書けるかどうかのチェックをしています。

 

 

結構自前でやるのは大変なんだなぁ…。

でも、デジタルの世界で活動しているだけでは経験できないことができて、とても刺激になります!

とはいえ、もっと数量が多くなったら自分たちだけでは対応できなくなってしまうんでしょうね。

(そんなに売れるんだったら、それはとても嬉しいことなんですが。)

 

箱に詰める作業は…まだ箱がないのでできません!

箱詰めの様子はまた日を改めて…。

 

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

【おーくしょんパーティ!】拡張カードセットを作りたいって話

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

今回はおーくしょんパーティ!の話なんですが、まだ先のことになるであろう話です。

 

拡張カードセット作りたいんですよね~。

なんと気の早いことか。完成もしてないのに。どれだけ売れるかもわからないのに。

せめてブログに書いて、はやる気持ちを抑えよう、と。

 

何を拡張するか。

拡張できるのは

  • キャラ
  • ミッション
  • アイテム

ってところですよね。というかこれしかないですね。

キャラ

拡張のキャラはクセが強くてもいいのかな、と思うので、ステータス値が低めだったりスキルが発動しにくかったりしてもいいかもしれないですね。

で、ざっと考えついたままにキャラとスキルを書いてみるとこんな感じ。

Summoner (サモナー = 召喚術士)

スキル名 : サモン

内容 : どれか1つのキャラを自分の次のターン終了時まで自分のものとする

つまり、今までのファイターのスキルの強化版ってことですね。ファイターは無効にするだけなのに対して、こちらはそれを利用できる。

なので、全体的にステータス値は低くていいかもしれません。

Sage (セージ = 賢者)

スキル名 : チェンジ・ザ・ワールド

内容 : 全てのミッションカードを山から引き直す

クエストをがらりと変えてしまうことで、相手を妨害したり、自分がクリアできないものを取り換えてしまったり。

ただ、誰が有利になるかは時の運なので使い勝手は悪いかも…。

Monk (モンク = 修道士)

スキル名 : コンセントレーション

内容 : 全てのミッションのクリア目標ステータスを自分の次のターン終了時まで任意のステータスに変更する

ミッションのステータスを自分に有利なステータスに変えれば、一点突破型のキャラ構成でも安心ですし、相手に不利なステータスに変えてクリア不能にしてしまったりと色々使えそうな感じ。

Enchanter (エンチャンター = 付与魔術師)

スキル名 : エンチャント

内容 : このターン使用したアイテムを破棄しなくてよい

これは…どうなんですかね。アイテム使用宣言はダイスロール前なので、結構リスキーな感じしますね。

ステータス値を多めにしたり、スキル値を3種類にしたりして調整が必要そうです。

Elf (エルフ)

スキル名 : フィールド・バリア

内容 : どれか1つのミッションを自分しか入れなくする (※1つのゾーンにつき1つまで  ※チェンジ・ザ・ワールドを使われると解除される)

自分の進みたいルートを確保出来るわけですから、これは結構いいかもですね。

ミッション

これはもう少し強いモンスターを用意したりとかくらいにとどまりそうです。

ただ、今までのクリアステータスの組み合わせ以外のものも用意しても良さそうな気がしますね。

アイテム

テストプレイも手伝っていただいた方からのアイディアなんですが、ファイターやシーフなど他のプレイヤーを邪魔する系のスキルの対象にならない「不可視の護符」というものを考えました。

これがあると、妨害されなくなるんで所持金が多いプレイヤーは買いたくなりそうです。

貧乏プレイヤーが先に購入してしまうなどの駆け引きプレイも発生しそうですね。

 

 

新スキルを考えるのが楽しくて、それ以外が若干適当な感じに…。

とはいえ、しょせん作られるかも全くわからないものですし、こんなもんでしょうかね…。

 

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

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

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

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

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

 

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

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

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

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

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

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

 

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

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

 

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

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

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

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

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

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

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

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

サーバ側

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

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

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

 

テストクライアント側

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

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

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

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

 

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

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

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

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

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

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

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

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

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

 

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

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

【おーくしょんパーティ!】マーカーペンの代替案

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

前回、マーカーペンが高くてどうしたものかと代替案を考えたという話を少ししました。

今回はそのあたりについて詳しく書いてみようと思います。

 

代替案1 : 紙幣をそのまま金額表示に使う

同時に番号を言いながら、手持ちの紙幣を出し合うという案です。

これは何と言っても追加で作成するものがなくなるので、コスト的にとても魅力的です。

しかし…この方法だと、例えば自分が500G紙幣1枚しか持っていない時に10Gをベットしようとすると、まず両替が必要になってしまいます。

10G含みで両替すると10G単位での入札をしようとしていることがわかりますし、100G x 5枚だけに両替したら、100G単位でしか入札してこないことがわかってしまいます。

これは結構致命的ですよね…。それに、両替も手間がかかるし…。

コスト的な魅力はとてもあったんですが、残念ながらボツということに。

代替案2 : 専用ボードとマーカーチップを作る

こんな感じのボードを考えました。

番号を示すマーカーチップを入札額のところに置いて、番号と金額を示すものです。

これが1枚だけ場にあって全員が同時にマーカーを置こうとすると、確実に手が交差してまともには実行できないだろうと想像できます。

なので、全員がこれを持ち、隠してマーカーを置いてから同時にオープンする方式にする必要がありそうです。

このボードだと、ステータスの合計値を示すところがないので、裏面にこんな感じのものを作って、マーカーを置いて数値を示すことを考えました。

こうなると、両面印刷のボードとマーカー5個が4セット必要になってしまいます。

なんだか結局作るものが増えてコストカットにはならない感じがします。

それにコンポーネントが増えてややこしくなるし、お世辞にも UI が優れているとも思えません。

ということで、この案も残念ながらボツということに…。

 

こんな感じでいくつか代替案を考えたわけですが、結果マーカーペンを使うのが一番いいのではないかという結論になりました。

安価なマーカーペンを…探す……。

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

【おーくしょんパーティ!】原価との戦い

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

今回は、製品化に向けて原価について悩んだことを書いてみます。

 

いきなりですが、おーくしょんパーティ!のコンポーネントはこんな感じです。

まとめると、カードが66枚、紙幣が70枚、シートが2枚、ポーンが5個、ダイスが2個、マーカーペンが4本…と。(マーカーペンはホワイトボード用のやつです。)

結構な物量だなぁ…。

これをワンストップでポンと発注できると楽なんですが、それぞれの印刷屋さんで得意不得意などありそうですし、そもそもマーカーペンとか用意してもらえるのだろうか?という根本的な問題が…。

全部まとめてやってもらって箱詰めもしてもらえると楽なんでしょうけど、それだとどうしても原価が上がってしまうので、箱詰めなどは自分たちでやって、コンポーネントはそれぞれ良さそうなところに別々に発注する方針にしました。

これが一般的なのかどうかは全然わかりません。なぜならアナログゲーム制作は初めてだからです!(威張って言うな、という。)

 

いろいろ見積もり依頼などしてみた感じ、やはりカードが高いですね…。角丸加工とかニス加工とかオプション付けちゃうとどうしても…。

どこまで妥協するのかというのも原価を抑える時のポイントになりそうです。

 

それと化粧箱が高かった!箱って結構な値段するんだなぁ…。初めてのことなので驚きや発見が多いです。

これはもう相見積もり取って安いところ探すしか…。

 

さらにさらに、サイコロも高かった。自分で使うダイスなんかは数が多くないし何度も買い替えなくてもいいので単価は気にならないですが、制作側になってみると安く作って手ごろな価格設定をしたいと思い単価にシビアになってしまいます。

木製ダイスでちょっと大きめで手になじみやすいもの…なんて当初は考えていましたが、これはちょっと価格的に難しそうだなぁ…。

ここも価格とクオリティのバランスで悩みどころです。

 

そしてなんといってもマーカーペン。ホワイトボード用ので、キャップのところにイレーサーがついている奴がいい。

でも、イレーサー付きのってマグネットがついているものが多いんですよね。マグネットはいらない…。マグネットなくていいからその分単価下げてほしい…。

マーカーペンはかなり高かったので、クオリティを下げざるを得ない感じです。

とはいえ、イレーサーなしだとプレイヤー側でティッシュやら用意してもらわなくてはならなく、もしかしたら箱を開けた瞬間遊べないケースがあるんじゃ…なんてことを考えるとイレーサーは必須ですよね…。

これをなんとか見つけねば……。

 

ということで、製品はどうなっているか見てからのお楽しみ!(もしかしたら用意できなかった…とか全くないとは言えないのが怖い。。)

 

ちなみに、マーカーペンが高いので、どうにかしてペンを使わないでいい方法はないかといくつかアイディアを出しましたが、結局マーカーペンが一番プレイしやすいということで、なんとかしてマーカーペンを探す方向に。

この時のアイディアについてはまた次回にでも書こうかと思います。

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

ゲームマーケット2017秋に出展決定!

ラディアスリーは ゲームマーケット2017秋 に出展することが決定しました!

日にち : 2017/12/02(土), 12/03(日)

場所 : 東京ビッグサイト

出展タイトル : おーくしょんパーティ!

現在開発中の「おーくしょんパーティ!」初お披露目となります。

また、同時にアプリ版も展示予定ですので、是非足をお運びください。

(試遊もできます!試遊だけでも大歓迎です!)

 

ブースなど詳細が決まりましたら、改めて告知させていただきます。

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

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

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

 

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

  • 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 → そのまま

 

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

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

 

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

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

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

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

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

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

 

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

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

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

 

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

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

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

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

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

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

 

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

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

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

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

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

 

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

 

 

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

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

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

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

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

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

 

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

 

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

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

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

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

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

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

 

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

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

こりゃヤバい。。

 

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

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

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

 

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

 

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

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

 

詳細は次回!

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

乞うご期待ッッ!!