【完成】巨大娘防衛SLG完成、直後DLsiteに断られ、ヤケになり技術的な改善点を延々と話すの章
喋った（今回は喋りの方が分かり易いと思うよ）：
booth：
DLsite（この数日後に審査通った、該当表現は変えた）：
……という訳で、大体昨年の１２月のいっぴくらいかな、開発してきた巨大娘防衛SLGを発売に至りましたよ、と。
余り盛り上がりというか、気持ち的に切り替わっていないのは
DLsite様にてZORIZORIキャッスルのお殿様というキャラを出したら、これがアカンと。
今差し戻しを喰らってる最中な事で、これが固有名称を消せば済むのか、
まあ固有名称つってもZORIZORIキャッスルのお殿様なんて人は居ない訳で、
私が描いた絵を消せないとダメなのか。
別に実際の写真を使った訳でもないのにね、実在の人物をモチーフにしてると注意されましたが、
そのDLsiteが思い浮かべてる様な実在の人物って人は、お殿様なんですかね？ 良く分かりませんけども。
まぁそんな風に何か気持ちの切り替えがスッキリしない日々を送っているなあと。
どうせ発売したらバグ報告とかもあるでしょうし。
DLSiteに登録してみると500円の作品だと
マージンはちょうど250円、５０％って低いなあという事も改めて痛感しまして、
まぁ今はDMM、FANZAの方にも進めようと思っていますが、見たらこっちは200円なのでもっと少ないんですが。
仕方無いので現在はBOOTHで発売、こっちは手数料5%だからねえ、という訳で
大特価200円で出しております。
概要欄にURL貼っておくのでどうぞ。
さすがに200円だったらちょっと楽しめるくらいの出来になってるんじゃないか。
これだけ手間取ってDLsiteのＤＬ数が悪かったら、まぁ今までの動画にも発売しましたよーってURLを書き換えなきゃなって思ってるのですが、
それをBOOTH中心にしていこうかなと思いさえある。
果たしてイラスト発注費の４万円は償却できるのか。
そんな所です。
で今回は、前回
は一番の悩みとして画面遷移の仕方を振り返って、
あーここバグ出そう、次回はこの方式は止めとこうってなったんですが、
他の細々した所を振り返って、このゲームの振り返りは終了、区切りとしたいと思います。
まずいきなり技術でマニアックな話になりますが、
まぁBOOTHからでも体験版プレイできますので、そっちを触っておくと少し呑み込みやすいかも。
今回の兵器データはえー、この様に……
<div id="weapon_ui">
<!-- 解禁される武器兵器全部書いておく -->
<div class="weapon" data-name="ジープ">
<span class="cost">250</span>
<img src="./img/battle_zeep.png" />
<button class="bild" data-cost="250">生産</button><span class="have">1</span><button class="attack" attack-sound="@defo" sortie-sound="weapon_go" data-w-type="tank" data-move-time="1.0" data-move-v="5" data-power="4" data-distance="170" w-number="1">出撃</button>
</div>
<div class="weapon" data-name="90式戦車" data-lv="5" data-need-type="A" style="display:none;">
<span class="cost">650</span>
<img src="./img/battle_tank.png" />
<button class="bild" data-cost="650">生産</button><span class="have">0</span><button class="attack" attack-sound="cannon" sortie-sound="tank_caterpillar" data-w-type="tank" data-move-time="0.75" data-move-v="4" data-power="13" data-distance="190" attack-after-ms-wait="1250" w-number="2" disabled>出撃</button>
</div>
生産して巨大娘と戦う兵器の全てのデータを、HTMLとして値を持っているんですが、
こうすると変更も容易ですし、また”ここに一箇所に固まっている”ってのが案外管理しやすいのかなと。
これは一種の大胆な挑戦だったのですが、
少なくともこの規模だと破綻する事なく、最後まで結構上手い具合に……
つまり今まで追加したパラメーターが何が何やらワカラン、となる事なく行ってくれたかなと思います。
ただ今見てもかなーり長くなっていてそろそろどれがどれやら限界になりそうな感じもあって、
唯一途中から考えたとすれば、例えば
data-w-type、これは陸か空ユニットかみたいのを記してますが、
初めに設定したきり変更されないのと、例えば
data-cost、出撃コストは持ってる数が多いほど増えますよという事で、変更される数字もあると。
まぁ実際には出撃コストは初期値のまま、持ってる数に応じて追加コストをプラスするという方式を取ってはいるんで、
コスト自体は書き換わらないのですけど、それだと数式を別のどこかに持ってる事になっちゃうんですよね。
この兵器にまつわるデータ、計算は全てここに収めておきたいし、
また初期のまま変更されないデータはこの、data-が付かない、ここに書いてる所は変更されるものはdataが付く、みたいな、
ある種の命名規則で管理しても良かったのかなと。
よく見ると
attack-sound="@defo"
みたいに、これは出撃音なんですけど、@とか付けて読み込んだ時に特別処理するとかもありますよね……
ただこういう命名規則で意味合いを付けるというのもある程度までは良いんですけど、
こうなった時はこうで、こうなった時は……ってなったら、その把握に時間掛かるようになって、
結局その面でバグを抱えるって事にもなっちゃいそうで。
Javaの設定ファイルみたいな感じで。
確かにプログラム書かなくて済むけど、設定ファイルのルールが複雑過ぎてまずその為のドキュメントをずらーっと読みまくって、
慎重に値を書き換えなきゃみたいな。
でそれを嫌って値の管理をGUIで行うようにすれば……、Unityですよね。
だからUnityはドラッグ＆ドロップでファイルを落とすと、なんか知らない様なデータが一杯出来るし、なんか分かんないけどバージョンアップしたら
データ壊れたぞ、動かないぞ、とかってのもあるのかなと。
それらは初めから巨大なシステムを想定してるからですが、
私は同人の個人制作で、そこが唯一と言っても良いくらいのメリットだなと思うので。
結局、データの複雑さに対し、どう上手く構造をソフティーに持つのかな、って話になると思うんですが。
ソフティーという事は、扱うデータがちょっと簡単になったり、複雑になったり、
あるいはSLGだったり、ACTだったりで全然正解が違う、それぞれのベストな方法をまるで職人の勘みたく、
こうだろうと決めて来るのが理想みたいな所ですよね。
それは企業だとそれを嫌って、でっかい物を扱えるシステムで、ひたすら手順を厳格化して対応するのも分かるかなと。
で今の所の考えとしては、まずそのdata付けるか否かっていう簡単な命名規則に、
あとこれはDOMですから、コンポーネントの入り組み具合によってデータ表現出来るというのもありますね。
つまり現在は
<button class="attack" />
っていう、ここから生産して出撃させるよという意味で、ボタンっていうコンポーネントに
兵器にまつわるデータを全て書いてますが、
別に実際に使用しないDOMを用意して、書き込み用のコンポーネントにしても良いかなと。
例えば
w-number="4"っていうのはID的な通し番号なんですが、
こんなものは自明なんで、プログラム的にカウントしたいよなあとか。
その為に専用のspanだかなんかを含んで、なるべく使うべき所のみを明記し、
それ以外の変更が少なさそうな所はバックヤード的に押しやりたい、という所ですね。
で調べるにwebComonentというのがあるんですが、
例えば
<cat />
みたいな独自のDOMを定義できて、これが何だというと、
<div>
<span />
<img />
</div>
みたいな、一組のDOM、この入り組みを指している、という事も出来ると。
多くの兵器に共通する様な所はこういう独自のHTMLを定義して短く済ますとか、
あるいはデータ的には、後からこの独自のHTMLを加える事で、
一組みの属性、効果を与えられるって事もあるのかな？
これも次回ちょっとやってみたいなと。
ゾンビSLGは今回と似ていて新しくやれる所少ないなー……なんて前回の動画
で語りましたけど全然ですね、だからこそというか、改善すべき所が一杯ありました。
あ、あとそれ絡みですが、
こうしてコンポーネントに書かれたデータを読み込む時は全て文字列で、
例えばdata-w-typeは文字列のままで良いですし、
data-costみたいのは数字に変換しなきゃいけないんですが、
例えばここで
data-move-time="0.4"
みたいなのが少し問題になるというか、ここでバグ出しちゃう事が数回ありましたので何とかしたいなと。
つまりdata-costは"450"
とかで整数なんですが、
data-move-timeは"0.4"、少数なんですよね。
JavaScriptの処理的には、前者はparseIntなんですが、
後者もそれでやっちゃうと0になっちゃうという。
後者はparseFloatですね。
まあこれをうっかりして間違えて想定した挙動にならない、という事が割とあった。
これはもう、独自のメソッドを用意して、そうですね、小数点(.)が含まれてるなら
自動的にparseFloatだし、えーっと、アルファベットが含まれてたらそれは文字列である、
って自動で処理をさせるべきだったかなと。
もちろん、例えば111って名称の人が居たら、名前なんで文字列にしたい所を
数字になっちゃうんですけど、そっちの方がずっとレアケースなんでね……
つまり、上記のHTMLで記したデータが
armyAttack({
"src" : $attack.siblings("img").attr("data-unit-src") || $attack.siblings("img").attr("src") ,
"w_type" : $attack.attr("data-w-type") ,
"w_number" : $attack.attr("w-number") ,
"move_time" : parseFloat($attack.attr("data-move-time")) ,
"move_power" : parseInt($attack.attr("data-move-v")) ,
"power" : parseInt($attack.attr("data-power")) ,
"distance" : parseInt($attack.attr("data-distance")) ,
"attack_after_ms_time" : parseInt($attack.attr("attack-after-ms-wait")) ,
"hp" : parseInt($attack.attr("data-hp")) || 1 ,
"attack_sound" : $attack.attr("attack-sound")
});
という形でゲームで扱うオブジェクトに変換されるよという事で、
これがデータをゲームたらしめたるかなりの根幹で、あとはこの値に基づき三角関数とかで動きを決めるだけなんですが、
まぁ長ったらしいので、ここもある程度自動化できるよなーと。
話を聞いてるとかなりシンプルな構造かと思われたのでは無いでしょうか、
そうです、シンプルで無いと早く作れませんし、効率が良い物ってシンプルな筈なんです、多分……
ちなみにプレイヤー側も実行ファイルをフンフンフンして、HTMLを入手したら、
兵器の値を勝手に書き換えれば凄く強いヘリ、動きまくる戦車とか簡単に出来るんですよね、これだと。
でもそれこそ制作的な面では理想を行っているって事だと思うんですよね……
そういう事が出来ちゃうってのはセキュリティ的な問題であって、簡単な改造が反映されるってのは
制作としては喜ぶべき状態なはず。
あとそう、実は前に遷移の事を語った後に出たバグなんですけど、最後の最後に来て、
つまりデータが入り組むに従って……って事なんですが、
明らかに厄介な事になりそうなバグが見付かったぞと。
現象的には、巨大娘が兵器を攻撃して倒すと、
たまーに、あさっての方向を目標にして歩いて行っちゃう事があった。
これがなんでかって言うと、
まず兵器、戦車があったとして、攻撃の際には1秒間だけ光ってから攻撃するんですが、
でそこで巨大娘の攻撃、これはすぐに行われるんですね。
で巨大娘の目標ってのは兵器に攻撃された時、その兵器を目指すように作ってるんですね。
でもたまたまその処理が同時に走った時、
既に自分の攻撃で死亡している相手兵器を目指すようになっちゃう、
それは出来ないんで、0,0の座標を目指す、みたいな事になっちゃってた。
これは本当に評価が難しい所で、
これを抜本的に解決する方法は分かっていて、
順に並べれば良いんです。
つまり巨大娘が動いたら次戦車、と順々に行動を並べる。
もし同時に条件を満たしていても巨大娘の攻撃が先で、戦車が攻撃する事は有り得ない。
ただ制作として、同時に動かしちゃっていいかってやったからこそ
早く軽く済むって事は多いにあって。
だが同時に動かすってのは要はそれらを組み合わせた時に何が起きるのか想定しにくいって事でもあって、
今回みたいな事が起こる。
しかも原因が把握し辛い……
結局今回は巨大娘が攻撃した後に戦車が死んでるようだったら……っていう特別処理を書いてなんとかしたんですが、
もっと規模が大きくなったらこれは抜本的にやらないと、本当にあちこち特別処理しなくちゃならくて、
破綻する気配さえあった。
うーん思ったのは、接続の確立ってのはどうかなと……
つまり巨大娘、戦車、というのがあったとして、戦車が攻撃する時に一回もう巨大娘に接続してやると。
正確には接続オブジェクトに巨大娘、戦車を渡してやる。
でそこで安定的な処理をする。
接続の際に渡した処理以外は、もう一切行われなくなる……っていう事なんですが、
うーんこれだとその接続に絡む処理は良いけど、他で無視される事もあって困るかなあ、
どうしてもって物には接続オブシェクトの外で並んで、順に消化して貰おうとか。
要は同時、平行に動かしながらも問題を省いて恩恵だけを受け取ろうって事が出来るか、なんですが。
そういう風に知恵とバランスを見極めてやっていけたら格好良いなあと……
あとゲーム的には、暇な時はコインクリック連打しなさいって事だったんですが、
ここはおざなりで、もうちょっと作りたかったかなと。
そう、ただクリックしてぽいんと出るより、
スィングゲージが出て、中央付近とかタイミング良く押せたらお金が入る、
とかの方がまだ間が待つ面白さは少しあったかなあとか……
まぁこれはやっても良かったんですが、他が優先されるっていう制作の余裕の無さからですね……
あとDLsiteで発売されてみないと分からない事ではありますが、エロとしてもサイズフェチとしては恐らく微妙だろうなと。
ただそのウルトラマン・レディーみたいな、巨大娘的な性癖が自分は今いち分からないかな……という根本的な面はあり。
こういうのがええんやろというのは勿論経験からして知っているんですが、
例えばビルをまたぐ巨大娘の一枚絵が報道風に入るとかですね。
果たしてそこに手を掛けていいのか、自信の無さがあったってのはある。
今回はゲーム画面、会話画面、エロ画面みたいに分けましたけど、
そういう報道とか、ゲームの途中に他のパートが入るみたいな所が、
ここは前も言ってる通り画面遷移にまつわる根幹の所なんでもう初めからやり直しになるくらいなんですが、
災害パニックとしては案外重要だったんじゃないかなって感じは覚えますねえ……
そんな訳でゴジラ vs ガメラじゃないですが、次回、アンゼリカ VS ルア、南海の孤島の大決戦とかあったら
そこを考慮したい所です。
まあ売れないだろうから第二段は無いし、南海の孤島の大決戦だと映画なら良いかもだけど、
ゲームとしては絵面が微妙だろうなあ…… まあ……はい……
この記事が気に入ったらサポートをしてみませんか？