zillionプロジェクト開発ブログ

マジうれしいっす。
こんな僕の制作物に待っています。だって！？

やべえ、頑張らなきゃ。

よし、ツールバーの表示を改善、メインファイルのファイルフォーマットの最終稿の決定、MFCリボンの再構築。

それと、以前から作っていたダイアログ形式のリソースですが、自作クラスを使うと毎回メモリリークするので、Cwnd形式で少し手間をかけようかと思います。

実際の作成方法も、徐々に形になりつつありますので。

ところで、動画編集って面倒ですね。痛感しました。

NiVe作った人とかすごいです。趣味でプログラムできる人が、裏ではどれだけガンバているか、NiVeは教えてくれます。

俺だけじゃないんだ・・・そんな気分にもなります。

相変わらず、DirectXはスプライトしか表示できていません。
というのも、エディター、ランタイム汎用ライブラリの完成を待っているからです。

しかし、こちらもメインファイルのローダーを提供しています。
今後はその子供ファイルとなる、シーケンスファイルですね。

シーケンスって何かとか、そこは後々説明します。
ゲームエディタのかなり重要な部分です。
シーケンスを使って作っていきます。

それと以前、OEViewerについての説明をするといいましたが、まだですよね。
約束は破っちゃだめっすね。

OEViewerとはオンラインゲームエディターで作成されたゲームたちをつなげるというのが目標です。
例えば、メールボックス、いろんなオンラインゲームごとにあっていちいち開くのがめんどくさい、だから、ガジェットとして、ウィンドウに配置するものなのです。
フレンドリストを共用したり、ランタイムにも、できればViewerとの連携機能を用意し、プレイ中でもメッセージを送れたりしたいなーと

また、ちーと行為は、このViewerリンクから追放することで、すべてのオンラインゲームエディターで開けなくなるという、こともできるようになります。

Viewer本体はAIRで現在作成されています。担当はトビッチです。

ですが、結局はほとんどはサーバー側の工夫ですね。AIRはそれを読み込んで表示するにすぎません。

[3回]

スクショでの発表をたびたび行ってきましたが、これでは、動いていることをあまり見せられませんので、今の作業がひと段落したら、動画形式での、途中発表をさせていただきます。
また、第一回は、ソフトの動作状況のみではなく、今後どのようなソフトウェアを目指すのか、どのように動かすのか（構造）などを解説する動画を準備します。

デスクトップのムービーを撮ろうとカマハルカの瞳を使用してましたが、駒落ちが多いですね。
仕方ないんでしょうけども・・・

ゲームの内部処理のエクスポート処理にまで手が回ってきました。
今日の作業時間は、実は３０分程度なので、そこまで作業していません。
ですが、、明日ゲームの内部処理を書くために、ある程度の下準備は施しました。

エクスポートデータは仮ではありますが、あるので、早めにエディタとランタイムをシンクロさせたいです。

エディタの、重さについては少々避けられないでしょう。
MFCの時点で重く、さらにDirectXの初期化クラスで、グラボが一定以下の水準は、エラーを出して終了されるようになっています。（終了しなかったといっても実用に値しないぐらいですので・・・）、PhysXで、実際のデバッグなどを行う。（この部分でかなりのPCがアウトになる可能性があります。）

どちらにせよ、データを読んでランタイムに表示するという構造をしている以上、古いPCでは動かないのは目に見えているんですよね。それにPhysXは大きいです。
PhysXで最初に対応するのは、あたり判定のみですが、その後で、海のシミュレートや、布のシミュレート・・・
入れていけば重くなります。

どうなんでしょう・・・

[2回]

ただいま作っております。これをライブラリ化して、カズのほうに渡して、そのデータ通りに動くようにランタイムを改造してもらいます。

そうすれば、俺もエディタの機関部である、エディト機能自体に着手できるのでありますからなぁ。

