ブロックチェーンゲーム開発の現在地　『CryptoDerby』における技術的工夫

マルチチェーンへの対応対応

竹村也哉氏（以下、竹村）：その派生で、マルチチェーンの話をします。マルチチェーン対応ができているプロジェクトは、世界でも比較的少ないと思います。

これはプログラムの構成の話なんですが、マルチチェーンは今どうなってるかというと、基本的に下のこの大きな部分は、ソーシャルゲームのサーバーがあると思ってもらえばだいたい近いです。

これを上のEthereumにつなぎつつ、複数のチェーンにつなぐことができるのが、私たちが考えているマルチチェーンです。これはEthereumはできているし、他も、リアルタイムでつなぐところはできているので、もう少しでまさにマルチチェーンという状況になります。

技術的には、ネタを明かすとシンプルです。ですが最初からこの設計でやってないと、けっこう面倒くさいんじゃないかと思います。ただ、本当にソーシャルゲームがあって、パブリックチェーンがつながってるみたいな感じですね。

これも各ブロックチェーンのファウンデーションと話していまして、「確かにそれいけるね」みたいな話をもらっているので、Ethereum系でなくても、Bitcoin系でもこれいけそうですし、スマートコントラクトやスマートコントラクト的なものが動くブロックチェーンであれば、ほとんど対応できるのではないかと思います。

フロントエンドの開発について

あとは、フロントエンドについてです。やはり3Dを使いたかったので、WebGLなどを使ってやっています。いまうちはPlayCanvasというツールを使ってやってます。これは日本でそれほどメジャーではないというか、おそらく日本でPlayCanvasを一番使っているのはうちじゃないかというくらいのツールなんですが、UnityのWeb版みたいなツールです。

シーンのエディターがあって、グラフィックの人がある程度使えて、プログラムも書けてみたいな、ブラウザ上で動くUnityのような感じです。ただ、UIのコンポーネントが少なかったり、日本のいわゆるブラウザゲームに向いてるわけではないなど、いろいろ問題があったりはします。ただ、見た目はUnityがブラウザ上で動いてるみたいな感じで、スクリプトはJavaScriptで書ける、そんなツールです。

ただ、先ほども言ったようにPlayCanvasを日本で使っている人は少ないので（笑）、けっこう改造をしながら、おそらくPlayCanvas側の想定ではないことも、日本や海外のPlayCanvasの人に話を聞きながらやったりしています。

例を1つ挙げると、HTMLでの画面遷移を追加したのがけっこう魔改造でした。シーンの遷移というのは、キャンバスが1個あって、そこで遷移するような想定なんです。スマートフォン版を作ったとしても、フルサイズのキャンバスがあって、その上でモデルが出て、ボタンが出てみたいな、そういう想定のものです。

それでは、すべてのゲームの遷移をそこで作って、ネイティブアプリみたいな遷移をPlayCanvas上で全部作らなければいけませんでした。さらに、PlayCanvasにはUIコンポーネントが少ないんです。

なので、ブロックチェーンゲームでもソーシャルゲームでも、ショップ作ったり、なにかつながっているメニューを作ったりするのがPlayCanvasはあまり向いていません。ですので、そこはもうHTMLや普通のJavaScriptで作ったほうが早いのではないかということで、いろいろと改造しました。

ですので、PlayCanvas上でHTMLゲームみたいな遷移を作るところを、自社で足したりしています。それに伴って、Vue.jsを足したり、Firebaseや普通のブラウザで入れるようなコンポーネントを入れてあります。

また、TypeScriptも使いたい人が社内でいたので、3Dのゲームになっていくと、JavaScriptでやるよりもTypeScriptがあったほうがいいかなということで、ちょっと足してあったりします。フロントでいうと、だいたいこんな感じですね。

サーバーサイドはGoで開発

サーバーについてもお話しいたします。2018年前半は、Ethereumがまともに動かせるサーバーが、Go言語かNode.jsの二択でした。弊社はNode.jsの経験もあるんですが、いろいろ考えてGo言語にしました。

GoとNode.jsはどっちが良かったのか、正直あまりわかりません。ただ、「Go言語はそれほど開発効率良くないな」というのが社内での意見です。ただ、動くものはできるし、悪くはないけど、もっと開発効率がいいやつがいまだったらあるんじゃないのかなと。ただ、結果的にはGo言語使ってます。

スマートコントラクトを叩いたりするところはSolidityなどを使っています。ブロックチェーンもSolidity＋αで、EthereumはSolidity一択なんで、Ethereum用にはSolidityを使ってます。SolidityやTruffleなど、「スマートコントラクトを叩くんだったら普通はこうだよね」みたいなものを使ってるいます。

あとは開発管理です。これも普通だと思っていますが、AtlassianのConfluenceやJIRAなどを使って、ChatworkやGoogle Drive、Gitなどを使って開発しています。Jenkinsなどを使っていますし、これも普通かなと思います。

開発中に困っていること

開発中に困ってることです。ブロックチェーンゲームは、これから作る人もいま作ってる人も、外国の人とのやりとりが増えます。メジャーなブロックチェーンのファウンデーションの技術系のチャットに入るとほぼほぼ外国人ですし、日本メインでやっているブロックチェーンはほぼありません。また、日本メインでやっていて儲かりそうなブロックチェーンはさらにないので、英語ができないとけっこうしんどいです。

