ゲーム開発

CEDEC2015_1日目その③

消滅都市の運用の一年
受講の動機
とりあえず、毎年「ソシャゲ運営」を志す学生が多いので、現状を知っとこうと受講。
あと、そっち系希望の学生に色々と伝えられたらなぁと、いう感じ。
「長く楽しんでいただく」
あれ?このキーワード…どこかで
ああ、そうだ。運営希望の学生の履歴書だわ。
なんだろ、テンプレでもあるのかな?
逆にいうと、こういうキーワードにうんざりしているかもしれない人事のことを考えると、ちょっとNGなのかもしれない。
とりあえず、開発とカスタマーサービスのお話でした。
まずは技術寄りから
開発環境は
C++&Cocos2d-x3.0RC0(改造済み)
だそうだ。あれれ?そうなんだ。確かに昨年の今頃は3.0RC0だったけど…そっかー。
まぁ、僕自身ソシャゲ運営してないから、運用して以降にエンジンのバージョンあげるリスクについては良くわかりませんから、ノーコメントっすわ。
はい、出ました。キーワード「LWF」
http://albatrus.com/main/cocos2d/6795
これは、cocos2d-x等の上でswfファイルを再生するライブラリのようです。オープンソースなので、そのうち中身を見てみましょう。
昔、僕のいたチームはScaleformGFXってのを使ってたので、それに近いものなのかな?と推測します。
オーディオはCricketAudioを使用。そうね。cocos2d-xのオーディオはしょぼいもんね。
で、それ以外は結構内製ツールを作って使っていたみたい。
ゲームエンジン全盛期にあってもやはり、内製ツールは必要不可欠なようだ。
実はポッ拳もそういう話してたな・・・おっとこれ以上は言えないな。
データはエクセルで作って、そしてJenkins。これもキーワードやね。今までゲーム系には馴染み薄いキーワードだったけど、ソシャゲ系くらいからドゥンドゥン使われるようになってきたね。
サーバ側はお馴染みの
PHP5.4
MySQL
のほか
cascade
silex-MagicSpice
GameLib(内製)
を使用して作られている。
http://www.slideshare.net/greetech/cedec2015-52078074
ていうかここに書いてるじゃねーかちきしょー。
ということで説明はここまでで感想だけ書く。
CSチームと開発チームの溝があって、お互いに「あいつら分かってない」状態になりがち。そこまでじゃなくても、どうしても開発は色々と後回しにしがちだし、CSはさっさやれって思ってる。
そういう部分は、僕が開発してた時代から、現在の講師職に至るまで、何か身につまされるものがあります。
「あいつら分かってない」じゃあ、解決・・・改善しねーんだよね。
というわけで、この会社はドーバー会議ってのを開いて、その溝をできる限りうめていこうと考えた。新人は最初にドーバーに充てられるってのも面白い。
変に凝り固まる前に、CSについて知っておくのはいいことだと思う。
で、この後に、コードからrunActionを変えていくっていうかなり大胆な変更をする決断の話になっていくんだけど、確かにかなり大胆な変更(runActionの仕様変更という)までして、ちょっとここで疑問に思ったのが、そこまでしてるのに何故頑なにRC0なんだろうか…。
色々と既知のバグもあるしさ…それ程までにエンジンのバージョンアップってのはリスクを伴うのだろうか…と最後までもやもやした。
あと、色々と改善があったが、一番効果的だったっポイのはAndroidハードウェアスケーラ。これはほぼノーコストで、画像引き伸ばしが可能ということで、若干のコード改造は必要なものの、それを補って余りある効果があるようだ。
…あれ?でもこれも最近のcocos2d-xだったら入ってなかったっけ?
うーん。もやもやするわー。

| | コメント (0) | トラックバック (0)

CEDEC2015_1日目その②

