FC2ブログ

ニートが頑張るブログ

ニートが現実逃避するために創作活動など色々とカオスに頑張ってみる
ニートが頑張るブログ TOP  >  自作ゲーム開発

弓矢、盾、チャンバラづくり


「8月の半分」くらいをかけてやってたことにゲームづくりがあった筈なんだけど
その解説の文章を全く書いてなかった。


やったこと。
実は変わったこと。
色々やってるんです。







◆体躯の傾きのなめらか変化

しゃがんだ状態からの前後移動 


「旧アニマルメーカー」で、最後まで直せなかった現象に、実はこれがあります。
しゃがんだ状態で前後に方向を変化させたとき、傾きが一瞬で変化してしまう、という奴。
旧アニマルメーカー

これを一応なめらかにした、みたいなのも変化だったりする。


一応、注視モードや平行移動モードにして、 左に歩いてからすぐ右、みたいに
向きを変化したときの体の傾きなんかも、前は一瞬で変化してしまっていた。
そこもなめらかに変わるようにした。


あと、地面の角度に合わせて傾くやつも改良したので、ここが治りました。
床との角度調整



「足元の地面の法線と、その角度に合わせて近づく」という奴でいけるだろうと思っていた筈なのに、
前の奴だと、ここまで急な角度だと、角度が飛んでいました、


なぜそうなるのかというと、実は「軸」の方が180度変わっているのですね。
床の法線

この、前の地面と、後の地面では、 法線の軸が180度、実は変わっているのです。
そういうのにも対応できるようにした、と。
こういうのが、作者にしか分からない変化。


で、「見た目」の進歩が地味なのは当然として、
問題は内部処理の変化の地味さだったりする。



こういうのを実現するために、内部の変数の処理からして、かなり根本的に直してたりするのです。


◆キャラの押し出し

これは、前のアニマルメーカーでもやれてたことですね。

キャラ同士の衝突


ゲームにおいて 「キャラとキャラがぶつかったとき」、どうあるべきか。


・そこで完全に止まってしまうのか? or (それともごまかしっぽく減速でもするか)

・そこで相手を、どんどん押せてしまうのか? (アフリカの動物同士の衝突)

・すりぬけてしまうのか? (ソウルシリーズの敵なんかはある程度押し続けると時間で抜けるようになってる)

・それとも、のけぞりモーションなんかを再生して、ごまかすか? (MGSVのFOBで、味方キャラにぶつかったときはそうなる)



・・・
・・・全部、「不正確」な筈です。


本当は、自キャラは歩きづらくなり、
相手キャラは「おっとっと」と押し出され、押された方向に歩を進める、
というのが現実的な筈です。


自分のアニマルメーカーのシステムなら、それが実現できるのです。


まぁ、そのためには、 「加速のシステム」を「二重」に改造する必要があったりするわけです。
(ちゃんと説明する気がないのでテキトーだけど)



で、前のアニマルメーカーでもそれをやりましたし、今回のこれでも出来るようになったということです。


◆盾を作りました。

今の段階でここまで武器を作り込む予定ではなかったはずなのに何故かつくってしまった盾です。
(謎解きメーカーに、盾の要素なんかなかった)


盾(左手武器系)を拾うと、 左手に自動に装備します。

そのあと、Xキーを押すと、その武器の構えに移行します。


盾武器の場合は「盾構え」にしているので、盾を構えられるということ。

で、構えていると、相手の攻撃をブロックできる、と。
現時点で、敵とチャンバラできますよ。



自分もこういうのが作れるようになったのだなぁ~と、これだけで感慨無量だったりするのです。
だって、なんか凄い、ダクソみたいなゲームが近づいてきてる気がするから。


しかも、盾拾い、盾投げとかも全部リアルタイムに出来るってのが嬉しすぎる。


盾構えモーションと、それにあわせえて揺れる盾
だいたい、この「盾構えのモーション」からして、我ながら好きなのです。


こうやって、Xキーを押すと、なんか、「いい感じの揺れ」が、盾に発生しているのが分かると思います。


つってもなにもしていません。
全部自動的に生み出されるようにしているのです。
武器を構えたり振ったりしたときの 揺れ、揺り戻し、 そういうのもいい感じになるように直したのです。



盾でガードをしたときの挙動 触感

そして、このブロックをしたときの「感触」

これ、我ながらかなり好きなんだが??



ダクソ1でさ、 盾を構えた印象深いやつがいるんだよ。

森のこいつ。

こいつを、槍系の武器で突いたときの コンって感じが好きでした。

ああいうのに迫りたい。


あと、自分の盾に自分の武器の攻撃も当たるようになってます。

だから、こんな「盾鳴らし」みたいな行為が自分でできます。
盾鳴らし


これ、「ドラゴンズドグマ」の、敵のファイターがやってくる威嚇行為みたいですよね。


同様に、
自分の左手武器に対して、自分の右手武器の攻撃が衝突する、みたいなことも、起きます。
これは
なんか、天誅弐の 玄武を思い出す。



◆武器に付随する手足

武器を持っている手足が、 多少、「武器に"逆に"引きずられる」という現象も、表現できるようになりました。


盾で防御したときに、その盾が押し出され、更に、 その盾を持っている「手も曲がる」
そういうことが表現できるようになったということです。


で、これによって、武器を持った状態での 振り返り やら走りやら、 ダッシュやらも、
全部表現力がアップしたのです。

ダッシュをしたときの手足、武器、ツインテの動き

急に加速したとき、手足の武器が重みで遅れてついてくる。
結果的に、手足が後に伸びる感じが自然に表現される、と。
(長さ制限がいるかもだけど)


◆「揺れものスクリプト」というのを自作しました。


何かの中に、子オブジェクトとしてトランスフォームをブチ込んでおくだけで、あとは勝手に「いい感じ」に揺れてくれるような
便利なスクリプトを作ったつもり。


多分、「ダイナミックボーン買え」とかそういうことになってくるんだろうけど、やりません。
どんだけショボかろうが、全部 自分で作ります。

(自分のゲームのなかに、自分の知らんスクリプトがあるというのが、なんか嫌なんだよ)


で、
これで、例えば「尻尾」だとか「ツインテ」だとかの揺れの表現も、前よりかはマシになったのです。

尻尾全般の動きがよくなりました

上下にジャンプすれば、それの逆に揺れて、その後揺れ戻しがくる。
Y軸の旋回もそうだし、注視や平行移動モードからの、左右のダッシュでも、いい感じに揺れるようになりました。


前のバージョンでは、実はここが擬似的で、テキトーだったのですね。


◆攻撃システムと、全身の 「揺れ」

で、殴った尻尾とか 頭とか、手足とかが、 攻撃に合わせて、 その部位だけ「揺れる」ようにする、というやつもやりました。


カマキリを殴ったときのリアクション
例えば、
カマキリのお腹のあたりを殴ると、こうなります。

尻尾と羽が攻撃に合わせて こう動いて、そのあと揺れ戻しがくる、と。
前は、血が出るだけでした。

恐竜の頭を殴ったときのリアクション

を殴れば、が揺れる。 手足を殴れば、手足がゆれる。
尻尾をなぐれば、尻尾が揺れる。

全身をなぐれば、全身がのけぞる。 (←これだけしか作れてないゲームが、実は大半です)



これがまぁ、できてるゲームも、限られるかなと。

例えば ソウルシリーズだと、になってから、これができてるようになりましたね。
いや、ブラッドボーンか。


ブラッドボーンから、ボス戦がなんかぐっと良くなったのは、これもあるでしょう。

ブラボの 「聖書者の獣」
ダクソ3だと「ボルド」あたりの手足を殴っているとき
今までと「ボスの触感が違う」ってのが 分かる人はわかった筈です。


攻撃に合わせて手足が個別に揺れるってのは、気持ちがいいものなのです。



「ダクソ3」をやってから、「仁王」なんかをやると、味気ないのが、この点なのですよね。


でかい鬼の 足を切っても手を切っても、その殴ってる部位がその攻撃に合わせて揺れる ということが「無い」ので、
なーんか、味気ない。

せいぜい、発生するのは、ちょっとした「全体の」のけぞりモーションだけなのです。



仁王のボス戦がダクソに比べてなんかしょぼいように感じられるのは、そこなのです。

ボルド怨霊鬼だけで、そこがもう違う。







で、ダクソ3にしたって、「ボス戦」でこそ、こういうのが作りこまれてるけど、通常の雑魚では、こんなの無いはずです。