また、うちの会社にはHTMLコーダーがそんなにいないので、HTML専用でやれる人がもうちょっといたほうが良かったと思います。

あとは、これもおそらく普通のブロックチェーンゲームではそれほど必要ありませんが、Ethereum以外のチェーンに詳しい人は日本を探してほぼいません。TRONも皆無ですし、そういう人がもうちょっといればと困っています。そうは言ってもなんだかんだやってるので、国内ではうちはEOSとかTRONについてはまだわかるほうなんじゃないかという、残念な状況になってしまっています。

また、コミュニティ対応が多いです。ブロックチェーンゲームをリリースまで持っていくと、ソーシャルゲームよりもはるかにコミュニティ対応が増えます。ソーシャルゲームと違って、ユーザーの資産を管理しなければいけないので、ある意味、銀行や金融商品みたいな性質がブロックチェーンゲームにどうしてもついてきてしまいます。

なので、ユーザーからのクレームもソーシャルゲームと方向性が違っていて、「俺が出したお金の資産はどうなってるんだ？」であったり「うちの資産を増やすためにこういう提案をしたいんだけど、どうなんだ？」など、ソーシャルゲームではあまりないような提案やユーザーとの絡みが増えると思います。

これはおそらくどのブロックチェーンゲームもこういうことになっていてまして、DiscordやTelegramなどいろいろなメディアを使っています。コミュニティマネージャーみたいな人がいてやりとりしてがんばってやってます。

ですがコミュニティ対応にはけっこう時間がかかりますし、コストもかかるなと思いながらやっています。でも良いところもあるので、ブロックチェーンゲームはそういうビジネスなんだろうなと思ってやっております。

現状とこれから

では、「現状どうなってるか？」という話と、「これからどう増やしていくのか？」というお話です。この後、競馬場の正式リリースをしたり、競馬のジョッキー機能や、ギルドのような「馬主回」機能も入れていこうと思っています。これも、他のチェーンとつなぐことも、今月からやっていきます。

基本機能はこれからも追加していくし、ブロックチェーンの対応もやっていくし、海外展開も4月5月ごろからやっていこうという感じで動いています。

また、賞金付き大会などのeスポーツもブロックチェーンゲームと相性が良いので、そういうことも仕掛けていきたいと考えています。

あとは、競馬なので地方競馬みたいなものや地方大会みたいなものをやっていくと、もうちょっとやれることが増えるんじゃないか、ということも考えています。これは考えるだけでなくて進行中でもありますが、実装はもう少しあとになりそうです。

こんな感じで人が足りていないので、ブロックチェーンゲームに興味ある人いたら、一緒に働けるとうれしいですし、業界のコミュニティが小さいので、他の会社でやってる方でもお友達になっていただければありがたいなと思っております。以上です。

オンチェーンからオフチェーンに移行する仕組み

司会者：ありがとうございました。では、質疑応答に移りたいと思います。ご質問がある方いはらっしゃいますか？

質問者1：今日はありがとうございました。おそらく『CryptoDerby』だと馬が対象だと思いますが、いろいろなチェーンにトークンを書き出せるとか、他にもいろいろあるとは思いますが、複数のチェーンに同じものを書き出すことは可能ですか？

竹村：技術的には可能ですね。うちがやっているのは、ERC721をEthereumの上で作っていて、データベース上に、「ゲーム内にあるのか、ゲーム内にないのか」みたいなフラグをDBに持たせています。そのうえで、Ethereumに吐き出した後はゲーム内では使えない、みたいなかたちにしてあります。

ただ、そこはプログラムなので、原理的にはEOS側のノンファンジブルトークンに吐いて、Ethereumにも吐いて、両方に持たせることが可能ですが、それではゲーム全体が破綻してしまうので、Ethereumの上にあるならEthereumの上にあるし、ゲームのなかにあるか、どこかのチェーンにだけあるみたいな、そういう設計でやってますね。

質問者1：オンチェーンからオフチェーンに持ってくることは可能なんですか？

竹村：できます。それはEthereumなどのトランザクションを監視しておいて、取引所と一緒ですね。取引所のユーザーのウォレットがあって、取引所のウォレットがあって、そこに移したり、入れたり出したりができるのと、基本的には同じ構成ですね。

質問者1：なるほど、ありがとうございます。

司会者：ありがとうございます。他にご質問がある方はいらっしゃいますか？

質問者2：開発人数ってはどれぐらいでやられてるんですか？

竹村：だいたい10人ちょっとですね。フロントが4人ぐらい、サーバーが2、3人で、スマートコントラクトが1人、あとは企画とグラフィックみたいな感じですね。

質問者2：PlayCanvasの学習コスト的についてですが、Unityを触っていたらすんなり作れたりしますか？

竹村：そうですね……、UnityがわかってJavaScriptがわかれば、たぶんそれほど大変ではないですね。サンプルがいろいろあって、ネックになるのが開発者コミュニティがほぼないことですね。それ以外はそんなにネックはないかなと思います。

一応GMOさんでPlayCanvasをサポートされています。あとはSlackに最低限の小さいコミュニティがあるので、そこで質問とかすればなんとかなるかなと思います。

質問者2：ありがとうございます。

司会者：それでは、本日は以上とさせていただければと思います。ありがとうございました。

（会場拍手）