マップチップを自作し始める

新しいダンジョンを作るのに木が必要になったのですが、色んなところの素材を使うと統一感がゼロになるので、マップチップも自作し始めました。

とりあえず今日は木を描くことにしました。

一番最初に描いたのが下のやつです。

光の当たり方が全く分からなくてかけませんでした。

フラクタルみたいになっちゃいます。

あと葉っぱの部分を大きく描きすぎました。

次のやつは光の当たる方向を左側にして、葉っぱの部分も少なくしました。

あと、パレットを「ENDESGA 32」というのにして、色数に制限をつけました。

さっきよりはマシ。だけどなんかのっぺりしている。

実装してみるとこんな感じ。

想像以上にあってないですね・・・。他の素材も自作すればだいぶマシにはなると思いますが、正直これでやっていける気がしない。

もう少し細かくドットを打たないと厳しいですね。光のあたってる部分の境界をもうすこしぼかさないと不自然な感じがします。

色数絞っているので仕方ないのかもしれませんが、もうちょっとなんとかしたいです。

ちなみに使ってるパレットはこんな感じです。

今後は全ての素材をこのパレットに合わせていこうと思います。

今までは色数を無限に使って描いてましたが、色数を制限した方がそれっぽいゲームになるらしいので、これからは３２色に絞って描いていきます。

それでは。

もう病気だわ

またやってしまいました。

どうしても色が気に入らなくて、かなりいじってしまいました。歩行グラも修正しないといけません。だるい。

もうここまでくると病気なんじゃないかと思います。

本当にこんなことやってたら一生完成するわけないってわかっているのに、どうしても衝動を抑えられませんでした。

この衝動が昨日みたいに良い方向に働く場合もありますが、大体は悪い方向にしか向きません。

今も動いているgifを見て、ボディーラインが気になっています。あとマントと服。

僕はドット絵を描いている時、一部分に集中しすぎて全体を俯瞰して見ることを忘れてしまいます。なので、あとで見返した時に「ここが気に入らない！」となるわけです。

神絵師どころか普通絵師ですらないのに、そんなに粘ってどうするのか。

あと5日です。本当に間に合うのか、ちょっと不安になってきました。

今日1日中こいつとswiftやってたせいで、ダンジョン作りが全然進まなかったんですよね。

なんかダンジョン部分のレイヤーの表示順番がバグってて、攻撃エフェクトがうまく表示できません。

z-indexみたいに表示順を指定できればいいんですが、phina.jsにはそういう機能はありません。一番最初にあらかじめ表示順番ごとにレイヤーを定義する必要があります。

まあそのとおりやってるんですけどね・・・。なぜかうまくいかない。

まあ明日頑張ります。あと5日あればいけるいける。

めっちゃいい感じになった

ダンジョン生成部分を変えて、木をはやしたらめっちゃいい感じになりました。

これだよこれ！僕が求めていたのはこれです！

前のは森という感じがしませんでしたが、これなら森っぽい感じがします。

これ簡単そうに見えますけど、木の影とかレイヤーとか結構気を使って作りました。

あと、移動時のマップスクロールを非同期処理にしました。

この間までJavaScriptはデフォルトで非同期処理だと勘違いしていたので、今回改めて非同期で書き直しました。

おかげで移動中にカクつくことがなくなり、非常にスムーズです。

あとは攻撃部分ですね。エフェクトを追加して派手にしたいところです。それとダメージ表示をメッセージではなくアニメーションで出すようにしたいです。

残り6日でそこまで行けるか微妙ですが、今日の進捗でやる気が出たので頑張ります。

それでは。

進捗とα版公開予定日について

報告

ダンジョン部分と調合部分を切り離して開発することにしました。

調合部分で設計ミスがあり、完全に作り直さなければならなくなったため切り離しました。

なのでAlpha版はローグライクオンリー。Beta版で調合部分追加。という形をとりたいと思います。

進捗

リザルトシーン

リザルトシーンを実装しました。

スコア計算は、HP・MP・持ち物・敵討伐数・満腹度によって変わります。

