投稿記事

2023年 05月の記事 (18)

竹林ソフト 2023/05/31 20:00

クラフトゲーム開発(装備変更の調査と作業)

TopDown Engine で装備を切り替えるあたりを調べながら実装します。
あとアイテム画像も差し替えていきます。

↓TopDown Engine の Weapons についてのドキュメント
https://topdown-engine-docs.moremountains.com/weapons.html

ドキュメントとソースコードを参考にしつつ、とりあえず

  • CharacterHandleWeapon.ChangeWeapon() を呼び出せばよさそう。
  • デモ付属の KoaraSword をコピーして Axe を作ればよさそう。
  • 数字キーが押されたときに、そのスロットにあるアイテムを評価する。
    • 武器だったら変更する。
    • 消費アイテムだったら消費する。(そのうち)

くらいの理解から実装に着手します。

↓剣と斧のアイコン画像は差し替えました。

  • インベントリ内のアイテムが、どの Weapon クラスに対応しているかを TopDown Engine でどう紐付けるべきなのかわかっていない。
    • デモとかソースコードを追っていく必要がある。めんどい。

↓Weapon クラスの見た目はアニメーションを作る必要がある。

というのがわかりました。
アイテムと Weapon クラスの紐づけは確認せずに自作してもいいかな、と思います。TopDown のインベントリシステムを使い倒そうとしているわけじゃないので。

まとめと今後の予定

今回の記事はあまり進捗がないので「来週までに作業して記事にするか」とも思ったのですが、それはこの開発が来週にシフトするだけなので短くても記事にしました。
今後も「(進捗が)ないよりまし」の精神で記事投稿していこうと思います。がんばります。

竹林ソフト 2023/05/30 20:00

ねこ巫女籠城ゲーム開発(建築操作の改善)

前回は城郭を少し作ってみました。今回は、その城郭を作る操作で未実装の機能を実装したり、操作しにくかった点の改善をしていきます。

地形の編集操作の見直し

45 度の傾斜までしか作れないようにする理由

城郭については専門家じゃないので都度調べるのですが、城郭の斜面の傾斜は 45 度がよい、という説明が多いようです。

45 度
https://www.touken-world.jp/tips/44007/
https://shirobito.jp/article/923

草が生えている場合や堀切などでは 60 度までの傾斜もあったようですが、このゲームでは 45 度までしか傾斜を作れないということにします。

小田原市|総構(小峯御鐘ノ台大堀切の 50~60 度の堀切を紹介している)
https://www.city.odawara.kanagawa.jp/kanko/spot/p31082.html

ただ、極端な例を出すと自然地形の崖は当然 45 度以上の傾斜なわけで、「プレイヤーが変更した場合の傾斜は 45 度までにする」みたいな仕様がよさそうなのですが、どうするかは悩み中です。
とりあえず、盛土と掘削の操作の上限を 45 度にする変更は実装します。

45 度の制限の実装方針について

今はドラッグして作った範囲に対し、更に上下ドラッグすることで編集できます。

↓ドラッグでエリアを作って、そのエリアを上下ドラッグして高低差を指示する

高低差がない平坦なエリアを編集するときはいいのですが、すでに高低差があるエリアを編集するときにどうするかは決める必要があります。

↓高低差があるエリアの例

高低差があるエリアのときにどうするかの案

・エリア内を最初にクリックしたセルの最も低い頂点の高さにする。
・クリックしたセルの周囲のセルを順に同じ高さに変更していく。
 ・ただし、この変更で傾斜が 45 度に収まるように制限する。

例えば、この上の画像ときに右上のセルをクリックしたら、右上のセルの高さに合わせようとしつつも 45 度の制限で高さを変更しきれずに、にエリア内の各頂点の高さが1ずつ上がるような動作を想定しています。

具体的には、同じ高さにする処理を、その高さから最も離れた頂点から順に処理していけばいいと思うんだけど、記事が長くなったので実装と動作結果は次の記事にまとめます。

まとめと今後の予定

今回は地形の編集操作について検討して方針を書き出しました。次回は実装と動作確認を行います。今回のように、機能の見直しも続けていきますが、ゲームとして通して遊ぶために未実装な機能も選んで着手していきたいです。がんばります。

竹林ソフト 2023/05/28 20:00

すくすくスクワット VR(スクワットで育つ樹木の開発)

スクワットすると育つ樹木を仮実装していきます。

アセット選び

小難しく考えると実装できないので、手持ちのアセットから樹木と草花を探しました。

↓木をカスタマイズして作れるアセット
Broccoli Tree Creator

これは何かのバンドルで購入してたアセットで、樹木のパラメータをスクワット回数に応じて動的に変更できるかを確認します。

↓草花の Low Poly アセット
Low Poly Vegetation Pack

大きな樹木を複数人で囲んでスクワットするのも味わい深いのですが、花壇わきでスクワットして花が咲いたら隣の花壇に移動するような風景もいいなぁ、と思ったので花のアセットも選びました。

樹木や花がすくすく育つ様子を表現する

樹木が育つ表現

↓アセットを選んだ後で、樹木が育つ様子をどうにかできるのか調べてて出てきた記事からの抜粋です。

Broccoli does not provide a way to go trough animated steps to grow a tree. The runtime demo actually creates full grown trees and just scales them on their position. You can control almost every aspect of the tree, but you end up creating a new mesh every time changes are commited and processed.

機械翻訳

