世界一のブロックチェーンゲーム『マイクリプトヒーローズ』ができるまで

マイクリプトヒーローズの作り方

上野広伸氏（以下、上野）：よろしくおねがいします。まずは自己紹介をさせていただきます。

私は『マイクリプトヒーローズ』を作っているdouble jump.tokyo株式会社のCEO兼CTOの上野広伸と申します。

double jump.tokyoは、2018年4月に設立されたブロックチェーンゲーム開発専業の会社です。

マイクリプトヒーローズはファミコン時代を彷彿とさせる、ドット絵にチップチューンミュージックで構築された歴史上のヒーローが戦うゲームです。マイクリのコンセプトはこちらに書いてあるとおり「ゲームにかけた時間も お金も 情熱も、あなたの資産となる世界」なんですが、このコンセプトはすべてのブロックチェーンゲームに通じるコンセプトなのではないかとも思います。

ゲーム概要としては、ヒーローやエクステンション（装備品）を編成し、バトルし、手に入れたエクステンションをまた編成し、バトルし、というサイクルのゲームとなっています。ヒーローの絵を自分でセットできるアートという機能があるんですが、これでスキルや能力値が変わったりするし、もちろんレベルアップの要素もあるので、自分でアセットの価値を上げていけるようなゲーム性になっています。

2018年11月30日の本リリースから7ヶ月ですが、こちらにあるようにユニークユーザ5万人、DAU6千人、累計売上1.2万ETHでここ最近はずっと世界一をキープしています。市場はまだ小さいのですが、だからこそ世界一も取れたという市場感なんですが、市場自体は右肩上がりに成長しているので、実に未来ある市場だと思います。

こちらのパブリックビューイングはゴールデンウィーク入った日曜にユーザ主催で開催されたものになります。100人ほどのユーザーさんに集まっていただき、お台場の映画館を借り切ってマイクリのバトルを上映してみんなで盛り上がるという、なかなか他のゲームだと見ない熱量のゲーム、コミュニティになっています。DAU6,000人に対してユーザ主催の休日昼間のオフ会に100名が集まる規模感は凄いです。ありがたいです。このユーザーと一緒にゲームの価値、アセットの価値を上げていくような、熱量のあり方がブロックチェーンのUXの本質なのかもしれません。

ブロックチェーンゲームとNFTの流れ

ところで、ブロックチェーンゲームのゲーム史的な位置づけを振り返ってみると、まずはゲームにコンピュータが加わりビデオゲームになりました。そこにインターネットが加わりオンラインゲーム、さらにSNSというかコミュニティが加わりソーシャルゲームになりました。そこにブロックチェーンというかエコノミー的要素が加わってブロックチェーンゲームになるという位置づけをしています。すなわち、ゲームを次のステップに進化させる要素なのではないかと。

ブロックチェーンゲームタイトルとしては、まずはこの走りとなったCrypto Kittiesが2017年11月に出て、ブロックチェーン上でゲームが成り立つのではないか、デジタルアセットとはこういう考え方なのではないか、ということを世に知らしめました。その後、いくつかのタイトルが出て、2018年11月にマイクリが出ました。ちょうど Crypto Kittiesの1年後ですね。2019年はこの前リリースしたCrypto Spellsをはじめとして、日本先行でブロックチェーンが盛り上がる流れになっています。一気に盛り上がるのは年末から来年じゃないかなーと予想と期待をしています。

NFTとはなにか？

NFTとは、ブロックチェーン上でデジタルアセットのことを指す概念です。基本的に通貨はその数字つまり量に意味があるので、デジタル上で数字さえ合っていればそれでよし、という交換可能なものを「Fungible Token」というのですが、それとは違う「NFT＝Non-Fungible Token」という「一つひとつに意味ある違うものですよ」という概念ができました。

Ethereum上でNFTを扱う標準仕様として、CryptoKittiesのグループが「ERC-721」というものを策定し、それが承認されました。

標準仕様と認定されたことで、「ERC721って未来があるよね。これでいいよね」というみんなの了解の下、この仕様に基づいてさまざまなサービスが出てきました。それがNFTのエコシステムを築いているという状況です。

NFTにまつわるエコシステムとしては、ERC721の仕様が歴然としてあって、その仕様に基づいて、例えばNFTの取引所として現時点でデファクトの「OpenSea」があります。ERC721という仕様に基づいてゲームを作り、取引所も作り、Walletも作られています。

そういう仕様ベースでどんどんサービスが作られていっているので、一気に市場が作られている状況です。

『マイクリ』の中でNFTとして扱われているものは3種類ぐらいあります。「Hero」と「Extension」と「LandSector」 です。

