ぼちぼちまちま日誌2

【キャラ語り】ノチ

前回予告した通りのノチです。

20200531204407.png
【ノーチラス】
一人称:僕 / 二人称:君、あなた
地獄の十王の1人。生前は人間。「ノチ」と呼ばれることが多い。
性格について、りちるからは「野心家」、閻魔からは「マッドサイエンティスト」と評されている。また、本人としてもおおむね同意している模様。
生前は科学者であり、十王になっても科学者。海洋学者が一番近そうだが造船したり未開の島を求めたりすることもあるため、「科学者(広義)」というのが適切かも。
海と未開のロマンが好き。科学者ゆえなのか非科学的なものに対しては少々キツめ。特に神話に対しては「荒唐無稽な絵空事」と言う程度には辛辣である。そのため海神であるシャボンとは当然仲が悪く、ノチ単独でシャボンと接触することを閻魔から禁止されるレベル。(と言っても一方的にノチがボロクソ言ってるだけであり、シャボンからノチに対して好き/嫌いの感情はない。) ただ非科学的なものすべてが嫌いという訳ではないらしく、例えばトトロとかオカルトとかそういうのは好き。恐らく科学的事実を否定した作り話的なものが嫌いなんだと思います。

【服装】
仕事の関係で服をガンガン汚すため、汚れても惜しみなく捨てられるよう簡素・質素な服にしています。立ち絵では見映えの都合でコートをなびかせていますが、実際のコートはもっと重量感があり高級感があります。むしろコート以外全部安い。ブーツはレインブーツっぽいものですが、レインブーツよりも通気性はあるイメージです。バッグはナイロンなどの頑丈な布でできたウエストバッグであり、またバッグも服も同様汚れたらすぐ捨てられるようなものを使用しています。

【持ち物について】
20200531204408.png
①カメラ
ノチにとっての必需品。インスタントカメラとG〇Proみたいなカメラです。
撮ったものをすぐ現像できるように、カメラは一眼レフではなく写真後即現像できるタイプのインスタントカメラにしています。現像にこだわる理由は「電気や無線が通っていない場所での作業」を想定しているからで、撮った写真は風で飛んでいったりしても良い程度の一時的なものを被写体にしているイメージです。
一方のGo〇roっぽいカメラは動画などが撮れるタイプです。こっちは保存用。ただ「写真撮るぞ!」って時は画質の綺麗な別のカメラを使うので、こっちはいつどこで何があっても写真を撮れるように……といったものです。

②スタンガン(?)
ノチらしい変わり種アイテム。
ノチは既に死んでおり護身する必要がないため、護身用のスタンガンというよりも「対象に電気を流す」ということに特化したような形状をしています。
具体的には水に電気を流したり一時的に生物を怯ませるときなどに使います。小型なのでちょっと電気流したいな~ってときがあったときにしか使いません。あくまで日常用(日常?)。大がかりなものはノチの実験室にあり、実験などの時はそっちを使ってます。

③武器類(拳銃・サバイバルナイフ・毒薬)
拳銃に入れる弾は普通の弾丸と麻酔と電気銃。
使用用途はいずれも狩猟などであり、あまり護身は意識していません。護身目的ではないため、すぐ武器を抜けるようなところにはしまわずカメラなどと同じくウエストバッグに収納しています。電気銃は『海底二万里』でネモ船長が使用していたのが元ネタ。

体験版について

20200518182730.png
ツイッターのほうで既に呟いていますが、色々と進展あったのでブログでも改めてお知らせです。
なお、あくまで現時点の方針ですので今後の進捗によって変わると思います。そこだけはご了承の程よろしくお願いします。

●体験版の公開方針:体験版と開発版
体験版を公開する前に複数回にわたって開発版を公開する予定です。
まず開発版と体験版の違いについて。開発版は「難易度調整や操作性確認のためのもの」で体験版は「ゲームに興味を持ってもらうため」ということを目的としたものとなっています。基本的に開発版のほうが公開頻度は多いですが、開発版ではバグ修正は次回開発版公開に持ち越す予定です。要するに開発版Aのバグは開発版A-0.01で更新される訳ではなく開発版Bで更新されるということです。体験版はその逆のイメージです。