今までは敵を倒してもうまみが無かったわけですが、これでようやく敵を倒すメリットができました。

ロードシーン

ゲームを始めるときに、アセットなどを読み込む時間が必要になるので作りました。

これが無いとゲームがフリーズしているように見えます。

こちらを参考に作りました。

phina.jsでオリジナルのローディングシーンを作る - Qiita

パーセント表示もできるんですが、めんどくさすぎてやってません。

そこまで重たいゲームじゃないので必要性を感じなかったっていうのもあります。

プレイヤーのスプライトシート

腕が長いので1ピクセル短くしたのにまだ長く感じます。あと2ピクセルくらい短くしないとダメですかね。

あとは後ろ向きができれば完成です。

最適化について

シングルスレッドで動くゲームなので最適化するのがベストなのですが、公開日が遅くなるのでやりません。

テストしましたが、メモリーが４GB以上あれば普通に動きますので大丈夫です。

α版公開時期を決める

6月1日にα版を公開したいです（願望）

先ほど書いた通り、α版はダンジョンのみのミニゲームです。調合機能はβ版からです。

配布は前回と同じくこのブログのゲーム置き場から行います。

まあいつも通りあまり期待しないで待っていてください。

以上！

ゲーム制作に行き詰まった

そもそもなぜこんなことを言い出したのか

今作っているゲームのコードが汚すぎて、開発に行き詰まったからです。

前作のゲームの時と同じで、自分でも何が何だかわからないところが出てきてしまいました。

ソースコードを書いたときは分かってても、時間が経つとわからなくなるソースコードになってしまいました。

そのため、上手い書き方・わかりやすい書き方を身に付けたいと思い、どうすればいいのかを色々と探っていました。

良いコードを書くにはGitHub見なきゃダメなんだなと思った

僕はGitHubをやってません。

GitHubをやっていないので、GitHubのトレンドもGitHubユーザのコードも全く見てませんでした。

Qiitaで十分だと思っていたからです。

実際わからないことは、ほぼ全てQiitaを見て解決してました。

だけどQiitaを見て自分で書くとコードが汚くなるんですよね・・・

今思えば、Qiitaは「こうすれば動くよ！」「ここはこうなってるよ！」という感じでわかりやすく教えてくれる場所です。

だから、Qiitaにある解決方法を自分なりの書き方にして書くことになるので、当然自分の癖が出て汚くなるわけです。

GitHubは「こんな便利なものを作ったよ！」という感じで作品をアップするイメージです。

しかも作品の中身をオープンにするので、みんな他人が見てもわかりやすいコーディングを心がけています。

自作PCで透明なケースを使っている人が、配線ぐちゃぐちゃに繋いだりしないじゃないですか。

それと一緒で、GitHubの人たちは出来る限り綺麗なコーディングを心がけている印象があります。

あとコードの分割とか集約の仕方とか、実物を見ないと勉強にならないので、やっぱりGitHubを見て勉強しないとダメだよなーと思いました。

上手い人の真似をする

今アプリ開発でSwiftを使っていますが、まだ使い始めてまもないので一番得意なJavaScriptでコードの書き方を勉強します。

一応僕もローグライクゲーム開発者なので、Rot.jsのダンジョン生成部分とかを見て勉強しようと思っています。

あと普段使っているphina.jsを読んでみるとか、他の方がphina.jsで作ったゲームを読んでみるとか、上手い人のコードを見て真似してみます。

そうやって学んだことをミニゲームを作ってアウトプットし、自分のものにしていこうと思います。

今作ってるゲームはどうするのか

ぐっちゃぐちゃの部分だけ書き直して、また再開します。そうしないといつまで経っても完成しません。

出来るまでGitでブランチ切りまくるつもりです。

ミニゲームも作りますが、本当にミニサイズのゲームしか作らないつもりなので、メインの作業にはあまり支障は無いと思います。

そういう感じでやっていきますのでよろしくお願いします。それでは。

ゲーム制作の進捗【112日目】

新しいスプライトシートを作った

48x48で描きました。死ぬほどドットを節約して描いてます。