それぞれ、ここに説明されているとおりですが、Heroというのがゲームでいうところのキャラクターですね。Extensionは装備品やアイテムなど、そういうものになります。LandSectorは、『マイクリ』の中で9つの国に分かれているんですけれども、その土地のアセットということになります。

このように3種類のアセットを組み合わせてゲームをするというのが斬新で、ウケた要素の1つかなと考えております。

マイクリプトヒーローズ開発の歴史

今から『マイクリ』の開発の歴史について語っていきたいと思います。

開発初期にドタバタがけっこうありました。

まず、2018年11月30日に本リリースするんですが、9月21日から10月1日はプレセールというかたちで、「こういうゲームをリリースするので、あらかじめHeroのアセットを販売しますよ。みなさんこれに賛同していただけるなら買ってくださいね」というものをやりました。

今だとプレセールをやることのメリットが少なくなってきているのかなと思いますが、その当時は、ブロックチェーンでなにかサービスを出す時は、プレセールというかたちでデジタルアセットをサービス開始前に販売するという方法が流行しており、そのやり方に則ってヒーロープレセールというのをやりました。

そのあと本リリースをする前に、サービスがちゃんと回るかどうかという検証を含めて、9月25日〜11月2日まで「バトルβ」を、サイドチェーンのLoom Networkというブロックチェーンの技術を使って実施しました。バトル部分も含めてフルオンチェーン開発したものの、めっちゃ動きが重くて作り直しを余儀なくされました。

そうこうしているうちに、2018年10月23日にgRPC-WebのGenerally Available版がリリースされました。gRPCというのはGoogleの通信フレームワークなんですが、そのWeb部分の公式版がようやく出た形です。

それをもって、「11月末の本リリースはgRPCを用いようか」という決定をしました。そして11月30日にリリースですね。かなりドタバタというか、ほぼ1ヶ月で作り変えてた感じです。gRPCに決めてから1ヶ月後にリリースしました。その当時のメンバーには、なかなか焦りとドタバタをもたらした感じになります。

β版時にどういうことをやったかというと、現在のEthereumのブロックチェーンは、世界全体のすべてのすべてのトランザクションを単一チェーンで扱うため、なかなか動きが重いんですよね。

というわけで、「そのメインのブロックチェーンのサブとなるサイドチェーンを動かす」という考え方がありまして、さらに「そのメインチェーンとサイドチェーンをうまくつなぐような標準仕様としてPlasmaというのを考えましょうよ」みたいな話があって。

結果的にまだPlasmaの決定版が出てないののですが、その当時は「もうすぐLoom NetworkがPlasmaでメインチェーンとサイドチェーンつながって動くなるよ」みたいな話もあったので、β版の時はLoom Network上でゲームロジックを作っていました。

Ethereumには「スマートコントラクト」というブロックチェーン上でプログラムを動かす仕組みがあります。そのプログラム言語はSolidityというもので、フルSolidityでゲームロジックを書いて動かしたんですが、サイドチェーンでもゲームロジックをすべて動かすとなるとなかなか重くて厳しかったというのが結論になります。

β版時の構成

β版時の構成としては、NFTの所有情報はEthereum上に残し、ゲームロジックはLoom Networkで動かす構成でした。

β版はけっこうシンプルな機能だったのですが、ゲームの内の機能一つひとつを別のスマートコントラクトで作り込んで、デプロイして動かすということをやっていました。

ですがβ版の結果としては、ひと言で言って、重くてゲームを快適に遊ぶのは無理でした。

ただ、これではLoom Networkに悪いので補足すると、ぜんぜん速いんですよ。Loom Networkは非常に良い技術で高速であることは間違いないのですが、例えば「3人のHero対3人Heroで、今回の攻撃は何パーセントの確率で全体を毒にする。毒にかかったらどれぐらいヒットポイントが減る」とか、そんなことを表現するのに今のEVMは向いてないのですよ。そういうことのためにあるものではないので、動かないんですよね。

今はEthereum 2.0に向けて「WASMでもっと高速に動かしましょう」みたいな話も出てきています。ですが、もともとはそんな非常に複雑なロジックを動かすためにあるものではありません。

「Shardingのないブロックチェーン技術は性能的にはサーバ1台で出せる性能が限界値になる」と書きました。

いろいろなブロックチェーンでSharding技術も取り入れられるのが標準的になってきてはいるものの、最もシンプルな現在のEthereumやビットコインって、無限の可用性を誇るという話があります。あれは何を言っているかというと、ビットコインなどMinerのためにサーバが数万台ありますが、数万台の可用性がありながら、性能的には、ある瞬間はどこか1台でしか動きませんという話なんですよね。

