FPSを作ってみる@wiki
02)
最終更新:
slice
-
view
(2015/02/27)
当たり判定
当たり判定マネージャのコード読んでコメント加えたりした。
んー、とりあえず変にメモリ節約を意識しちゃってるせいで読みにくいわ、メソッド名が紛らわしいor意味が通ってないわで微妙な印象。
その割にはあんまり速度的な貢献が無さそうなとこが、ねぇ
んー、とりあえず変にメモリ節約を意識しちゃってるせいで読みにくいわ、メソッド名が紛らわしいor意味が通ってないわで微妙な印象。
その割にはあんまり速度的な貢献が無さそうなとこが、ねぇ
あと常識的に考えてビックリだけど当たり判定ルーチンにテストコードがついてない。
いや、2年前だから当たり判定に限らずテストコードを書く習慣自体なかったんだけど。
今これは不味いよなぁ…
すぐどうにかしなければ駄目というものではないけどGoogleTestで使う部分、2DのGJKのテスト位は書いておきたい。
いや、2年前だから当たり判定に限らずテストコードを書く習慣自体なかったんだけど。
今これは不味いよなぁ…
すぐどうにかしなければ駄目というものではないけどGoogleTestで使う部分、2DのGJKのテスト位は書いておきたい。
ま、そんなとこです
imageプラグインエラー : 画像を取得できませんでした。しばらく時間を置いてから再度お試しください。
(2015/02/26)
2年前
絵のほうばかりやっていて、と思われてそう(いや、半分くらいその通り)だが
ちゃんとプログラムの方も進めている。伸び伸びになってる剛体物理に向けて…
ちゃんとプログラムの方も進めている。伸び伸びになってる剛体物理に向けて…
で、今はコリジョンを管理するコリジョンマネージャの整備をしている。
コリジョン関連のコードは履歴を見るとまともに機能追加したのが実に2年前(!)で、
当然内部動作など覚えてなかったのでざっくり読んだ所、同じようなインタフェースを複数定義していたりまどろっこしい書き方になっていたりと設計の無駄が多いと感じた。
まずはコードを読みながら使える部分の取捨選択とコメントの付加。
大量の物体を出す予定はなく、物体を円で衝突判定した上で個々の詳細判定ができれば十分なので今はそこまで出来ればOKとしたい。
imageプラグインエラー : 画像を取得できませんでした。しばらく時間を置いてから再度お試しください。
コリジョン関連のコードは履歴を見るとまともに機能追加したのが実に2年前(!)で、
当然内部動作など覚えてなかったのでざっくり読んだ所、同じようなインタフェースを複数定義していたりまどろっこしい書き方になっていたりと設計の無駄が多いと感じた。
まずはコードを読みながら使える部分の取捨選択とコメントの付加。
大量の物体を出す予定はなく、物体を円で衝突判定した上で個々の詳細判定ができれば十分なので今はそこまで出来ればOKとしたい。
(2015/02/12)
以前「漫画は手間かかるから、やるとしたら線画の4コマかな」と言った通り、4コマを描いた。
前々からやろうと思ってたネタが丁度twitterでお題だったので、丁度いいなと。
前々からやろうと思ってたネタが丁度twitterでお題だったので、丁度いいなと。
絵自体は白黒だし特に書くこともないが吹き出しと活字を使ったのは始めてで、
魅せ方を考えるのも結構難しかった。
あと前回の反省を踏まえ、如何に絵を使いまわすか?という事も視野に入れた。
4コマといえど全部描いているとそれなりに時間かかってしまうからねぇ‥
魅せ方を考えるのも結構難しかった。
あと前回の反省を踏まえ、如何に絵を使いまわすか?という事も視野に入れた。
4コマといえど全部描いているとそれなりに時間かかってしまうからねぇ‥
今回はまんまだったが次は人物だけとか、素材に拡大縮小回転を加えたりとかで部分的に使いまわすのにも挑戦したい。
(2015/02/08)
背景にドラゴンいるやつとは別にまた新しく絵を描き始めてしまうという。
なんか、その日の気分で進める気になったりならなかったりするんよね。
なんか、その日の気分で進める気になったりならなかったりするんよね。
ひたすら絵を描いていると特に自分の場合
色々付け足して無駄に分量が増える=一枚の時間が長くなる 傾向があるようで
(絵に限ったことではないのだけど)
そういった時にずっと同じ絵で作業してると飽きてしまう。
飽きたらどうするかと言えばプログラミングを進めるか、描く対象の資料集めや練習と称して適当な写真の模写を始めたりする。
色々付け足して無駄に分量が増える=一枚の時間が長くなる 傾向があるようで
(絵に限ったことではないのだけど)
そういった時にずっと同じ絵で作業してると飽きてしまう。
飽きたらどうするかと言えばプログラミングを進めるか、描く対象の資料集めや練習と称して適当な写真の模写を始めたりする。
で、模写をしている内にふと
「写すだけもなんだし、ちょっと角度変えてやってみるか」
「背景も足してみようか」
等と思いつき、色々やってると最終的に
「折角だからシチュも考えて一枚の絵にしてみようか」
となる訳である。というか、今までのデジタル絵は殆どこのパターンだったりする。
例えば一番最初のエレビッツ、あれも最初は一匹だけのつもりだったし
wheatleyも、虎さんもそう。
ヌマクローに至っては漫画しかも2ページになった。
「写すだけもなんだし、ちょっと角度変えてやってみるか」
「背景も足してみようか」
等と思いつき、色々やってると最終的に
「折角だからシチュも考えて一枚の絵にしてみようか」
となる訳である。というか、今までのデジタル絵は殆どこのパターンだったりする。
例えば一番最初のエレビッツ、あれも最初は一匹だけのつもりだったし
wheatleyも、虎さんもそう。
ヌマクローに至っては漫画しかも2ページになった。
まぁ、漫画形式はあの件で懲りたので当分無しとしても
描いてる本人にさえ予測できないとこがなんとなく面白いので
今後も思いつき方式でやっていきたい。
描いてる本人にさえ予測できないとこがなんとなく面白いので
今後も思いつき方式でやっていきたい。
大体「あ、やばいこれ描いたこと無い」 ->(資料集め)->「むずい」->
「練習しないと」-> (別の構図が浮かぶ)->(そっちを描き始める) とかなって
時間かかるけど…
「練習しないと」-> (別の構図が浮かぶ)->(そっちを描き始める) とかなって
時間かかるけど…
現状:
気力的に完成まで漕ぎ着けそうな物がモブドラゴンの奴と、今やってる奴の2枚。
その他怪しい物が4、5枚。
気力的に完成まで漕ぎ着けそうな物がモブドラゴンの奴と、今やってる奴の2枚。
その他怪しい物が4、5枚。
ゲーム
ちょこちょこ一応進めてはいるがお察しください状態。
imageプラグインエラー : 画像を取得できませんでした。しばらく時間を置いてから再度お試しください。
(2015/02/01)
前にも書いたけど、ここ最近絵の方が楽しくて困る。
純粋に描く楽しさと言いますか。
描くという行為自体も、元となるシチュエーションを妄想するのも楽しい。
純粋に描く楽しさと言いますか。
描くという行為自体も、元となるシチュエーションを妄想するのも楽しい。
プログラミングもね、最初は絵と同じように自分の書いたプログラムが動くだけで楽しかった。
でも、何年かやってれば腕前はともかく自己評価が「できて嬉しい」から
「まぁ、この位は当然だよな」みたいになる事が多くって、
モチベーションが中々上がらないのも事実。
たまにC++のリファレンス見て勉強したりもするけど若干の義務感も混じってたり。
でも、何年かやってれば腕前はともかく自己評価が「できて嬉しい」から
「まぁ、この位は当然だよな」みたいになる事が多くって、
モチベーションが中々上がらないのも事実。
たまにC++のリファレンス見て勉強したりもするけど若干の義務感も混じってたり。
プログラム
ま、それはそれとしてプログラミング関係で現在取り組んでる課題としては
自作ライブラリで「とりあえずゲームループを動かす」だけ等の、
簡単な事をするのが簡単に出来ないという事。
自分で言うのもなんだがリソースのパス登録から始まりゲームスレッド用のアップデート関数に描画スレッド用の関数、
ゲームシーンクラスの定義と、とにかくお膳立てが多い。
自作ライブラリで「とりあえずゲームループを動かす」だけ等の、
簡単な事をするのが簡単に出来ないという事。
自分で言うのもなんだがリソースのパス登録から始まりゲームスレッド用のアップデート関数に描画スレッド用の関数、
ゲームシーンクラスの定義と、とにかくお膳立てが多い。
これらは全くの無駄な記述という訳ではないんだが、初めてWin32APIを勉強した時のような
「ウィンドウを開いて単色で塗りつぶしたいだけなのに何で100行近く書かなきゃならんのだ」というアレに近い。
動作のカスタマイズに対応する為に色々設定できるようになっているものの
実際問題そんなに使われないので結果、シンプルさを阻害する役にしか立ってないという。
カスタマイズ用の関数なんて普段は存在すら意識させず、カスタマイズしたいと思った時に調べられれば良いのだ。
「ウィンドウを開いて単色で塗りつぶしたいだけなのに何で100行近く書かなきゃならんのだ」というアレに近い。
動作のカスタマイズに対応する為に色々設定できるようになっているものの
実際問題そんなに使われないので結果、シンプルさを阻害する役にしか立ってないという。
カスタマイズ用の関数なんて普段は存在すら意識させず、カスタマイズしたいと思った時に調べられれば良いのだ。
そんな訳で実は以前にヘルパークラスを用意してはいた。(prochelper.hppが一応それ)
しかし自分で試しに使ってみた結果、ヘルパークラスのヘルパークラスが必要なようだ…
しかし自分で試しに使ってみた結果、ヘルパークラスのヘルパークラスが必要なようだ…
絵
多分みんな同じような感じだろうと思われるが、下書きばかり溜まってく現象が発生中。
絵の工程が大まかに 下書き、墨入れ、塗り という流れだとすると
やっぱり無から有を作り上げていく下書きの段階が一番テンション上がる作業な訳で、そこで満足してしまう部分はある。
まぁ最後までキチッと完成させるのも大事で、仕上げたら仕上げたでやってよかったとなる物だけどそれなりの時間はかかるし。
絵の工程が大まかに 下書き、墨入れ、塗り という流れだとすると
やっぱり無から有を作り上げていく下書きの段階が一番テンション上がる作業な訳で、そこで満足してしまう部分はある。
まぁ最後までキチッと完成させるのも大事で、仕上げたら仕上げたでやってよかったとなる物だけどそれなりの時間はかかるし。
現時点で下書きは5枚ほど。
このうち完成に漕ぎつけられるのはどれくらいかわからんが、折角だしちゃんと体裁を整えてから公開したい。
imageプラグインエラー : 画像を取得できませんでした。しばらく時間を置いてから再度お試しください。
このうち完成に漕ぎつけられるのはどれくらいかわからんが、折角だしちゃんと体裁を整えてから公開したい。