最初のセッションはWebGL
受講の動機は、WebGLに興味があって、洋書やクロノスのサイトを見てたけど、なんかゲームに繋がるものが思いつかないから。
さて、
講演者のサイト
http://wgld.org/
の紹介があり、いくつかの有名サイトを紹介された。
結論から言うと、思ったより浅かった。残念だが。でも金を払っている以上は元は取らせてもらおうかいと思って貪欲に聞いた。
さらに結論だが、Javascript言語を使用し、3Dをお手軽に(つまりは教育用にぴったり)お勉強しようということだ。
現状だと、まだゲームとして実用レベルじゃないのかな~って感じ。
いくつかのサイトの紹介があったが、ゲームっぽいのはSpaceLamb。
ゲームとしては、正直微妙な感じで、そして重い。
まだまだ…って感じはした。
もうほんと、数年後を見据えた分野だなっていうのが僕個人の結論。割とさっさとGLSLを組める段階までは持ってこれるので、やっぱりお勉強には向いてるかもなぁ。
Webベースなので、もっと技術が実用に向かって来れば色々と化ける可能性はあると思う。
ブラウザを介するので、モバイルとPCの垣根がなくなるかなーって思ったけど、結局ハードウェア×ブラウザの組み合わせで、挙動とパフォーマンスがかなりカオスらしい。
うまくいかないものだね。
メリットとしてはブラウザが対応しさえすれば、UnityWebインストーラみたいな、インストールは不要ってこと。
そこはメリットかなー。
WebGLがネイティブと変わらなくなってきてるーってな話があったけど、自分でいじってみた感想は、まだまだ重いですわ。
俺がJavascript慣れてなくて、非効率なコードになってるんかもしれんけど。
ブラウザ介そうがなんだろうが、3Dをゴリゴリ動かすとバッテリーがゴリゴリ減るらしい。これはもう仕方ないだろう。
実行するたびにリソースDLがかかるが、まぁ…確かに動かすまでがすっげー重たい。
だから、ニコニ立体のようにリソースを見るためだけの手段として使うのは、非常に頭がいい。ベストな利用法だろう。
ここでトレンドのキーワード「Metal」「Vulkan」が出ました。あと、WebAssemblyは勉強不足でよく知らないので、後で調べておく。
さて、未来の話で、WebGL2.0はOpenGLES3.0ベースで、GLSL3.0、とりあえず明示的に3.0使用としない限り、1.0扱いらしい。
で、この世代になるとマルチレンダーターゲットが可能となり、TransformFeedbackを使えるようになるとのこと。
MRTはとりあえず、説明しなくても語感からわかるだろう。
トランスフォームフィードバックは、頂点shaderだのジオメトリshaderだのの結果を頂点バッファオブジェクト(VBO)に反映させるってことやね。
まぁ、ただしジオメトリシェーダは使えないらしいので、(´・ω・`)
さらにVertex Array Object(VAO)が使えるようになるとのこと。
OpenGL系列はこの辺が面倒なので、これができると助かるのだ。クソ重たいのもそれなりに改善されるかも。
その次にポッ拳のセッションに行ったが、写真撮影不可(カメラないので関係ないけど)、SNS投稿不可だった。なんだろう…ポケモン絡んでるから?
とりあえず感想…は、一人のプログラマの力でよくもそこまで…が正直な感想でした。

| | コメント (0) | トラックバック (0)

CEDEC2015の1日目①

貴重な基調講演
「つくる」ということ。
羽織に袴の講演者が出てきた。中村 伊知哉氏というらしい。
色々な経歴があるようで、ゲーム系としてはセガでドリキャスやプーチの開発をしていたらしい。
昨年のウェアラブルの人と同様、結構ぶっ飛んでる。
CEDECの基調講演は最近、こういうノリ多いな。
キーワードは、「技術と文化」「DigitalとPop」
しかし絵がうまいなこの人。
初音ミクの模写もうまかったし…頭良くて絵もうまいとかずるいよなー。とか思ったりした。
そういえばRefeia氏とかも工学博士だったり…んもうずるい。
9.11のときにアメリカにいたり、3.11ではすぐに現地にすっ飛んで行ったりと、
すごい経験をしつつ、「9.11では、お茶の間でリアルタイムでTVで飛行機が突っ込むところを見ていた日本人のほうがヴィジュアル的なリアリティがあった」みたいな視点はなかなか思いつくものじゃない。
3.11の話では「匂い」や「車両に書かれたバッテン」の話をしてくれた。匂いってのは様々な匂いの入り混じった…経験のないにおい…実際には死臭ということなのだろうけど、そこははっきりと述べられなかったのでどうか分からない。
ちなみに車両にバッテンが書かれていると、中に遺体があるということらしい。妙なリアリティを感じた。
じゃあリアリティが大事って話かというと、そうじゃない。むしろもっとデジタルの可能性の話だ。
とりあえず現代のキーワードはNet-Cloud、Service-Social、Device-Multiscreen。
だがここから超えて→Beyond Smart
Wearable&IoT&AI
次の段階に入りつつあるということ。
47%の職業が機械に取って代わられる…来ましたね、最近よく聞くキーワード。
クリエイティブな部分ですら機械が担当…
じゃあ、どうなるのかというと、スポーツ!!
ここで面白い話が…「義手、義足の人のほうがパフォーマンスが高い」
http://logmi.jp/15032
とのこと。中村氏はサイボーグ004の話をしていたが、僕はエドワードエルリックや、銀河鉄道999とか考えてました。
で、結論として、中村氏は「超人スポーツ」を提案していた。「超人!!」ときました。キン肉マンですよ。人間が機械の力でそこまでなれる日が来つつあるってことですね。
僕は荒唐無稽とか思ってなくて、なぜなら、CEDECの講演者のぶっ飛んだ構想ってのは、結構現実化しているからである。
日本はデジタル後進国らしい。
MITの100$PCは中村氏ほか日本人の発案とのことで、MITはすぐに実用にとりかかり、日本の文科省は門前払いしたそうだ。
ま、お役所だからね。
ちなみに100ドルPCってのはこれね。https://ja.wikipedia.org/wiki/OLPC_XO-1
昔、なんかの本で読んだよ。これ。10年くらい前の話なんやね。
そしてここhttps://ja.wikipedia.org/wiki/OLPC#.E5.8F.82.E5.8A.A0.E5.9B.BD
なるほど、日本がこういった面で遅れている(技術的な話ではなく、意識的な話で)のは確かにそうなのだろう。
じゃあ日本はだめか?って話ではなく、日本すげえよって話で、日本人はすげえクリエイティブなんだぜって話。
面白いのは、海外からのクリエイティブ評価は高いのに、日本人自身のクリエイティブ評価が低いってのはなんなんだろうね。昔アメリカ様からさんざん「コピーキャット」って言われたトラウマでもあるんですかね。
子供にPC持たせてプログラム教育しちゃおうぜぇ。さいこーにクールだろ?誰かも言ってたな、これ。楽天の社長だっけ?
さて、面白い話はつづく。
外国人が日本の文化で持ち帰りたいもの。
マッサージチェア(機能的にもデザイン的にもサイコーにクール)
給食当番(海外はそんなのないんだって、日本だけなんだって、おもてなしの精神がそれで育ってる?)
交番(海外のポリスは取り締まるもの。女子供に道案内なんかしません。らしい)
老舗(100年単位で続いている企業なんかそうそうない)
自由(まぁ、海外は意外と自由じゃないよね。アメリカ映画とか見てるとそう思う。イギリスとか日本人が耐えられないレベルで不自由だと思うわ。)
日本人は表現したガリです。お母さんのお弁当をみてもわかるでしょう。
・・確かに、お母さんすごい。
昔NZにいたときに、ホームステイ先のカーチャンが弁当くれたのだが、まぁ、オレンジとパンとコーラが入ったタッパーやった。
日本人的にいうとまぁ、BENTOじゃないわな。
あとは中村氏の構想を話していた。特区を作って、いろいろやりたいという話。2019年にできるという話
http://agora-web.jp/archives/1603380.html
なので、あと4年後が楽しみである。
動くガンダム・・・見てぇなぁ

| | コメント (0) | トラックバック (0)

inside cocos2d-x

cocos2d-xのSpriteBatchNodeはキャッシュではない。

じゃなくて、なんかー、学生さんとかがー、cocos2d-xにおけるSpriteBatchNodeのー質問とかー、してくるんですけどー、なんかー、認識間違えているっぽいんでー、書きますー。

まず一つ目の勘違いですが、例えば

auto sprite = Sprite::create(ファイル名);
なんかでスプライトオブジェクトを作りますよね?これが基本ですね。実にわかりやすい。で、例えば同じファイルを読み込みたいとした場合。

Sprite::create(ファイル名);

のたびにロードが走っていると思っている人も多いようで。例えばブロック画像とかをタイル状に表示したいとする。
■■■■■
■■■■■
■■■■■

こういう感じね。並べるだけなのに、この例だと3*5のロードが走ることになると思うだろう。しかし、安心するがいい。cocos2d-xは優秀である。ひとまずCCSprite.cppの
Sprite* Sprite::create(const std::string& filename)関数を見てくれ、こいつをどう思う?

とりあえずinitWithFileって関数が呼ばれてるよね?その中では

Texture2D * TextureCache::addImage(const std::string &path)

という関数が呼ばれている。中を見ればある程度STLの知識がある人なら何をやっているかわかるだろう?とりあえず丸コピするけど

    auto it = _textures.find(fullpath);
    if( it != _textures.end() )
        texture = it->second;
    if (! texture)
    {
        // all images are handled by UIImage except PVR extension that is handled by our own handler
        do
        {
            image = new Image();
            CC_BREAK_IF(nullptr == image);
            bool bRet = image->initWithImageFile(fullpath);
            CC_BREAK_IF(!bRet);
            texture = new Texture2D();
            if( texture && texture->initWithImage(image) )
            {
#if CC_ENABLE_CACHE_TEXTURE_DATA
                // cache the texture file name
                VolatileTextureMgr::addImageTexture(texture, fullpath);
#endif
                // texture already retained, no need to re-retain it
                _textures.insert( std::make_pair(fullpath, texture) );
            }
            else
            {
                CCLOG("cocos2d: Couldn't create texture for file:%s in TextureCache", path.c_str());
            }
        } while (0);


    }


とりあえず何をやっているのかというと、

①ファイル名をキーとした連想配列(unordered_map)に、今回のファイル名があるのかを問い合わせる
②ファイル名をキーとするレコードが存在するのならば、そのレコードのデータ部分(second)をTexture2Dとして返す
③ファイル名をキーとするレコードが存在しないのならばイメージデータ(画像データ)としてファイルを読み込み、その結果をTexture2Dとして連想配列に登録しそれを返す。

…分かりづらい説明かもしれないけど、大雑把に言うとファイル名とメモリ上の画像データ本体の対応表を作っておいて「既に同じファイル名が読み込まれてたら対応表から画像データを返し、そうでないならロードが発生する」というわけ。

つまり、同じ画像を並べたりする場合には特に何も工夫しなくとも無駄なロード(同じファイルを何度もロードする等)は行われない。というわけ。偉いねぇ~。


さて、本題に入りたいんだけど、どうもSpriteBatchNodeの役割を「事前ロード」だと思っている人(学生さん)が結構多いようです…それは違います。事前ロードしたいなら連想配列に乗っける部分だけでいいので

Director::getInstance()->getTextureCache()->addImage(filename);

だけで十分なはずです。これでこれ以降のfilenameの読み込みにロードが発生することはないでしょう。じゃあSpriteBatchNodeってなんなのかというと、OpenGLのいわゆるバッチ処理を実現するためのものです。

Sceneに紐付いている通常のSpriteであれば、それぞれのスプライトに対してドローコールが行われるドローコールってのは読んで字のごとく、描画のための処理なんだけど、glDrawなんちゃら~ってな関数の呼び出しなんだ。

コイツは現在メモリ(もしくはVRAM?よくわからんけど)にある頂点情報とかそういうのを元にポリゴンを描画するものなのね。

えっ?スプライトじゃねーの?って思うのかもしれないけれどもcocos2d-xはOpenGLで動いていて、四角いポリゴンにロードした絵を貼り付けてレンダリングすることによって2Dの画像を見せているわけ。だからポリゴンの描画処理は必要なのよ。

で、このドローコールは一回の呼び出しがそれなりのコストがかかっちゃうので、同じような(同じ画像の)スプライト一個一個に対して呼び出しをかけると、非常に非効率なのである。だから、複数のポリゴン情報(頂点座標とかUV座標とか)を溜めて溜めて、まとめて処理することで、描画処理を軽くしようっていう…大雑把に書いたけどそういうことよ。
(大雑把すぎて若干不正確だけど、そういうイメージ持っといて)

で、前述したけど通常のSpriteの描画の場合はそれ一個に対して一個のDrawCallが対応しちゃうので、それまとめられねーかなーで考えだされたのが、SpriteBatchNodeだ。

通常、SpriteなどのNodeから継承されたクラスは、シーンの描画時トラバースで一個一個実行されてしまうので、対象となるSpriteオブジェクトをSpriteBatchNodeの子に入れることによって「こいつはバッチ処理するんだぜ」っていう扱いになる。
(※なお、cocos2d-x ver 3.○○からは、オートバッチとやらが実装されているので、ユーザーはこういう煩わしいことまで考えなくてもいいのかもしれない)

というわけで以下の様なコードは間違いである。

auto batch = SpriteBatchNode::create("画像ファイル.png");
this->addChild(batch);
 
for (int i= 0; i < 10000; i++) {
 
   auto sprite = Sprite::createWithTexture(batch->getTexture());
   sprite->setPosition(i*100,100);
   addChild(sprite);
}

…残念ながら間違いです。完全にキャッシュとバッチを勘違いしてます。
あまりこういうことは言いたくないんだけど、上のコードはちょっと改変しているけど某cocos2d-x入門者サイトに書いてあったコードなのよね…で、学生さんとかが鵜呑みにして間違ったコード書いて…。正直、その某サイトの人に連絡とって書き直しを要求したいんですが、連絡先とか書いてないし…。

最初、タイピングミスかなーとか思ってたんだけど「解説」として

「CCSpriteBatchNodeクラスを使って、前もっと画像データを読み込みます。
これを行うことで、今後同じ画像データが呼ばれた時のメモリーの負担が少なくなります。」

って書いてるし、

「実際に画像を表示する際に、CCSpriteBatchNodeクラスから画像を利用します。」

って書いてるので、うーん、残念ながらちょっと間違って解釈している可能性が高いと思います。
あまり「名指しで批判」とかはしたくないほうなので、そのURLはここでは書きませんが、そこの管理者さんがもしここを見ることがあれば修正していただきたいとは思っています。
結構入門用としては人気がある…というかほぼ必ずトップに来るサイトなので、マジお願いします。

| | コメント (0) | トラックバック (0)

お仕事と関係ないゲームプログラミング(多角形切断)②

とりあえずさきほどUVバグが治ったので、とりあえずはリリースまであと少しってところかな…あとは絵を用意しなければなぁ…

さすがに正常に切断し始めると、そに子の絵を使うのは憚られたので昔描いた絵を切断したスクショを載せとく。

Blade

エッジ部分がちょっと汚くて、原因もわかっているのだが、こういうこまけえ事は置いておいてさっさとリリースに向けて準備する。

そもそも後ろが葛城さんであるため、これもオリジナルにしないとならない。とりあえず思いつかないので昔描いたこの辺を全身描いて清書すっか…とか思ってる。

Chuka

…脚とか足元描くのは苦手だからなあ。こういうバストアップ絵でごまかしてた自分が憎い。

ということでリハビリもこめて「新・絵心教室」を買ってしまった!!


あ…いや、こんなん買ったって絵がうまくなるとか思ってないですよ。ともかく絵を描く「理由」が久しぶりにできたので、しばらくは頑張ると思います。

えー、早くも話が逸れてってますけれども今日は切断辺から新しいポリゴンを作る話。

図を見てくれ…こいつをどう思う?

Kaisetu

すごく…切断です。
ともかく、0,1,2,3→0,1,C_0,C_1 & C_0,2,3,C_1になるわけだ。

手っ取り早く考えるために切った瞬間に0,1,2,3を捨て、新たに0,1,C_0,C_1 & C_0,2,3,C_1とすると考える。

言うは易し、実装するは結構ややこしい…と思ってウンウン唸って、ピキィッ…!!と思いついた。

Denryu_2

まさにこれっ…!この状態っ…!圧倒的閃きっ…!!悪魔的…悪魔的閃きっ…!

図をよく見てみよう。新たに生成される多角形の一辺は確実に「切断辺」である。当たり前だ。

ということは…だ、新しい多角形は、切断ポイントを多角形の開始点(インデクス=0)と終了点(インデクス=頂点数-1)とすることができる。

あとは最初から用意している順序でならべればいい。つまり上の例だと0,1を挟むようにC_0とC_1を設定し、もう一方は2,3を挟むようにC_0とC_1を設定すればいい。

と、言葉でいうと簡単なんだが、C_0とC_1の順序を間違えると簡単にねじれてしまう。これすらも解決する方法を次回書くことにする。

ちなみに今回はcocos2d-xを使ってプログラミングしている。いずれ近いうちにAndroidのGooglePlayでリリースしたいからだ。

一応、cocos2d-xのさわりを知るために結構役に立ったのと、なにより表紙の女の子がかわいいので、それだけでも価値ある一冊だと思います。


| | コメント (0) | トラックバック (0)

お仕事と関係ないゲームプログラミング(多角形切断)①

久々に純粋なゲームプログラミング熱が燃えておるのでメモっとくー。

もう少しで完成ではあるんだけど、現状ではBladeMasterというAndroidアプリのパクリ状態である。

要は凸包多角形を切断し、切断後に新たな多角形を二つずつ生み出すというものだ。

いいのだ。パクリとかそういうことは問題ではない。このアプリを同僚から見せてもらった時に「ぜひ作ってみたい!!」という、そういう情熱に駆られてしまった。

http://www.youtube.com/watch?v=q0SSwZ9qRJo


数学、物理的に作るのが面白そうと感じたからだ。プログラマには自己顕示欲みたいのがあって、やっぱり周囲に「ドヤァ…」って言いたいのね。ま、他人がすでにやってることなので、今回のは言ってみればギタリスト初心者が誰かの曲を耳コピして、ちょっとオリジナリティ加えて周囲にドヤァ…って感じですわ。

途中経過

Setudan

そに子ちゃんごめんなさいヾ(;´Д`A
手元に適当な画像がなかったのでつい…

お詫びにこれ買ったので許してそに子ちゃん



証拠写真

Ds

…えっと、今回のテーマってなんだっけ?

さて、このゲームを作るときに数学的に難儀しそうだと思ったのが

  • 切断辺の計算
  • 中心(重心)の計算

難儀というほどでもなかったんだけど、これ学生とかも読んでると思うので、まず切断辺の作り方を書いておく。

切断辺を作るには切断点が二つ必要。切断点は外積を用いることにより算出できる。「線分と線分の交点」を計算すればいいだけなので、例えば線分ABと線分CDの交点ならば


crosspoint = B+CD*(|AB×AC|/(|AB×AC|+|AB×AD|))


こんな感じで切断点は作れた。これを各辺チェックし、切断点と切断点を結ぶことによって切断辺を作ることができる。

ここでプログラム的(幾何学的)な問題に直面、最初の多角形は各頂点に0,1,2,3などという順序がついている。

ここをうまいことやっとかないと「ねじれ」が発生して、新たな多角形を正しく生成することができない。

ちょっと今は時間ないので、ここについては次回書くことにしよう。なお、外積から交点を計算するとかいうのは俺オリジナルで高校の教科書になんか載ってない。「ゲームプログラミング本」とかも読んでみたけど見つけきれてない(たくさんは読んでないのでどっかにあるのかも)

というか今の職で学生に教えているほとんどが俺アルゴリズム過ぎるので「正解」には程遠いのだろうけれども少なくとも今までも数学的力技(すうがくてき)でなんとかかんとか「問題を解決」してきた。

が、本も読んだりして裏を取るべきなのかもしれない




分厚いのと難しいのとで読めてませんね、これ。

…もし頭のいい人がこれ読んでたら「正しく」て「効率の良い」アルゴリズムを教えてください。おながいします。

| | コメント (0) | トラックバック (0)

DirectX11参考書籍

もうDirectX12も出ようというのに、DirectX11の書籍やサイトは9のころに比べるとずっと少ない気がする。

もちろん、代表的なサイトはDirectX11をやってはいる。

ゲームつくろーの人もDirectX10の時点で飽きちゃったみたいだけどね。
http://marupeke296.com/DX10_main.html

あとは入門的なところだとNanashi-soft
http://yun.cup.com/directx11.html

かなぁ…でもDX9のときみたいなガチ入門からシェーダバリバリまで体系的にってなサイトはもうかなり少ない気がする…ていうか見つけきれていない。

まぁ、DX11はちょいとハードルが高いんでDX11使うレベルならリファレンス見とけって感じなんだろうね。正直、慣れてくるとMSのチュートリアルとリファレンスで事足りることは事足りるんだけどさ。

ということで、一応体系的に解説してくれているのが、鎌田 茂雄氏であろうとは思う。

DirectX10/11を扱うなら、


これかな…と。グラフィックの話だけでなく、フォント(DirectWrite)やらサウンド(DirectSound)の話まで入っているため、ゲームに必要な一通りの機能を網羅したい時にはいいだろう。

さらに、色々とシェーダいじりして、オモチロイ表現をやりまクリスチーネ剛田な人はShader Guruがお勧めだが、これちょっと高い。大人なので買ってるけど、

これはマジで高い。でも初歩のポリゴン表示から、3DCGの基礎的な話、シャドウの表現、SSS(サブサーフェススキャッタリング)の簡易表現、最後にGPUレイトレーシングの話など、盛りだくさんではある。盛りだくさんなんだけど…この値段はっ…!

ちなみにもうひとつMESH GURU ってのもあるんだけど。これはメッシュの基礎知っている人には不必要だとは思う。だけど…まぁ、FBXの話も載っているし、スキニングの説明がわかりやすかったりする。するんだけども…まぁこれは必要ないかな。

| | コメント (0) | トラックバック (0)

接線ベクトルと従法線ベクトル

法線マッピング実装しようとしてるんだけど、なんかうまくいかない。まぁ、ずーっと2D格ゲープログラマだったから仕方ないね。

Rokdebone2にて法線マップ設定してXファイル出力したのだが、Xファイルの中に法線マップ情報がない。「どのファイルを指定したか」すらない。
Xファイルの野郎、アンビエントすら設定できないと思ったらこんなヤツだったのか。よくもこんなキチガイフォーマットを!
今度という今度は許さないぞ!
とりあえず、致し方ないためテクスチャ名に"_bump.dds"というファイル名を探し、あればバンプ用のシェーダに、なければ通常のシェーダに投げるってことにしようと思う。
割と困るのは、全然テクスチャがない場合、シェーダ側からの確認の方法がわからないってこと。これもアプリ側からの切り替えでどうにかするか…
さて、そういうわけで気合を入れてノーマルマッピングしてみたわけなのだが、どうも職場ではうまく表示されない。ほぼ同じシェーダで「RenderMonkey」では正しく表示されているというのに…どういうことなの?
やっぱりシェーダコード理解しないとダメか。めんどくせえ…
なるほど、頂点シェーダの中にTANGENTとBINORMALってのがあるね。これ、なんだ?少なくとも全然設定してないから、これが原因なんだろう…。
どうも、tangentは接戦って意味だから、このtangentってのは接線ベクトルを表しているようだ。
ではbinormalってなんだ?従法線?従法線ベクトル?なんぞそれ…
すんませんわかりません。だいたいわかるけど、ああ、わかったわー。
ますますわからなくなった・・・OTL
んー、要は、法線があって、そいつに直交する2つのベクトル(そいつらはまた直交している)ってことやね?で、そんなもんなんで必要なん?
これの21ページ目くらいから、わかりやすく書いてるね。(・∀・)イイネ!!
おそらくこの資料の「接空間」ってやつは、対象の面(法線ベクトルの元になってる面ね)から見た空間ってことね。つまり、XYZで表すと法線がZで、あとどっちかわからんけど、Xが接線(TANGENT)でYが従法線(BINORMAL)ってことかな?
おー、そうすると面を構成する頂点における法線ベクトルとそれに接する辺のベクトルとの外積で、まぁ、接線ベクトルだか従法線ベクトルだかがわかるわけだ!
…もう数学やん、これ。
…ちょっとまて、ちょ、おま、こんなもん自分で、全ての頂点について計算せぇへんとあかんのか?
ウボァーめんどくせー
ppAdjacency とか引っ張ってきて計算すんの?マジで?
たかがノーマルマッピングで、いや、ノーマルマッピングって、そんなに?・・・そんなに?

なんか関数ねーのかよー!時間ねぇー!!

みつけました

引数多くて面倒だね、でも仕方ないね。

ここまでやってやっとまともに表示することが出来ました。くっそー、めんどい

そして今作っているゲームにどうやって組み込もうか


| | コメント (0) | トラックバック (0)

GGJ(Global Game Jam)レポ

ええ、まぁ、私もゲーム開発者の端くれなので、今年もGllobal Game Jamなどという既知街なイベントに参加してきました。実は風邪を引いてしまっておりましてね、辞退しようかとも思ってたんですが…年に一度だし、頭がぐわんぐわんするのを抑えて出席してきました。

昨年が、非常に僕としては悲しい出来だったため、今年は頑張るぞ、事前に武器(汎用的なエフェクトやドット絵、モデル等)も用意して、出てみました。

なるほど、一言で言うと、僕にとってのGGJとは「自分の足りなさを実感するイベント」では無いかなと思います。

前回は事前準備、適応力などが欠けており、今回は色々と考えて用意しておりましたが、残念ながら、今回は別のものが欠けているために、碌でもない結果となってしまいました。

何が欠けていたのかと言うと、プロジェクトマネジメント、リーダーシップなどの能力です。実は他のメンバーは学生しかおらず、ゲーム開発が初めてってのが半分ってな状態でした。

ゲーム作りの基礎から教えてしまう状態になり、どうも学生達がこちらを頼りすぎる状況を生んでしまい、正直、初日は殆どプログラムを組んでおりませんでした。

また、一部のメンバーのモチベーションが低下しているのを放置してしまったために、まぁ、なんだかなーって状態にしてしまいました。

こういう状態になってしまったのは、年長者でありながら、キチンと計画を立てることが出来ず、キチンとプロジェクトを構成できず、キチンと命令できなかった僕に責任があるのですが、まぁ、こっちもガッツリ開発やりたくて参加しているわけで、段々フラストレーションがたまってくるわけですよ。

結局、そこにイラついてしまったので、「楽しめばいい」ということにすら失敗する始末。「エロボロス」とかを見ると、見栄を張らずに、もう少し自分を出して楽しんで滅茶苦茶な企画を出せばよかったのかなと思います。

今回、「ああすればよかったな」と思ったのは、ドット絵がかけない学生にドット絵を強要するのではなく、その素材でどう組み立てていくかを考えればよかった。変な常識にとらわれてしまっていたのかもしれない。

また、こちらで完成部分までの道のりを示してあげればよかったのかなと思います。今までは、周囲が「ゲーム作りたい、自分でアイディアを出したい」人間に囲まれていたため、それが当たり前と思ってたり、そういうのに頼ってた部分があったのかもしれません。

とにかく、教員としても「他人のモチベーションの維持」ってのはテーマになってくるため、このスキルはガチで育てていかないといかんなー、と感じた。

さて、とりあえず、どういう状況だったかを時間を追って思い出してみる。

福岡GGJは他と違い、初日が土曜から始まるために時間がかなり短くなっている。これを見誤ったのは悔やまれるが、とにかく思い出してみる。

はじめに基調講演、なにやら4カ国からゲーム開発者、メディアアーティスト達がアドバイスをくれる。
アメリカンな男女のジョークが微妙に笑えずに・・・なんやワシはアメリカンジョークがわからへんのかー、とか考えて、その後にチーム決め

自分とこの教え子一人確保。
このレベルなら、十分なものを作れそうだと思った。

そして、他のやつらがいるであろうルームへ・・・。どう見ても、全員が学生・・・これは・・・・。
適当なところに陣取り、ブレインストーミング。どうやらブレインストーミングって概念を知らなさそうな感じなので、なんとなくブレストになるように誘導。

誘導しているつもりが、なんか僕が仕切っているみたいになり、デザイナーの一人はこの時点でモチベーションが低下していたっぽい・・・「ヤバイ」とは思うものの、初対面の人間にどうこうできる自信もないため、放置、まぁ色々とアイディアが出てくる。

意外と蛇系のアイディアが目立たない。

結局「四季(死期)」をテーマにしたゲームを作る事になったが、そのチョット前にトラブルが・・・実は僕らが居る場所は日曜日の「こどもGGJ」で使う予定だったようだ・・・マジ?場所提供していただいているので、こう……言い辛いんだけど、そういうのは最初に…ね?

で、移動する事になる。
さっきのモチベーション低いのがさらに低下している。そりゃな、モチベーション低い時は、何かにつけ落ちていくからな…。

3時までにプロジェクト名と概要を出さなければならないが、もうね「サッサ終わろうぜ」ムードが見え隠れ…。

正直、こっちもムカついたんで、蹴飛ばそうかと思ったんだが、まあ、しゃあない。余計な事で時間を使う暇はない。まぁ、そういうのにも配慮し、メシ食い終わってさっさと決める。

プロジェクト名でかなり時間がかかった。内心「プロジェクト名より…仕様」だと思ったが、まぁ、これもジャムっぽくていいのかなと思ったら大間違い…

仕様がろくに決まっていないまま開発スタート。

当然みんなは僕に仕様を聞いてくる。

あのさ、プランナーがいないんだから、それを僕に聞かないでくれ。
プログラムの質問、グラフィックの質問、「これでいいですかー」

そりゃ、僕が怖かったのかも知れん、高圧的に映ったのかも知れん、だが、ちょっと流石にこれはひどいと思った。

そりゃ僕にも色々と落ち度はありますよ。でも僕だって人間ですよ、あっこまで質問されたらイラっとするし、「もうそれは君で決めて」っていいたくなるよ。

そういうことを言うと、「えー、こっちで決めちゃっていいんですかー」

って、いや、僕はリーダーじゃないし。ていうか、プランナーもリーダーも実質不在なんだから、ある程度の部分は自分で決めろよ!
見たいな態度をとると、「無責任」みたいな目で見られるし…マジで、ココ来る前に一回くらいは開発しててくれ…そしたらどういうことかわかるからさ…。

そりゃ、俺は好き勝手言いますよ。ここにきている以上はある程度「出来る」と思ってるもん。ああ、でも違うんだな、自分のモノサシを他人に押し付けちゃいけないんだな…押し付けると、それは、悪い形で帰って来るんだよな…

まー、イライラが実は溜まってたわけで、抑えようとするんですけどね、寝不足になって、意識が朦朧としてくると、アレですよ。
漏れてくるんですよ…色々、フラストレーションが…

それはともかく一睡もしない予定だったが、かなりの時間居眠りこいてたらしい、小一時間以上。
全然気がつかなかった。
しかもイビキかいていたらしい…ああ、そりゃ、風邪で鼻がつまってるからだわ…。

こう言うところや無茶振りをするところをもって、俺が不適切だというのなら、そうなのだろう。年長者である以上はこれを超えなければならないし、指導者としては、これは許されないのだ。

でも、正直言わせてもらうと、この場は別に、学校じゃないんだから、いち開発者なんだから、ブチ切れても良かったのかなと思う。

とはいえ、僕がこのチームに配属されたのは、一応教員であるからして、指導、リーダーシップを発揮する事を期待されていたのだろうと思う。

大口を叩きながら、期待にこたえない男、それが俺。


やはり二日目はかなり能力が低下してしまう辺り、年なんかナーと思いつつ、うまいこと周りをコントロールできなかったことに、自信をなくしてしまった。

このイベントだけでなく、実は1月は自信をなくしまくりなのだ…。

どれくらいなくしているのかというと、ことあるごとに「死にたい」という言葉が僕の脳内でフラッシュバックするほど自信をなくしてしまっている。
これは年度の早い段階でどうにかしないと、本当に自殺しかねない…




| | コメント (0) | トラックバック (0)

GlobalGameJam

GlobalGameJamというイベントに参加してきました。
これは48時間でゲームを一本開発すると言う鬼のようなイベントです。
こんなイベントに誰が参加すんのさ…とか思ったら意外と多く、福岡では学生さんが多かったけど、企業の人も参加してました。
とくにGFFに加盟しているような企業は、率先して開発者が参加しているようで、福岡のゲーム会社のエネルギーを感じた。

しかし、福岡の、とはいえ、長く大阪にいたので、有名どころしか知らず、結構知らない会社の人とか多かった。

さらに、わざわざ大阪から参加しておられる人も居て、「大阪でもやればいいのに」とか話してました。頑張れよ大阪!

まぁ、こういうイベントに無料で参加できるだけでもありがたいことで、ホントいい時期に福岡に帰ってきたよなって思いましたね。

さて、スケジュールですが、もじぴったんのプロデューサーの方の講演のあと、開会式、そしてチーム決め、テーマ発表。

今回は、Extinction(消灯、消滅、絶滅)。でした。まずはブレーンストーミングでしたが、学生だからもっと突飛なモンが出てくると思ったんだが…むしろオッサンの俺の方が突飛過ぎた。

とはいえ、あまり現場が長い人間が多いチームは、それはそれでよくないなと思った。なぜかというと、冒険しない方向に、つまりスケジューリングを考慮に入れすぎるのだ…完成できなくてもいいじゃないとは思わない。

とか言いつつ、それほどぶっ飛んでもなく、完成度も低いという最終結果に納得行っていない。

とはいえ、これは半分くらいは俺のせいなのだ。ノートパソコンがMacbookAirだったので、プログラマとして、他人との連携がしにくく、余計な作業が発生したり、現場の人間なのに、他のプログラマに適切な指示を出せなかったからだ。確かに、指示を出すとかの経験は乏しいからな。

いい経験だったと思う。

でもマジで心残りが多すぎるので、来年はもっと頑張ろうと思う。頑張ろうってのは、眠らないわけじゃなくて、事前準備をモットしっかりしておこうと言うこと。周囲の状況をまとめていけるように心の準備も必要だね。

金払ったって、こういう経験はそうそうできるものではないよ。

「金にならない」とか、くっだらない理由で参加しないとか、怠惰以外の何者でもないだろう。参加しようぜ!!

| | コメント (0) | トラックバック (0)

より以前の記事一覧