ニートが頑張るブログ

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

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

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


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

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

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



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

画像はこれから充実させていきます。一作品に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)

牢獄たんぽぽ

 
で、ゲーム作りの報告。
今回は流石にマジでかなり色々変わったつもりです。 これで。




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


◆基本操作
方向キー: 歩く    スペースキー: ダッシュ 
シフトキー: ロックオンor並行移動 (ロック対象がいるときはオンオフ、無いときは押しっぱなし)


Zキー: 武器振り  ドアを開ける 看板を読む!
シフトキー+Zキーで武器を投げる
Xキー: ちょい押しでジャンプ 長押しでしゃがむ
Cキー: 吐血 エフェクト出力テスト
Vキー: 箱と自キャラの操作切り替え
Bキー: 爆発四散
Nキー: 時間停止  Mキー: コマ送り 
Dキー: キャラを追加
Fキー: 箱を追加






ところで何度か言ったような気がするけど
このグダグダやってるようにしか見えないプロジェクト「これからの方針」みたいなのを書いてみます。

こんなんを想定しています。
今作っている「地形メーカー」というやつから派生させて
「謎解きメーカー」のようなものを作ろうと思っています。

それと同時に、
その謎解きメーカーのフォーマットで作ることの出来る謎解きを集めた
面クリア型の謎解きゲームも作ろうと思っています。 
(問題集みたいなもん) 
(チュートリアルとかをかなり充実させたいと思っている)


つまりまぁ、天誅忍凱旋の「虎の巻」のようなプログラムと、
それによって作られたステージ集としてのゲーム、(忍百選みたいなもん) 
この二つを同時に、今の地形メーカーからの応用で、作りだそうということです。


その謎解きゲームを完成させたあとでも
地形メーカー自体を改良するのは続けます。
そんで、どんどん進歩したゲームを作れるようにしていこうとは思っています。
最終的に謎解きメーカーとそれ以降のゲームでは互換性はなくなるわけですが。

地形メーカー(プリミティブ) → 謎解きメーカー → 謎解きゲーム集 (今ここの分岐に来ている)
 ↓
改良・別のゲーム
 ↓
いつか作りたい妄想・理想のアクションゲーム



地形メーカーはまだ汎用的な感じです。

こっから、謎解きに特化した謎解きメーカーを作るのです。
そいつは、普段自分が言ってる「四肢切断がどうのこうの~」とかいうゲームからは一旦離れるモノです。


で、今回はかなり色々固めて来ました。
「地形メーカー」としての最後の更新くらいだと思います。
次からは本格的に謎解きメーカーに移行していきます。

[ 2015/08/20 14:51 ] 自作ゲーム開発 | TB(0) | CM(0)

ドアとスイッチと罠


「ドア」「スイッチ」「罠」が出来ました。
そんだけで更新です。




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


◆基本操作
方向キー: 歩く    スペースキー: ダッシュ 
シフトキー: ロックオンor並行移動 (ロック対象がいるときはオンオフ、無いときは押しっぱなし)


Zキー: 武器振り  ドアを開ける!
 シフトキー+Zキーで武器を投げる!!
Xキー: ちょい押しでジャンプ 長押しでしゃがむ
Cキー: 吐血 エフェクト出力テスト
Vキー: 箱と自キャラの操作切り替え
Bキー: 爆発四散
Nキー: 時間停止  Mキー: コマ送り 
Dキー: キャラを追加
Fキー: 箱を追加



いちおう現状で出来ることの組み合わせで、謎解きを2つほど作ってみました。
本当に「1ひねり」くらいの簡単な謎解きです。

謎解き 謎解き


以下、やったこととかについて解説

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