と言っても正面しかできてませんがね。

実際に動かすとこんな感じ。見やすいように２倍に拡大してます。

等倍率は下のような感じです。

腕が長すぎるとか微妙に気になるところがまだありますが、ひとまずこれで正面部分は完成ということにします。

腕の長さは次回までに直しておきます。

やっぱり48x48で統一した方が、圧倒的に違和感が少ないです。

ちなみに前回の素材がこちら⬇️

違和感がバリバリです。素材としては結構気に入ってるんですが、このゲームには向きません。

ダンジョン完成までのタスク

ダンジョン部分の完成まででやるべきタスクです。GitとかでちゃんとTodo管理してます。

これが終わったらダンジョン部分だけで遊べるようにして、ポーションの合成システムの制作に入ります。

これからやる分

• 歩行グラ制作
• MobがPlayerを見つけたら追いかけるようにする
• Mobのステータス読み込みを別々にする
• Dorp itemの追加
• ソート機能実装
• 中断機能の実装
• トラップの拡張

ちなみに終わった分はこんな感じです。

終わった分

• アイテムの特殊効果[3/21]✓
• マッピング[3/25]✓
• ロード画面[4/?]✓
• インベントリのページング[3/26]✓
• 敵の種類を増やす[4/18]✓
• 階層移動するとステータスバーが更新されないバグ[3/26]✓

時間がかかりそうなのから優先して終わらせたので、数は少ないですが工数は結構かかってます。

中断機能を実装したいと考えていますが、最初のリリースがミニゲームであれば省いてもいいのかなと思います。

歩行グラも別にやらなくていいと言えばいいのですが、ゲームの見栄えが良い方がいいので何とかします。

今回はこの辺で。それでは。

自作スプライトシートが完成しました【ゲーム制作108日目】

スプライトシートが出来た

FireAlpacaでドット絵を描いてみる - 仕事やめたのでゲームを作るのやつが完成しました

早速使ってみました。

微妙。浮いてる感が凄まじいです。

よく考えたらこのゲームの解像度が正方形なので、長方形の素材だとおかしなことになります。

あと細い。もうちょっと太らせないとゲームの感じに合いません。

帽子を入れるとどうしても細長くなってしまうんですが、顎をもっと削って一頭身にすればだいぶマシになると思います。

やっぱり48x48で描かないとだめですね。

一応動いているところも載せておきます。

今見たら白飛びしてるところありますね・・・

トラップ素材も作った

ちなみにトラップの素材も作りました。

一応地雷のつもりです。でもやっぱり浮いてます。むずい。

借りてきた素材の雰囲気にあってないんですよね。

やっぱり解像度は合わせないとだめです。48x48で描き直します。

今回の進捗は以上です。

それでは。

とりあえずローグライクゲームと呼べるようになった【ゲーム制作95日目】

前回の進捗記事から15日も空いてしまいました。
一応ぼちぼちやってはいます。ただ、全部書くとゲームをする楽しみが無くなると思うので、今回からは適当な部分をかいつまんで書こうかと思います。

ということで、トラップを仮実装してみました。

「TRAP」って文字が書かれているところが仮実装のトラップです。
上を通るまでは表示されませんが、踏むとトラップが出てきます。トルネコと同じ感じです。

あと、メッセージウィンドウを3行から5行に増やしました。

3行の方が文字が大きくて見やすいと思ったのですが、やはり情報量が少なすぎてプレイしていてストレスが溜まりました。

一応ここまでで、

• ランダムダンジョン
• パーマデス
• 食糧問題
• ターン制戦闘
• グリッドベース
• ノンモーダル
• リソースマネジメント

がとりあえず揃ったので、ローグライクゲームの定義である「ベルリン解釈」はクリアしたと言っていいでしょう。
これで晴れてジャンルを「ローグライト」から「ローグライク」にできます。
複雑性が足りませんが、それは敵の特殊効果やトラップの種類を増やしていけばいいだけなので、まあOKということにしてます。

