プロフィール

Na-7

Author:Na-7
SE(システムエンジニア)として約15年間システム系ソフト会社を勤めあげ、2008年3月退社。現在、ゲーム制作会社設立を目指して活動中。


アクセスカウンター


最新記事


最新コメント


最新トラックバック


月別アーカイブ


カテゴリ


DATE: CATEGORY:スポンサー広告
上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。
| BLOG TOP |
DATE: CATEGORY:三国志軍記開発
拠点モデルの高さ修正04
開発中のメイン画面
以前は斜面が地形モデルより突出していたが、配置座標や外壁の修正により、斜面でも違和感なく配置されるようになった。



◎原因調査

部隊を拠点位置に移動させると、拠点モデルから若干離れた場所に集合します。

これは拠点モデルの配置場所がズレてるから…と予想したのですが、チェックすると、指定したXZ座標位置に正しく配置されてました。ということは、部隊の配置場所がズレてるということ?



◎拠点の高度修正

拠点モデルの配置座標をチェックしていたら、拠点モデルが地面にめり込んでいるのが気になってきたので、先にこれを修正しましょう。

従来は、拠点モデルの中央の高さに合わせて配置していたので、中央より周囲の位置が高いと、斜面が突出しました。

拠点モデルが地面にめり込んでいる


そこで、城のY座標を「周囲8隅の中で、一番高い座標に合わせて配置」しました。

拠点モデルの高さ修正01

めり込み現象は解消されました。しかし、真横から見ると空中浮遊状態に見えます。

拠点モデルの高さ修正02

