Unionしりとりを作ったときの悩みどころ

ちょっと前のことになるけれど、まる1日ぐらいかけてUnionフレームワークでしりとりをつくってみました。Unionフレームワークというのは、簡単に言うと、非常に機能が限定されたサーバーを介したFlash(クライアント)同士の通信をするためのフレームワークです。

http://wonderfl.net/code/09c5c9273314f630a67ec6a021913e153317de2c

Unionというフレームワークを見て、最初に思いついたアイデアがFPSとしりとりでしたが、Unionではサーバー側にはクライアントが作ったattributeを保存する機能しかなく、クライアント同士で同期させてオブジェクトを出現させる等のことはとても難しいです。それに気づいたときにはcheckmate〆切直前で、もう諦めざるを得ませんでした。直前にTypeShootができていたのも、応募するには厳しかった一因です(質が良すぎるのとと遊びすぎという意味で)。
FPSは上記の理由と、応答に100ms弱かかるという理由で見送りましたが、しりとりはそういうのが関係ないので、「クエリの読みを得る」関数と「クエリが汎用性のある語か知る」関数を実装すればできたも同然です。

まず「クエリの読みを得る」方法は、SocialIMEを利用しました。前々からよく使っていたのですが、SocialIMEの変換APIに漢字交じりの語を投げると、ちゃんと文節に区切られて変換されて返ってきます。漢字の箇所にはかならずひらがなの候補が混じっているのでこれを取り出してつなげると読みになります。SocialIMEは新語がどんどん登録されているので新語の読みはばっちりです。文節区切りや漢字の読みを間違ってしまったり、ひらがなの候補が複数ある場合は違う読みがとれたりしますが、めったに起こりません。
SocialIMEのドメインにはcrossdomain.xmlがないので、Flashでリクエストするにはプロキシを通す必要があります。5ivestarさんのプロキシをお借りして、読みだけ取り出すサンプルを置いておきました→● また、SocialIMEにはカタカナをひらがなにする機能はないので、そこは自前で実装しなければなりません。面倒くさかったので、Kana.ASのソースをお借りしました。

次に、「クエリが汎用性のある語か知る」方法ですが、これはASに限らずかなり難しい問題です。最初Google Trendで検索してひっかかったらOKにしようかなと思っていましたが、Google Trendには公式のAPIがありませんでした。仕方がないので、クォーテーションでくくって、Google AJAX Search APIで検索して、カウントが高いものをOKにすることにしました。ただ、この方法には欠点があって、文章の一部にマッチしてもカウントされるので、短い文字数の語が（たとえ単語の形をなしていなくても）たくさんヒットするようになってしまいます。また、「単語＋助詞」の形の語もたくさんヒットしてしまいます。前者は文字数制限をかけることである程度対処できますが、後者は現状解決する手段がありません。

これでしりとりを作れます。しりとりが終わってしまった場合の処理が面倒くさかったので、何文字でも尻を取れて、「ん」で終わっても続くようにしました。

軽く運用していて次のことに気がつきました。

文字数3文字以上では緩い。また3文字の場合「ブーン」等がきたときに続けられない。
しりとりに終わりをつくってしまったら、強制的に終わらせる荒らしが出てくるかもしれないので、やっぱりなくていいのではないか。リセットボタンも同様の理由で悩む。
「を」「アッー」などどう考えても続けられない語は、最初からはじいてしまおうか。
わからない単語が出てきたとき、即座にぐぐれるようにしようか。
チャットできたらいいなぁ。

以上を鑑みて現在の形になりました。一度やってみてください。たまに1人でやっていると、ブレーンストーミングっぽくなります。