でも
自分のこのアニマルメーカーのシステムなら、
ボスだとか、雑魚だとか、大型だとか、小型だとか、人型だとか、獣だとか、 そんなの関係ありません。
全員、区別なく、全身揺れるし、 そもそも敵の大きさなんか あとからいくらでも自由に変更できるのです。



◆壁突き刺さり


自分が勝手に尊敬し、すげーと思っているゲームに 「EXANIMA」というのがあります (EXAMINAと間違えやすい)


このゲーム、武器振りの表現がとにかく凄いのです。

絶対勝てないと思う。
まぁ何かが根本的に違うんだろう。


でも、なんか目指したいと思っている。 こういう「雰囲気」も含め。
 (diablo1の雰囲気を継承できてるのはこのゲームくらいだよ!)

(ちなみに、今の自分のゲーム、グラフィック的には最底辺レベルの水準だと思うけど)
(そんなのは後でどうにでもなると思ってやってないんです)
(まずは動き操作系です)


↑こないだも、「武器が壁に突き刺さる」というのをやってました。


すげえなぁ。


でも、自分も真似してそれを作ってみたんです。

壁突き刺さり

武器を壁に向かって振って、当たると、突き刺さります。


突き刺さったあとは、しばらく引っ張らないと、引っこ抜けません。 (走ったり、逆向きだったりすると、抜けるのが早くなる)


やってみたら
まぁ、結構同じ表現ができたのです。


自分の場合「突き刺さり後の主人公の角度制限」というのもやっています。

突き刺さったら、シフトキーとか関係なしに、「平行移動モード」になるのです。
これが、ショボさをごまかせているかと思います。


さて、こうして出来た「壁突き刺さり」
なんの役に立つのか。


当然、自キャラのリアリティやら戦法に関わってくる。

壁際で、安易に攻撃を出すと、困ることになるからね。


武器が壁に弾かれるのを嫌う人はいるかもしれないけど、しったこっちゃない)
(もっとすごいペナルティを作ってやったぞ、ということ)


まぁ厳しすぎてもアレなんで、
武器や技ごとに壁との関係性は分けるようにしようとは思っています。

・壁に突き刺さる

・攻撃モーション・タイミングによっては突き刺さる

・突き刺さらない

・壁にあたったら、逆方向に押し出される

・弾き返される


・・・みたいなパターンがあるかと思われます。



例えば、パンチとか鈍器のような攻撃が壁にあたったときは「逆方向に押し出される」が発動します。

鈍器


で、壁武器刺さりで、 一番重要なのが、敵の挙動に関わる部分ですね。


骨に見つかって、逃げながら、攻撃をさそってみましょう。

敵の斧の大振り攻撃が、壁にあたるように誘導すると。突き刺さって、そのあとしばらく反撃も防御もできなくなります。
その間に反撃できる、というのが生まれるのです。
(一応地面に突き刺さることもあるけど、条件厳し目にしてる)


いま、壁突き刺さりというのを雑に作っただけなのに、もう、こういうのになってる。


この感じを出せてるゲームはほとんど無いようにも思う。



◆弓矢


弓矢を作ってしまいました。


今回ここまでやる予定なかった筈なんだけど、
盾が作れたのが嬉しすぎて、やってしまいました。

弓装備 弓構え 矢射出 壁突き刺さり


弓を拾うと、「左手武器」として装備されます。

その状態でXキーを押すと、弓を構えます。

そのままZキーを押すと、手に矢を握り、矢を引きます。

Zを離すと、矢を放ちます。

・・・
これだけ作るのも滅茶苦茶大変だったのです。


でも出来た時は滅茶苦茶嬉しかった。


ほんとう色々大変。


Zを押した瞬間、右手が空いていると、プレハブとしての矢を発生させ、右手に装備させ、
右手の攻撃パターンやら矢の状態やらを大量に書き換える。

そして、「右手の矢」の攻撃モーションとして、「弓矢引き」を発動させる。

Zを途中で貯め、途中で離すとキャンセルされる。

Zを十分貯めたあとに、逆にXキーを解除するプレイヤーがいるかもしれない。
そのあとも普通に矢が飛んでしまうとおかしいことになるので、それは許さないようにする。

そういうときは、右手に「近接武器としての矢」を持ったままの状態になるようにする。


その状態からZを押すと、手に持った矢で「突き刺し攻撃」をする。
右手に持った矢を近接武器として使う

あらためてXで構えながらZを押すと、今度はそのまま手に持ってた矢をつがえ、撃つことが出来るようにする。



・・・
そんな感じのリアルさで、矢を撃ちまくることが出来るようになりました。


撃った矢は、 敵に攻撃できるのは当然として、 やはり、 「壁に突き刺さり」ます。 
(ここに、さっきの近接壁武器の壁刺さりも、流用できるのです!)



右手が空いてる状態で
「壁に刺さった矢」に触ろうとすると、また右手に矢を入手できます。
つまり、矢を再回収できます!!
そのとき、「壁武器引き抜き状態」になります。

壁に刺さった矢の再回収

これがすっごいいいと思う。われながら。


大抵のゲームで、撃ったあと矢なんてものは、
点滅して消えるだとか、そのまま何もできなくなるというのが大多数だと思う。


「弓矢の作り込みがいいゲーム」
撃った矢が地面に落ちて、再利用できるというゲームとして「ラストオブアス」があるけど、


今回、ある意味、「矢の再利用」に関してはラスアス超えたと思っている。 (よういうわ)



結局、ラスアスでも、矢をアイテムとして手に入れようと思ったら、そのままインベントリ行きになって、「消滅」させるしかない。

敵や壁に命中したあと、一定確率で「刺さった矢」が壊れないで、「拾えることを示すUIが表示される」ってだけである。
ラストオブアスの矢回収

矢を拾うと消滅し、「内部の変数が1増える」ってだけのことである。


でも、

自分の場合は、矢が消えたりしない! 

「そのまま」拾える! 

「そのまま」引っこ抜く!

「そのまま」右手に戻ってくる!

「矢筒」なんていうインベントリに移動して、消えたりしない!

右手に持った矢を、そのまままた引くことができる!

そのまま再発射できる!


・・・そういう、何も消えない、何も誤魔化さないループになっているのです。 一応。


◆殴り


あと、何も持っていない状態での Zキー押しで 「パンチ」が出るのは前からでしたが、
そこに「攻撃判定」をつけるのもやりましたね。 敵をちゃんと殴ったりできるようになりました。


これが、地味に大変でした。
下手すりゃ、弓矢つがえよりも大変だったかも。



やる前は「透明の攻撃用こぶし武器」というのをプレハブに用意しておいて、殴ろうとしたら そいつが発生して、
手にその攻撃がくっつくようにすればいいだけだと思っていました。


いやまぁ「そのとおり」でした。 予想した通りだったんだよ。

でも、「それだけ」だと思っていたことを、いざ 実装しようとしたら、 それが予想以上に大変で大変で、
まぁ難しかったです。



でまぁとにかく、殴りもちゃんと作れました。




前回の 謎解きメーカーというゲームでは、
スイッチの近くでプレイヤーがZキーを押すと、なんとなく「スイッチが押せる」という風になってましたが、
今回はそういうのもなくして、ちゃんとしようと思っています。



「スイッチ」という物があったなら、 そのスイッチをちゃんとキャラが「素手」なり武器なりで 「殴って押すべき」
そうやって手でちゃんと ドスっと殴ると、スイッチが動くと、 そういう風にしたいと思っているのです。


・・・
まぁそんな感じでした。
先月、ずーっとやってたこと。 モデリング以外で、「半月くらい」かけてやってたことが、 こういうことでした。


先月やってたことを。やっと解説できた。


何も変わってないようにみえて、色々やっているのです。
そしてあまりに進みが遅い。



まぁ、大分、固まってきたのでは・・・ないか?

そろそろ、「動き」とか「攻撃」とか以外の領域に、移行できないか?

[ 2018/09/11 22:16 ] 自作ゲーム開発 | TB(0) | CM(5)

アニマルメーカー改善中


随分久しぶりにUnity開発やった気がする。
なんでこんな久しぶりなのか。
まぁ今年の半分は、「生活費を稼ぐためのシステム」を構築するために潰した、ということにしよう。
上手く行ってるかはともかくとして。


で、やってみてまぁ色々進みました。




やったこと。

・エフェクト
・素手殴り
・足
・スローモーション
・注視
・ロックオン
・視界
・敵挙動
・地形に合わせて傾く
・・・

大体こんな感じ。



まあとにかくやってみれば
ラプトルがこっちについてきてくれます。
糞可愛い。

じゃれるラプトル

もうこれだけで全部どうでもいいです。

[ 2018/07/04 07:42 ] 自作ゲーム開発 | TB(0) | CM(2)

四肢切断カムバック

 
最近頭のなかで「情けない」しか喋って無い気がする。
それしかつぶやいてない。


一応ようやくゲームづくりに戻ってきた感じなんだけど、
そんで今こんな感じ。




やったこと。
武器周りを多少やりました。


・武器拾い
・武器振り

・武器貯め、武器貯めながら歩き
・武器投げ

・武器弾き(地形にあたってのけぞり)

・全部位切断判定




ようやく首チョンパが出来るようになって、
アニマルメーカーらしくなってきたと思います。
そろそろ血のエフェクトをやるべきですね。



たったこんだけのことをここまで持ってくのに何でこんなにかかるんだよなぁと。
そんでもってショボいなぁと。

動きがおかしいなぁと。

(恐竜やカマキリの歩きはまだマシなのに、なんで人間の歩行が変なんだよ)
(普通逆だろう)



グダグダ説明してもいいんだけどもういいや、という気分でもある。


でもやっぱちょっと書く。

アニマルメーカーunity
[ 2018/04/20 18:00 ] 自作ゲーム開発 | TB(0) | CM(8)

足が直ったあああ

 
アニマルメーカーunity版が直りつつあります。

接地感が良くなりました。 旋回感がよくなりました。
本当に、色々と良くなりました


ああ良かった。



ラプトルあるきまわり





だからもう、そんだけで更新です。
そんだけの報告。


ほんとうにもう、これだけのことがどれほど嬉しいか。
これだけ直すのがどれだけ大変か、難解か、

アニマルメーカーが根っこの部分でどういうことをやってて、
それを移植するにあたって、
どこをどうやったら何がどうなって、あれが上手く行かなくて、
どこをどう工夫したらあれがこういう風に直るのか、
hiza2.transform.Rotate (Vector3.right, -Mathf.Atan2 (last.transform.localPosition.z - hiza2.transform.localPosition.z, -last.transform.localPosition.y + hiza2.transform.localPosition.y) * Mathf.Rad2Deg);
・・・
・・・

そういうことについて延々と語りたいような気もするけど、
文章じゃ無理。 ホワイトボードとか使って延々と講釈するようなものなので、もういいや。


とにかく良くなったんです!



てかかなりリアルでしょう。


てか、今のPS4時代のゲームでもなんでも良いけど、
「足の運び」に注目しながら、
キャラをその場で旋回させてみてください。

絶対、この水準で旋回できてるゲームなんか、殆どない筈です。
大体、ごまかしてる。


TPSなら、銃を構えながら平行移動させてみてください。
その際に、足のアニメーションが、角度毎に「何種類」あるか、数えてみてください。

8方向作ってたら、まだマシな方。
前後左右の4種類しかアニメが無いゲームが、殆どではないでしょうか?

それが、このアニマルメーカーでは、無限です。
平行移動、注視移動時の足の運びの滑らかさ自然さが、マックスなのです。


「ARK」っていう恐竜ゲー、ありますね。

あのゲームで、恐竜をテイムして、サドルをつけて、背中に乗ってみてください。
ark 騎乗

FPS視点モードに設定してても、そのときだけは、恐竜見下ろし型の視点に強制的に移行して、
なんか、特殊な「固い操作モード」になる
のが分かるはずです。  (旋回しづらい非常に固い歩行操作)

あれ、なぜああなっているのか?

自分にはわかります。


すべての恐竜に、「左右平行移動」をさせるときのモーションを用意することができなかったから、ああなってるんです。

恐竜を自機として操作させるとき、
各種恐竜毎に用意している歩行モーションを、「前をまっすぐ歩くモーション」の一種類だけしか用意してないのでしょう。
(後退させるときは、アニメを反転させる)


つまり、恐竜に乗ったまま、左右に平行移動させるアニメがない。

アニメがないので、そういう操作をさせることができない!

そういう操作が出来ないので、強制的に恐竜騎乗時は、「ラジコン操作」しかないようにする。

だから、恐竜の背中に乗った状態でFPS視点にすることが出来ないようにしているのです。


これが自分の推理です。


ARKという恐竜ゲーにおいて、
恐竜騎乗時にFPS視点が解除されるのは、
恐竜毎に多彩な歩行モーションを用意するのが不可能レベルだったから。


他にもこう言う話、延々と出来る。

シロウトの作るゲームとプロの作るゲームで1番差が出るのはどこか?
それは何故か?
1番ハードルが高くなっているのはどこか?


ボスAI、プレイヤーと敵との位置関係で変化する挙動、
ここでは「旋回」、こうだと「平行移動」、こうなら「後ずさり」・・・
・・・
ワンダ ボスAI

AIづくりもそうだけど、
そもそもその、「モーションパターン」を色々用意するのが、シロウトにはあまりにハードルが高いだろう。
こうやってボスごとに骨組み作ったり、モーション作ったり、AI作ったりする、 
こういうのが「真の作り込み」であり、1番しんどいところなのかもしれない。


で、ホライゾンのときにも書いたけど、
一見高クオリティに見えるけど、
案外、 実は「敵の種類が少ない」ってゲームは多い筈。 
(だから同じボスと延々と戦わされたりする)

(ましてや小動物の作り込みを頑張ってるゲームなど・・・)


・・・ゲーム開発におけるそういうこと、
そういうコスト、ハードルを 全部ふっとばすのが、こういう「アニマルメーカー」みたいなシステムなんです。


・・・みたいなことを、これまでも何度も言ってきたと思うけど、

前まではとにかく、肝心の「歩きの動きの質」自体が、なーぜかヘボかった。

なーんかガクガクする。
なーんか上下にフワフワしてる。
なーんか、足が地面を滑ってる。


前までのラプトルの歩き
大見得きってたくせに、1番重要な部分で、ヘボいパフォーマンスにしかなってなかった。


本当に出来が悪かったと思う。

ああ恥ずかしかった。

flash版のアニマルメーカーの時点では、そこそこどの動物も歩けているのに、
なんでそれをUnityに移植しようとしたら、
こんなにも上手く行かないのかと、マジでUnity開発のモチベが地に落ちていたんです。

これはもう
UnityのRaycastとか、当たり判定とか、きっとそういうのの精度が悪いから、ガクガクするんだろう、
こんなに変なことになるんじゃないかと、勝手にUnityのせいにも思えてきて、
マジでやる気ゼロになってました。



だからこそ、色々モデリング作業ばっかしてたりとか、ある意味「逃げて」いたのですね。



でも今回、とうとう カマキリモデルを入れようとしてみて、
その、カマキリの動きすら酷いのに、もうブチ切れました。 (セミはそこそこ歩けてたのに!)

本格的に直す前のカマキリの動き

これはもう、本格的になんとかしなければならない。
一晩中うんうん唸って、改善アイディアが降りてくるのを待ちました。 


降りてきた。

そんで、プログラムの大幅な改修をしました。 
これは本当に大変だった。 本当に精神的にキツかった。


そしたら、直ったんです!


カマキリが、やっと、これくらいのリアルさで歩かせられるようになったんです!!

カマキリのマジ動き

この、「カッカッ」という感じの、足運び・・・

これはもう、旧アニマルメーカーのカマキリよりも、何倍もいい動きになっています。
やっと越えられたんです。


勿論課題はまだまだ山積みだけど、
今の自分はもう、カマキリがこれくらい歩いてくれる、
それだけでもうなんか全部どうでもいいくらい、嬉しいですね。


あぁ~直った~良かった~
まさか直せるとは思ってなかった~。
ああ諦めないで良かったなぁ~ 
みたいな感じ。


とにかく今回も、カマキリのお陰で一念発起できたということですね。

[ 2018/02/01 19:46 ] 自作ゲーム開発 | TB(0) | CM(5)

unity版アニマルメーカー セミ追加


スッゴイ久しぶりにアニマルメーカーのunity版の進捗でも貼ります。

本質的に何も変わってないじゃん
むしろ接地感とか悪くなってるくらいじゃん
って思われるかもしれんけど、