どこか1台がブロックチェーンの次のブロックを掘るというか、ハッシュ値を見つけたサーバで動いたものが正で、というふうになっていくと、仮に10万台あったとしてもたった1台で動かしているのと同じです。昨今、例えば、ソーシャルゲームとかでも「ユーザーがいっぱい来たら10台、20台、100台並べて動かしました」という時代に、「1台でがんばってください」と言われてもなかなか。しかもその1台もめちゃくちゃ重いです。

「ワンチャン、サイドチェーンだったらどうかな？」と思ったんですけど、やっぱり無理でした。あと、仮にShardingがあったとしても、実はクロスシャード問題があるので、そう簡単にはいきません。

この「バトルβ版ですごく苦労しました」みたいな話は、去年のHi-ConというEthereumの技術者団体が集まるようなカンファレンスで発表をしたので、もし気になる方は資料を見ていただければと思います。

（会場笑）

β版を経てわかったこと

β版の結果を受けてどうなったかというと、「すべてブロックチェーンでゲームを作り切るというのは、現時点の技術では難しい！」という結論に至りました。

とはいえ、一部をオフチェーンで作るにしても、イケてる技術（投資に値する技術）じゃないとベンチャーとしては良くありません。これは、開発も1つの投資の側面があるので、会社としてはベンチャーですから、ストーリーを作るためにもどんな技術に投資して作り上げるかが重要です。なんというか、一言で言って、イケてる技術を使いたいと考えていました。

短期間で開発効率よく開発できて、イケてる技術でWebでのパフォーマンスの良い技術がないものかと考えたときに、「そうだ！　gRPCを使ってみよう！」という結論になりました。

振り返ると、技術選定から実装、どこまでならリスクを背負えるかなど、この判断だけはおそらくCEO兼CTOみたいな人でなければ決断は難しかったと思います。

構成を見直しました。ゲームで提供する上でブロックチェーンで性能が厳しいのは間違いありません。そうだとしても、ユーザーが熱狂するのはブロックチェーンの新しいユーザー体験なので、それなくしてブロックチェーンゲームを作る意味がありません。そのかけがえのないものはそのままに、NFTエコシステム部分はそのままに、ゲーム部分だけはオフチェーンで提供する方針としました。

この部分が熱狂を生み出す部分だと思っているところですね。自分自身が自分で自由に所持や譲渡ができるというデジタルアセットの世界観や体験、ERC721の仕様に則ってサービスがバーっと出てきているという、こういうエコシステムに自由に自動的につながり、発展する仕組み。ここは変えられないので、NFTを扱うところはEthereumを残しました。

オフチェーンとつなぎこむところに関してEthereum上で発生した事柄は、Ethereum上でのイベントログをウォッチすることで「こういう動きがあった」ということを補足して、それをオフチェーンに反映します。

NFTのオンチェーン・オフチェーンのお互いの反映は、gatewayとなるスマートコントラクトやgatewayとなるサーバでやっております。

あとは、ユーザは既にネイティブアプリのサクサク感に慣れているので、満足していただくためにはWebでもサクサク動く仕組みにしなければならないのですが、「そこはHTTP2で動くgRPC-Webだったらいいじゃん？」という話になりました。

今言った話を図解しています。

オフチェーン部分はgRPCで動かしています。システムアーキテクチャはこんな感じで動かしております。

Ethereumのメインチェーンがあって、あとはオフチェーンで、裏はAWSのAuroraとS3を使って動かしています。

gatewayコントラクトの部分に関しては、gatewayコントラクトを用いてオンチェーン・オフチェーンの所有情報の管理を行っています。

まあ、gatewayなので、gatewayコントラクトから発せられるevent情報を参照してオフチェーンに反映するんですが、Ethereumのnodeってすごく緩やかなEventual Consistencyです。

普通に開発し始めたら一番使う「infura.io」というEthereum nodeがあるんですが、無料で使える部分は動きが不安定な部分もあったりするので、サービスレベルに持っていくためには、安定的にevent情報を取得できるようなEthereum nodeを、有料でもいいし自分で立ててもいいし、まずはそこを見つけることが大事だと思います。

あと、Ethereumはトランザクションの反映未済なのか反映済みなのかすごく間があるんですね。Pendingみたいな状態があるので、「Pendingですよ」という状態をサービス上で表示してあげる仕組みは大事だと考えています。

また、Ethereumのオンチェーンのデータを変更する場合に、GAS代という書き込み手数料のようなものがかかります。GAS代はEthereumのメインチェーンのトランザクションが盛り上がっているときとそうでもないときで非常に変わります。

GAS代もインフラコスト上はバカにならないものがあります。とはいえ、GAS代をケチるとなかなか反映されないので、ここの最適値を見つけるのは難しいです。これは今でも最適解に達しているわけでもないので、『マイクリ』としても今後の改良の余地があるかなと考えています。インフラコスト対反映速度の問題ですね。