誤差も積もればバグとなる

整数以外の演算は誤差が出るんだよな。
計算は一箇所にして、参照させないとダメだな。
たまに弾が巻き戻ったり残像拳発動したりします。
(´・ω・｀)はあまじはあ

半透明なテキストエディタ

製作とはあんまり関係無い話。
UNIXとかそうゆう文化に全く触れてこなかったのでEmacsとかvimとか扱ったことがない。しかし、半透明なテキストエディタでコーディングしてる人の画像をみて、あぁなんてクールなんだろう自分も使ってみたいなぁと思い、反射的にWindows 7 64bit環境へNTEmacsさんをインスコさせて頂いて、.emacsファイルとやらとせっせと弄って、起動して、いざ見てみるとやっぱり透明なウィンドウ格好いいなぁ、と。たぶんこれは便利だなぁと。世の中にはこんな素晴らしいものを作ってくれる人がいるんだなぁと感じた次第であります。

Coooooooooool!!!

でも、Emacsの操作体系覚えるのメンドクサイです。
いや、覚えたら早くなるのかもしれないけど、Windowsしか使ったこと無くてVC++でマウス使いーのインテリセンス頼りーのってGUIに慣れきった状態だと、果たしてキーボードでガシガシ書いていくのが本当に効率的なのかどうか良く分からないのです。そうゆうシーンはなかなか様になってると、かっこいいのはそうなんですが。

ただ、HHK(Lite2)使ってるのにこのままってのも邪道だよなーと勝手に胸を痛めていたり。

しかし、別に悪いってわけでなくて、むしろこれが良くて、キーボード右部分が無くてコンパクトだし、カーソルキーとPgUp,PgDown,Home,Endが右下に集まってるからマウスと連携しやすかったりするわけです。これはこれで動線短くて素敵だと思うのですがどうでしょうか。

postしてないけど進んでないわけではない

…という弁明。

成長のスピードが急だと今日の自分から見て昨日の自分が拙く見える。
振り返って修正してばかりいると一向に前に進まない。

細かい進展は明日書く。
本当は弾撃つぐらいまではやりたかったけどなぁ。

作ったこと
・dxlibの入力関係のラッパ、及びキーコンフィグ
・キャラクターのwasd移動（実装の詳細は超適当
・それにあわせた画面の移動と描画
・画面の拡大縮小

キーコンフィグにかなり自由度加えたらものすごく時間かかった。
でも、最近のゲームってこの辺充実しているし、便利だから真似たかった。
一度作ったら再利用できるしね。

車輪の再発明～衝突判定編～

色んな形同士で衝突判定する部分を書いた。
正しくは書いている途中。
絶対どこかにあって誰か書いてるよなこれ（笑）。
強いて言えば小数部分も保有しつつ、衝突・包含は整数型でしか判定しないのが特徴？
普通は小数部分に適当な閾値を決めてやるのだろうけど。
めんどくさかったので、また必要になったら考える。

点と線分とベクトルと三角形と矩形と円とそれらの組み合わせの図形についてそれぞれclass化した。
それぞれの包含と衝突の操作書いたら再利用できる部分は多いものの結構な分量に。
一度書いてしまえば楽だと思うのでさくっと書いてしまおう。

重すぎて動かない

関数オブジェクトが良く分からない。

std::for_each(hoge.begin(), hoge.end(), piyo());

だと、piyo()が関数オブジェクトである必要があるのは分かった。
でもclass A内のB関数の中で、同class内のC関数を入れたいときどうするのだろう。
適切な関数アダプタがわからないし、そもそも用途が正しいのかも分からない。
結局全部while文です。まぁ、困っては無いのだけど。

auto it = hoge.begin();
while (it != hoge.end()) {
  piyo(*it);
  ++it;
}

とある開発画面。

(　ﾟдﾟ) 606666msだと…。


1FPS分の処理に600秒かかっているという壮絶な糞ゲー。
全く最適化せずに2万キャラクター操作したらこうなるよっていう話です。
とりあえず今は1000分の1くらいにはなってます。それでも遅すぎですね。
画面外の処理をもっと手抜きしないとゲームにならんなこれ。

製作どころじゃない

別に知らなくても作れるんだろうけど、これを期に勉強したいことが多すぎて進んで無い。
C++はこれほどまでに宝の山だったのか状態。

あと、話題のUnityはC++使うのに12万5千円かかるそうで。
無料版はJavascriptとC#のみ。
ビジュアルをどのレベルでどう実現するかは未定なので、まだ関わらないでおこう。
とりあえず基本的な部分を作るまではDxLibを利用させていただく予定。

偉い人達の技術を盗みに

C++0xもといC++11とそのライブラリで使えそうなものを探した。
全くノータッチだった。知らない間に世界は進んでいるのか。
色々変わっていて、まだ分からないけど、おそらくとても便利で強力になっているだろう。
使い易く標準化されたものは積極的に取り入れていこう。

週末はお勉強だけで終わるかもしれない。

頭の容量が足りない

実のところ前回に引き続き四分木で立ち止まっている。ほとんどIKDさんのとても素晴らしいsampleをコピペしてオレオレ規約に簡単に書き直して使おうとはしているのだけど、いくつかの不安要素が解消されない。動くには動くんだけど細かい流れが一度に追えないので怖い。頭のメモリが不足しているのだろうか。練度が足りなくて圧縮技術が無いとも言えるな。

【不安な点】
・生のポインタを使っている
・自作スマートポインタと自作リスト（コンテナ）を使っている
・多分後から読んでもすぐには理解できない

汎用性が高くて高速なのかもしれないけど。結局４分木空間分割自体が、そうゆうもの（自作コンテナ？）を作ることなんだろうけど、実行速度を見ながら部品をSTLで置き換えて書き直そうと思う。

…ということを考えただけで終わった。

それにしても「ゲームつくろー！」は大変参考になります。

学が無い私でも非常に分かりやすく、かつゲーム製作のクリティカルな部分が書いてあります。多謝。

2Dなので四分木で最適化した

元はと言えばWUXGA解像度の画面全てを使って、1pixelにつき1characterで描画するというあまりに無知で無謀な計画が最初だった。本当に何も知らなかった。全characterが毎Frame移動して衝突して、というひたすらrichな計画。

とりあえず書いてみたはいいが、全然動かない。1frameの処理に何秒かかっただろうか。適当なcontainerに無理やり詰め込んで、総当りでぶん回した。200万characterの負荷は2011年のPCにはあまりにも重過ぎた。

なので、まずは毎秒30frameは最低でも出せるくらいに頑張る予定。


4分木空間分割を最適化する、をオカズに遊んだ。

骨組みほとんどそのまま移植というか引用した。色々妥協してXGAに落として色々数値弄ってみたけど、1worldで200～300characterぐらいが限界っぽい。それでも弾同士が密集されると描画しなくてもけっこう重い。むしろcharacter数よりも密集度のほうが大事かも。

sampleの数字弄ったもの。この方法だと分散された弾の衝突判定と移動が高速。

とりあえず、algorithmは隔離しといたので、これで困るようになったらまた考えよう。

このblogの方針

詳細な内容はwikiでも作って自分ら向けに書くとして、このblogはその日の進捗状況だけ書いていく。

チラシの裏に書かずに公開するのはmotivationの維持のため。

開発は必要なものから順に実装していく予定なので進捗率とかは無し。

早めに動くα版公開して、feedback貰えるようにしたい。

100人ぐらい集まるといいな。