この後ですが、引き続きダンジョンを作る予定ですが、同時並行でプレイヤーの素材を作り直そうと思っています。
というのも、今使っているプレイヤーの素材は解像度が32×48でかなり小さいです。
このゲームは1グリッド96ピクセルなので、もうちょっと大きくてもいいです。
あと単純に可愛いキャラじゃないとやる気が失せると思ったので、作り直すことにしました。
ホーム画面の立ち絵も描きなおします。今ならもっとうまく描けるはずです。

ということで今回はこの辺で失礼します。それでは！

進捗【ゲーム制作80日目】

いろいろありましてあまり進んでません。ずっと空を見ていました。あとswiftしてました。

まだ回復してないけど進捗報告いきます。

新しい敵追加

敵がデカい。

ステータスはかぼちゃのやつを流用してるので変わらないです。

ていうか敵のステータス管理部分作ってませんでした。追加するときにやっと気づいた。

あと下向きのアニメーションしか実装してなかった。カボチャの時は違和感なかったんで気づかなかったです。

インベントリのページめくり

アイテムが3種類しかないので伝わりにくいかもしれませんが、方向キーで持ち物を確認できるようになりました。

今後

引き続きダンジョン部分を作ります。

• トラップ
• 階層ごとに出現する敵を分ける
• アイテムを増やす
• ドロップアイテム etc...

トラップ以外は新要素ではないので、ちゃんと毎日作業すれば今月で終わるはずです。

まあ絶対サボると思うので5月半ばくらいまで掛かると思います。そもそもアプリ開発の仕事があるので思うように進まない気がします。

今回はこの辺で。それでは。

マッピングを作る【ゲーム制作70日目】

重い腰を上げてマッピングの作成に取り掛かりました。

と言っても、作り始めて既に3日ほど経過しています。

とりあえず通った部屋のマッピングをして表示するところまでは出来ました。

問題は通路のマッピングです。なんでか知りませんが通路のマッピングを追加すると部屋のマッピングが不安定になります。

部屋に入ってもマッピングされたり、されなかったりします。

上の写真ではプレイヤーが部屋の中にいるのに、なぜか通路としてマッピングされてしまっています。

最初はプレイヤーの絶対座標の更新前にマッピングが行われているのではと思いましたが、promiseを使って移動が終わってからマッピングするようにしても直りませんでした。

というか、そもそも座標の更新前にマッピングが始まっていたとしても、部屋の中をウロウロしていればそのうち部屋がマッピングされないとおかしいんですよね。そういう仕組みになってますから。

今日はもう疲れたので修正は明日にします。それでは。

ダンジョンゲー制作【65日目】

満腹度

20歩あるくと満腹度が1減ります。

ちょっと早いかなとも思いますが、ダンジョン自体がそんなに広くないですし、アイテムもたくさん落ちているのでこれくらいでちょうどいいでしょう。

ダンジョンで拾ったアイテムは持ち帰ってポーションの素材に使うわけですから、このくらいのバランスがちょうどいいはずです。

アイテムに効果を付けた

基本的に登場するアイテムはポーションの素材＆食料になります。

アイテムはダンジョン中にたくさん落ちていますので食べ物に困ることはまずありませんが、食べてばかりだと持ち帰れるアイテムが無くなってしまいます。

また、アイテムの特殊効果に頼り過ぎても同じです。

ただ、このままだと敵と戦うメリットが無いので、ドロップアイテムを実装する予定です。

敵同士が衝突しないようにした

前々から気になっていた敵が重なるバグを修正しました。

やっとすっきりした。なんで今まで直さなかったんだろ。

今日はこの辺で。それでは。

ダンジョンゲー制作【64日目】

作り直し始めてから何日経ったんだろと思って数えたら64日も経ってました。

2ヵ月やってこれっぽちしかできてないことにめちゃくちゃショックを受けてます。

ターン制御エンジンをまた変更した

フラグ管理式に戻しました。

というのも、アイテムウィンドウを開いている時にスリープさせるつもりだったのですが、JavaScriptではスリープが使えないということをすっかり忘れていて、アイテムが使えなくなってしまったんですよね。

