12日目 衝突応答!

12日目!

学生から社会人になってしまいました、12日目です。

今日の目的

衝突時に力を加えることで、現実にはありえないめり込みを解消します。

応答

めり込み状態からの復帰は、めり込んだ量に応じた力を加えることで解決しています。 Penalty-based methodという方法らしいのですが、雰囲気で実装しているので正確性は怪しいです。
今回はトンネリングを考慮しないので、スイープ生成などは行なっていません。 本来なら判定と応答の処理を分けるべきなのですが、判定時に応答に必要な演算を行っています。

github.com

まとめ

ようやく一通りの動作が揃いました。 次からはゲームのロジックをかけそうです。

13日目はステージ作成です。

進捗!

f:id:himatyu:20180405092959g:plain

github.com

11日目 ごーたい

11日目!

終りが見えてきました、11日目です。

今日の目的

衝突応答に必要な「力」を受ける物体挙動を実装しました。

剛体

力の作用の下で変形しない物体のことである。by Wiki先生。
とのことですが、正直いまいちピンときません。
unityやUEなどではRigidbodyとして万能物理シュミレーション機能と提供されていますが、 ここでは「力を受ける物体」という感じのふんわりした定義で実装しました。
本来なら多くの要素が絡み合うものですが、今回は重力・抵抗・加速度・速度・質量のみの要素を使用しています。
なおモーメントは考慮していません。

gist.github.com

まとめ

衝突応答への準備が整いました。
あとはめり込んだ分反発力をかければできるみたいです。
とはいえColldeeとRigitbodyの連携など一筋縄でいかなさそうです。

12日目は「衝突応答」を行う予定です!

進捗!

見栄えしないw f:id:himatyu:20180330075333g:plain

github.com

ねねチャレ 10日目 !! 衝突判定のコンポーネント化

10日目!

少し間が空いてしまいましたが、10日目です。

今日の目的

衝突判定及びアプリケーション周りのリファクタ

衝突判定まわり

今回はColliderとColldeeを用意しました。 unityだとXXXColliderといったコンポーネント自体が判定してる感じの命名です。 ですが判定機能をコンポーネントに持たせないので、 判定を行うColliderとそのパラメータを持つColldeeコンポーネントに分離しました。

ナローフェーズやトンネリング対策も実装する際はCollider側にします。

Application周り

mainスコープのObjectをAPP:Scene:Object:Componentの内包関係に修正しました。 メモリ領域自体はスマートポインタを使用しているので親の生存に依存しません。

まとめ

ようやくリファクタ終わりました。 普段リファクタをしてなかったつけが一気に回ってきた感じですw リファクタは計画的に。

11日目は「衝突応答」を行う予定です!

進捗!

github.com

ねねチャレ 9日目 !! 衝突判定

9日目!

ねねっちのボールプルプル挙動が目標ですが、いきなりには出来ないのでとりあえず 衝突判定からやっていきます。

今日の目的

球と箱の衝突判定の実装。

衝突判定

本来ならナローフェーズなどゴニョゴニョしないと行けないようですが、 最小限構成という事ですっ飛ばします。
直接OBBとSphereの判定を行います。

gist.github.com

OBBとSphereのBoundVolune自体はEntityから生成しています。
姿勢行列などはTransformから更新できるようにしています。

まとめ

衝突系の道程は長いので、まず衝突判定からやっていきました。
応答の前に剛体のステップを踏むのですが、その前にリファクタさせてください・・・。
そろそろMainが大変な事になっています(゚∀゚)

10日目は「衝突判定のコンポーネント化」を行う予定です!

進捗!

f:id:himatyu:20180319032724g:plain

github.com

ねねチャレ 8日目 !! シェーダーでごにょごにょ

8日目!

仮のシェーダ実装しました。

今日の目的

流石に単色描画から脱却したかったので 、ランバートシェーダいれます。

ランバート反射

法線とライトのベクトルを内積して陰影をつける手法です。

gist.github.com

今回は平行光源として演算しています。

まとめ

おそらくNENEの迷宮に使われているランバートを実装しました。
実際は環境光や反射光など考慮すべきなのですが、 そこら編はアプリケーションコードとして後日行います。

9日目は「衝突判定」を行う予定です!

進捗!

f:id:himatyu:20180317063719g:plain github.com

ねねチャレ 7日目 !! コンポーネント化(すいませんリファクタリングですまじスイマセン)

7日目!

二回目のリファクタリングしました!
(ネタがないわけじゃないです・・・工数と予定が合わないのです・・・。)

今日の目的

先日のTransformにコンポーネント指向を取り入れます。

コンポーネント指向

システムを独立した結合の弱い再利用可能なコンポーネント群で構成する。
というのがコンポーネント指向の趣旨のようです。(By wiki)
ゲーム製作に置き換えると、アプリケーション層のオブジェクトに対して エンジン層/アプリケーション層のコンポーネントを付与することでゲームのロジックやビジュアルを組み立てていくといった感じでしょうか。
unityやUe4などのゲームエンジンもこの思考を取り入れていますね。

ならばきっとNENEEngineも取り入れているでしょう。
それでは、最小のコードを見ていきます。

github.com

最小コード(の差分)です。
簡単に紹介していきます。

IBehavior

コンポーネントの基本となるインターフェースです。
検索要素としての実体名と型情報を持っています。
型情報は持たせなくともDynamicCastによるnull比較で代用可能ですが、
私はこちらのほうが好きなので持たせています。

Behavior

コンポーネントを持つクラスです。
Unity(C#)では出来ない可変長テンプレートによる完全コンストラクタなコンポーネントを生成できるのは自分的にポイント高いです。
コンポーネントも親を持つので、更新中に削除されることを考慮して破棄を遅延して行っています。

まとめ

一応、ねねエンジンに実装されているであろう機能は実装する方針なのでコンポーネントを実装してみました。
コンポーネントとして付与できるようになると、圧倒的にゲームエンジン感できますねーーー。
そろそろ、絵的な進捗がないと怒られそうなので次はシェーダ周りをやろうかと。

8日目は「シェーダーでごにょごにょ」を行う予定です!

進捗!

絵的なものはありません!

github.com

ねねチャレ 6日目「トランスフォーム!!」

6日目!

トランスフォーム実装しました!

今日の目的

モデルに渡すワールド行列を管理するトランスフォームクラスを実装します。
これで、モデルを簡単に操作できる用になります!

Transform

gist.github.com

簡単に紹介していきます。

RTS行列

特に説明するまでもないですが、いわゆるworld行列です。
親子関係は考慮しないので、一つだけです。
RSTから変換後の向きだけ抽出しています。

まとめ

やはり、数学系が実装されてると楽ですねー。
ねねっちもそれを見越してWindowを走らせていたのかもしれません。
流石ねねっち・・・。

7日目は「コンポーネント化(すいませんリファクタリングですまじスイマセン)」を行う予定です!

進捗!

f:id:himatyu:20180315004406g:plain github.com