●体験版と開発版の公開スケジュール
今の時点では以下のように予定しております。(当然修正される可能性あり)
・開発版① : 6月あたりを目途。1-2を収録。
・開発版② : 10月、11月あたりを目途。2-1収録。
・開発版③ : ステージ1を収録。
・体験版① : ステージ1を収録。
以降は不明。ストーリーは一気に読んでいただきたいと思っているので後半を含むものはまとめて開発版!ってことになるかもしれないです。

●開発版①について
開発版①は以下のような仕様になる予定です。ただ、1-2だけだとあまりにも短すぎる感あるので1-1と1-2をまとめるかもしれませんし、中ボスを追加した特殊仕様になるかもしれません。というかそうしたい。
・収録は1-2のみ。プレイ時間は早いと1分くらい。もうちょっとボリューム持たせた場合は3~5分くらいになるかと。
・BGM/SEもしかしたら入らないかも(ごめんなさい)

「開発ページを作りたい」ともツイッターで言ってたんですが、これに関しては作ることで決定しました。
開発ページができあがったら開発ページのほうにhk3の情報をまとめていく予定です。開発ページにも新着情報の項目を設けますが、開発ページの新着情報は本当に進捗報告に特化しますのでブログの開発日記は相変わらずです。

大体こんな感じです。よろしくお願いします~。以下色々報告。
●pixivFANBOX更新しました。
【モーション】短刀:ダッシュ攻撃 + 小ネタ:武器を取り出す/しまう
●ノチの立ち絵描いた
今hknhのサイトが止まってる状態なので更新に時間がかかりそう……です……!すみません。
とりあえず次のブログあたりでノチ取り上げます。その時に立ち絵も上げるのでひとまず今日はツイッターのリンクのみで。

何だか色々エトセトラ

近況報告だったり進捗報告だったり何だったりのごった煮記事です。

【hk3進捗】
それなりに進んではいるんですがネタバレだったり水面下の作業ばかりなので特にスクショ映えするような進捗は無いです。今は中ボスのAIコモン作成中。
中ボスってザコ敵よりもAIに個性があるけどボスほどではない、みたいな認識だったんですが、な、なんだろう……癖、強くね……?
私のコモンの書き方が無駄に行替えを使うからというのもあるんですが、今作ってる中ボスのAIコモンが1000行超えそうで、作者としては想像以上にボリュームあるなーという驚きがあります。これボス3000行超える可能性ない?大丈夫?
行数増えれば増える程コモン開くのに負荷がかかってる感じがあるので、ボスはAIコモン細かく分けようか検討中です。
ちなみにザコのピクチャパターンは20枚未満であるのに対し、中ボスは30~40枚くらいです。まだボスのピクチャ作ってないんですが果たして何枚になるのやら。

当初の予定では体験版は出すつもりなかったんですが、難易度とか操作性に対して不安が多いので一転して体験版出す方針にしました。
体験版では1-2、2-1を公開する予定ですが、体験版(1-2、2-1)なのか体験版a(1-2)、体験版b(2-1)という公開方法になるのかは不明です。まとまってるほうが体験版として良い気はしますが、フィードバックを目的とする場合はa公開→改善したbを公開 みたいな方針のほうが良いような気もするんですよね。まだまだ公開の見込みがたってないので体験版公開できそうな頃になったら改めて告知します。
実を言うと今の時点で1-2体験版公開できる範囲のアクション部分は終わってるんですけど、GUIが全くの手つかずな為に公開できないという。GUIさえなければ公開できるんです……でもGUI進捗0%進む見込みナシのガン詰み状態なのでまだまだ体験版公開できる見込みが立たないんです……。

【BOOTHで公開した素材について】
これのことです:【立ち絵素材】メイド
DL数0件だったら凹むな……と怖さ半分でDL数確認したら思っていたよりもDLされていたみたいで嬉しかったです。ありがとうございます。この素材が創作のタネになれば嬉しい限りです。
「クレジットしていただければ報告は任意」みたいなスタンスですがやっぱり報告あると嬉しいです。ってことでご報告お待ちしております!