おまけに動きもカクカクしていて「これだったらRot.jsのエンジン使ってるのと何も変わらないなー」と思い、フラグ管理式のターンエンジンに戻しました。

とはいえ、以前のバージョンに戻したという訳では無く、全く新しいものを一から組みなおして作りました。

今回のはちゃんと紙に書いて設計したので、コードも簡潔ですし今のところバグもありません。あと動きもサクサクです。

もうこれ以上ターン制御は触りたくないです。いじるとしても、今回作ったやつに機能を付け加える以外やりたくない。

攻撃エフェクトを付けた

レイヤーがずれてますが、一応実装できました。

本来ならキャラクターの上に攻撃エフェクトのレイヤーを持っていきたいのですが、どうにもうまくいかずこんな感じになってます。

今回はこの辺で。それでは。

ゲームターンエンジンの進捗

一応区切りの良いところまで行ったので

バグはあるんですが、一応動くようになりました。

攻撃エフェクトがバグってるのは気にしない。

このgifだとFPSが遅いのでわかりずらいですが、実際はすこしカクつきます。

同期処理にしたので多少のカクつきは覚悟してましたが、ちょっとこれは気になるレベルです。

うーんどうしよう。敵の動きを少し早くして遅延を減らすのが一番手っ取り早いですが、それをやりすぎてもカクカクしてるようにみえるんですよね。

というかここまで処理が遅延するのが気になります。

もうすでにエネミーの動きは少し早くなっているので、多少の遅延は吸収されてくれてもいいはずです。それなのにまだ遅延しているということは、単純に僕の書き方が悪いということなんでしょう。

探索AIも非同期で並列処理させてるんですがねぇ。

まあ、この問題は時間が掛かりそうなので気が向いたときにやるとして、とりあえずダンジョンを作りこんでいこうと思います。

今日はこの辺で。それでは。

ゲームターンエンジンをぶっ壊す！

ゲームターンエンジンをぶっ壊す！

理想

エンジンをロックする↓

プレイヤーが行動する↓

エネミーが行動する↓

エンジンをアンロックする end

現実

ロックする↓

プレイヤーが行動する↓

エネミーが行動する↓

アンロックする(本来ならここで終わる)↓

ロックする(なんで？)↓

プレイヤーが行動する↓

エネミーが行動する(経路探索で死ぬ)

たぶんエンジンをアンロックするタイミングずれて早すぎるんだと思います。

エネミーが動いている最中にロックが解除され、プレイヤーの入力が通ってしまい、エネミーの行動が二重入力されている感じがします。

攻撃時は同期処理、移動時は非同期処理するように書いたつもりが、どっちも非同期になってるっぽいです。

何となく来週中には完成しそうですね。

前書いたエンジンはすべて消して、新しいを一から作ったので若干時間が掛かりましたが、それでもまあいい感じのペースです。

エンジンが完成したらアップデートしようかなと思います。

それでは！

ゲームターンエンジンを作り直している

ゲームターンエンジンとは、プレイヤーとエネミーの行動を交互になるよう制御するシステムのことです。

僕が勝手にそう呼んでるだけで、実際何というのかは分かりません。

この間の記事でアロー関数やりましたが、それがきっかけでPromiseの使い方がだいぶ分かりました。

そして、このPromiseを使えば楽に同期処理が書けるようになるので、今までのフラグ管理式ターンエンジンをやめて、Promiseを使った同期ターンエンジンに書き直そうと思いました。

フラグ管理だと処理が複雑になりますし、非同期なので思わぬバグが発生することがあります。

しかし、同期処理にすればフラグもいりませんし、他の煩わしいことも考えずに済むようになります。

ということで、さっそく作り始めたわけですが、とにかくうまくいきません。

一歩だけ動けるけどそのあとは動けないとか、キーボードの入力受付がラグで死んだりして、思うようにいきません。

たぶん時間が掛かるやつです。

でもこれが出来れば行動の終了フラグを検知したり、プレイヤーとエネミーが同時に行動するバグも防げるので頑張って実装します。

今日はこんな感じで。それでは。