これでも一応、いろいろ試行錯誤してなんとかマシにしようとした結果がこれなんです。





続きは長いです。
大したことやってなくても、延々と語れるんです。

[ 2017/11/27 10:53 ] 自作ゲーム開発 | TB(0) | CM(5)

利き弐号機の問題点



で、結局撮影も忘れて今度は「利き弐号機」というミニゲームを作ろうとしています。
(前に作った「利きゴジラ」というゲームの応用です)


ゲームというか、単なるクイズですね。
それもゴジラの時以上にマニアックなだけのカルトクイズ。 
ゲームとしては全然面白くないと思う。 
でも思いついてしまったんだから仕方ない。作る。



やることとしては、
色んな弐号機の画像を見せて、
「その弐号機を描いたのは誰なのか」を当てるクイズ。
そんだけ。


お題となるのは、

・TVのカット、
・映画のカット、
・あとは公式のイラスト


この3種類の系統の中からになると思う。

(あと追加するとしたら、「漫画」というカテゴリもありえるが、今回は止めとく)
(漫画の弐号機の画像つったら、ほとんどがさだもっさんだし、じゃあそこをクイズとして成立させるには)
(「それ以外のエヴァの公式漫画」からも大量に集めなきゃならなくなる。 それは嫌だ。絵の質的に)
 ((そもそも、貞エヴァ内の弐号機の絵自体、実はカッコイイモノが少ない))


で、この超単純そうなミニゲーム、作るの意外と大変だと思う。


資料集めもそうだし、
第一、「答え」と言うものが自分自身にも完全には分かってないのだ。


アニメのエンディングのスタッフロールで
その回は誰が作画監督で~
誰が原画で~、という事は書いてあるけど、
シーンごとの細かい分担なんかは書かれて無いわけで、
具体的にどのシーンを誰が書いたのかなんて、そこはもう勝手に推測するしかない。


で、その推測が、まぁほぼ確実に当たってるだろうな、と思えるような回もあれば、
よくわからんよなぁという回もある。


で、こうして資料集めとかしてみると、
弐号機って、案外活躍してないなぁ。

弐号機の出番が、ある程度あるTV版エヴァの回というのは、

8話
9話
12話
19話
22話
24話
くらいであって、これにしたって、8話以外はあんましアクションが少ない。


で、8話の水上の作画担当に関してはまぁほぼ確信を持っているので、
8話のクイズに関しては問題ない。

でも残りの、細々としたところが、本当に困る。


・19話、サッパリわからん。
(四つん這いの初号機が磯光雄なのは分かるじゃん?でも弐号機の担当がわからん)
わからんウチは、クイズには使えない。誰か教えてくれって感じ。


・22話
ところで、自分がTV版のエヴァ全話の中で1番好きなのが、当然、22話なんですが、
22話は、メカの作画も、(あんまし動かないけど)、いいですよね。


↑で、こういうのを見ると、
もう、この足の感じ、ハイライトの感じだけで
「ああ、吉成曜だなぁ~」と分かるのですが、 (例の、零号機がロンギヌス構えてるイラストと全く同じ感じだから)


じゃあ、22話の弐号機の画像をクイズに出して、
それを書いたのは吉成曜!という答えで、果たしていいのだろうか?


こういうのは、その回の作画監督が修正入れまくったから
結果的にまるでその人が描いたかの如く見えるけど、
実際の原画さんは別の人だったりするんじゃないかと?

それなのに、「それっぽいから」といって答えが吉成曜でいいのかと、思ってしまうのです。


・24話
24話の弐号機も、中村豊が描いたと言って良いのか、摩砂雪が描いたと言って良いのか、よく分からない。



・・・そんな感じで、TV版の弐号機クイズの問題づくりは、
8話以外微妙、ということになってしまっています。


劇場版の弐号機クイズに関しては、まぁ、TV版よりかは大丈夫だと思います。
 (劇場版原画集(上)に、誰がどの原画描いたか、全部かいといてくれればいいのに)


で、最後に問題になるのが、
公式イラスト系のクイズ


公式イラストの中で弐号機が描かれているやつを集めまくって、
それの作者さんで、利き弐号機のクイズにする。


で、これに関しては、
「Evangelion - Die Sterne」という画集があって、その巻末には
誰が描いたイラストなのかが懇切丁寧に全部書かれているので、
まぁこのクイズを作るためにこんなに有り難い資料は無いわけです。


でも、当然ながらそういうのに載ってないエヴァのイラストだって世の中にはあるわけで、
そういうのをイメググったりして見つけてきた場合、
 (もしくは自分のエヴァフォルダの中にいつの間にか保存されてた画像)
結局自分で鑑定していかなければならない。


で、答えが分からないと困る、というわけ。


↑これとか誰でしょうか?

自分の目利きとしては、
候補としては、「長谷川眞也さん」かなぁ?という感じなんですが、どうでしょうか?
誰か分かる人教えてくれ。
 (根拠としては、なんとなくの、「綾波の目の感じ」)
  (長谷川眞也さんが綾波描くと、なんか目が可愛くないとこがあると思う (酷い) )

EVA弐号機 顔
あと前々回貼った↑これとか、
これも「本田雄さん」であってるのか?不安になる。

(弐号機の「首の部分」だけで、認定して構わん気もするんだけど、なーんかアスカが不安になる)


ところで、あらためて「Die Sterne」を見てて、凄い気になったことがあった。(日記)

なんか、同じ絵を二回見た気がしたので、気になってもっかい見てみたら
微妙に違う絵なのだ。


それが これと、この絵。
本田雄 初号機
すしお 初号機

で、作者さんを見ると、

上が本田雄作
下がすしお作、なのだ。


こんなことってあるか?


自分には、本田さんの絵の方が、その、恐れ多いんですが、下手に見えるのだ。


こんなことって、あっていいのか?
(エヴァ関連のイラストで本田さんが劣る、なんてことが!)


ていうか大体この絵はなんなのだ?
なんで、こんなに似てる構図なんだ? (トレスか?トレスなんですかぁ??)
「すしお氏があとから被せた」って解釈でいいのか?



勿論、この「足の感じ」「胸の感じ」を見るだけで、
「あぁ、本田さんの描いたエヴァかもなぁ」とは思うんだが、
その後のすしお氏のイラストの方が色々と洗練されているように見えてしまうから、
なんか、ねぇ。

こうなってくると、「本田さんっぽく描かれた偽モンの絵」とでも思いたくなってくるくらいである。


これは一体なんなのか。
今更ながら、ものすごいエヴァの謎である。


あと、鶴巻和哉の描いた弐号機のイラストが一枚も見つからなくて寂しいんだけど
ないんだろうか?

[ 2017/11/02 21:51 ] 自作ゲーム開発 | TB(0) | CM(3)

Unity諦めなかった


unity諦めたといったな、あれは嘘だ。
ということで
これはすぐにでも言っとかないといかんなぁと思った報告です。


前々回、unityのビルドが上手くいかん、やる気が出ないとか、アホが抜かしてましたが、
なんと作業してるパスに日本語が含まれてた、とかいうド素人なミスをしてただけでした。

で、普通にWebGLのビルドが出来るようになりました。


で、unityへのアニマルメーカーの移植も、いくらか、山場を越えてきました。
基礎の基礎、のような部分はなんとかなってきてると思います。


ということで、plicyというサイトに投稿してみました。



ブラウザ上で触れます。


アニマルメーカーからの移植として、
今なんとかなったのが、

・2、3関節、逆関節までの対応、表示。 (関節の回転と長さ調整も)
Z注視、平行移動、
・しゃがみ、しゃがみ移動、
・しゃがみ短押しからのジャンプ


・・・くらいのことです。

(他にも、今は自分しかいじれないけど、「全身の大きさをリアルタイムに変えまくっても歩ける」、というのもやりました)


まぁ、まだまだ全然ですね。

アニマルメーカー全体が持っていた機能の数々から考えると、10分の一も進んでないかもしれません。

四肢切断、再接続、これらのことを考えるだけで頭が痛いし、
そもそも、頭、しっぽ、羽根、ヒレ、という、足以外の体のパーツの挙動についても考えなければいけない。



でも、基礎の基礎の部分、こうやってちゃんと歩けるようになっただけでも、わりと糞嬉しいのです!!


(前は、崖際から落下する、ということすらままならなかったのだ)

