-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
サーバとクライアントのAPIルール化を検討したい #67
Comments
このあたり書籍「オンラインゲームを支える技術」などのゲーム技術に関連する本を見てみると、どういった機能を持つサーバを作るべきか参考にできないかなぁ。ただし自分もこの本まだ未読なので適当に書いています。 北大の付属図書館には蔵書があるようですね。 |
あー、今手元に無いけど読める環境にあるので近々見てみます。 |
あと、こっちも読めるなら読んでみて。 "ゲームプログラマになる前に覚えておきたい技術|セガの新人教育カリキュラムから生まれたゲームプログラミング解説書!" 「Chapter15 ライブラリの作り方」なんかが役に立つかもしれません。 |
おっと、オンラインゲームを支える技術あるかと思ったら別の本だった。。。土日行けたら北大いこうかな |
さて、超久々に更新 このあたりの定義ファイルのフォーマットたたき台1作った // 型定義 Yamlでの例(動かないかも といった形で定義して、それぞれジェネレータで使いやすいようにクラスを作ってもらう形がよさそうかも。 ちなみにemit_clientがクライアントが送信する時で、emit_hostがサーバが送信する時ですね。それぞれの逆がonになります。 あと、self_allっていうのが定義されてる全部のパラメータを指しますw 定義のフォーマットはぶっちゃけ何でもよくて、多分JSONで書くのが一番いいのかもしれない |
あ、インデントごみったw |
やり方としては、MVCで言うModelをベースにサーバ側とクライアントでうまく同期しましょうって考え方です。 Modelには定義があって、それぞれのインタフェースでのみ更新が許可される といった感じですかね。 で、更新されたら裏でクライアント側とも同期して〜といった感じ。 この辺のスキームが現状だと相当適当なことになっているのでつなぎ込みの意識のズレとかが出ちゃうのかなぁと思ってます。 |
これは長期的のためプライオリティは低めですが、サーバ側とクライアント側のAPIの想定にズレがあったり、デバッグがしにくかったりするので、この辺を歩み寄らせたい。
考えているのは、APIルールをコード化してしまい、ブラウザモックやサーバモックを一発で生成できるくらいにしたい。
APIルールの仕様(脳内、どんどん修正変更はいる)
・API名(object_streamとか)
・型(int string array object)
・example_data(データ例(モックとして使う))
・emit_interval(送信間隔 0で一定時間配信ストップ)
・API-Trigger(指定したAPIがコールされたらこのAPIをコールする感じ?)
とか思いついた限り。
これらのラッパー作るのに相当な時間はかかる気がするけど、GGJの経験上これがあるのとないのでは相当違いがあると思うので、是非とも作りたい。
あとはどこまで現実的な線に落とすかってのが肝だったりする(パターンとかみつけて似たパターンはルール化してしまうとか。逆にイレギュラーパターンはAPIルールにすると複雑になるので避けるとか、あとはAPI-Triggerあたりは無限ループ防止とか)
The text was updated successfully, but these errors were encountered: