プチ一念発起。
ということで最近実は、
Unityの勉強してたりします。 （今更）
今までさんざ渋ってたくせに、なんで今さらunityに手を出したのかというと、
まぁ色々ある。
なんかニコニコ生放送のページがついにflash捨てて
完全にHTML５に移行してるのを見たのもあるし、
とにかく今のままじゃ自分のゲームは重すぎて自分のやりたいことなんか一生実現できないと痛感したのもある。
（更にここで、
unityとUEだったら自分の性に合ってるのはどっちなんだ？みたいなのもあったんだが）
・・・
まぁそんな感じで覚えようとしてるんですが、やっぱ難しいかも。
いや、結局スクリプト系だから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でのゲーム作りが楽だったわけでもない。
◆いややっぱ、むしろ色々と大変すぎた面の方が大きいはず。
↑例えばだ、
３Dのシューティングゲームで「こういう弾」が飛んでくるとしよう。
「これをどうやって実際に画面上に表示するか」それだけのことで、ASで、paraflaでこれをやるのは結構大変だったんだ。
（いや、
２Dのシューティングのフラゲを作るのなら、ラクショーだよ？）
まず弾の座標が、
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に、３D変換された位置とか大きさとかを指定出来るわけ。
・・・
こういうシステムの構築を全部自分は自力でかんがえてた。
でもコレだけでも足りない。
これだと
「点」としての表示にしか使えない。
今回表示したいのは
「線」のビームなので、「先端」も計算しないといけない。
が、イチイチビーム一個に、先端の向いてる方向やら、その方向がフレーム毎にどう変化したかやら、
全部計算してると、もう重すぎてやってられない。
自分の場合は、
「前のフレームの自分自身の位置」を利用させてもらった。
これを
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の一番の問題は、
ビルドしたゲームのサイズがアホみたいにでかくないか？ということ。
例えばまさに
↑さっきの「玉転がしのゲーム」、ビルドしたら
１７メガバイトの容量になりました。
なんじゃそりゃ。 なんでこんなアホみたいにシンプルな玉転がしの実行ファイルが、
１７メガにもなるんだよ。
今まで自分がparaflaで作ってきたゲームとかプログラムとか、全部
１メガに収まってます。
全部そのようになるようになってます。
地形を２次元配列だけで編集、再現できるようにするだとか、
ドット絵のテクスチャを限界まで減色するだとか、
あと、内部にモーションデータなんか一切持たなくても、
ありとあらゆる動物の歩き走りをリアルタイムに生み出せるシステムにするとか、
そもそも、flashのパス絵は素材として滅茶苦茶軽いとか、
・・・そういうことをしてるからこそ
フラッシュゲームは滅茶苦茶軽い容量に収めることが出来るし、
webページに貼り付けやすいし、すぐに遊べる。
そういうのがあった。
（が、まぁ自分のゲームの処理の重さに耐えかねて、今こうして鞍替えをかんがえてるワケだけど）
でもまぁ、unityにアニマルメーカーを移植して、
ゲーム容量も軽いし、
そして処理も軽いゲームになれば万々歳だなぁと思ってたワケですよ。
（アニマルメーカーはモーションのデータだとかを用意する必要がないので）
それなのに、試しに、アホみたいな玉転がしのゲームをビルドしてみたら、
１７メガですよ。（シンプルなゲーム、素材の少ないゲームなら、ビルドしても軽いだろうと思っていたのだ・・・）
いっつも言ってるけど、
自分のサイトには１メガのファイルしか置けないんですよ。
これは自分的には大問題です。
じゃあどうすんのよ、と。
どっか他所に置くのか。
「unityでアップローダー」といえば、まさに
このサイトが有名だけど、
ここ使うの？
でもなぁ～、
なんというか、自分としては、
ここには「完成品しか置けないっぽい感じ」があるじゃん。
（少なくとも自分はそう勝手に思っている 他人様のとこなんだから、
作りかけのゴミを置くべきではないと）
本当に、テスト用のプロジェクトとか、「そういうのを気軽におけるような場所」ってないの？
flashが自分の性に合ってたのは、まさにそこもあると思ってるんですよ。
「今こんなの作ってます」って、
そういうのをブログ上にすぐに貼れる。 めっちゃ気軽に貼れる。
それで、もうその場で触って貰えばいいし。
・・・どうもこの辺がよく分からんのよな。
みんなどうしてるわけ？
他にも。
なんかさぁ最近、
「フリーゲーム作りました！」つって見に行ったら、
iOSがどうの、
Google playがどうの、
アンドロイドがどうのとか、
そんなんばっかじゃん。 アレ何？そういうんじゃなくて、なんで
ブラウザ上ですぐ触れるようにしないんだろ。
自分としては、ゲームというものは、（とくにフリーゲームってんなら）
作ったら
すぐに触れる場所に、すぐ触れるような形で置いておきたい。
（だから何度も言うように、flashが凄く合ってたワケだ）
よってunityも、web playerとして置きたい。
でも、なんかchromeも、もはやunityをweb playerで動かさせる気ないよね。
あら？
だったら結局flashもunityも、「chrome八分」されてるという点では、同じじゃないか？とか思ったりする。（でもなぁ、
こういうデモはchromeからでもイキナリ遊べたりする）
（自分はこういうのをやりたいんだよ）
そんな感じでした。
自分がunityを極められるのはいつの日か。
♪クラッシュバンディクー極めたが マリオカートが大流行
（↑自分の人生を表した替え歌）
（（parafla極めたが・・・））
（そして自分がunity極める頃には、また別の何かが流行ってるんじゃなかろうか）