諦めかけてたところから、そこそこ動くようになるというのは、死ぬほど嬉しいのです


ここまで来るのも結構たいへんで、内部ではトンデモないことをしてるんだけど、まぁいいや。
 (特に関節の回転の仕組み)


で、これで色々もう試せますね。


でも課題が山盛りなのが分かります。


1つ、足音が変ですね。 これ、exeや自分の手元でテストしてるときはこんな変な音じゃないのに、
なんかWebGLだと凄いピチピチした短い音に聞こえます。 


しゃがみ


一応は、「Cボタンでしゃがみ移動」することで
「普段は頭がつっかえる場所」に入っていくことが出来る、とかのプレイも、既に出来つつあるけど、

ダッシュで突っ込むだけで、地形のなかにめり込むことが出来るし、

そもそも、しゃがみで入ったあとにしゃがみを解除すると、すっごいガクガクする、とかの問題もあります。


ジャンプにも問題あります。

てか、かなり誤魔化してます。 空中でジャンプできる時点で、現状色々誤魔化してるのがバレバレです。
まぁこれ自体はすぐ直せますが。


アニマルメーカーの一番の問題として、「ジャンプの挙動が安定しない」というのがありました。

キャラが同じ量、同じ距離をジャンプしてくれるかどうかがかなりバラつく、という問題があって、
これは謎解きメーカーからもずーっと解決してません。

今回も解決しそうにありません。


まぁそれにしたってね、自分のこの、「1ボタンで、しゃがみ、しゃがみ移動、ジャンプをまとめることが出来る操作感」を、
こっちに移植できたってだけで、滅茶苦茶嬉しいんですよね。


で、今一番酷い問題が、
壁、柱にむかって走り続けると、そのまま壁をよじ登れてしまうことですね。


これ、なぜこうなるかは、半分くらいは理解しています。
図で説明するといいんだろうけど、まぁメンドイからなし。

地形メーカーのときとやり方を変えたから発生した問題だともいえます。
(そのかわり、球の上だろうがなんだろうが自由に歩けるようになったんだけど)


解決方法も、半分くらいは思いついてます。

足から撃った、RAY(ビーム) は、 ぶつかったメッシュの法線(ノーマル)を調べることが出来る。 (凄い機能が使えるもんだ)

これで、「垂直の壁を蹴ったときは、上方にかかる反動に、バイアスをかける」
みたいなことをすれば解決しそうに思えるではないですか。


で、それやったんですよ。

でも、そしたら余計にひどくなって、余計に地面にめり込むようになりました。 わけが分からん!!

全く、こういうところが一番たいへんなんです。


一番酷くて雑な解決の仕方としては、「頭部が持っている衝突判定」を凄くデカくして、
足が壁をけろうとする以前に戻しちゃうみたいなのも考えられますけど。


まぁそんな感じで、

WebGLのビルドできるようになりましたよー、

ブラウザ上で試作品を公開することが出来るようになりましたよー、

触れますよー、

今こんな感じですよー


という事が報告できるようになりましたとさ。

[ 2017/07/12 09:50 ] 自作ゲーム開発 | TB(0) | CM(3)

Unityあきらめた。

 
unityあきらめた。


早っ!


いや、完全に諦めたとか 完全に意味が分からんとか、そういうことではないんだけど、
とにかくイチイチ「やってられんこと」が多発する。 一旦中止、そんな感じ。 そういう話です。


まず、
unityにアニマルメーカーのシステムを移植しないと話にならんなぁというところから始まりました。


ユニティちゃんの旋回動作は酷すぎる。 あんなのを動かすアクションゲームなんか作りたくない。

じゃあそれ以外のアセットやらモーションやらをストアから買ってきて、それを組み合わせてゲームでも作るのかというと、
なんかね、そういうゲームの作り方からしても、自分の思う「ゲーム作り」の感覚から違うんだよ。


ストアからこのキャラモデル落としてきます。
このロコモーションシステム入れまーす。
モーションは、ここのモーションを落としてきて、適用します、この背景使います。
銃はこのアセットねー
・・・
・・・
はい、一時間でFPSが作れましたね? 
unity簡単ですね?


・・・
みたいなの、そんなのはゲーム作りじゃない。 そんな感覚がある。

「はい、コイン落としが作れましたね?」


いや、別に素材を自分で全部作れっていいたいわけでもないし、
「全部自分で作れ」ってんなら、そうやってミドルウェアに頼ることすらせずに「無」からゲーム作れってことになるんだろうけど、
そこまで言いたいわけでもない。


でもやはり自分としては、
「根っこの部分」

「このキャラ歩きシステムはどういう仕組みで動いているのか?」

そういう根っこのプログラムの部分を
自分で作ってないくせに、どうやって動いてるのか、自分でコードを理解してないくせに、
そういう「キャラ動かし用」のスクリプトを持ってきて、それで「動いた動いた」とやってる姿勢が、

自分の思うゲーム作りからはかけ離れてるように感じるワケですよ。



というわけで、やはりアニマルメーカーをunityに移植して、
それをキャラクター操作の基礎として始めたい、というのがある。


それ以前にも アニマルメーカーには物凄いメリットや応用性があると思っている。

あらゆる形式の動物を自機としても敵としても配置可能。 リアルタイムにも編集可能。
(unityでは、ヒューマノイド型を基準にしか考えられんであろ?)
(そしてそれ以外の形状の動物やモーションは、イチイチなんか落としてこないといかんであろ?)

そして四肢切断や、びっこ引き、部位破壊なども完璧に実際的に表現できる。
 (擬似的な表現ではなく、本当に足の機能が落ちたことによりびっこを引く、ということを表現できる)

モーションの滑らかさなども段違い。

段差クッション、走り、歩き、ジャンプ、しゃがみ、しゃがみ歩き・・・
それらかける、注視移動、旋回移動、平行移動の組み合わせが、どうきても、対応可能。

それらを、アニメーションコントローラーとか入れなくても、
いやそんなシステムよりもよっぽど滑らかで自然に、色々な挙動を表現することが出来る。




(例えばユニティちゃんがしゃがみながら後方斜め右にすり足しながら切り上げ攻撃をする、みたいなこと、簡単にできるか?)
(アニメーションコントローラーや「アニメーションマスク」とかで頑張れば出来るだろうけど、)
(でも、そもそも「しゃがみ右後ろ斜め歩きのモーション」なんていうニッチなモーションがなければ、作れないだろう)
だが、アニマルメーカーなら、自動的にそういうモーションが出来る!



・・・
とにかく、アニマルメーカーを移植してしまえば最強だろう、そんな感覚があったのです。


で、やってみる前に、
まず、アニマルメーカーが根っこのところで何をやってるのか、というのをちょっとだけ紹介してみよう。



本質は、「伸び縮みする棒」の制御なのです。


↓アニマルメーカーのキャラの足に、「力の元のなる部分」を表示させてみると、こうなってるのです。

アニマルメーカー





この「棒の先端」に注目すると、先端は「楕円」の動きをしていることがわかると思う。 

これ、これを思いついたことが全ての始まりでした。


で、この棒が地面にめり込んだ時、その「めり込んだ量の分の力」が、「逆に全身にかかる」ようにしているのです。

これが、「踏み込みの力の変化」の表現になってる。

アニマルメーカー

地面との最終接点が、実際のかかとの位置となる。 (その分足は縮んだことになる)

そして、「膝の方向ベクトル」というのも計算しておく。

で、足の縮んだ分の量だけ、膝方向を伸ばしていく。 これが、自分が考えた、自作IK(インバートキネマティクス)ということです。
(黄色い矢印が、膝の伸ばすべき量)



つまり、
「地面の下側」としては、変化する足の蹴り込む力の伸びとして、
「地面の上側」としては、足を縮めて戻す動きの先端として、
すべてが「円の動き」に帰結するのです。

これってなんか凄くないですかと。


大体基礎がこんな感じ。
これが基礎となって、アニマルメーカーは動いているのです。

アニマルメーカー

この基礎があるから、この接地感、物凄いなめらかな挙動変化、そういうのが実現できてるのです。

例えば、この円運動のY軸を更に回転させたりすると、平行移動とかも物凄い滑らかに表現できたりする。
そういう機能をどんどん付けていく。


根っこが凄いシンプルだから、壁を這うとかの拡張性もある。

・・・
我ながら、そうとう凄いことしてきたような気がしてきた。