【近況報告】
戦国無双4買いました。
三國無双7買ったときは作業がきつかったのもあって1か月くらいゲ製から逃亡しましたが、現時点では逃亡はしない……はず!したらごめんなさい。

絵とか

20200428211803.png
久々にギャラリーページにイラスト追加しました。よろしくお願いします。
あとBOOTHに描いた立ち絵を無料素材として公開しました。→【立ち絵素材】メイド - のろらる通販部 - BOOTH
何となくサイコパスっぽい雰囲気のあるメイドさんです。「口も眉も動いてるけど目だけ表情がない」っていうのをやりたかった結果こうなりました。そういう訳で表情に硬さがあって使いにくいかもしれませんが、うまーくこねくり回していただけると幸いです。
20200428212216.png

今までの塗りに対して何となく古臭さや芋っぽさを感じていて、何とか垢抜けられないかなぁと試行錯誤中です。
塗りの古臭さの件のほかに、作画コストなどを色々再考するとどうしてもコスパの悪さが拭いきれなくて、どうにかこうにか早く描けるようにできないかなーと思うこともあって、まぁ色々とあって今に至ります。
一番上のイラスト描いてて「あれこれ良くない?」と思ったのでしばらく練習していこうかなーと思います。

2020年に入って一番ってくらい絵を描くモチベーションが高いんですが、Twitter見ると何となく察せられるようにゲ製メチャクチャ修羅場です。
システムの根幹部分を「とりあえず動いてるからヨシ!」で放置してる上に増設しまくった結果このザマです。もうやだ。そろそろこの作業抜けたい。

武器調整中

あたり判定システムの工事が終わったので遠距離武器の設定を行っています。
今までのあたり判定システムのDBがゴチャゴチャしてて大変なことになってたのよね……処理負荷うんぬん気にするよりも管理しやすさを重視したほうが良いよな~~とつくづく実感しました。

タイトルの通り、今は遠距離武器(今回は弩)の調整を行っています。
攻撃的な性能にしながらも、短刀とどっこいの性能にしつつ、でも弩1つでラスボス倒せるような性能にしたいんですが……これが結構難しい……。弩を強くしすぎると短刀のメリットが完全に消えちゃうんですよね。わざわざ近づいて攻撃するよりも遠くから撃ったほうが良い。

やっぱり遠距離の「敵の攻撃が当たらないところから攻撃できる」特徴ってめちゃくちゃ強いんですよね。背後から突然ゾンビの大量の群れ!みたいな時は攻撃範囲・攻撃力がある近距離の強みって現れると思うんですが、2D横スクロールゲーで難易度簡単なゲームにそんなシチュエーションってそうそうありませんし。「敵がどこにいるか視認できる・急に敵が死角から襲ってくることはない」環境において「火力が高くて攻撃頻度がすごい短距離」と「遠くから攻撃できる遠距離」だったら遠距離のほうが絶対安全ですしゲームオーバーせずに敵倒せますし。難易度高いゲームだったら適材適所で武器を選んだりいかにコンボを繋げるかって重要なスキルになりますが、hk3はアクションゲード下手でもできるような難易度にしたいのでそういうスキルは求めないようにしたい。となると、使用する武器を選ぶ際「安全に攻撃できる」という特徴ってめっちゃ強くね?となる。

まぁそんな訳で散々短距離の悪口言いながら、何とか短距離強くしようと思って短刀は使いやすさを第一に意識してます。使いやすい短刀に比べ弩はもうちょっとテクニック性合ってもいいかなーと思ったり、弩の攻撃のスキあったほうがいいかなーとか思いながらコマンド組んだところ、テンポクッソ悪いわ使ってる感触ないわで本当~~テストプレイ1回目で「使いにくいッッ!!!!」って速攻で武器切り替えました。ダメじゃん。

今テストプレイ3回目くらいのところにいますが、テストプレイ1回目に比べて良くなってると思う(多分)のでぼちぼち頑張ります……。

