【おーくしょんパーティ】コンポーネントの調達先

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

「おーくしょんパーティ」のコンポーネントは色々なところに発注していまして、どこで調達しているのかというのを書いてしまおうかな…なんて思います。

アナログゲームの世界に飛び込んで初めてのタイトルということで、何をどうやったらいいのかかなり迷ったということもあり、こういった情報があるのはもしかしたら役立つかもしれないと思いました。

いっそ書くなら思いきってガッツリ書いてしまおうかな…と。

 

まず、おーくしょんパーティのコンポーネントを改めておさらい。

  1. カード類
  2. 紙幣
  3. オークション&ラウンドカウントシート
  4. プレイヤーシート
  5. プレイヤーコマ
  6. サイコロ
  7. マーカーペン
  8. 説明書
  9. 化粧箱

(…結構種類あるな。。。)

では、それぞれ詳しく。

カード類

キャラクターカード 、スタート/ゴールカード、ミッションカード、アイテムカードとありますが、全て萬印堂さまにお願いしました。

ハーフサイズ、両面カラー、ニス加工、丁合、帯留め

といった仕様でお願いしています。

萬印堂さまは基本的には全量問題ないものが送られてくるので、必要な数量を発注すればいいと思います。

紙幣

10G、50G、100G、500G とありますが、全て Graphic さまにお願いしました。

仕様はこんな感じ↓。

A7チラシ・フライヤー / 両面カラー / 上質70kg / 変形サイズで W 100mm x H 50mm

あえて上質紙にしました。出来上がったものは思いのほか紙幣っぽい感じが出ていてよかったです。

Graphicさまでは、印刷ミスのようなものも含まれるんですが、いくらか余分に送られてくるので、必要な数量をそのまま発注して大丈夫だと思います。

オークション&ラウンドカウントシート

こちらも Graphicさま。

A6カード / 両面カラー / ホワイトコート223.5kg / 両面PP貼(つやあり)加工

プレイヤーシート

こちらも Graphicさま。

A6カード / 片面カラー / コートボールL判 395kg / 片面グロスPET貼加工

プレイヤーコマ

こちらはタチキタさま。

形状が悪いものなどある程度含まれていますが、それを考慮して多めに入っていますので、必要数を発注すればいいと思います。

サイコロ

こちらは Foshan Dong Xuan Trading Co., Ltd. さま。

6面 / 16mm / 角丸 / ドット

alibaba.com で注文しました。ちょっと質問したいことなどがあったので、サイト上で英語でメッセージをやりとりしました。

へこんでいたり、ドットの塗りがおかしかったりするものが、まあまあの割合で含まれているので 10% くらい多めに頼むのが良さそうです。

マーカーペン

こちらは Shanghai Universe International Trade Company さま。

AliExpress でマグネットがついていなく、イレイサーがついているものを探しました。

こちらは書けなかったり割れていたりというものがかなりの割合で含まれていました…。25% くらい多めに頼まないと足りなくなると思います。

まぁマーカーペンをコンポーネントに含める人はいないと思うので参考程度にしかならないと思いますが。

説明書

こちらは萬印堂さまのサービスで無料でやっていただけました。ありがたいことこの上ないです。

A3 / 両面カラー

紙はお任せですが、コート紙にはなります。

化粧箱

こちらはハコプレさま。

  • サイズ : 内寸 W109mm x D154mm x H30mm
  • 用紙 : フタ&ミ = 印刷紙コート90kg , 裏地 = シルクボール(白)
  • その他仕様 : 片面カラー・PP(超光沢)

印刷が小さく欠けている部分があるものがいくつかあったので、気持ち多めに頼めるならその方がいいかもしれません。

その分をサンプル品などに回してしまうならちょうどの数量で問題ないでしょう。

コマなどをまとめる小袋

最後におまけで小袋なんですが、こちらはシモジマで購入してきました。…普通ですね。

 

これらをバラバラに頼んで、納品時期を考えつつ発売日に間に合わせるには、結構綿密にスケジュールを組まないといけないと思います。

納品後にアセンブルしてシュリンクパックする時間も考慮しないといけないので、もしこんな感じでやる場合はスケジュールに十分注意してくださいね。

 

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

Unity2017.3.0p4でLambdaの実行が失敗する原因の調査

ラディアスリーの加藤です。
先日『Unity2017.3.0p4 で AWS SDK が例外を吐くようになったので原因を調べてた』というエントリーを書いたのですが、テストを行ってみるとどうもiOS端末上で lambda の実行が失敗する事に気が付きました。
アプリ起動時にユーザデータの確認のため lambda を叩いてデータを取得するという処理を行っていたので、当初は「起動直後に lambda を叩いた場合 Credential なんかが確定する前に lambda を叩いてしまうケールがあるのかな?」なんてことを考えていました。
成功するケースもあるので、「リトライ処理を組み込めば良いのか?」なんてことも考えたのですが、原因がはっきりとしないまま変なリトライ処理を埋め込むのも気持ちが悪いと思い調査を行ってみました。
結構、軽い気持ちで調査を始めてみたのですが、これが意外と混沌としてしまっていて、思いの外時間を取られてしまったのですが…
まぁ、せっかくなので足跡を残しておこうと思います。
…Webでの情報も少ないので、レアケースなんですかね?

続きを読む Unity2017.3.0p4でLambdaの実行が失敗する原因の調査

Unity2017.3.0p4 で AWS SDK が例外を吐くようになったので原因を調べてみた

ラディアスリーの加藤です。

先日まで、macOS Sierra + Unity5.6.5p1 を利用して開発を進めていたのですが、ひょんなことから macOS High Sierra に乗り換えることになりまして、ちょうど『素数ガール』のリリースも終わったことだし、この際 Unity の環境も見直してしまおうなどと思い立ちまして、Unity2017.3.0p4 に移行することにしました。

暫くの間は、特に問題もなかったので「これで新環境に移行できたかなぁ…」なんてことを考えていたのですが、ちょいと Unity から AWS Lambda を叩くプロジェクトを実行してみたら変な例外が発生することに気が付きました。
先日まで動いていたプロジェクトが急に動かなくなったんで、ひとまずは Unity のバージョンを戻して試すか…なんてことを試してみたら、Unity5.6.5p1 を High Sierra で動かすと、ファイルシステムが変わった関係で Assets 配下のファイルがUnityで読み込めないんですね…

この現象については、Unity からアナウンスとパッチが公開されていたので、すぐに気づくことができたんですが、肝心の AWS Lambda の例外に関しては、どうも Unity2017.* の問題っぽいと…

そんなわけで、原因と対策について調べてみました。
あまり日本語の情報も出回っていないようですし、せっかくなので足跡を残しておこうと思います。

続きを読む Unity2017.3.0p4 で AWS SDK が例外を吐くようになったので原因を調べてみた

【おーくしょんパーティ】ゲームマーケットでの試遊

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

今回は、遅ればせながら…ゲームマーケット2017秋で試遊していただいた「おーくしょんパーティ」のプレイ内容を振り返ってみたいと思います。

 

まず、試遊スペースの稼働状況について。

開場後30分~1時間くらいは、

  • お目当てのブースに直行する
  • (会場直後の入場口が正面入り口側でないこともあって)手前からじっくり見て回っている

というような行動が多いようで、ラディアスリーの試遊スペースは閑古鳥…。

でも、最初の一人が「試遊したいです」となって試遊が始まると、そのあとは途切れることなく最後まで試遊していただけました。

2つの試遊スペースのうち1つを中村が担当していましたが、一度もトイレにもいかず説明をひたすら繰り返していました。

体力的にはしんどかったですが、とてもありがたく、手ごたえも感じられました。

そんな中、何度も覗きに来ていただいたもののタイミング的に参加していただけなかった方もいらっしゃり、申し訳ない状況も発生してしまいました。

おーくしょんパーティはプレイ時間長めなので、少しやり方を考えないといけないかなぁ…。

あと、プレイ時間長めのために、より多くの方に体験していただくことが難しいというのも悩みです。

 

さて、プレイ内容について。

ゲムマの2日間、私の卓でプレイしていただいた方たちの中で最も強いパーティだったのが D, D, D, B という組み合わせで、ステータス合計 35 という方でした。

(その後、ぶんぶん交流会で D,D,D,C の 37 というパーティが誕生。)

逆に最弱は、B, A の2枚だけのパーティで、ステータス合計 8 …なんとも頼りない。

ですが、最強の方はダイスに嫌われ、残念ながらトップにはなれませんでした…。

最弱パーティの方はアイテムを駆使して、大健闘!トップではなかったですがビリにもなりませんでした。

こうしてみると、単純に強いパーティを揃えればいいというゲームではないのがわかっていただけるかと思います。

 

変わったプレイをされた方もいらっしゃいました。

何名かの方がやっていたのは、シーフばかりを集めるプレイ。やはりシーフで別プレイヤーから直接お金を奪えるのは強いですからね。

それから、プリーストを集めるプレイ。プリーストのスキルで解決してしまおうということで、ダイス運に賭けるギャンブラーな方だったんでしょうか?

もっと強烈なのは、パラディンを集めるプレイ。パラディンは戦闘ミッションで発動させると自爆しますが、それもいとわず1ゾーン目から発動したら必ず自爆させるという脅威のプレイを敢行した方が一人だけいらっしゃいました。

 

こういった場でインストすることに不慣れでヘタクソな私でしたが、皆様とても温かい目で見てくださり、そして上記のように色々と楽しんでいただけたようで、初参加としては非常に良い感じだったんじゃないかと自画自賛してみたいと思います。

これからも、まだまだ新タイトルを出していこうと思いますので、どうぞよろしくお願いします。

 

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

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

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

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

 

素数ガール

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

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

 

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

 

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

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

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

 

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

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

 

さらに、

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

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

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

ブロンズ素数…?ペガサスローリング…!

 

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

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

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

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

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

 

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

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

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

 

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

無料なので…是非。

素数ガール

 

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

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

 

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

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

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

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

以前、箱詰めの前段階までの話を書きましたが、いよいよ全コンポーネントが揃いましたので箱詰めしていきます!

 

…の前に。

紙幣を数えて帯封をする作業を。

手前が4種類の券種です。

500G x 15枚、100G x 15枚、50G x 10枚、10G x 30枚 をひとまとめにしたのが奥の束です。

これをひたすら数えるッッ!

 

紙幣が用意出来たら、入れ忘れがないように台紙を用意します。

(カードは丁合&帯止めして納品してもらったのでこういう作業はしなくても大丈夫でした。楽だわー。)

 

各コンポーネントを台紙に並べます。

こう揃っているのを見るとテンション上がりますね!

 

箱に左側の

  • カード
  • 紙幣
  • コマ&ダイス
  • マーカー

を入れます。

 

蓋をするように

  • プレイヤーシート
  • ラウンドカウント&オークションシート
  • (チラシ)
  • マニュアル

を入れていきます。

蓋をして…シュリンクパックをすれば出来上がりです!

簡単!そうに見えますが、数が多いとかなり大変でして…。

隙間時間にチクチクと進めていった感じでした。

 

原価を抑えるために、セット数を増やし…自分たちでやることを増やし……相乗効果で結構大変なことに。

でも、たくさんの人に購入いただけると苦労も報われます!ので、是非ご購入ください!!

 

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

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

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

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

 

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

こんなのね↓。

 

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

 

 

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

 

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

 

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

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

 

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

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

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

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

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

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

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

 

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

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

 

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

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

では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 上で起動して確認します。こうなると複数のプレイヤーで実際に遊べるようになります。

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

 

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

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