鎌ヶ迫ブログ

長らくお待たせいたしました。BREW開発環境のためのテスティング・フレームワークBREWUnit for Cのver.0.1をリリースします。現時点では、アサーションの結果をDBGPRINTF関数でそれなりにフォーマットして出力する程度の機能しかありません。ver.0.1ということでご了承下さい。

• brewunit_0.1.zip [197????]

これから時間を見つけてガリガリと機能強化を進めていきます。それに伴い、関数インタフェースが変更になる可能性が多いにありますので、どうぞご注意下さい。ライセンスはGNU LGPLです。

機能に関するご意見、ご要望等ございましたら、遠慮なくコメント下さいませ。

初の一日に二回目の更新です。

Qualcomm社によるBREWに関する情報を発信するサイトBREW JAPAN.COMに、弊社製品であるSpear®に関するコラムが掲載されました。執筆者は(一応)私です。拙い文章ではありますが、ご一読頂ければ幸いです。

コラムと一緒に掲載されている写真の三人は、弊社の取締役です。両サイドの二人は弊社の象徴(?)であるプロペラ帽を被っているのですが、お分かりになりますでしょうか? 優れたプロダクトを愉快に開発する(株)吉田鎌ヶ迫を、これからもよろしくお願いします。

» 続きを読む

コンピュータ関連の書籍を買い、部屋に山積みにして悦に入るのが趣味と噂される不肖・鎌ヶ迫です。備忘のため、最近購入したO'Reillyの書籍のうち、このブログにて未レビューの書籍をリストアップしときます;

• 「おもしろい」のゲームデザイン (読了)
• 詳解 シェルスクリプト
• プレファクタリング
• GNU Make 第3版
• Head First Java

• データベース実践講義 (注文済み)
• 開発者ノートシリーズ Maven (注文済み)

期日の保証はできませんが、読了した書籍から順にレビューしていきます。どうぞご期待下さい。

SmalltalkやJavaといったオブジェクト指向言語を利用した開発では主流となっている(気がする)テスト・ファーストですが、これを手続き型であるC言語、しかも組み込み用途のBREWで実践するためのテスティング・フレームワーク "BREWUnit for C" の開発に着手しました。

字面だけ読むと何だか凄いことのようですが、C言語用のCUnitは既に存在しますし、C++用のBREWテスティング・フレームワークもフリーで公開されています。これらを参考に、グローバル変数の使えないBREW環境、しかもC言語での開発でも利用できるものを実装しています。

現在、必要最低限の機能(assertion, 結果の出力)までは実装が完了しています。近日中にver 0.1としてこのブログにて公開します。ライセンスはGNU GPL v2に準拠する予定です。

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

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

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

今回は"Spearについて"はちょっとお休みして、ここ1週間の動きなど。

先週の01/26(木)、弊社のP2Pフレームワークを利用したリアルタイムP2Pネットワーク対戦ゲームが、auのWIN端末向けにリリースされました。携帯では初のP2Pアプリということで、多くの方が興味を持って下さったようです。ウェブサイトやブログのアクセスが増加し、無償で配布している評価版のお申し込みも多数頂きました。誠にありがとうございます。

1週間が経過し、ようやく落ち着きを取り戻しつつあります。しかし、ビジネスの面ではより一層盛り上がって参りました。あちらこちらへ足を運んで弊社製品について説明する日々でございます。本当にありがとうございます。

» 続きを読む

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

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

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

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

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

» 続きを読む