Webを支える技術

Webを支える技術 †

ゲームプログラマーが読むWebを支える技術 †

#amazon(4774142042,left)

ゲームデザインとWebAPIデザイン †

友人から勧められて「Webを支える技術」を読んだ。 RESTやURIに関して、曖昧な理解しかしていなかったので、腑に落ちる記述が多く、とても参考になった。 たとえば、RESTやURIはリソースを表すので、URIには、名詞を用いるべきであるという指摘はなるほどと凄く参考になった。 これから、ゲームプログラマーは、WebAPIを用意することが多くなるだろうから、そのルールは、意識しておく必要があるだろう。

私はゲームプログラマーなので、ゲームの場合はどう書くかと想像しながらこの本を読んだ。この本を読んでいて、図らずも一般のWebプログラミングと、ゲームプログラミングの違いが明らかになった。

それは、ゲームのプログラミングには、"交換原理"があるという点だ。

そして、ゲーム用WebAPIは、RESTの原理に逆らって、動詞をURIに使う必要が出てくるだろう。 つまり、攻撃する、歩く、魔法を唱える、商品を買うのような、動詞をURIに含める必要が出てくる。 その場合、べき等(何度その更新が行われても、結果が変わらない)を維持することは難しい。

なぜならば、ゲーム自体が、リソースを直接触るのではなく、コストとリソースの交換に基づいてデザインされるからだ。 つまり、ブログの投稿と違い、交換がゲームロジックの中心にある。

ブログの更新と、経験値の更新の違い †

たとえば、エントリーの投稿や更新は、以下のようにする。

エントリー投稿

POST /blog/entry/ HTTP1.1
host: example.jp

エントリー編集

PUT /blog/entry/11211 HTTP1.1
host: example.jp

この場合、直接、entryの生成や、entry 11211番の編集を行える。つまり、URIは名詞(リソース)であり、PUTやPOSTと言う動詞を用いて、リソースの制御を行うと言うRESTの哲学に合致する。

しかし、ゲームの場合、例えばHP(ヒットポイント)が1000あるボスへの攻撃で以下のようにしたらどうなるだろう。

PUT /enemy/boss/hp HTTP1.1
host: example.jp

HP->0

いきなり、ボスのHPを1000が、0になってしまった。あるいは、それすらもめんどくさいから、もう自分の経験値を直接いじる。

PUT /my/exp HTTP1.1
host: example.jp

exp->1000000

経験値が、0から1000000になった。はぐれメタル何匹分だよ。

ゲームの場合、何かアクションして、その結果、何かリターンを得ると言うパターンが多い。

例えば、

呪文を唱える。->自分のMP(マジックポイント)を10減らす。->敵に、HP20ポイント分のダメージ
敵を倒す。->自分のHPが40減る。->経験値30ポイント獲得
アイテムを買う。->自分のGoldが300減る。->強い武器を獲得

の様に、さまざまな行為が、何らかの交換を伴っている。 逆に、ユーザーが直接、経験値や、ゴールドを制御することは出来ない(それはチートと呼ばれる)。ゲーム内では、直接、リソースを制御することは無い。

むしろ何らかの行為を通じて、リソースは増減する。例えば、敵を倒す。村を救う。全滅するなどの行為により、経験値が増え、ゴールドが増減する。

ゲーム向けWebAPI †

「Webを支える技術」のRESTの話を参考に、ゲーム用WebAPIを考えると以下の様になる。

PUT /行動主体/動詞/ターゲット/ターゲットID/ HTTP1.1
host: exmaple.jp

多分、名詞と、名詞を、動詞でつなぐとシンプルな表現になるのではないか？

PUT /my/attack/enemy/101/ HTTP1.1 <-敵ID 101を攻撃
PUT /my/buy/item/1011 HTTP1.1 <- itemID 1011を買う

無論、もう少し複雑な例は

PUT /my/spell/magic/10/enemy/101 <-魔法ID 10 を敵、101にかける。

のような例が出てくる。英文法の SVOO(主語、動詞、目的語、目的語)とか思いだすと良いかも。 しかし、この場合、本書で言及されているような、べき等を守ることは難しい。過負荷によって、/my/attack/enemy/101が複数回実行されると、それだけでゲームバランスが変わってしまう(HTTPの利点であるコネクションレスが悪い方向に作用してしまう)。

ゲームデータ参照は、GETが良い †

一方で、ゲームデータの参照は、GETが十分役に立つ。

GET /my/exp HTTP1.1 <-経験値を参照
GET /my/status/hp HTTP1.1 <- HPを参照

の様に、自分のゲームデータを参照する祭には、GETが役に立つだろう。

ただし、一回読んだら消えてしまう魔法の地図とかを作る場合には、GETで良いのかまだ分からない。べき等でないし、参照であるにも関わらず、主人公の状態が変化するからだ。

まだまだ、試行錯誤 †

ゲーム用のWebAPIはまだ少なく。私は、良いAPI設計がなんであるのかまだ分からない。ただ、RESTの原則に逆らって、参照以外の行動には、動詞を含むAPIとして設計するのがよいのではないかと思う。