2019.09.09 CEEDECの講演資料がアップされていたので追記しました！
https://cedec.cesa.or.jp/2019/session/detail/s5c9dede391631
株式会社アプリボット、竹端さんと株式会社Cysharp、河合さんのセッション。
正直なところKotlinにはあまり興味はなく、 Cysharpや MagicOnionの話が聞きたくて参加しました。
河合さんというよりはneueccさんといった方が有名かもですね。
https://twitter.com/neuecc
Unity用の非同期処理向けライブラリ、UniRxを作成された方です。
Qiita:UniRx入門 https://qiita.com/toRisouP/items/2f1643e344c741dd94f8
個人的にすべての環境をC#に寄せていくという河合さんの考え方に非常に興味があります。
講演の途中で河合さんも言っていたのですが、サーバーはサーバー、クライアントはクライアント、双方が双方のことがわかっていなくても大丈夫なように作る、という考え方は今後の開発では適切ではないと思います。
両方のエンジニアが、どちらに書くのかを随時検討しながら必要な方に処理を実装する、というつくり方が適切だと思います。歴史上、開発手法の勝者は適切な手順をとった人がとりがちです。
もうUnityつかってサーバーもクライアントもC#で書いて、全部C#環境にしていくことが開発者のハッピーなんじゃないの？というのは一つの最適解かと思います。
Cygameと組んだ河合さんの動きはとても気になりますね。
河合さん個人のことは置いておいて講義内容に関して記載していきます。
■gRPC × サーバーサイドKotlin
アプリポッドさんが gRPC × サーバーサイドKotlinでゲームを実装するにあたった背景は、新しい技術を取り入れておきたいという部分が強いようですね。
Qiita:gRPCって何？ https://qiita.com/oohira/items/63b5ccb2bf1a913659d6
wikipedia:Kotlin https://ja.wikipedia.org/wiki/Kotlin
Kotlin自身に将来性があるという判断は確かにそう思います。早めに対応することでのメリットは大きいでしょうね。
UnrealEngine4なんかも早めに対応していた会社は現状とても価値が上がっていますよね。そういう立場になれる可能性が高いといえるとおもいます。
JAVAでもともとやっていた、わかっている部分というところも大きい。純粋なゲーム会社だとそういつ知見を持っていないところが多いですから、結構なアドバンテージです。
そろそろ会社的にどういった技術で押していくのかという部分を決めてその方向で特化していかないと、その開発会社じゃないとという価値を維持していくことは難しいと思います。
UnityにおいてgRPCはそのまま使えないということで対応方法を説明してくれていました。詳細は下記の資料をご覧ください。
※2019.09.09 早速資料がアップされていました！https://speakerdeck.com/n_takehata/kuraiantotong-xin-haipahuomansunatong-xin-ji-pan-falsekai-fa-tomagiconionniyoruriarutaimutong-xin-falseshi-xian
こういったサーバーサイド周りの新技術の情報は常にアンテナを張っておきたいですね。
サーバーサイドエンジニアでないので正直詳しくないのですが、それぞれ出てくる用語を都度調査するのと、それをしないのでは年単位で大きな差が出てくると思います。
もう10年来調査することを続けているのですが、プロジェクトマネジメントにおいてやってきていない人とはアウトプットに大きな差を出せると思いますね。
■Cysharpのアプリポッドへの協力内容について
ここからは河合さんの講義のレポートになります。
現状アプリポッドさんと技術的な協力体制を作っている模様。
ともにサイバーエージェントグループですしね。
サーバーエージェントグループは数が多いし、協力体制がしっかりしている。
そういったところは純粋なゲーム業界もみならわないといけないと思います。
協力はしているものの、現状のアプリポッドさんの技術選択は、河合さんからするとC#じゃないものが入っている時点であまり好みではない様子。
改めて公開された資料を見てみて理解したのですが、河合さんの理想とすればサーバー周りをすべてMagicOnionで対応していきたいと考えてた感じですね。
ただ現実的な対応方法としてアプリポッドさんの対応はRealtime ServerのところだけMagicOnionで対応し、その他の部分はアプリポッドさんの棄損で対応していたやり方に合わせたみたいです。
あとはクライアントとサーバーでロジック共有したいところは、サーバー内にC# Internal Serviceを用意し、それをKotlin Serrverとやり取りさせるという仕組みにしたようです。 Internal Service 内のC#のソースで共有されているものは、元ソースで作成されたものがコピーされる仕組み。
確かに中間言語を使用したりするよりも、問題が発生しにくい仕組みかと思います。
■MagicOnionについて
MagicOnionというものを作っているので協力してほしい会社は言ってきてほしいとのことです。
MagicOnionの説明は下記の記事がわかりやすかったですね。
Qiita:Unity+MagicOnionで超絶手軽にリアルタイム通信を実装してみた https://qiita.com/mitchydeath/items/cecf01493d1efeb4ae55
MagicOnionはリアルタイム通信フレームワークです。今だとリアルタイム通信はphotonが多く採用されていますかね。
photon https://www.photonengine.com/ja/photon
photonは早くて便利なのですが、もっとカスタマイズできるといいかなと思います。
MagicOnionがどこまでそれにこたえてくれるかはわかりませんが、現状photonよりは期待ができるかなと。
河合さん曰く、「全部C#の環境にしよう」という方針はなかなか賛同を得られにくいことは理解しているとのこと。
まあ確かにそうですが、オールC#の開発手法がいざトレンドになったときに準備をしていたのとしていないのとでは大きな差が出ます。
もうサーバーサイドはphpを工夫して使っていくよりは、もっと処理速度重視で開発言語を選んでいかないといけないと思うのですよ。
C#ということであればクライアント開発のほうにも応用できますし、結局あれほど開発に慎重論が出ていたunityは主流になりましたしね。
わたしがサーバーサイドの知識がいまいちというところで、レポートとしてしっかりまとまっていなくて恐縮です。
技術者の皆様の興味を持つ一端になればと思い、アップします。