カメラの角度を制限すればごまかせそうですが、できればもう少しマシな状態にしたいですね(^^;



◎外壁の高さ修正

そこで考えた案は「城壁の外側のみ高くする」です。

城モデル修正 → 画像再取得 → 城簡易モデル修正

拠点モデルの高さ修正03   拠点モデルの高さ修正04

地面にめり込まず、空中に浮かず、斜面でも綺麗に配置できました!^^



◎欠点

新方式は1つだけ欠点があります。城門の位置が隠れることが多いのです。

城壁が高いバージョンと低いバージョンを使い分ければ対処可能ですが、モデルパターンを増やすとパフォーマンスが低下する(インスタンシング効果が薄れる)懸念があります。

また、普段はカメラ位置が遠いので、城門の有無を気にするプレイヤーは少ないと思います。

以上の理由により、この欠点は対処せず放置します。
(最終段階でパフォーマンスに余裕があれば対処するかもしれませんが、優先度は低いですね)



◎次回予告

長らく放置していた問題を1つ解決しましたw

次回は「6月の総括と7月の目標」です。

スポンサーサイト

テーマ : ゲーム製作 関連 - ジャンル : ゲーム

| BLOG TOP |
DATE: CATEGORY:三国志軍記開発
エースター法による移動経路実装07
開発中のメイン画面
経路探索中のフリーズ現象が解消され、プレイヤーが気持ちよくプレイできるようになった。但し、経路探索は従来より時間がかかるようになった。



◎フリーズ回避方針検討

今回は、遠距離経路探索時のフリーズ現象を回避する方法を検討します。

A案
 探索処理効率を上げて処理時間を短くする

B案
 遠距離探索を行わないよう探索条件に制限を設ける

C案
 探索処理を定期的に中断/再開して
 他の処理を並列的に進める

D案
 探索処理をスレッド化して
 他の処理を並列的に進める

まずA案ですが、フリーズ現象は長い場合4~5秒に及ぶことがあります。60fpsを目標とした場合、処理時間を5000ms→5ms=1/1000としなければなりません。さすがにこれは無理っぽいのでA案は却下します。

B案は有効な回避策の1つと思いますが、(Xbox360と異なり)PCは個体差が激しいので、PC性能によって探索時間が異なるという問題があります。例えば、CPUが2.6GHz程度であればマップの1/4ぐらいの距離までOKですが、低性能PCの場合は1/4でもNGです。1/4を切るとゲームデザインに支障を来してしまいますが、「CPU2.6GHz以上」という動作環境条件は厳しすぎるので、B案はなるべく避けたいですね。

C案は、経路探索中の部隊のみ停止します。他の処理は並列的に動くので、フリーズ現象は回避されるハズ(^^;
B案に比べて、動作環境や探索距離の制限が不要というメリットがありますが、プレイヤーが味方部隊に遠距離を指示した場合はしばらく待たされます。

D案は、実装に「スレッド化」という技法を用いる点はC案と異なりますが、方向性/メリット/デメリット等はC案と同じです。


こうして考えると、D案が一番スマートに出来そうな気がしますが、私はスレッド化未経験なので、1から勉強した上で大幅改修を覚悟する必要がありそうです。今の所他にスレッド化したい処理は無いので、今回はC案にします。



◎探索処理の中断/再開

C案を具体的に記述します。

・所要時間カウンタ/中断箇所マーカーを設ける

・探索処理中に所要時間カウンタをチェックし、
 一定時間が経過したら処理を一時中断する
 (中断箇所をマーカーに記録する)

・中断すると、他の処理が通常通り行われる

・次フレームUpdateの際に、中断箇所マーカー位置から
 探索処理を再開する

今回の改修にあたり、地形種別情報クラスと最短経路探索クラスを分離しました。移動コストは地形種別に依存するので1つのクラスだったのですが、デカくなりすぎたので分離したら、プログラムが把握しやすくなりました。



◎デバッグ

改修後に動かすと、フリーズ現象が解消されないばかりか、エラーが出るようになりました。
あちこち手を入れ過ぎたかなぁ?

とりあえず一時中断箇所をコメント化すると、従来通り正常動作しました。中断/再開処理の何かがおかしいようです。

その後の調査で、エラーの原因は「経路が2地点を永久ループしオーバーフローに至る」という所まで判明したのですが、何故そうなるかは不明です。

試しに部隊数を1部隊に限定すると、フリーズ現象は解消されないものの、エラーは発生しなくなりました。
わけがわかりません(--;

…いや、ちょっと待てよ?
よく見ると、コマ送りで動いてるっぽいので、もしかしたら一回のタイムリミットが長すぎるのかも?

タイムリミットを 16ms→1ms としたら、フリーズ現象が解消されました!でも、フレームレートは8fpsで思いっきりカクカクします(処理落ち現象)。タイムリミットを1msとしたのに、Update()が16msとなる理由は不明。



◎システム時刻の取得

Update内でシステム時刻を取得するコードはこんな感じです。

DateTime timeLimit = DateTime.Now.AddMilliseconds(1);
while (true)
{
  if (DateTime.Now > timeLimit)
  ~


ところが、ループ内でDateTime.Nowを出力して確認すると、値が変わりません。どうやら、System.DateTimeの値は1フレーム内で更新されない模様。

フリーズ現象が解消されなかった原因はコレか(--;



◎Stopwatchを利用する

1回のUpdate内で正確な経過時間を取得する方法が無いかとネットを調べたのですが、希望に沿ったものはなかなか見つかりません。しかしふと「タイムルーラーが1フレーム内の経過時間を正確に測定している」ことに気が付いて、ソースを解析すると、Stopwatchクラスを利用してました。

あれ?以前も調べたような…デジャブ?w
とにかく実装しましょう。

// ストップウォッチの宣言
Stopwatch stopwatch = new Stopwatch();
// ストップウォッチのリセット
stopwatch.Reset();
// ストップウォッチ開始
stopwatch.Start();

while (true)
{

  // ストップウォッチのチェック
  if (stopwatch.ElapsedMilliseconds > 3)
  ~


エースター法による移動経路実装06

実行すると、60fps(Updateは4.2ms)を綺麗にキープ!!

経路探索中は部隊の位置が停止(アニメや操作は有効)し、経路決定後に移動が始まります。

やりました!フリーズ現象解消です!^^



◎エラーの原因と対策案検討

しかし、部隊を増やすと経路探索処理でエラー発生。

原因は、経路探索インスタンスが1つしかないので、複数部隊が共有すると経路がゴッチャになるからでした(>_<)

というわけで、対応策を検討します。

A案(並列処理方式):
・探索要求毎にインスタンスを作成する
・メモリ効率が非常に悪い
・探索時間は経路の長さに比例する

B案(待ち行列方式):
・探索中に他の探索要求が来ると待ち行列に記録する
・探索要求は受付順に処理される
・探索距離が近くても、長時間待たされることがある

C案(単一処理方式):
・探索中に他の探索要求が来ても無視する
・探索が終わると、次の探索要求を受け付ける
・他の探索処理が全て終わるまで待たされることがある

A案が最も公平で理想的な印象を受けますが、問題はメモリ効率の悪さです。100部隊の探索要求が同時に発生した場合、単純計算でメモリ100倍喰うので、これは避けた方が無難ですね。

次に公平と思われるのはB案ですが、よく考えるとこのゲームではあまり意味が無さそうです。

・ゲーム開始時のみ探索要求が大量発生する
・ゲーム開始後は探索要求が重なることは少ない

ゲーム開始時の順番を制御しても意味がありません。
(全部隊の探索完了後にゲーム開始が理想)
というわけで、C案とします。



◎実装

C案を実装し、80部隊で試してみました。

エースター法による移動経路実装07

最初は全部隊停止状態ですが、60fpsで(フリーズ現象なく)アニメは動き続け、経路探索が終わった部隊から移動開始します。

気になるのは、5分経っても移動しない部隊が半分以上いることです。以前はフリーズ状態(経路探索に16ms使用した状態)で3~4分かかりましたが、今は経路探索に3msしか使用していないので、20分ぐらいかかるかもしれません。



◎次回予告

フリーズ現象は回避できましたが、ゲーム開始時の80部隊経路探索が20分もかかるのは問題です。とりあえず他の課題を片付けてから時間短縮を図りましょう。

前回ラストに記述した懸案A~Bを解消したので、次回は懸案C~Dに取り組みます。

テーマ : ゲーム製作 関連 - ジャンル : ゲーム

| BLOG TOP |
DATE: CATEGORY:三国志軍記開発
エースター法による移動経路実装04
開発中のメイン画面
マップ全域に80部隊を分散配置し動作テストを行った。中央(黄矢印)に向けて最短経路で移動している。



◎遠距離対応

今回はまず遠距離対応の改修を行います。と言っても、多分配列の上限を上げるだけで動くと思いますが、問題は上限を幾つにすべきか?

マップは256×256だから理論上の最大値は65536かもしれませんが、現実問題としてこれはありえません。では幾つぐらいが妥当でしょうか?

…いや待てよ?よく考えたら、経路探索後に配列を毎回初期化して経路数分確保すれば済む話では?

…くだらない問題でお騒がせしました(汗)



◎測定

遠距離対応の改修及び動作テストは良好でした。残る問題はパフォーマンスなので、パターンを変えて所要時間を測定しました。

エースター法による移動経路実装04

条件:
 80部隊をランダムに配置し、中央に移動させる

結果:
 100×100(面積比:1/25) 経路探索=1~2s 移動中=60fps
 250×250(面積比:1/4) 経路探索=15~20s 移動中=60fps
 500×500(面積比:1/1) 経路探索=70~80s 移動中=60fps




◎分析と考察(経路探索)

経路探索の所要時間は面積比に比例するようです。今回は集合場所が中央なので、端から端まで対角線に指定するとさらに時間がかかりそうですが、そのような操作は通常行わないので、今回の条件で十分と思います。

500×500で80部隊80sということは、平均すると1部隊1秒ですね。但し移動距離は最長でも端から中央までですし、ランダム配置なので平均的に考えると「マップ全体の1/4程度の距離を1部隊移動させる経路探索に約1秒かかる」ということです。

1秒というのは微妙な時間ですが、

・1度に複数部隊の経路探索が行われないよう
 ゲームデザインを工夫する

・経路探索中画面がフリーズしないよう気を配る

上記の方向で回避したいと考えています。

…でもやっぱりフリーズしちゃうかな?この点に関しては後で検証します。



◎分析と考察(移動処理)

今回は前回よりも動作が軽く、60fpsをキープしました。前回は裏で何か(WindowsUpdate等?)が動いていたのかもしれません。

もう少し詳しく説明すると、Update()が0.3msで、負荷の大半はdraw()によるものです。広面積の方が早く(10ms)、中央に部隊が集中すると遅く(15ms)なります。これはネームプレート描画負荷の影響によるものと思われます。(遠くの部隊はネームプレートが表示されないので負荷が軽い)

経路移動処理はUpdateなので、これをさらに早くしても殆ど意味がありません。というわけで、(経路関連の)移動処理パフォーマンスは現状でOKと判定します。


余談ですが、ネームプレートはXNA標準のスプライトバッチで実装しているので、全ネームプレート(文字入り)を画像に落としてインスタンシングで一括描画すれば、パフォーマンスが改善出来ると思います。
(今の所実施予定はありませんw)



◎動作テスト

経路探索中に画面がフリーズしないか動作テストを行います。

条件:
・各部隊がランダムで指定した拠点に移動する
・目標拠点に到着したら、他の拠点に移動する


プログラムは簡単に出来たのですが、開始から小一時間待っても動きません。中断して詳しく調べると、経路探索中のクローズリストにノードが5万件以上溜まってました(爆)

もしかしたら、拠点が移動不可の場所に存在し、移動不可の判定を出すまで全経路を探索しているのかもしれません。(注:拠点の配置場所と地形種別はまだマッチングしてません)

拠点番号を固定して確認すると、移動不可の判定を返すまで3分ほどかかる様子。
80部隊×3分=240分(約4時間)
…そんなに待てないよ!(^^;


移動可能な拠点番号を指定した場合は、ある場所に部隊が集合します。でも、集合場所に拠点が存在しません。何か変ですね(?_?)

…ああそうか!
拠点のposには、マップ座標ではなくオリジナルの緯度経度情報を格納したのを忘れてました!

移動不可が多い原因はコレだったんですね(^^;



◎拠点間の移動

プログラムを修正すると、部隊が拠点間を移動するようになりました。

エースター法による移動経路実装05

部隊が目標の拠点に到着すると、次の目標拠点をランダムで選択し移動を再開します。狙い通りの動きになりましたが、懸案も見えてきました。


懸案A:
 初期経路探索時にフリーズする(約3分)

懸案B:
 次の経路を探索する際にフリーズすることがある(約1秒)

懸案C:
 拠点の座標と表示位置が少しずれている

懸案D:
 移動不可の拠点が存在する(少数)

懸案E:
 移動不可時の処理未実装

懸案F:
 部隊任務との連携は未検証

懸案Aは、シナリオ初期データを工夫して、初期目標を中~近距離に制限すれば多少緩和できます。懸案C~Fは今後の課題です。

問題は懸案Bで、画面が一瞬静止状態となるので、プレイヤーに過度のストレスを与えてしまいます。しかしこれを改善するのはかなり難しそうです(--;



◎次回予告

今回は、拠点間を最短経路で移動させることが出来ました。

次回は、懸案Bの対処方法について検討します。

テーマ : ゲーム製作 関連 - ジャンル : ゲーム

| BLOG TOP |
DATE: CATEGORY:三国志軍記開発
エースター法による移動経路実装03
開発中のメイン画面
全80部隊を一斉に動かすことが可能となった。一斉に動く様はなかなか見応えがあるが、今後のパフォーマンスには不安があるようだ。



◎原因調査

前々回は、曹仁部隊の最短経路移動に成功しました。しかし他の部隊は動かないので、原因を調査して修正します。

まず他部隊の座標値を逐次出力して確認すると…あれ?座標値は変化してますね?

否!よく見ると、(上下or左右or斜めに)プラスマイナス1.0の範囲でループしてます。何かチラチラすると思ったら、同じ場所で向きだけ超高速反転してたんですね(笑)

さらに全変数を細かくトレースして解析すると、移動経路座標にY座標(高度)を反映してなかったので、現在座標から中間目標座標までの距離が正しく算出されていないことが判明しました。このため中間目標配列番号を指定するカウンターが更新されず、最初の中間目標座標から動かない状態となってました。

ちなみに、曹仁部隊はデバッグ設定のためY座標を0としていました。つまり、ミスにミスが重なったので、逆に正常動作したというわけです(爆)



◎修正

高度を設定すると正常に動き出したので、座標系を適当に調整した上で、80部隊(モデル400体)をランダムに配置し、中央に移動させてみました。



多数の兵士が一斉に(中央を目指して)動く様は迫力があるというか、見応えありますね^^



◎今後の課題

動作はOKですが、パフォーマンスは△(やや不満)です。

○経路探索
・80部隊の近距離経路探索に1~2秒かかる
 →ゲーム開始時は気にならない
 →プレイ中の再探索は注意が必要
  →ゲームデザインの工夫で回避?
 →遠距離は未対応

○移動処理
・80部隊の通常描画で50fps(15ms)
 →現時点では遅いと感じないが、
  画面分割/索敵範囲/履歴矢印などを追加すると
  30fpsを切る可能性が高い

後々のことを考えると、パフォーマンスをもう少し上げたいところですが、改善の余地はあるのでしょうか?



◎次回予告

次回は遠距離対応の改修と、パフォーマンスの改善を図ります。

テーマ : ゲーム製作 関連 - ジャンル : ゲーム

| BLOG TOP |
DATE: CATEGORY:三国志軍記開発
三国カオス
三国カオス
基本プレイ無料のMMORPG。絆を結んだ有名武将に変身し、その能力を使うことが可能(時間制限あり)。他プレイヤーやNPCを交えた団体戦も可能。



◎5月の目標達成度

・活動時間月140時間以上

実績:96h(達成率:68%)

 (中間目標:5/15迄に70h以上)

実績:50h(達成率:71%)


・駐留任務関連画面調整(8h)

実績:13h(達成率:100%)


・年間スケジュール見直し(16h)

実績:6h(達成率:100%)


・移動ルート作成ロジック実装(40h)
・部隊移動処理の実装(24h)

実績:46hで実装中(達成率:60%)


・ブログ更新/HP更新(40h)

実績:31hでブログ更新、HPに「A*(エースター:最短経路探索アルゴリズム)サンプル」追加


・別件企画(12h)

実績:未着手


活動時間少なすぎです(ーー;



◎作業時間分析


作業時間集計2011年5月(PDF形式)

○良かった点
・予定作業はほぼ全て着手した
・移動処理方式を確定させた

○悪かった点
・中盤に休みすぎた
・集中力が長時間続かなくなった

沢山休んでおきながら、長時間頑張る日も無いので、活動時間が全然伸びませんでした。



◎5月はサボリ

5月中旬に休みが多いのは殆どサボリです。道路工事とか目が痛くて空けられない日もありましたが、夜中に数時間ぐらいなら出来たはずです。せめて休み明けに8時間以上出来れば良かったのですが、暑くなってくると集中力がもたず長時間できませんでした。

いい加減暑さ対策を講じようと、100円ショップでつっかえ棒2本と断熱シートを購入し、天窓からの日光を強引に遮光したら、少し涼しくなって後半ペースが徐々に回復してきました。


ちなみに、道路工事は同じ場所を何度も掘り返すのが不思議だったのですが、これは近所の家が建て増しする準備だったようです。(正式に挨拶に来ました。建屋の工事は7~9月とのこと。本番はこれからかーー;)



◎近況報告

5/30以降、6月前半までほとんどお休みしました。これはただのサボリではなく、深刻な理由があります。


甥が学校の友人達に性的な動画を撮られてメールでバラまかれていたことが発覚し、大騒ぎになりました。学校側の調査では10人以上の子供達に流布済で、完全な回収は不可能とのこと。狼狽した母親(姉)の相談役となって集中的にフォローしてました。

学校側は加害者の親子を集めて厳しく指導し、また警察と相談して、加害者のパソコン調査や事情聴取を依頼しました。一方で「これは氷山の一角ではないか?」という疑念が湧き、甥にさぐりを入れると過去に同様の事件があったことが発覚し、再び大騒ぎになりました。

今回の事件で、子供達の「いじめ」の根深さを改めて痛感しました。いじめた側はちょっとからかった程度の認識で害意は薄いようですが、子供達はまだ半人前で法律/常識/モラル等が欠けており、「これ以上やってはいけない」という一線を平気で超えてしまうのが恐ろしいですね。

5/30から本件のフォロー及び家庭教師のボランティアを引き受けて注力してましたが、事件は現在収束しつつあり、6月の定期試験も終えて家庭教師も一段落しました。(今後は週1~2回のペースでやります)
また、甥はLD(学習障害)の可能性があるかもしれないので、最近はそちらを調査しています。


それと、今週父親が癌手術を行いました。手術は無事成功したので一安心ですが、付き添いを母親一人に任せきりにするのは良くないので、たまに交替したり精神面のフォロー等を行っています。



◎進捗状況チェック

5月に部隊移動処理が終わらなかったので、5月末時点で1~2週間分遅延している状況です。6月はさらに遅延するので、来月初旬に計画を再調整します。



◎6月の目標

・活動時間月72時間以上

・部隊移動処理の実装(32h)

・駐留任務効果の実装(16h)

・ブログ更新/HP更新(24h)

部隊移動処理を早く完成させたい所ですが、パフォーマンスの問題はかなり厄介かもしれません。



◎次回予告

次回はエースターによる移動経路実装(その2)です。

テーマ : ゲーム製作 関連 - ジャンル : ゲーム

| BLOG TOP |
DATE: CATEGORY:三国志軍記開発
エースター法による移動経路実装01
開発中のメイン画面
エースターによって導き出した移動経路を視覚的に表示した。川の迂回経路が確認できる。



別件トラブル対応のため、しばらくお休みしてましたが、そちらの見通しがついたので、開発を再開します。


◎移動コストの準備

今回はメインプログラムにエースターを組み込んで、部隊の移動処理を実装します。

まずはじめに、移動タイプ別の移動コストデータを準備しましょう。

移動コストデータ(移動タイプ:騎馬)(PDF)

これは騎馬タイプの移動コストです。縦軸が移動元の地形、横軸が移動先の地形です。

移動コストは移動先の地形のみ影響するゲームが多いのですが、三国志軍記では、移動元の地形も影響します。ちなみに、移動コストが最も軽い(早い)のは「道→道」のパターンです。



◎ノード&エッジデータのメモリ展開

ノードやエッジデータは、予めメモリに展開しておくことにしました。プレイ中に動的に取得することも可能ですが、

・マップの端はエッジ数が異なる
・移動タイプによって侵入不可地形が異なる
 (エッジ数が異なる)

経路探索ループ内で、上記を毎回チェックするのはパフォーマンス上好ましくないので、メモリよりパフォーマンスを重視することにしたわけです。(ちなみに、メモリ使用量を計算したら20MB程度でした)

25万件のノード&エッジデータをメモリに展開すると、起動が数秒遅くなりました。インスタンスの作成に時間かかるようです。起動数秒なら許容範囲内ですが、ゲーム中の速度はどうでしょうか?



◎移動経路の記憶

経路を毎フレーム探索すると負荷が高すぎるので、部隊毎に移動経路を記憶して、何か契機が訪れない限り経路に沿って進むこととします。

移動経路は最初List型を使用したのですが、順番を保全する必要があるので配列で組み直しました。



◎製造

一通りコーディングしたのですが、オーバーフローでエラーになったりフリーズしたりでまともに動きません。

目的地を近くとし、移動を1ユニットに限定すると、(向きのアニメが異常ですが)とりあえず別の地点に移動し、停止しました。

向きのアニメは画像番号の問題かもしれないので後で調べるとして、移動経路や移動先がおかしい点が問題です。

・移動先が真上なのに斜めルートを選択することがある
 →斜めのコストが上下左右と等価であるため?
  →コスト計算をint型→float型とし、
   斜めのコストを1.42倍とすべき?
 →結局、道に沿っていただけらしい?

・移動方向がおかしい
 →向きの計算において、XNAは右手座標系であるため
  Z座標を反転する必要がある
 →Z座標を反転する(-1を掛ける)ことにより解決

・川を越えるケースがある?
 →セル(マス目)の左上端に沿って移動するので、
  見た目がズレているだけ?
  →ズレに関しては座標を補正すれば問題無い



◎ルートの視覚表示

ルートを視覚的に表示して、ルートに問題が無いか一目で確認できるようにしましょう。

エースター法による移動経路実装01

赤矢印はエースターが導き出した経路です。曹仁部隊は経路に沿って川を迂回し目的地に到達します。^^


エースター法による移動経路実装02

移動部隊を複数に増やすと、経路はそれぞれきちんと作成されました。しかし曹仁以外の部隊は移動しません(泣)



◎今後の課題

・曹仁以外の部隊が動かない
 →座標の更新処理は行われている
  (どこかで元に戻っている?)

・経路探索処理が非常に重い
 →部隊数が多く遠距離になるとさらに長くなる
 →処理中は画面が更新されずフリーズ状態となる
 →目的地までのルートは記憶しているので、一度動き出すと負荷はかからない

他の部隊が動かない問題に関しては、近日中に解決できる自信があります。しかし処理が重い問題は、結構ヘビーかもしれません。うむむ…。



◎次回予告

今月も半分過ぎてしまいましたが(汗)、まだ先月の総括をしてなかったので、次回は「5月の反省と6月の目標」です(しばらく休んだ理由も記述します)。

テーマ : ゲーム製作 関連 - ジャンル : ゲーム

| BLOG TOP |

copyright © ゲーム制作の舞台裏 all rights reserved.Powered by FC2ブログ
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。