【報告】pixivFANBOX更新しました。支援者の方向け記事でメイキング公開してます。
【メイキング】モーションが完成するまで~はしご移動~
twitterでは繰り返し言っていますが、pixivFANBOXでは「今まであまりやってないことをやる」みたいなスタンスですので「今までよくやっていたことをpixivFANBOXのみのコンテンツにします!」って事はしません。私個人の方針としては、pixivFANBOXは「サイト・SNSでの活動+α」の+αにあたるところって感じです。
とは言っても、今まで面倒臭かったり公開したくなかったりでやってなかったけど実はやりたかったんだよなぁ!みたいな事はそれなりにあるので、そういうものをFANBOXに流すのもありかな~とか思ったりしてます。自分と相談しながらもう少しFANBOXのコンテンツは増やしていきたいなと。
ちなみに全体公開でこんなコンテンツ公開したりしました。
【全体公開】本の紹介①:妖怪系の本あれこれ

【ウディタ】デバッグで詰んだ箇所メモ

ウディタ製ゲームのバグ取りの際に何十分も足止め食らった箇所として記憶にあるものの個人的まとめです。
起動条件・イベント移動系のバグがないのは作ってるゲームの仕様上ほとんど使うことがないからです。

【CDB読込み/書込み場所の指定を間違えてる】

20200419170539.PNG
割とやらかす。
下みたいに指定する変数を間違えた例について、単純に変数の指定を間違えた場合ならまだいいんですが、「Cself24で値を取ってCself25に入れて、Cself25を使って違うDBから値を取る……」みたいなことを何回もやって「あれ、これってCself24?Cself26?」ってことになるとバグ取りで大混乱が起こります(実際に起こりました)。DBにアクセスする可能性がある変数が複数存在する場合は名前の付け方に気をつけような……!

【数値代入の変数間違えてる】

20200419170540.PNG
これもまぁやらかす。明らかにおかしい値が出たら多分これ。
バグったらバグ起こった箇所前後を精査することになると思うので、前後のやつに比べるとある程度気づきやすいと思います。

【DB読込んだつもりだったけど読み込んでない】

つい最近こいつで30分詰みました。
条件分岐Aの時にa,bを、条件分岐Bの時にb,cを読み込むとき、条件分岐Bで実はbを読み込んでいなかった みたいな奴です。
前回呼び出した時のbの値が残っており、条件分岐Bで処理したいbの値と偶然一致したりすると上手く動いたりするのでまぁ気づかない。
ちなみにこれについては、「DBを読み込むタイミングを統一する」である程度対策取れます。というかスクリプトの視認性考えても読み込むタイミングを統一したほうが良いかと。
ただ、DB読み込む項目数が極端に多い・文字列を複数読み込む場合などで処理落ちが心配な場合は、とりあえず最初の処理でCself10~Cself99=0入れるのが良いと思います。それで処理おかしくなったらこれが疑わしいかなー。

マップ組みとギミックあれそれ

マップの外観は去年に大方終わらせてるので、今はマップの中身(ギミックとか、エネミーの配置とか)を組んでます。
エネミーのAIも組んだ!移動コモン作った!坂道も正常に動く!さぁイベントをガンガン設置していくぞ!俺は今ゲームを作ってるんだ!と意気込んでましたが、そ、想像以上につまんねぇ……。まぁ地形見ながら坂道はここからここまでの座標でーとかそういう作業なのでつまらなくても仕方ないね。ちゃんと動くとテンション上がることには上がるのでそれをモチベに頑張ります。

マップに向き合ってることでギミックもじゃんじゃか作ってるので、とりあえずギミックの紹介。

【スイッチ】
割と早い頃に登場します。攻撃することでスイッチが押下され、ギミックが作動したりします。
攻撃で作動するタイプか触ると作動するタイプかで悩みましたが、触ると作動する場合は仕組みに気づかずに作動しちゃう可能性が十分にあり得るので攻撃で作動するタイプにしました。

【強制スクロール】
ザ・アクションゲームっぽいギミックです。それなりに早いタイミングで登場します。
あまり頻繁に登場するギミックではないのですが、登場するマップが異様に長かったり変則的だったりするのでもしかしたら鬼門になるかも。
もし難易度が極端に上がるようだったらコンティニュー時の救済措置もありなのかなぁとか考えてます。ひとまず保留。

