Skip to content
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

Open
miio opened this issue Mar 10, 2012 · 7 comments
Open

サーバとクライアントのAPIルール化を検討したい #67

miio opened this issue Mar 10, 2012 · 7 comments

Comments

@miio
Copy link
Owner

miio commented Mar 10, 2012

これは長期的のためプライオリティは低めですが、サーバ側とクライアント側のAPIの想定にズレがあったり、デバッグがしにくかったりするので、この辺を歩み寄らせたい。

考えているのは、APIルールをコード化してしまい、ブラウザモックやサーバモックを一発で生成できるくらいにしたい。

APIルールの仕様(脳内、どんどん修正変更はいる)

・API名(object_streamとか)
・型(int string array object)
・example_data(データ例(モックとして使う))
・emit_interval(送信間隔 0で一定時間配信ストップ)
・API-Trigger(指定したAPIがコールされたらこのAPIをコールする感じ?)

とか思いついた限り。

これらのラッパー作るのに相当な時間はかかる気がするけど、GGJの経験上これがあるのとないのでは相当違いがあると思うので、是非とも作りたい。

あとはどこまで現実的な線に落とすかってのが肝だったりする(パターンとかみつけて似たパターンはルール化してしまうとか。逆にイレギュラーパターンはAPIルールにすると複雑になるので避けるとか、あとはAPI-Triggerあたりは無限ループ防止とか)

@yuskesuzki
Copy link
Collaborator

このあたり書籍「オンラインゲームを支える技術」などのゲーム技術に関連する本を見てみると、どういった機能を持つサーバを作るべきか参考にできないかなぁ。ただし自分もこの本まだ未読なので適当に書いています。

北大の付属図書館には蔵書があるようですね。

http://opac.lib.hokudai.ac.jp/opac/books-query?mode=2&code=21520371&key=B133142038122619&TGSRC=0&IRKBN=0

@miio
Copy link
Owner Author

miio commented Mar 11, 2012

あー、今手元に無いけど読める環境にあるので近々見てみます。

@yuskesuzki
Copy link
Collaborator

あと、こっちも読めるなら読んでみて。

"ゲームプログラマになる前に覚えておきたい技術|セガの新人教育カリキュラムから生まれたゲームプログラミング解説書!"
http://www.shuwasystem.co.jp/gpro-sp/index.html

「Chapter15 ライブラリの作り方」なんかが役に立つかもしれません。

@miio
Copy link
Owner Author

miio commented Mar 13, 2012

おっと、オンラインゲームを支える技術あるかと思ったら別の本だった。。。土日行けたら北大いこうかな

@miio
Copy link
Owner Author

miio commented May 18, 2012

さて、超久々に更新

このあたりの定義ファイルのフォーマットたたき台1作った

// 型定義
// 送受信時のパラメータ
// Model名
が恐らく最低限必要

Yamlでの例(動かないかも
model:
name: Player
param:
{
id: int,
name: string,
hp: int,
mp: int
}
emit_client:
- update_user:
{
- name
}
emit_host:
- update_user:
{
- self_all
}

といった形で定義して、それぞれジェネレータで使いやすいようにクラスを作ってもらう形がよさそうかも。

ちなみにemit_clientがクライアントが送信する時で、emit_hostがサーバが送信する時ですね。それぞれの逆がonになります。

あと、self_allっていうのが定義されてる全部のパラメータを指しますw

定義のフォーマットはぶっちゃけ何でもよくて、多分JSONで書くのが一番いいのかもしれない

@miio
Copy link
Owner Author

miio commented May 18, 2012

あ、インデントごみったw

@miio
Copy link
Owner Author

miio commented May 18, 2012

やり方としては、MVCで言うModelをベースにサーバ側とクライアントでうまく同期しましょうって考え方です。

Modelには定義があって、それぞれのインタフェースでのみ更新が許可される といった感じですかね。

で、更新されたら裏でクライアント側とも同期して〜といった感じ。

この辺のスキームが現状だと相当適当なことになっているのでつなぎ込みの意識のズレとかが出ちゃうのかなぁと思ってます。

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants