ニートが頑張るブログ

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

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(4)

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


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

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

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



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

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

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


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


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


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

[ 2016/08/30 18:42 ] 自作ゲーム開発 | TB(0) | CM(2)

トロッコ問題プロジェクト、始動


なんで全然更新できてないんだ7月?
まぁずっとゲームは作ってるんだけど。

↓で、今こんな感じです。



Z 武器を振る 人を突き飛ばす ハシゴを登る スイッチを起動する
X ジャンプ

(「トロッコが来るぞーボタン」が妙にクリックしづらい不具合があります)




まぁつまりあれです。 「トロッコ問題」をモチーフにしたパズルゲームを作りたいワケですね。


もう現時点で、自作の問題をエディットできるところまではできています。


「トロッコ問題」についてはググれば分かるでしょう。

で、これ自体は6年くらい前から一気に有名になった概念かと思います。

「白熱教室」という番組で、
功利主義について考えるときの思考実験として紹介されてきた感じ。



このゲーム自体は 「トロッコ問題の是非」とか、「自分ならいざという時どう動くのか」とか、
そういうことを考えさせるためのゲームでは一切ありません。


とにかく設定目標に応じて 死亡人数以下になるように動くだけ、 
そういうパズルゲームにしようと思っています。


とはいえ
結果的に、トロッコ問題を更にめんどくさく考えるキッカケにはなるかもしれない。

トロッコ問題

例えば、今、殺傷系の武器で人間を突き飛ばそうとすると、死ぬようになっています。

じゃあデブを突き飛ばしてトロッコを止めなければならない時、
そもそも突き飛ばした時点でデブが落下死しちゃうようなケース、
つまりその時点で殺人罪が完全に成立している場合でも、
人間はデブを突き落とすべきなのか?


・・・みたいなことも考えられますからね。


まぁそんな感じ。


トロッコ問題という命を秤にかける要素

それプラス、「線路のややこしさ」という要素

それプラス、全作の「バナナゲーム」同様のギミックとアクションを仕込むことも出来ます。

どうなることやら。




ここから更に、
前提となるルールのバリエーションも、いくつか追加しようと考えています。


例えば、
◆人間の命に重みがあるパターンでのトロッコ問題

実際、「転落させるべきデブ」が自分の母親だったり子供だったりした場合、
それでもあなたはデブを突き落とせますか?
みたいな問いもあるわけですよ。

で、もし出来ないのなら、それはもう人間の命には重みがあるってことですね、ということにする。

ちなみにプレイヤーキャラ自身にも重みをつけるパターンも考えようと思う。


◆殺人トロッコ問題
これはもう全くの真逆。

できるだけ大勢の人間が死ぬようにするにはどう動くべきかを考えるパズルになります。

この場合でも命の重さに差をつけることが可能です。


◆臓器くじ問題
普通の人、デブ、母親、子供・・・以外にも、更に
「ドナー」「レシピエント」という要素を追加しようと考えています。


「レシピエント」は重病患者で、そのままほっとくと死ぬことにします。
全てのトロッコが停止したときに自動的に死ぬ存在、ということにします。


一方、
「ドナーカード」を持った人が轢き殺されると、内臓をぶちまけるようにします。
その内臓のエフェクトは全てのレシピエントに振りまかれて、レシピエントの病気が治ります。

その上でどう動くか、というパズルになる。

「トロッコ問題」と「臓器くじ問題」を一緒くたにしてしまう! そんなアイディアです。


◆エトセトラ エトセトラ
あと爆弾持たせたりしたいんだよね。 せっかくバナナゲーで作った爆弾だから。

爆弾をもたせた人をトロッコが轢くと、大爆発! デブじゃなくてもトロッコは強制的に停止する、と。
でもその周辺にいる人も死ぬからどうするか?みたいな感じ。
爆弾の移動が鍵となる。


・・・まぁそんな感じ。

今んとこどうかなこれ。

やっぱ、実際に面白いステージを作れるかどうかに全てがかかってる気はします。


この「トロッコ問題をゲーム化する」というアイディア自体は6年位前から思いついていたはずです。

今まで
だれも作らなかったのが不思議なくらいの題材だと思う。

https://www.pippinbarr.com/games/trolleyproblem/TrolleyProblem.html
↑ググッてみて、唯一見つかったのがこれです。 「trolley problem game」
それくらい誰も作ってない。

んでもってこれは、トロッコ問題について考えさせるための
ごくごく基本の導入みたいなモンであって、ゲームでは無いですね。



で、最初の時点では、もっと単純な、2Dの構図で
人間を突き落としたりレールを切り替えたりするだけのシンプルなゲームを想定していました。
でも、結局バナナゲームの派生で作るようになっちまいましたね。


これはどうなのか。

そもそも「主人公」をキーボードで操作する要素は必要なのかどうか。
今からでもマウスクリックだけでレール切り替えをするだけのゲームにすることも可能なんですけどね。
シンプルな操作のゲームのほうが流行りそうだけども。


でも、
主人公が実際に歩いていって、自分の手で人を突き落とす、
自分の行けるところでスイッチを切り替える、
その途中過程でトロッコに轢かれるかもしれない・・・

みたいな要素を入れるためには、やっぱし主人公操作要素がほしいところなのです。


で、ただのバナナゲーの派生なのに、その割になんでこんなダラダラしているのかというと
これでも結構内部的には変わってきているのです。


まず箱の挙動と箱の衝突判定を相当改造しました。

箱の移動に「最小単位」を用意するようにしてしまいました。
箱を押してみたり、武器で殴ってみるとわかりやすいです。 

つまり、箱の位置というのが常に「グリッド的」に収まるようにしてしまったのです。

こうすると、動きとしてはダサいけど、まぁ衝突判定は劇的に軽くなるのです。
結局こういう方向になっちまうんですよね。



あと操作性も、もっとシンプルにしようと思っています。 

ジャンプもこのゲームには必要ないかもしれない。
ジャンプを排除すれば、「今この通路にいるとトロッコに轢かれるしかない」みたいなことがシンプルにわかりやすくなるしね。


現時点ではスペースでダッシュする操作をなくしました。
こんなことだけでも調整が結構大変でして。

トロッコ問題
[ 2016/07/17 17:10 ] 自作ゲーム開発 | TB(0) | CM(2)

スライム凍結

 
最近やっとること。

しょうこりもなくゲームを作ろうとしています。

プロジェクト一個は潰れて、もう一個を作り中。


↓潰れたのはこれ。



前に言ってた奴。 
バナナゲーを元に、そこにラー油シミュレーターラー油を移植してきて、
「全ての敵がスライムのゲーム」にしようとしたやつ。


ラー油と違うのはY軸の概念が出てきたことですね。

スライムをドラッグしてみてほしい。
壁にへばりつけたり、段差を登らせたりすることができるようになってます。
スライムがちゃんと地形に合わせてヌルリと変形する感じは、ちょっと面白い。

スライム

あと一応、スライムのロックオンと、攻撃まではできるようにしました。

Xしゃがみからの、Z切り上げ攻撃をスライムに当てると、
なんかホットケーキをひっくり返すような感じがでます。
ロックオン状態で左右にカニ歩きしながら左右攻撃を当てたり・・・

スライム
(これはスクショが微妙 もっとふわっとできます)


・・・とかやってたのですが、 
なんかダメかな?という気がしてきたので、このプロジェクトは多分中止です。



もっと色々とやりたかったんだけどね。

なんかこう、DMC1のシャドウのコアみたいな動きしたり、
スライムの一箇所だけが突然尖って突き刺してきて、ミクさんの首に突き刺さって首が飛ぶとか、
そういうゲームが作りたかったもんです。

スライムだけのゲームでも、いくらでもやりようはあると思う。



何でダメなのか。
なんかやってみたら意外とスライムも重いなということと、
マウスでラー油をいじるのと違って、剣で攻撃したときに意外と自由に変形できそうな予感がしてこなかったことですかね。
つまり、このアクションではプレイヤーが思った通りにスライムを分断とか、どうも出来そうにない。
実際に移植してみたら想像以上にダメだった。



これがうまく行ってたら、
いろいろとエラソーなことがかけたんですけど。


例えば、「ゲームに出てくるスライム」についての話

ゲームに出てくるスライムって、こういう「単体」って感じのが多いワケですよ。
ダクソ1 スライム

予め決め打ちされた「ブヨブヨアニメーション」を再生するだけの「実は柔らかくない存在」なのです。
ダクソ1 スライム


・ちゃんと壁や地形にそって変形したり、
・へばりついたり、
・壁からデローって落ちてきたり、 (ダクソのスライムは上から落下してくるだけ)
・食らった攻撃にあわせてその通りにちゃんと変形をするようなスライム。
・スライム同士がくっついたり、ちぎれて分裂したり・・・

・・・
そんな「理想のスライム」がゲームに出てきたら、
もっとすごく気持ちいい&気持ち悪い存在になれたと思うのですが、そういうスライムってあんま見たことがない。

スライムがマジなゲームって無いもんかなぁ~
・・・
そういう話。


で スライムは諦めて
今作ろうとしてるのが↓こういうゲームです。

線路

5、6年前から温めてたゲームアイディアを、やっと作ります。

具体的に何を作ろうとしているのかは、もうちょっと形になってきてから書きます。 
(多分分かる人は分かってるだろうけど)


とりあえずレール素材を作りました。

レール素材

レールと草

こんだけの素材でも、作るの結構めんどいよ。

草の素材が8色、だからレールに8色しか使えん。
草の素材にこれを重ねて、視認性を良くするように草の方を思いっきり陰らせて、とかやる。

で、出来たこれを分割してテクスチャとして使うわけだけど、
その時は輝度を下げる方向にイジって使用するから、そういうのも見越した色加減にする、とかね。


レールうねうね

[ 2016/06/25 14:23 ] 自作ゲーム開発 | TB(0) | CM(9)

最高のパズルゲームとは



もう無視して
「今作ってるゲームのぼやき」 を、結局書いておきます。



・なぜこの程度のゲームがいつまでたっても完成しないのか

・というか一体毎日何をやっているのか

『内部的には変わった内部的には変わった』とか毎回言っているが、
 実際何が変わっているのか


・・・
などなどのことを、ちょっと分かりやすく説明してみる話。


[ 2016/02/01 18:29 ] 自作ゲーム開発 | TB(0) | CM(6)

エディットモード多分完成


とりあえず、何となく更新しておきやがりたくなる日です。


ゲームがここまで進みました。
と言ってもやはりまだ全然なんだけど。


エディタとしての部分が、いい加減、本当に完成したと思います。
UIとかはまだアレだけど (最終的に特に進歩しない可能性もあるけど)
これで、自分が作りたいと想定しているのと同じ形式の謎解きマップデータが作れるはずです。




swf直接・右クリックで保存とか・全画面表示とか



今まではスロットを選んで、
セーブとかロードとかするのがややこしかったかもしれませんが
それを廃止しました。

エディットモードを選択すると、先頭に20個、プレーンのマップデータが並ぶようにしています。
それをちょっとでも開くと、オートで勝手に内容を保存しといてもらえるようにしました。
これで大分直感的に作りやすくなったのではないか。


あと色々方針変えました。

今までは
マップエディタと謎解きゲームの部分は最終的に分離させて、二つリリースしようと思ってたのですが、
それも止めました。

実際今みたいな感じで、エディットモードと謎解きのモードは同居できそうです。
それはそれでまた色んな問題が出てくると思うけど。


例えば
「天誅忍凱旋」でも、
なんか裏ワザ的なことをすれば、ディスクに予め登録されている
規定の任務を持ってきて、それを自分で編集してメモリーカードに保存することとか、出来た気がします。


今、このプログラムは
チュートリアルだろうがなんだろうが編集できるようなフリーダムなことになってますが、
これを制限して、最初の20個しか編集できないようにしてしまえば、まぁいいわけです。


でもそれはそれでなんか味気ない。
裏ワザで、ズルして本編の謎解きだろうが編集できるようにしてしまいたい。
クリアしてもしなくてもいいチュートリアルの面は、いじれるようにするとか。
そういうのも考えています。


で、やっとエディタが完成したので
たった5個だけだけどチュートリアルを用意してみました。 ようやく。
最初の5個のやつがチュートリアルのつもりです。

移動に関する、基本の基本の操作がちょっとだけ分かるだけです。
(でもチュートリアルを作ることでまた見えてきたバグとかもあるのでなんとかしなくては)


こういう複数面構成のチュートリアルをひとまとめにしたやつを、あと10倍用意します。

・ドアの種類とか鍵の使い方とか ドアの相対移動・絶対移動・ドア指定移動についてとか
・武器の種類とか武器の振り方の指南とか 剣撃で飛んでくる矢を落とせることとか
・箱の種類とか 箱の壊れ方とか 箱の使い方とか
・アイテムの種類とか アイテムの効果とか 巨大化縮小化無敵化とか
・罠の種類とか罠の利用法とか
・スイッチの使い方とか スイッチのトグルの挙動とか
・戦闘とかロックオンとか 殲滅ミッションについてとか
・自殺とかバナナの焼き方とか
・・・


で、チュートリアルが終わってから、本気で謎解きの面を用意していきます。
(いつまでかかるんだ)
(でも、結構良い感じのひねった謎解きが作れそうな手応えは感じているのだ・・・)

ていうかこれ、チュートリアルだけで50面くらい作れるんじゃないかと、
そんな気がしてきた。

[ 2015/12/24 17:24 ] 自作ゲーム開発 | TB(0) | CM(0)

そんなことよりもバナナは焼けたのかい

 
さて、ブラッドボーン です。
これでもう今年の自分は完全にオシマイでしょう。 完全にフヌケになります。


だからこそ、

せめて今日までに、作ってるゲームのチュートリアルくらい完成させようと思ってたのですが、無理でした。

じゃあせめて今日までに、エディター機能の部分くらい完成させようと思ってたのですが、それも無理でした。


一時停止メニューづくり・・・
落下死・・・死亡時の演出づくり・・・
エディット画面のUIを洗練させろ・・・
複数マップ間移動での情報の保持・・・
武器の持ち運び・・・
最初から武器を持っていること・・・
スイッチの情報保存・・・
目標の作成・・・
バナナ・焼きバナナ・敵の殲滅・自殺・脱出等を目標とする・・・
バナナを焼けるようにする・・・
それなりに敵とチャンバラが出来るように・・・敵のAI・・・敵のエディット・・・
壁スイッチと床スイッチでのトグル機能の挙動・・・
スイッチの種類毎による挙動の調整・・・
装飾のパス絵を完成させろ・・・



とかなんとかやっているウチにどんどん完成が程遠くなっています。




swf直接・右クリックで保存とか・全画面表示とか

シフト+Zで爆弾とか投げられます。 


というわけで途中のをテキトーに貼って、今はブラボに逃げます。


まぁ、武器を持ち歩いたり物を壊したり入手した情報が残るようになって、
多少実感が変わったくらいにしか感じられないでしょうが、
それでも今回はだいぶ変わったつもり。
ずーっといじってて、これ。


何故この程度の変化がこんなに大変なのか。
あとで泣き言を書きます多分。

(追記: 泣き言 中止しました)


とにかく今はブラッドボーンです。

[ 2015/12/03 11:07 ] 自作ゲーム開発 | TB(0) | CM(0)

マップチップ完成


自己嫌悪がひどくて二週間ぐらい自分のブログ見れませんでした。 (いつものこと)


ずーっとゲーム作りしてる筈なのだが全然進まん。


あとはメニュー作ってステージ作るだけかと思ったら
まだまだ全然そんな段階ではなかったっぽい。 (いつものこと)


まずそれ以前に色々と固め直しました。


今回は流石に何が変わったのかサッパリだろうけど、
分かりやすい点としては、テクスチャというかマップチップがようやく全て揃いました。

全テクスチャ
最初は16枚で良いか~みたいな所からスタート。

全テクスチャ
100枚以内で収まるかなぁと。

全テクスチャ
無理でした。120枚

[ 2015/11/02 16:37 ] 自作ゲーム開発 | TB(0) | CM(0)
月別カレンダー
06 ≪│2017/07│≫ 08
- - - - - - 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 - - - - -