鎌ヶ迫ブログ

弊社製品であるP2Pリアルタイム通信用フレームワーク Spear® について、お客様からの要望が多い機能を追加いたしました。本件に関するプレスリリースも発表し、CNET JapanやケータイWatchなどにも掲載されております。

今回追加した機能は、主にサーバ側の処理であるマッチングについて、タイムスタンプの古い方から自動的に端末をマッチさせるのではなく、いくつかの条件に応じたマッチングを実現させるものです。特に要求の多いキーワードマッチング、スコアやランク、年齢といった幅を持たせたい数値を用いるマッチング、そして接続相手を指定するマッチングの3通りの方法を新たにご提供させて頂きました。

追加した機能の詳細につきましては、弊社プレスリリースをご参照下さいませ。なお、今回の機能追加は、Spear®フレームワークの有償版にのみ対応しています。無償評価版につきましては対応いたしませんので、あらかじめご了承下さい。

それでは、実際のケータイアプリについて見てみましょう。

これまで、ケータイで対戦ゲームを作ろうとした場合、必ずゲームサーバを中継しなければなりませんでした。端末と端末が直接通信を行うことができなかったからです。結果、ユーザ数の増加に伴ってゲームサーバの負荷は高くなり、それを解消するためのコストが高くつくというゲームメーカにとっては大きな問題がありました。ユーザにとっても、他のユーザが増えることによって対戦が遅くなる、コストがゲームの価格を押し上げるというストレスの原因となっていたのです。

また、ゲームサーバでの中継にはHTTPという、主にウェブサイトを表示する時に利用するプロトコルが利用されています。この通信は人間が理解できる形式で行われているため、やや時間が掛かるという欠点もあります。結果、リアルタイム性を必要としない、カードゲームやボードゲームがケータイでの対戦ゲームの主流となっていました。

なぜC/SモデルではなくP2Pモデルなのか。前回はC/Sモデルの問題点を上げてみました。では、P2Pモデルはどう違うというのでしょうか?

直感的にもお分かりになると思いますが、ボトルネックとなるサーバが不要になるので、「速い」。これに尽きます。そもそもボトルネックとなるサーバが存在せず、端末はそれぞれ自律的に通信を行います。 ユーザが倍になろうが負荷はそれぞれの端末間に閉じ、全体として分散されますので、通信への影響は限りなく小さくなるのです。

また、サーバに掛けるコストは不要となりますので、他の力を入れるべきポイント(例えばゲームコンテンツそのもの)にリソースを割くことができるようになります。

つまるところ、Spearは、「サクサク動作し、携帯電話の端末と端末が他者を介在させずに直接通信するための機能を提供する、ソフトウェアの大きな枠組み」であるということです。

さて、もう少し突っ込んだ話をします。なぜサーバが介在するクライアント-サーバ(C/S)モデルではなく、端末同士が直接通信を行うモデル(P2P)を採用したのでしょう?

» 続きを読む

先の記事にて "明日から" と書きましたが、一週間後になってしまいました。申し訳ありません。

さて、まずはフレームワークとは何か、というところから説明します。フレームワークとは、ある機能を実現するための大きな枠組みです。ゼロからすべて作成するのではなく、フレームワークが用意している機能を利用することで、品質の向上や工数の削減を期待できます。例えば、高速対戦ゲームを実現しようとしたら、高速対戦用のフレームワークの上にゲームを作ればよいのです。

同じような概念に、ライブラリというものがあります。フレームワークとは異なり、機能を実現するために利用する細かい部品です。フレームワークの上にソフトウェアが乗っかり、ソフトウェアにライブラリを組み込む、というイメージでしょうか。

» 続きを読む

これまでこのブログでいろいろと記事を書いてきましたが、弊社製品について一切触れることがありませんでした。先の記事へのコメントにて弊社製品についてご質問があり、また、丁度よい機会ですので、弊社製品について少々書いてみたいと思います。

弊社商品 "Spear®" は、BREWに対応した携帯電話向けのP2P通信フレームワークです。

と書いても、業界の方でなければよく分からないと思いますので、明日から簡単に説明していこうと思います。