【破壊ブロック】
名前がわからない!!攻撃すると周囲のブロックを壊す奴ですね。序盤の最後のほうで出てきます。
スイッチが汎用性高いので何でもかんでもスイッチでもいいんですが、あまりにもスイッチに頼りすぎてる感があったので入れました。
本当は攻撃すると切れるヒモを導入する予定でしたが、ヒモってわかりにくくね……?ってことで破壊ブロックに。例えばヒモで吊られてる足場があって、足場がぐらぐら揺れる~とかなら「あっこれヒモだな?」ってわかりますけど、白い棒一本だったらヒモってわかってもらえるか微妙なんですよね。それならいっそのこと爆弾マーク書いてある破壊ブロックみたいな方が良いかなって。

恐らく今月いっぱいでラスダン以外のマップのセットが終わるので、終わったら残りの武器作って中ボスのAI組んでボスのデザインして~ってところですかね。10月くらいにはアクションパートある程度組み終わりたい……!
10月くらいにはアクション終わらせたい!というと終わり近づいてくるように見えますが、マジのマジで作業量予測不可能なストーリーパートがあるのであと1年は絶対終わりません。2021年下半期~2022年頃完成を目指してます。

サウンド周り整備終わり

サウンド周りの整備が終わりました。
いざ動画で撮ってみると「だから何」感あるんですが、これ本当きつかった……けど、この整備のおかげで表現したいことができるようになった筈なのでまぁ良し。表現したいことに関しては、実際にプレイしてみてからのお楽しみみたいな感じでお願いします。
ものっすごいクセが強かった坂道処理がついに安定化したり、中ボス・ボスのプログラムが完成したりと何だか着々と進んでおります。とは言っても”システムに関しては”の話なので、まだまだやること山積みなんですがね。2022年くらいの完成を目途に頑張ります。

メニュー縮小化

20200402205339.png20200402205340.png

上がステージ内でのメニューで、下がワールドマップや一部マップでのメニューです。
下はゴチャゴチャしててわかりにくいですが、「操作方法・オプション・セーブ・ロード・タイトルに戻る」がメニューです。

今までの予定ではステージ内とワールドマップとでメニューを分けず、一つのものを使うという方針でしたが、セーブ・ロードはステージでは使わないし……あと○○も使わないんだよな……って削っていった結果、結局メニューを分けることにしました。
また、今まではあった「ストーリーあらすじ」を廃止し、「アイテム回収率一覧」はワールドマップのシステムに組み込んだりと全体的にスリム化させました。
オートセーブにする?とか散々言ってたセーブは結局メニューに表示する形にしました。
操作方法はカットしようか悩み中ですが、低難易度ゲーという事を考えると表示しててもいいかなという事で表示中。

GUI作るの苦手すぎてどこからアプローチしたらいいのかわからず、とりあえず場所だけ決めとけ~!と思って今に至ります。
「とりあえず中身だけ」っていうの中々モチベーションあがらなくて萎えながらやってましたが、作った結果システムの関係上レイアウトこうしないといけない、みたいなレイアウトの制約が生まれたのでちょっとGUI作りやすくなりました。めでたしめでたし。

【おまけ】
・SKIMA登録しました。のろらるで公開してるコミッションよりもわかりやすい感じの内容になっています。
https://skima.jp/profile?id=110940
・pixivFANBOX更新しました。
https://www.pixiv.net/fanbox/creator/4322080/post/935850

【ウディタ】描画座標シフトメモ

ウディタの描画座標シフトとようやく和解できたのでメモも兼ねて。
正直合ってる自信あまりないのでここ違くね?とかあったらツッコミください。

前提の話

20200326211149.gif

上のGIFはX=200で表示している★マークを200pxスライドさせたものですが、これを実行する方法としては以下が挙げられます(他もあったら補足オナシャス)
(1) ピクチャ移動でX=400を指定
(2) ピクチャ移動で相対座標でX=200
(3) 描画座標シフトでX=200シフト
20200326211150.PNG
1の例はともかく2と3ってほぼ同じじゃね?ってところから今に至ります。ってことで2と3の違いをザックリまとめたあと、使い分けについてのメモりながらのまとめです。