ブロッコリーでは、木を成長させるためのアニメーションのステップを踏む方法は用意されていません。ランタイムデモでは、実際に成長した木を作成し、その位置でスケーリングするだけです。木のほとんどすべての側面を制御できますが、変更をコミットして処理するたびに、新しいメッシュを作成することになります。

ぐぬぅ。
そういう用途では設計されてないらしい。がんばって動的に処理してみるか、段階に分けたテンプレートを用意しておいて切り替えながら表示するかはできそう。

そして実際に触ってみて、木を構成するパーツについての Random Seed は固定にできるのがわかった。なので、Random Seed を固定にして各パラメータを成長に合わせて少しずつ変化したものを生成して読み込むようにすれば育つ様子は実現できそうなのがわかった。

ここまでの結論としては「できるけどめんどい」「そこまで真面目にやるプロジェクトか、これ?」です。

花が生えてくる表現

樹木をどうするか考えるのに疲れたので、花については簡単な表現にしようと思います。

案: スクワットを1回するたびに花壇に花が1本生える。

この案の懸念点としては、スクワット時には顔は正面を向いたほうがいいと思うので、あんまり近くに花壇があるとよくなさそうな点でしょうか。

とりあえず、この仕様で一定時間ごとに花が生えてくるデモを作ろうと思います。

花が生えてくるデモ

そして、作ったデモがこれです。

動作はこれでいいと思うのですが、スクワット回数が増えてくると花の数が増えるわけで、そうすると描画負荷が大丈夫かなというのが気になります。
もう少し詳しく書くと、描画負荷そのものよりかは「重要でない表現に負荷をかけたくない」というのもあります。1回のスクワットで花の大きさを少しずつ大きくして、最大の大きさになったら次の花を生やす、とかの方法がよいかもしれません。

まとめと今後の予定

樹木について、単に拡大しながら育成するだけなら簡単そうなのですが、枝葉がだんだん増えるような表現は少し大変なのがわかりました。どうするか少し考えます。
気になる点もありますが、とりあえず花が生える方法で開発自体は継続しようと思います。がんばります。

竹林ソフト 2023/05/26 20:00

NPC をコーディングして領地経営するゲーム開発(体験版までの開発の続き)

引き続き体験版までのタスクを片付けていきます。

やったこと

ドキュメントの記述

体験版までに作るべきドキュメントとして、Tutorial と Lua のドキュメントを書き上げてなかったのを仕上げました。

よいです。

建物にエフェクトを追加

↓キャラがワークしているときに建物ごとのエフェクトを表示できるようにしました。

よいです。
エフェクトを再生する仕組みは実装できたので、「こういうエフェクトありだな」というのが思いついたら、他の建物にもエフェクトを追加しようと思います。

アイテム表一覧のサイズを調整

アイコン画像の大きさで違和感を感じていたのを修正しました。

↓調整前

↓調整後

調整前よりましになったので、よいです。

まとめと今後の予定

ここまでで体験版までの作業の重いタスクは終わりました。後はここまでに作ったドキュメントの英訳が残っているのですが、それは機械翻訳でどうにかします。
次回かその次くらいからは製品版に向けての機能追加を再開したいです。がんばります。

竹林ソフト 2023/05/24 20:00

クラフトゲーム開発(装備変更の続き)

装備や使うアイテムの変更をキーボードの数字キーから行うあたりを実装していきます。
今回も割り切った実装をしていきます。完璧に作るのは開発コストが高いので、とりあえず動作すればいいことにします。

キー操作の受け取り

前回まででアイテム表示に選択中の枠を追加したので、キーボードの1から0までのキーに応じてそれが選択状態になるようにします。

↓まずは、1から0に対応する枠を配置してしまいます。

とりあえず描画できました。よいです。
次はキー操作を取得してフレームを表示を切り替えるあたりです。
 
とりあえず動けばいいので Input.GetKeyDown(KeyCode.Alpha1) を駆使して実装します。

↓キー入力を検出するコード

↓フレーム表示を切り替えるコード

↓キーボードのキー2を押したときの動作

よいと思います。

どういう仕組みの町にしたいか

このゲームでは、居住と生産、防衛をする「町エリア」と素材を集める「収集エリア」とは明確にわけます。今回、町について少し考えたので、それらを書き出してみます。

防衛について

タワーディフェンス寄りのカジュアルなものを目指すのか、壁と門とで集中的に防衛する城郭っぽいものを目指すのかを考え中です。
私はどっちのタイプも好きなので悩ましいです。

「入り口を狭くして敵が少しずつ入ってくるようにして、味方がそれを全方位から狙う」みたいな仕組みを作れるのが基本的なアイディアですが、それだけでなくて「今回はこういう防衛にしてみよう」みたいなプレイの幅が広がる仕組みはほしいです。

生産について

ワーカーの動線が重要な工場要素を持たせたいと思っています。

例えば、素材は作業場に運搬する必要があって、その運搬量を少なくすることで動線が重要になるようにするとか、防衛に必要な城壁を作るためには大量の焼きレンガを作り続けないといけない仕組みにする、とかです。

某ビルダーズの「この家具があるからこの部屋は~として機能する」みたいな仕組みを導入したい気持ちもありますが、もう少し考えてみます。

まとめと今後の予定

数値キーでアイテム選択を切り替える仕組みを実装できたので、次は TopDown Engine で装備を切り替えるあたりに着手したいです。

必要な要素技術は実装していくのですが、そろそろ要素技術だけでなくて、ゲームの雰囲気というか、ゲームクリアまでの流れをどうするかも考えて決めていこうとおもいます。がんばります。

« 1 2 3 4

月別アーカイブ

限定特典から探す

記事を検索