スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

"DXライブラリ"を作ってしまえば良い!

ゲーム業界に何らかの作品を提出する場合、
DXライブラリは使わない方が良いと言われました。

まぁ、裏で行われている面倒な事は見事に隠蔽しているので、
リソース管理などのプログラムの設計とか、そういうものが評価しようがないんでしょうね。


しかし、何かゲームを作るのであればDXライブラリがあると非常に便利です。
で、出した結論。

自分でライブラリを作ってしまえば良い。
(というか、何で今まで作らなかったんだろう)

自分で処理の流れを理解して、それを隠蔽する訳だから、
マイナス評価にはなるまい。 多分。

という訳で、今、DXライブラリみたいなものを作ってます。
スキンメッシュアニメーションの実行も、ライブラリの機能の1つになるでしょう。

とりあえず、画像を読み込んで表示する、とても便利な関数を作りました。
まぁ、関数内部で
------------------------------------------
【1】画像の読み込み
【2】画像の横幅・縦幅取得
【3】画像と同じ大きさの板ポリゴン(RHW)を生成
【4】テクスチャをセットした後 板ポリゴンを描画

------------------------------------------
これらをやってるだけなんですけど。

※【1】~【3】は、LoadGraph関数がやる
 【4】は、DrawGraph関数がやる


ともかく、どんどんゲームを制作しやすい環境を整えていこうかな、と。


~おまけ~
また自作曲を作りました。

今回は・・・なんか変な曲です。
一言で言うならば”奇妙”。

そして、毎回 未完成の曲ばかりでしたが、
今回は一応完成してます。

後半の方から曲の展開をどうしようか分からなくなったので、
とりあえず 打楽器を無茶苦茶ならして、無理矢理終わらせました。

同じフレーズが2回繰り返す所がありますが、
最後の方は違うフレーズになるので、どうぞ最後まで聴いてみて下さい。

【自作曲6】StrangeCave.mid
スポンサーサイト

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

コメント

なかなか難しいところではありますが

 あくまで個人的な意見になりますが。