てかどう違うんだよ

前提の話であげた例のX=200を2回実行してみます。
(a)ピクチャ移動で相対座標X=200を2回やる
(b)描画座標シフトX=200を2回やる
20200326211151.PNG
aの場合、今★マークがあるのは200(最初の表示場所)+200(相対移動1)+200(相対移動2)=600ですが、bの場合は200(最初の表示場所)+200(シフト分)=400です。まぁつまりそういうことです。

使い分け例

これは前提の話(1)の移動方法も含めてのメモです。多分実例上げたほうが早い。

ケースA : 右キー押すとピクチャを100px動かす
(1) 初期座標+100+100+100……
(2) 押される毎に相対座標100
(3) シフト量 = 100×右キー押された回数または押される毎に+10020200326211152.PNG

もしかしなくても一番簡単なのは(2)。(1)と(3)は手間としては同じですが、変数操作+のピクチャ情報取得で描画座標シフトの値を取ることはできないことを考えると、(1)のほうが管理的には楽なのかなぁと。後で詳しく触れますが、「描画座標シフトした結果描画されている位置≠ピクチャ座標」なのでここ注意。
ちなみに横スクロールゲームを作る際プレイヤーをピクチャとして描画する場合は移動量を相対でプラスしていくよりも下のやり方のほうが安定すると思います。

ケースB : ウィンドウ表示の際、後半がゆっくりになるように表示する
(1)1回目2回目共に同じ座標を設定し、1回目の移動はディレイ0で、2回目の移動は一定ディレイ置いてから実行
(2)何か上手いこと頑張る(スクショ参照)
(3)座標で指定する例と大体同じ。ただ描画座標シフトにはディレイはないのでウェイトで擬似的にディレイっぽくしています。20200326211153.PNG

(2)はちょっと面倒くさい……というか切り替わるタイミングで一瞬止まったりして上手く行かなかった記憶があります。ってことで、(1)と(3)の事例で絞ります。
移動ピクチャが1枚または複数枚で同じ座標の場合は(1)のほうが記述量が少ないので管理しやすそう。(3)が力発揮するのは座標がバラバラの塊を移動する時ですかね。

つまり描画座標シフトって何

ってことで再び本題。最初に「描画座標シフトと相対移動って大体同じだろ」って言いましたが、相対座標が「○○px動かす」を得意とするのに対し、描画座標シフトは「目的地の○○pxまで動かす」を得意としてるのかなーという感じです。言うまでもなく「目的地の○○pxまで」って動かし方を一番得意としているのは座標で指定する動かし方ですが、座標指定は座標指定ゆえに座標がバラバラの複数枚数の位置関係を維持しながら移動させるのは苦手、というか面倒臭いです。20200326213132.PNG

描画座標シフトが生きてくるのは、「それぞれの位置を維持しながら指定位置まで複数ピクチャをずらすとき」なのかなーと思います。例えばRPGゲーム戦闘画面のHPゲージとMPゲージを動かすときとか。座標をガッツリ指定するとなると「HPゲージはxxピクセルでMPゲージはxxピクセル……」と算出する必要がありますが描画座標シフトならピクチャ指定して○○px遷移でOKです。
もちろん相対座標でもできるんですが、使い分け例ケースBで示したように緩急つけるとなるといちいち「何フレームは何px動かして……」と算出しなきゃいけないので面倒臭い。

一方描画座標の欠点は間違いなく「描画座標シフトした結果描画されている位置≠ピクチャ座標」。例えば複数コモンで1枚のピクチャをアレコレしてる場合、コモンAで初めに座標(0,0)でピクチャ表示→コモンBでX200pxシフト→コモンAでピクチャ移動(200,0)みたいな時、予想したピクチャ位置とは当然ずれます。あとピクチャ情報取得で描画座標シフト量は取れないので「変数操作+」のピクチャ座標取得であれこれする場合も当然事故ります。

まぁつまり、ガッツリまとめると描画座標シフトって「複数枚のピクチャを対象に、それぞれの位置を維持したまま何かをスライドする時」に特に強いのかな!と思います。