で、これをなんとかunityに移植したいところなんだけど、
これが上手く行かない。
既にできてるんだから、そのまま同じことやりゃいいだろうと思うだろうけど、そうもいかんのです。


てか、どうせやるのなら、さらにさらに拡張性のあることをやりたい。


アニマルメーカーでやってる「地面と足のめり込みの衝突判定」ですが、この段階では凄いシンプルでした。
地面が平面だったので、y=0 より下の量だけ、全身にかかる力とすればいいだけでした。

これを、実際の3Dゲームとしても使えるようにするために
かなり特殊なことをしていました。

自分が「アニマルメーカー」→「地形メーカー」でやったこととして、
地形をある種のパターンに落とし込んで、その地形上に xとzの座標を打ち込めば、そのままyが計算出来るような、
そういう関数のようなシステム
でやってたのです。
ラプトル



ここんところを、どうせunityでやるのなら、
そんな四角いブロックと、数種類の決まりきった板ポリの柱だけで構成されている背景じゃなくて、

坂の柱


もう、普通の背景のポリゴンと、足の棒のめり込み量、それを常に計算できるようにすれば、
物凄い便利だろうと考えたのです。


その辺についてはここでもちょっと書いた。 もう地形との簡易判定モデルとか考えなくていいようにしたい。


で、unityはじめました

unity 最初の歩行システム


最初期はこんなでした。


実際に足を回転させて、その「摩擦」で歩くシステムができないか考えてみました。

リジッドボディの足を回転させたときの反発や摩擦だけで歩けたら、まぁ一番自然だろうと思ったんですが、駄目でした。

全然上手くいきません。



unity 次の歩行システム

次は、足の先端に「コライダー」を付けて、
そのコライダーが地形に衝突したとき、その最後の位置との差を、全身に伝えるようなシステムをやってみました。

4足にも対応できる歩行システム

歩きだしましたね。
これを少しずつ改良していって、
まぁここまで 実際足を自由に増やしたりして、色んな形状の動物も作れそうなとこまではいったのです。

インスペクターで長さ角度管理

パブリックな変数をいじれば、リアルタイムで足の長さや角度をいじったりすところも、できてはいるのです。
こりゃアニマルメーカーです。 いいとこまでは行きました。


でもやっぱり、まだまだ駄目でした。

これ、高い壁際とか崖とかに行くと、とたんにボロが出ます。


最後の歩行システム

最後に、足の根っこから 足の先端に RAYを撃って、そのビームが地形に刺さったとき、
「根っこからその当たった位置までの距離」が 「足の長さ以下」だったとき、「地形に足がめり込んだ」ということだから、
その分の量を全身に伝える
、そういうシステムを作ってみました。


で、もうこの段階で、平行移動操作も導入できてるし、
簡易ながら、IK (膝の位置の計算)とかも始めています。
 (膝のとこにある白い球が、膝の位置)




こうやって、テキトーに配置した「球」だろうがなんだろうが、その上を、問題なく歩けるようになってます。
これが、「背景モデルを組めばそのままその上を歩いていけるシステム」に繋がる筈です。



これが一番上手くいくべきだと思ったんだけど、やはりまだまだ挙動がおかしいのです。


こうやって、上手くいってそうな動画だけgifで貼ってると、なんか着実に進んでるように見えるかもしれませんが、
実際は全くそんな気分にはなりません。


本当に、上手くいかん、なんでこんなに上手くいかんのか、という
やってられんフラストレーションまみれなのです。



まぁそんな感じで、移植が上手くいってません。

どうすればいいのだ。

が、それ以前の問題も発覚しました。


ビルドができないのです!!!

上手くいかないなりに、
そろそろ「WebGLで公開してみるテスト」のほうもやってみようかと考えたのです。


でも、なんか知らんけど、エラーでビルドができません。


「フォルダを選べ」と言われるから、選んで、ビルドしようとする。数分待ってから、なんか終わってるっぽい。
でも見に行くと、フォルダの中身は空っぽ。 「build and run」を選んでも同じく無駄。 意味が分からん。


と に か く webGLでビルドができない。 
(ローカルのexeのビルドなら出来るし、そこではちゃんと動くので、プログラム的には間違ってはなさそうなのに?)


あと自分のunityのバージョン5.6では webプレイヤーとしてのビルドもできない。(これはそもそも選択肢が存在しない)


あんまりにもビルドが上手くいかないので、
なんか調べてたら、

そういうときはunityクラウドでビルドしてもらうのがいいよ、とか書いてあるのを見かけたので、
その通りにビルドしてもらったんだけど、


今度は、そのビルドした奴、自分の思った挙動とは全然違う動きをするのです。 なんかライティングもおかしいです。

・・・
意味が分からん。 さっきも言ったけど、ローカルのexeとしてビルドは出来るし、そこではちゃんと動くのだから、
これはもう unityのwebGLのビルドがおかしいことになっとるとしか思えません。


・・・まぁそんな感じ。


2つの大問題があるのです。


・アニマルメーカーの移植が想像以上に激ムズ!

・webGLのビルドが全く上手くいかなくて試作品すら公開できそうにない



前者は、自分の能力不足です。
「自分のやりたいこと」と「自分の技術・理解度」が釣り合ってないから、こういうことになるのでしょう。
 (もう諦めて簡単な2Dのゲームでも作るか?)


後者は、自分が悪いとは思いたくない。 unity側がなんかおかしい。
そんで、前にも言ったけど、ウェブ上で公開できなきゃゲーム作る意味ね~と思ってるので、これはかなりの問題ですね。
 (こうやってgif動画ばっかり貼ってるのにしたって、自分としては不本意なんですよ)



・・・そんな調子なので、unityやるモチベ、いきなり、かなり無くなって来ました。
ここまで上手くいかないとは・・・


これはもう、ちょっと一旦諦めて、やっぱ放置してるゲーム (いい加減トロッコゲー)に戻ろうかと思いました。


そういう話です。 そういう報告でした。 

やっぱなんだかんだで unity難しいよ。 


なんかこういう、どうしたらいいのかサッパリ分からん壁にぶつかり続けるとさぁ、

誰か、unityのすべてを分かってるような神のような人に、手取り足取り全部教えて貰いたいような気分にもなってくるよ。

そういうのが勉強会なんだろね。 そういうのが出来る人を羨ましくも思うよ。

[ 2017/07/02 11:25 ] 自作ゲーム開発 | TB(0) | CM(5)

Unityはじめました話


プチ一念発起。

ということで最近実は、Unityの勉強してたりします。 (今更)


今までさんざ渋ってたくせに、なんで今さらunityに手を出したのかというと、
まぁ色々ある。

なんかニコニコ生放送のページがついにflash捨てて完全にHTML5に移行してるのを見たのもあるし、
とにかく今のままじゃ自分のゲームは重すぎて自分のやりたいことなんか一生実現できないと痛感したのもある。

(更にここで、unityUEだったら自分の性に合ってるのはどっちなんだ?みたいなのもあったんだが)

・・・
まぁそんな感じで覚えようとしてるんですが、やっぱ難しいかも。

いや、結局スクリプト系だからASに似てるとも言える。知らんけど。
でも、分からんことはさっぱり分からん。

そういう話をする。

てか多分、今回は殆どParaFla!の話になるかもしれん。
 (多分これが自分がparaflaについてグダグダ喋る最後の機会になるかもしれん)


◆Unityをちょっと触ってみて思ったこと。 触感。感想。

actionscriptに似てると思ったトコ。それなりに多し。

あこれ、
onClipEvent (enterFrame) みたいなもんじゃーん。
onClipEvent (load)みたいなもんじゃーん、
ってな感じだったので、そこら辺は似てると思った。

なんだかんだでこの、「スクリプトをアタッチしていく感じ」というのは、すっごい慣れてる。


でもむしろ痛感したのは、
「ASってやりたい放題だったのだな~」ってこと。
これがよくわかった。


actionscriptは本当になんでも出来た。 滅茶苦茶である。


例えば
「子供のあるスプライト上に記述したスクリプト」から、
「親のスプライトが持ってる変数」をちょっと見たい場合とか、

_parent.hoge
とかで、あっというまにアクセス出来る。

_parent.hoge++;
とかで、イキナリ書き込めるレベルである。本当に、コレで動く。


で、その「hoge」が何なのかすら調べる必要もない。
型を気にしないとかいうレベルではない。