>ゲーム業界に~DXライブラリは使わない方が良いと言われました。
 応募先の会社によりけりだとは思いますが、どっちかと言われればそうかもしれません。
 
 実際問題 PCのゲームしか作っていない会社に出すのであれば間違いなく DirectXの方がいいと言えるでしょうし、仮に二人の応募者が同じレベルのプログラム・作品を提出して片方がDirectXもう片方がDXライブラリだとしたら確かに DirectXの方を採用してしまうかもしれません。
 
 けど、結局のところ提出物のアピールポイントをどこに持ってくるか、そして(スケジュール的な)コストをそこにかけられるか、次第じゃないでしょうか。
 そして、DXライブラリを使った場合でもそこはやりかた次第で十分カバーできるかと思います。
 
 例えばDXライブラリにはない C++のクラスを使った上位のシステム……テクスチャ・モデル・モーション・サウンドなどのリソース管理、データキャッシュ、非同期のリソースのロード(多重リクエスト)、メモリ管理(リーク検出も)、シーケンス管理、タスク、シェーダ、描画システム(透明オブジェクト、レイヤーなど)、コリジョン、エフェクト、BGM、3Dサウンド、スレッドなど、ゲームの底辺を支える仕組みをシステム化しそれを効率良く効果的に運用しているコード(設計に関するドキュメント付き)だとか、プログラム的に特筆するべきもの……たとえば自前で書いた物理エンジンがあるとか、A*を使いこなしているとか……があれば、ただ DirectXを使った凡庸なゲームよりかは評価が高くなる可能性は高いです。
 後者の場合、デバッグモードも公開して内部挙動の一端を見せられるとより効果的かもしれませんね。

 勿論DXライブラリしかやったことがなくて、今時の DirectXや OpenGLなどの 2D/3Dの基本を全く知らないのはマズイとは思いますが、そんな些細な部分を自前で書いているかどうかよりも、きちんと C/C++言語を使えているかどうかや、ゲーム全体の設計をどうしているのか、会社でプログラマとしてやっていけるかどうか(将来性はあるか)の方が重要な気がしますよ。

 あぁ、勿論プログラムが書ける書けない以前に社会人としてどうなのかってところは重要ですけど(w


 ちなみに最近の応募者のレベルがよくわからないので私の勝手な推測ですが、C++のクラスを使ってDXライブラリの1つのテクスチャハンドルを管理(生成と破棄含む)するクラスをきちんと書けるのは応募者の半分もいるかどうか怪しいと思っていますよ。

No title

結局の所、どんなライブラリを使っているかよりも
言語自体を理解して、ちゃんと設計できるか どうかが重要になりそうですね。
DirectXを使っていたとしても、
DXUTやD3DXみたいなヘルパー関数などを使ってばかりのコードだと高い評価は得られないとの事ですし。
(中身を理解せずに、「関数を呼んだら実行できた」みたいな状態ですからね)

しかし、改めて思いましたが、
まだまだやる事はありますね。

描画システムに関しては、Zバッファと半透明のオブジェクトがすこぶる相性が悪いので、描画順を並べ替えて表示するシステムがあった方が良いでしょうね。
描画順を 不透明→半透明 にすればある程度はマシになりますが、
更に
---------------------------------------
【1】視点に近い不透明のモノ
【2】視点から遠い不透明のモノ
【3】視点から遠い半透明のモノ
【4】視点に近い半透明のモノ
---------------------------------------
こんな感じで描画するようにしたい所です。
(コレでも万全ではないですが)

インデックスソートする仕組みも作っておきたいなと思います。
(実体を入れ替えるのではなく、ポインタを入れ替えて描画順を制御。)

あと協調性(周りと連携を取る)みたいなものも当然必要でしょうねv-290
(それを特に重要視している企業とかありますし)


そうですねv-292
自分も推測なのですが、C++をやってたとしてもtemplateや例外処理の所まで理解が及んでいる人は少ないと思います。
(自分もまだまだですが)

「ゲームが好きだから」、「自由な感じがする」みたいな志望動機も聞いたことがありますし、

ゲーム制作は頑張っても、言語への理解やソースコードの再利用性・拡張性まで深く考えてる人は少ないかなと思います。

一度、FizzBuzz問題とか やらせたらどんな結果になるかなとか興味が出てきました。
(企業側で統計とか取ってくれると面白そうなのですが)

No title

>言語自体を理解して、ちゃんと設計できるか どうかが重要になりそうですね
 最終的にははこういっちゃ身も蓋もないんですが、運とかその会社(採用担当官)との相性になります。 
 
 自分の得意とするところ、苦手なところを明確にした上で、アピールするところを前面にプッシュできるものであればそれでいいと私は思います。


>あと協調性(周りと連携を取る)みたいなものも当然必要でしょうね
 大手とかはその傾向はあるみたいですね。細かいことは入ってから研修 / OJTなどで教えればいい、ってかんじで。


>templateや例外処理の所まで理解が及んでいる人は少ない
 本職でも結構使わないですし、使えない人は多いですよ。
 特に windows以外のプラットフォームでは環境的に制限があったり使えないこともありますし。

No title

良い作品を作ったとしても、
最終的にはそれぞれの企業との相性になりそうですね。

ゲーム関連の企業と言っても、
特に映像に力を注いでる所や、
万人が楽しめる作品を目指している所など
色々と方針が違ったりしますからね。
(そういえば、 「作品を作るときは、その企業のゲームの雰囲気に似たようなものを作れ!
みたいなアドバイスをどこかで見たような気がします)


プログラミングでは、
自分の強みや弱点などを把握しておき、
強みの部分を特に強調してアピールすると良さそうですね。
(「まんべんなく平均的に出来る」、よりも
「何か ずば抜けてるものを持ってる」人が良い
みたいな事を仰ってた企業とかありました。)


templateとか例外処理などは,
それほど積極的に利用されてないんですね。
(結構、使われてるみたいなイメージがありました)

まぁ、特定の環境下でしか うまく使えない機能などを入れても
他の環境下では動かなくなりましたみたいな事が起こりうるので、
使わないほうが良いのかもしれないですね。

とりあえず自分はexportを使おうとして、失敗した経験があります。
(自分のコンパイラは対応してなかった)

No title

>それほど積極的に利用されてないんですね
>結構、使われてるみたいなイメージがありました
 このあたりはほんとピンキリです。会社・チーム、担当パートによるってかんじで。
 チーム制作だと練度が一定ではないので、そのあたり次第では制限がかかることもあります。

 使われているところは使われているんですよ。サーバー側だとかツールとか。
 ゲーム本体でも仮想メモリ+メモリが潤沢にあると普通に STL/boostとか templateを多用されることはありますし。


>export
 exportは難しいですねw
 対応コンパイラ少ないですから。

No title

つまりは、場所によりけりということですねv-293

力量に差のある場合のチームでは、
「この機能を使ったコードだと、(他のメンバーから見て)可読性が低くなるから・・・」
みたいな事があったりしそうですね。

exportは難しいです(w
結局、明示的なインスタンス化を全部しておく、というのも面倒くさい ので
クラスの宣言と実装を全部ヘッダファイル内に入れて対応しました。
(それ以外のクラスは、 .hと.cppに分離している)
コメントの投稿
管理者にだけ表示を許可する



上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。