今できているのは、ゲームシステムデータのローダーだけです。
これは、スクリーンがフルスクリーンで実行かとか、ゲームのタイトルとか、そのようなところのパラメーターになります。

今日製作しているのは、シーケンスごとに定義する部分、つまり、Flexでいえば、ステートに当たりますね。

これによって、ゲームをシーンごとに分けるようにします。

それはそうなのですが・・・

問題がありまして・・・

[1]ロード時間の問題
XMLのロードってどのくらいの時間がかかるのか。実用的な範囲で運用できるのか。

[2]ファイル分割の問題
シーケンスごと、武器ごと、キャラクターごとにファイルを分けられるようにした方がいいのではないか、という問題。
要所要所でロードすればいい。

[3]ランタイム開発間に合うのかという問題
エディターも最初の頃かなり遅れてたので人の事言えませんが、1人で間に合うのかという問題。


物作るって大変だなぁ

[2回]

hiroumaumaさんのブログでは、PSPプログラミング講習が人気を博しているようです。

残念ながら僕はPSPに関してプログラムを組んだことはありません。
ソースを見たことならありますが・・・
なので、MSXML6を利用した、XMLの内容の取得をしてみます。

内部を識別する処理はまだ制作していませんが、ここでは、OEのアップデート処理に使用されているソースを基に解説します。(ほとんどXPathの解説になると思います。
なんか、スクショが切れてしまっていますが、SULTはHRESULTのですね、{も切れて映っていません・・・
picasaweb.google.com/112707182961116286529/HmIZeB#5495050720645511426

ヘッダ部分はこうなってます
MSXML6において必要なのはこの３つです。
上の二つはOEの内部的な物なのでお気になさらずに。
picasaweb.google.com/112707182961116286529/HmIZeB#5495051393212118418
ヘッダの、#importだという事に気を付けてください。#include ではないです。
また、#importの後に<msxml6.h>をインクルードしないとエラーになるそうです。
一応、using namespace MXXML2;をしておく方がいいでしょう。
ただ、型があいまいですというエラーが出ることがあります。

この場合は、あきらめて名前空間から型やメソッドを指定しましょう。
ちなみにこのソース、MSXML2::となっているのはわかりやすくするためです。当然、using namespaceであらかじめ断られているので、このままでも使用できます。

さて、実際の処理のほうを見てみましょう。
    MSXML2::IXMLDOMDocument2Ptr Domp;
    Domp.CreateInstance(__uuidof(MSXML2::DOMDocument60));
で初期化しています。msxml6を使うなら、このままでいいでしょう。

    if((Domp->load(_variant_t("Updata.xml"/*実際はサーバー上のアドレスを指定します。*/))==FALSE)){/*MB_RETRYCANCEL*/
        MessageBox(NULL,_T("アップデートの確認に失敗しました。\n\nネットワークの接続の有無の確認及び公式サイトにて、パッチ等の配布がされていないかチェックしてください。"),_T("アップデーターエラー"),MB_ICONERROR|MB_CANCELTRYCONTINUE|MB_HELP);
        return E_FAIL;
    }

まず、if分の中でロードを試みて、FALSEかどうか判断していますが、MFCでデバッグならば、ASSERTでも構わないでしょう。長いので独自に#defineで作ってみたりとかでも、少し見栄えが良くなります。

メッセージボックスの中身は・・・・気にしないでください。自分で好きな物をどうぞ。

さて、実際にエレメントの中身を読み込んでみましょう。
    MSXML2::IXMLDOMNodePtr pElement=Domp->documentElement;
    CComPtr<MSXML2::IXMLDOMNode> pNode = FALSE;
    MSXML2::IXMLDOMNodePtr result;
    result = pElement->selectSingleNode("/updata/FullUpdate/DLAdd");
    AfxMessageBox(result->text);

これは,MFCで組まれているので、AfxMessageBoxで簡易的にやっていますが、使わないならば、MessageBoxやprintfでも、確認するだけであれば代用が効きます。

selectSingleNode("/updata/FullUpdate/DLAdd");
問題はこの部分です。この部分で、XMLのどこを取得するのかをXPathで決めています。

OEのこの部分は、最新版のダウンロードアドレスを取得しているところです。
ちょっと長いですが、Updata.xmlの内容は以下のようになっています。
<?xml version="1.0" encoding="utf-8"?>
<updata>
<PachedUpdate>
  <Docs name="Editer">
    <DLAdd>
      http://www
    </DLAdd>
    <id>
      1.00
    </id>
  </Docs>
  <Docs name="Runtime">
    <DLAdd>
      http://www
    </DLAdd>
    <id>
      1.00
    </id>
  </Docs>
</PachedUpdate>
<FullUpdate>
  <DLAdd>
    サービスは停止しました。（＾ω＾）
  </DLAdd>
  <id>
    1.00
  </id>
</FullUpdate>
</updata>

実際はサービスは停止しましたのところに、DL先のアドレスがあり、ダウンロードされるように作っているのですが、とりあえず表示するだけなので、これを取得してみます。
picasaweb.google.com/112707182961116286529/HmIZeB#5495058465513221266

まあ、こんな感じですね。
さりげなくスクショ公開しましたが・・・

ちゃんと中身が表示されています。
変えればこんな風になります。
picasaweb.google.com/112707182961116286529/HmIZeB#5495059856599499714

さて、ボケはこのくらいにして、開発を急がなければ～

[1回]

ようやくMSXMLの使い方がわかってきました。

XPathを使えば楽に、目的のエレメントが取得できます。

なんか、ブログの記事が難しくてつまらないぞとメールで、ご指摘いただいたので、今やっていること、わかりやすく書かせていただきます。

・自動アップデートへの対応

今やっているのは、自動アップデートそのものではなく、サーバー上からアップデートがあるかどうかを確認するものです。それからですね、ファイルを自動でダウンロードして、書き換えるのは。

どのようにやっているかというと、サーバー上には、最新のファイルたちのバージョンのリストがあります。
インストールすると、ローカルにファイルたちのバージョンを記憶する情報がレジストリに書き込まれます。

もし、このレジストリの値と、サーバーのバージョンの値が異なれば、もちろんのこと、このファイルは違いますね。

なので、そのファイルだけを受け取るのです。

・3Dのライブラリ化

例えば、エディターで作っているときに表示されていた3Dグラフィックと、実際に配布時にランタイムで実行されるときに表示される３Dグラフィックが違ったら大問題です。

正しく表示されるように作ったつもりが、表示されなかったり・・・

なので、このような基本的な描画処理は、エディターもランタイムもいっしょにしてしまおうというのが、目的なのです。

これによってそのようなこともなくなります。

・スタートウィンドウの作成

どんな人でも、初めて触るツールというのはとても扱いづらいものです。
なので、この改善策として、最初のウィンドウには、「学習」という項目があります。

そのうち用意するそれぞれのヘルプファイルへのアクセスのためです。

また、新規作成、開くなど基本的なアイコンもスタートウィンドウにおいておけば、グラフィカルなウィンドウで非常に操作しやすいのです。

・OEVServer[仮称]の作成開始
C#ですが、これはegretの作業項目となっています。
なぜC#にしたかというと、確かにjavaのようにクロスランタイムは無理ですが、サービスとしての運用が比較的容易であること。

また、javaに比べ少しばかり軽いこと。

LINQというシステムで、データベースに簡易的なアクセスを施せることです。

・OEViewer[仮称]の作成開始
これはAdobe AIRです。トビッチの作業項目となっています。
なぜ、AIRなのかというと、グラフィカルなデスクトップウィジェットを作れるからなのです。

これについての説明は明日です。というのも、これだけで1記事かけてしまうほど大きな内容なのです。

また、明日は久しぶりにスクショの日です。

少しは取れる内容があるかとは思いますので、頑張ってみます。

[1回]