そもそも
そのhogeが変数名なのか、関数名なのか、いや単にスプライト名だったするのか、
そもそも存在するのか
そんなことを全く気にしない。 

_parent.hoge(); とかで、hogeが関数なら、その関数をいきなり動かす。
_parent.hoge++; とかで、hogeが変数なら、イキナリ足す。
_parent.hoge._rotation=90; とかで、hogeがスプライトなら、イキナリ回転する。


なるようにしかならん。
全て、よきにはからってくれる。
とにかく、全くコンパイラが怒らないのである。

この辺、ASのフリーダムさって凄かったのだなああああ
てか自分は、相当甘やかされてたんだな~、というのが、よーくわかりました。


◆_parent . hoge話


ここんところが、unityだと
まず最初に使う変数の宣言。型指定。
private GameObject oya;

最初のフレームで、それを使って親を指定しておく。
oya = transform.parent.gameObject;

そんでその親が持ってるスクリプトを、GetComponentで取ってこないといけない。
PlayerCon oya2 = oya.GetComponent();

これで、ようやく、
oya2.hogeにアクセスすることで、oyaに記述されたスクリプト上の変数だとかを読めるようになる。
(それも、直接読みたけりゃ、親の変数がスタティックだとかもある)


自分の感覚からすると、ホント大変になった。


_parent.hogeだけで、イキナリ読めたんだよ。なにこのフリーダムさ。


ASだと、変数に型宣言とかスタティックとかもなかったようなモンだとおもう。
(自分がそう理解してただけなんだけど)

intって言った変数に、0.5とか足してもなんの問題もなかったと思う。
(これからはunityに怒られる)
(てか、0.5fって書かないと怒られる)


存在しない変数を読もうとしても、別にundefinedになるだけで、止まらない。
コンパイルエラーもない。

・・・
・・・とかとかとか、
とにかくASはやりたい放題で、その点はマジで楽だった。


ま、その辺テキトーだからこそ、逆に、作ったもの自体はすっごい重いんだろうなぁASは。

(つまりこの、プログラマ側が全く宣言や指定をしなかったhogeの正体がなんなのか、)
(イチイチ呼ぶ毎に調べるような必要が内部的にあるってことじゃなかろうか??)
(故に、いざ実行したときのスクリプトの処理が糞重い、と)


はい。そんな感じ。


でも、だからって
そんなにAS2.0でのゲーム作りが楽だったわけでもない。 
◆いややっぱ、むしろ色々と大変すぎた面の方が大きいはず。



カマキリゲー
↑例えばだ、3Dのシューティングゲームで「こういう弾」が飛んでくるとしよう。


カマキリゲー

「これをどうやって実際に画面上に表示するか」
それだけのことで、ASで、paraflaでこれをやるのは結構大変だったんだ。
 (いや、2Dのシューティングのフラゲを作るのなら、ラクショーだよ?)


まず弾の座標が、x,y,zとあったとしよう。

これをどうやって実際のカメラ上の位置として変換するか?

勿論、自力である。

ルートの角度、Xrot,Yrotみたいなのを自分で作る。そいつのcos,sinを常に計算。
まずは、遠近感抜きの、「回転としての変換」を考える。

(1,0,0)(0,1,0)(0,0,1)の頂点が、実際の画面上としての_xや_yとしてどう変化するか、
そして、画面との距離zがどうなるか、それらを変換する用の変数を作る。

Xsin=sin(Xrot);
Xcos=cos(Xrot);
Ysin=sin(Yrot);
Ycos=cos(Yrot);
xx = -Ycos;//xが1増えるたびにxがいかに増えるか
xy = -Ysin*Xsin;//xが1増えるたびにyがいかに増えるか
xz = Ysin*Xcos;//xが1増えるたびにzがいかに増えるか
//yx = 0;//yが1増えるたびにxがいかに増えるか(未使用)
yy = -Xcos;//yが1増えるたびにyがいかに増えるか
yz = -Xsin;//yが1増えるたびにzがいかに増えるか
zx = Ysin;//zが1増えるたびにxがいかに増えるか
zy = -Ycos*Xsin;//zが1増えるたびにyがいかに増えるか
zz = Ycos*Xcos;//zが1増えるたびにzがいかに増えるか


↑それがこういう呪文になる。
(これは全部自力で考えた)(実はこうするのがベストなんじゃないかと)


function henkan(x,y,z) {
x-=rx ;y-=ry; z-=rz;
x2 = xx*x + zx*z;
y2 = xy*x + yy*y + zy*z;
z2 = xz*x + yz*y + zz*z;
p2 = p/(p+z2);
return {x:x2, y:y2, z:z2, p:p2 };}


で、こういう関数をルートに作っておく。

(rx,ry,rzっていうのは、ルートの座標位置ね)
(これを引くことで、相対的な位置となる 「カメラ位置」みたいなもんである)

で、この関数にxyzを入れると、カメラ角度で変換されたxyzと、「p」という遠近感用のパラメータが手に入る。

この遠近感を、回転されたx2、y2にかけて倍率かけると、実際の_x _yに指定すべき位置が分かる。
で、
_x = x2*p2; _y = y2*p2;
_xscale = _yscale = 100*p2;

こうすることで、実際の、flashとしての位置指定、_x _yに、3D変換された位置とか大きさとかを指定出来るわけ。

・・・
こういうシステムの構築を全部自分は自力でかんがえてた。


でもコレだけでも足りない。
これだと「点」としての表示にしか使えない。
今回表示したいのは「線」のビームなので、「先端」も計算しないといけない。


が、イチイチビーム一個に、先端の向いてる方向やら、その方向がフレーム毎にどう変化したかやら、
全部計算してると、もう重すぎてやってられない。

自分の場合は、「前のフレームの自分自身の位置」を利用させてもらった。

これをoldx,oldyとします。

これは、フレーム処理の最後に自分の位置を保存しておけば、
その位置をさっきの関数にぶち込んで得られるの位置を利用して、ビームを傾ける角度が求められるわけである。


それでどうやるか?

それはもう、こうやって差分を計算する。
ビームの計算

そしてその差をatanにぶち込むと、角度がでる。

_rotation = (180 / Math.PI) * Math.atan2 ( yy / xx );

こいつを_rotationにぶち込めば、flash的には素材の回転ができる。

差分を使って、ピタゴラスの定理的に、ビームの伸びるべき長さも分かる。

_xscale = 100*Math.sqrt( xx * xx + yy*yy );


「長さ」は出来た。 じゃあ「太さ」は?
太さに関しては実はもう終わっている。 さっきの、_yscale = 100*p2;というやつである。

・・・
・・・
こんなである。
2Dのactioinscript2.0で、paraflaで、flashで、
無理やり3Dのゲームを作ろうとしたら、
ビーム一本でも、これくらいのことは自力で考えないといけなかったわけである。

(そしてこの自分自身の古い座標をみて表示方法を考えるやりかたは、「ビームが飛んできてる時」にしか使えない)
(ビームが地面に突き刺さった時とかは、また別のやり方を用意している)


ビーム一本でこれだし、
ビームの当たり判定にしても、なんかやり方を自分なりに考えてた。

他にも
テクスチャの貼り方、テクスチャの頂点の求め方、地形の構成、テクスチャの更新・・・
本当に、何から何まで・・・
自分はそういうことをずーっとやってきたのです。

3D用のソフトじゃないのに3Dのゲームを作るのがどんだけ大変だったか。


思えば、
エフェクトも自力で作る・・・
モーションも自力で作る・・・
地形作成ツールも自力で作る・・・
ロコモーションシステムも自力で作る・・・

それら全部、自分用のソフトを自分で作る所から、やってきてたワケだ。

(本当に、paraflaだけで3Dゲームなんか作ろうとするのは地球上で自分だけなんじゃないかとか思ったりする)

「最後のバカ」だったんじゃなかろうか)


(その「最後のバカ」がついに諦めた という話じゃないのか?これは)

(いや、これからもflashコンテンツは作ると思うけど)

・・・
でまぁ、
unityならもう、そんなことは一切考えなくてよくなるわけです。


本当に、「ビーム」なら、
考えるべきはビームの挙動のスクリプトと、あとはビームの見た目でも作ること。
当たり判定? カプセルコライダーでもアタッチすりゃそれで一発だ。
そんだけのことでしょう。

どうやってビームを実際に画面上に表示するかなんて、プログラマ側が意識することなんか一切ありません。

