ニートが頑張るブログ

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

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(4)
私はUnityは使わないので具体的なアドバイスは
致しかねるのですが、HTML5でビルド出来るのであれば
ゲーム投稿サイトを利用するのが手っ取り早いのではないでしょうか?

私自身はPLiCyを利用してます。サイトにHTML5でビルドした
ファイルをアップロードすれば勝手に最適化してくれるので
少々重たいゲームでもサクサク遊べますよ。
さすがにHTML5はflashとではスピードが違います。
数十年の技術格差は伊達じゃないです。

さらに勝手にブログなどに貼り付ける
コードも作成してくれるので、それをコピペして
こちらに貼り付ければわざわざPLiCyに誘導しなくても
直接ブログ上で誰でも遊べます。
(PLiCyでの公開を非公開にすればブログでしか遊べないようにも
できます)

私自身は40M~100Mくらいのゲームを複数公開してますが、
重いと言う苦情はまったく出ませんね。
それだけHTML5の技術は優れているのでしょう。

もちろん全て無料。実質的に自分のサーバーに
一切負担をかけることなく手軽に公開できるので
試してみる価値はあるのではないかと思います。
[ 2017/06/22 19:53 ] [ 編集 ]
コメント返信
> 藻屑 さん



> 私自身はPLiCyを利用してます。サイトにHTML5でビルドした
> ファイルをアップロードすれば勝手に最適化してくれるので
> 少々重たいゲームでもサクサク遊べますよ。

> さらに勝手にブログなどに貼り付ける
> コードも作成してくれるので、それをコピペして
> こちらに貼り付ければわざわざPLiCyに誘導しなくても
> 直接ブログ上で誰でも遊べます。
> (PLiCyでの公開を非公開にすればブログでしか遊べないようにも
> できます)


おおこれはありがとうございます!
自分の理想通りのサイトかも。
まずはブクマします。


ただここも試作品みたいなものを転がしておいていいのか分からんので、(非公開にせよ)
やはりまずはアニマルメーカーの移植をなんとかしたいところですねー。


> 私自身は40M~100Mくらいのゲームを複数公開してますが、
> 重いと言う苦情はまったく出ませんね。
> それだけHTML5の技術は優れているのでしょう。

おおお?
そこで既にゲーム公開してるのですか!?
どんなゲームなのか聞いてみたいところですが、聞いていいべきなのかいかんべきなのか、悩ましいところですね。

(本当にこういうのは、ヤマアラシのジレンマなのです)




てかそのPLiCyというサイトなら
UnityのwebGLをそのままアップできそうですねー。

(なんかまだ、見たところ数個しかアップされた作品はなさげですが)



というわけで良さげなサイトを教えてもらいましたありがとうございます。

[ 2017/06/23 14:57 ] [ 編集 ]
管理人のみ閲覧できます
このコメントは管理人のみ閲覧できます
[ 2017/06/23 18:22 ] [ 編集 ]
コメント返信

> 藻屑 さん


うわ答えてくださってるのに遅れました。


(聞いておいて返事送れるとか、いや、いつものことですが)
(本当に自分は自分のブログ一週間に一回以上みたくないので、更新するときでもないと、こうなってしまうんです)



うおー
教えてくださってありがとうございます。


いやー結構凄いですね。
凄くて良かったです。
 (ネット上のこういうやり取りというのは相手の人が凄くないと駄サイクル感が出てきますからね)


そのアクアリウムの奴とか、自分の思う「おもちゃ箱感」に近いですよ。
http://www1.kiy.jp/~yoka/gameland/aquarium/aquarium_swf.html
これよかすごいです。



水中でゴボゴボしてるやつも、なんか可能性を感じますね。 (リョナ的なw)
でもこれchromeじゃ方向キー効かん感じですね。




> (それも抵抗があるなら非公開にしてブログ限定にすれば
> 誰に知られることもなく気分を害する人は一人もいません)


なるほどー
ではやはりそんな感じでまずは物置に使ってみたいですね。



> 応援してますので私に分かる範囲の情報は
> なんでも提供します。


ほんとどうもです。
でも本当に、いくら応援されてもなんかこう「自己肯定感が溜まってこないと何も出来ない感じ」がするんですよね。

本当に、応援されても自己嫌悪でなかなか動けなくて申し訳ないって感じです。

[ 2017/06/27 12:28 ] [ 編集 ]
コメントの投稿












管理者にだけ表示を許可する
トラックバック
この記事のトラックバックURL

月別カレンダー
09 ≪│2017/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 - - - -