(つーか、普通のゲーム開発ソフトなら、unityにかぎらずまぁそうだろう)

(いやどうかな? 昔は、それでもみんな、テクスチャ一枚貼るのに色々準備必要だったんじゃないかな?

(まぁそれにしたって、「やりよう」みたいなのはこうやってネット上にいくらでも見つかるだろう)

(でもparaflaで3Dのゲーム作ろうとすると、先人とか完全にゼロだから、結局全部自力で考える必要があったということ)


・・・

じゃあ、「そんな大変だったアピール」と、その大変さから開放されたってんなら、
これからの自分は超高速でサクサクゲーム開発出来るのかというと、
多分、そんなことはないと思うのです。



やっぱしunityはunityで、色々と上手く行きません。
次回にはそういう話をすると思う。


今回も、もうちょっと続く。


で、unityで最初にやったことは、
チュートリアルの動画とか真面目に聞きながら、
思いっきりそのままチュートリアルの玉転がしとか作ってみたんですよ。

(この辺のことをバカ正直にやるのとか、自分としては珍しいくらいだろう)
 (でも実はこれにも意味はある。 下の「ビルドの話」に続く)


でまぁ、ちょっと弄って「塊魂」みたいなやつにしてやったのですよ。

塊魂モドキ

でもこの動きには不満がある。
塊魂の本当はこうじゃない。ちょっと動きが違う。

これ、触った瞬間に「子」になるようにしてるわけだけど、
そんで、y座標が地面より下にきたら、その差分を「親に足す」ようにしてるんです。

それで、塊魂感を出そうとしたんだけど、これでは足りない。

てかそもそも、「子」になった時点でコリジョンとかがなんか「親」に追加されたりはしてない気がするんですよね。

これは誰でも考える事らしく、
自分以外にも同じように、チュートリアルを改造して塊魂にしようとした人はいたらしくて
こんなのがあったんだけど、これは子供に地面との当たり判定がなくなってるので、塊魂になってないですね。


どうなのこれ。 結局、unityでは塊魂も作れないのか?


次やったこと、
まぁ安直に、ユニティちゃんを歩かせてみました。



で、これで思ったことは、やっぱり、ユニティちゃんは「旋回時の固さ」がひっどい

自分がunity製のゲームに触れて、いっつもいっつも思うことがこれでした。
自分で作ってみても、やっぱそうでした。

なんなのこれ。

マジで歩かせる気失せると思う。

みんなあれに疑問を抱かないの?



あとはちょっとした段差を登ったり下ったりしたときの挙動。
これも、非常にテキトー。 ヒョコっと瞬間移動してる。
ユニティちゃんの段差昇り降り


自分のがまだマシだと思ってます。
アニマルメーカーの段差昇り降り

足を引っ掛けて段差に登る挙動、
足をクッションにして高所から落ちる挙動。


そういうのは、アニマルメーカーなら、
なんのモーションすら用意しなくても、
なんのアニメーションコントローラーなんか入れなくても、
自動的にそういう挙動をリアルタイムでやってくれるのです。


よって、unityにアニマルメーカーのシステムを移植したいという話も次回でしたい。


・・・で、こんな風に「ついにflash諦めた unity始めます」ってだけの話でもないのだ。


◆個人的unityの一番の問題 容量 置き場

自分的にunityの一番の問題は、ビルドしたゲームのサイズがアホみたいにでかくないか?ということ。

例えばまさに
↑さっきの「玉転がしのゲーム」、ビルドしたら17メガバイトの容量になりました。

なんじゃそりゃ。 なんでこんなアホみたいにシンプルな玉転がしの実行ファイルが、17メガにもなるんだよ。


今まで自分がparaflaで作ってきたゲームとかプログラムとか、全部1メガに収まってます。
全部そのようになるようになってます。


地形を2次元配列だけで編集、再現できるようにするだとか、

ドット絵のテクスチャを限界まで減色するだとか、

あと、内部にモーションデータなんか一切持たなくても、
ありとあらゆる動物の歩き走りをリアルタイムに生み出せるシステムにするとか、

そもそも、flashのパス絵は素材として滅茶苦茶軽いとか、
・・・

そういうことをしてるからこそ
フラッシュゲームは滅茶苦茶軽い容量に収めることが出来るし、
webページに貼り付けやすいし、すぐに遊べる。

そういうのがあった。

(が、まぁ自分のゲームの処理の重さに耐えかねて、今こうして鞍替えをかんがえてるワケだけど)


でもまぁ、unityにアニマルメーカーを移植して、
ゲーム容量も軽いし、
そして処理も軽いゲームになれば万々歳だなぁ
と思ってたワケですよ。
(アニマルメーカーはモーションのデータだとかを用意する必要がないので)

それなのに、試しに、アホみたいな玉転がしのゲームをビルドしてみたら、
17メガですよ。

(シンプルなゲーム、素材の少ないゲームなら、ビルドしても軽いだろうと思っていたのだ・・・)


いっつも言ってるけど、
自分のサイトには1メガのファイルしか置けないんですよ。


これは自分的には大問題です。
じゃあどうすんのよ、と。

どっか他所に置くのか。

「unityでアップローダー」といえば、まさにこのサイトが有名だけど、
ここ使うの?


でもなぁ~、
なんというか、自分としては、
ここには「完成品しか置けないっぽい感じ」があるじゃん。

(少なくとも自分はそう勝手に思っている 他人様のとこなんだから、作りかけのゴミを置くべきではないと)



本当に、テスト用のプロジェクトとか、「そういうのを気軽におけるような場所」ってないの?


flashが自分の性に合ってたのは、まさにそこもあると思ってるんですよ。

「今こんなの作ってます」って、
そういうのをブログ上にすぐに貼れる。 めっちゃ気軽に貼れる。
それで、もうその場で触って貰えばいいし。


・・・どうもこの辺がよく分からんのよな。
みんなどうしてるわけ?


他にも。
なんかさぁ最近、「フリーゲーム作りました!」つって見に行ったら、
iOSがどうの、
Google playがどうの、
アンドロイドがどうの
とか、そんなんばっかじゃん。 アレ何?


そういうんじゃなくて、なんでブラウザ上ですぐ触れるようにしないんだろ。


自分としては、ゲームというものは、(とくにフリーゲームってんなら)
作ったらすぐに触れる場所に、すぐ触れるような形で置いておきたい。
 (だから何度も言うように、flashが凄く合ってたワケだ)


よってunityも、web playerとして置きたい。

でも、なんかchromeも、もはやunityをweb playerで動かさせる気ないよね。

あら?
だったら結局flashもunityも、「chrome八分」されてるという点では、同じじゃないか?とか思ったりする。

(でもなぁ、こういうデモはchromeからでもイキナリ遊べたりする)
(自分はこういうのをやりたいんだよ)


そんな感じでした。

自分がunityを極められるのはいつの日か。


♪クラッシュバンディクー極めたが マリオカートが大流行

 (↑自分の人生を表した替え歌) 
  ((parafla極めたが・・・))
 (そして自分がunity極める頃には、また別の何かが流行ってるんじゃなかろうか)



[ 2017/06/12 15:39 ] 自作ゲーム開発 | TB(0) | CM(6)

利きゴジラ作り中 またはゴジラ分類学


恥ずかしい駄文は速攻で流すに限る。

「利きゴジラ」のゲーム が、半分くらい出来た感じです。

今んトコこんな感じ。 結果は出ないけど、一応もう遊べますよ。



とりあえずランダムに各ゴジラ作品の画像を出して
それを当てていくクイズにする感じ。 まぁそんだけのことです。

画像はこれから充実させていきます。一作品に10枚は用意したい。
今は、とりあえずの3枚なので、今が実質一番難易度の低い状態になっていると思います。
とりあえずのポスターからの画像とか、分かりやすい画像のチョイスばかりになっていますんで。

プログラム的に難しいことは何もないけど
まぁ一応動くようになりましたねって感じの報告です。


で、「作品あてクイズ」のほうは別に問題ないのですが、
問題は「ゴジラあてクイズ」の方です。


このゴジラの分類法、人によっては異論があるんじゃないか
そういうことが気になって仕方がない。


マニアのためのめんどくせー話になります。 ていうか無駄に悩んでるだけです。

[ 2016/08/30 18:42 ] 自作ゲーム開発 | TB(0) | CM(2)
月別カレンダー
09 ≪│2018/10│≫ 11
- 1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30 31 - - -