Scratchでアクションゲームを作る（キー入力制御）
Scratchで、キー入力を作る場合、
通常、イベント＞〇〇キーが押された場合で作る。
しかし、次のようなアクションを考えた場合、
このイベントだけでは実現できない。
①しゃがみ攻撃
↓キーを押している間しゃがみ状態になる。
しゃがみ状態で攻撃した場合、しゃがみ攻撃になる
②斜めジャンプ
↑キーを押すとジャンプする。
→↑キーと素早く入力すると斜めジャンプになる
③溜め攻撃
aキーを押すと攻撃
aキーを押しっぱなしにすると溜め状態になり、
2秒後に放すと、溜め攻撃になる
ではどう実現するのか・・と悩んだ話をします。
結構難易度が高いので、ちゃんと説明できるか不安ですが、
とりあえず説明します。
普通のイベント＞〇〇キーが押された場合の問題点は何か？
ここから、説明します。
問題点．〇〇キー１つのキーかつ、押されたときしか制御できない点
実現できないアクション例は、2つのキーを使うか、
１つのキーの押されているかどうかを使うので無理ということ
つまり、操作で使うキー、それぞれが押されているか否かの状態が必要になる。
このためだけのkeyスプライトを用意します。
keyスプライトは画像とか、いらないです。
十字キー、ボタン、Bボタンぐらいの変数を持っていて、
十字キーは、電卓の位置に合わせ、key2,key4,key6,key8という変数と、
keya,keybという合計６個の変数を持っています。
どれかのキーが押された場合というイベントに対し、それぞれ６個のキーに対応する変数に１をセットします。押された状態ならば、１ということになります。
入力の最後と、表示処理の最後に、
keyupした?というメッセージを送るようにします。
そして、keyupした?を受け取ったら、
それぞれの変数に対応するキーが押されたではない場合、変数に０をセットし、
押されたか、押されてないかを変数で管理できるようにします。
そして、プレイヤー側のスプライトにコードで、
keyスプライトの変数を利用して、アクションの判定を行うという流れになります。
これで、斜めジャンプの入力をクリアできました。
次に、しゃがみ攻撃についての実現です。
これは、プレイヤー側のコードに、しゃがみの状態と、溜めの状態を変数で管理する必要があります。
しゃがみ状態は、キーが押されていればしゃがみ状態になります。
しゃがみ状態で、↓キーが押されていないなら、立ち状態にするといった感じになります。
するとしゃがみ攻撃は、state1というのにcrouch か、 standとなるので、
攻撃時にstate1との組み合わせて、画像を変更すればOKになります。
最後に溜め攻撃ですが、こちらも、
キースプライトと、state2という変数を用意し、charge状態かどうかで、実現可能です。
攻撃ボタン（keyスプライトの変数keyaが0）をはなした場合、
攻撃発射となり、溜めた時間によって、チャージ攻撃か、通常攻撃か切り替えるって感じです。
Scratchでアクションゲームを作る（背景スクロール）
アクションゲームの製作の続き
食いしん坊な甘露寺が、食い物を食べながら、ひたすら走るゲームを考えた。
ちょうど、無限列車のDVD得点のブラウザゲームで、炭次郎・伊之助・善逸が走るゲームがあったので、そんな感じのゲームを目指した。
①ひたすら右に進む
②進んだら得点加算
③道中、敵がでるので避けるか、倒すかする
④道中、アイテムを取って、腹を満たす
⑤腹が減ると体力が減る（不思議のダンジョン仕様）
⑥体力が尽きたらゲームオーバー
ゲームオーバー時の得点を競う感じのゲームだ
ひたすら右に進む件については、
これはマップスクロールする必要がある。
甘露寺自体は、動かずに、背景が流れていく表現だ。
背景のスクロール
背景画像を用意する。
刀鍛冶の里のような山奥のイメージ。
これを、反転した画像と組み合わせて、長い背景を作る
そして、キャラクターが歩いたことで変数により、表示する基準点の座標を、
右に動かしていく。
ゲーム内の歩いた座標から、背景は何コマ目に相当するか計算
例えば、この背景の画像が256pxだとすると、256歩動いたら、1枚分スクロールしたことになる。
0歩だとしたら、背景①のみが表示される。
128歩だと、背景①が右半分だけ表示され、反転版の背景②が左半分だけ表示される。
256歩だと、背景②が丸々表示され、
384歩で、背景②が右半分表示、背景③（＝背景①と同じ画像）を左半分表示するといった感じになる。
これをスクロールという単位で、右方向の位置（歩いた位置）を変数で管理し、
これをもとに、↑のようなスタンプによる表示処理を作る。
ちなみに悪魔上ドラキュラのようなゲームをつくることを考えると、
この背景の素材がたくさん必要になるので、今回は、ひたすら森っぽい背景で、走ることにした。
ちなみにこのスクロールが発生した場合は、
プレイヤー以外の敵やアイテムなども、スクロールにより、左側に動くようにしないと、不自然になる
Scratchでアクションゲームを作る（ドット絵）
Scratchのアクションゲームは結構ある。
比較的スプライト単位でアクションを制御すれば、いけるのかなと思う。
ということで、私のほうも、アクションもゲームを作ってみようと思った。
そして、子供を引き付けるために、鬼滅の刃を題材にすることにした。
まずやり始めて思ったこと、
素材がない → ドット絵描くか・・→２週間ほど、ドット絵を学ぶ。
ドット絵は、Edgeを使うと描きやすかった。
高機能ドット絵エディタ EDGE | TAKABO SOFT
子供にドット絵の説明をすると、やりたがって、今ではすっかりEdgeマスターになっている。
１週間目、解像度＝絵師の実力だと気づいた。
32px×32pxだとアイコンみたいになってしまう。
アクションゲームのキャラなので、ある程度ジャンプや攻撃のモーションで表現をしないといけない。
既存のゲームはどうしているのだろうか・・
FC 悪魔城ドラキュラのドット絵を参考にすることで、
96px×96pxぐらいが、現在の自分の目標値かと考えた。
ちなみに、スプライトリソースというサイトで、昔のゲームの素材を見ることができる。
https://www.spriters-resource.com/
動きのあるドット絵で躓く
ドット絵素人から見ると、キャラクター歩かせるモーションで、
何枚も画像描くのって割と狂気ですよね。
それで、一番わかりやすかったのが、以下のサイト。
https://robi-record.com/dot_walk/
この雰囲気でドット絵をまねて、甘露寺を作ることにした。
まぁ今の実力ではこんなところだろう。
とりあえずゲーム作ることが目的なので、これを動かすことに注力しよう！
Scratchでゲームを作るコツ
Scratchで複雑なことをするのは面倒だ。
しかし、ある時私はScratchの限界を知りたくなったので、
結構、複雑なゲームが作れるか試してみた。
ぷよぷよっぽいパズルゲーム
https://scratch.mit.edu/projects/250474669
結論でいうと、失敗、ほぼ作れないと思われるというか、
作り方を間違えたというか・・
普通のゲーム作るときの感じで、描画処理を中心に作ったのが失敗。
描画処理と呼んでるのは、Scratchのペンを利用し、
画面で必要な情報をすべて変数で持ち、単位時間＝0.1秒ごとに、以下のような処理を繰り返して、画面の表示を行う手法を言っています。
①ペンの描画をクリア
②変数から、状態を計算
③スプライトの位置を計算し、スタンプ
その結果、入力操作、ブロックに関する処理、描画時間がかみ合わず、
軽快に動作しなくなってしまった。
Scratchでパフォーマンスの問題は解決しにくいという結論になり、
これ以降、軽快な動作を確保しつつ作ることを教訓に得ました。
次に、RPGなどのマップチップを活用したゲームに挑戦しました。
https://scratch.mit.edu/projects/417775647
ちょっとバグってますが、描画自体はできます。
しかし、続けていって、わかったんですが、素材数の暴力がきつい。
Scratchでは仕組みが簡易的過ぎてある程度の情報量があると、DBが使えないのが厳しくなります。
キャラクターの動きなど、リソースが増えるほど、
ロジックが増える、素材も増える。
そう、つまりゲーム開発は素材との闘いなのだと気づいたわけです。
そこで、素材の少ないゲームといえば・・
ADVゲーム風のUIを作ることにしました
https://scratch.mit.edu/projects/417125372/
これはうまくいったかな、ストーリー部分の入力は気合が必要になります。
こんな感じでまとめると、Scratchでゲームを作るコツとして、
以下３点を気にする必要がある。
①メッセージの制御
作るゲームにはどういったシーンがあるのか？
シーンに応じて、メッセージを作るとよさそう
②リソース数の検討
登場するキャラクター数、モーション数、エフェクト数、アイテムなどのアイコン数、
効果音など、使いまわしも加味しつつ、全数が少なくなる検討が必要
③入力制御、表示時間の管理
ペンによる描画なら、１コマあたり、何秒間隔で表示するのか、
クローンを使うなら、メインのゲーム画面で、大体どれぐらいのクローン含めたスプライトで動作するのか
実際試してみて、すこしでも表示が遅いと感じるなら、減らすか、
そもそも、絶対数を決めてゲームを作るか
そうなると、RPGのようなリソースが多いタイプのゲーム、
格闘ゲームのような、入力時間がシビアで制御が複雑なゲームは結構厳しいということになる
Scratch その２
Scratchでシンプルなゲームをとりあえず完成させました。
インカの黄金というボードゲームのようなゲームです。
https://scratch.mit.edu/projects/318536747/editor
前記事、ボードゲームのシステムロジックが面倒というのを、できる限り頑張って作りました。
まともに遊べるゲームとしては初めての作品になります。
Scratchでのゲーム制作では「メッセージを受け取ったとき」の制御が生命線とわかりました。また、スプライトの分け方、個々のスプライトで比較的独立した動きをしたほうがいい、それで複数のスプライトを連携する際に、メッセージの制御が重要となります。
1ラウンドのルール
①洞窟を潜っていって、ゴールドを山分けする。
②同じ見た目の敵に出会ったら、力尽きてゴールド没収
これを3ラウンドし、ゴールドを競うような形でゲームを作りました。
進むとゴールドを山分けしながら、増やす。
戻ると、これ以上宝箱からゴールドを得られなくなりますが、
道中、山分けしたあまり部分を手に入れることができます。
要するに、どのタイミングで戻るかどうかの駆け引きが、面白いのがインカの黄金というボードゲームです。
8人までプレイヤーを想定しており、その場にいる人たちが、
端末を回しながら遊ぶ仕様です。
作っていての不満点だと、システム制御のロジックで、
システムメッセージのようなものが必要となるケースが多いです。
↑のゲームでは、ふわふわ浮いているナビのキャラクターにしゃべらせて、ゲーム進行しているんですが、この会話の部分が、既存の「見た目＞〇〇と〇秒言う」ブロックに依存するので、ゲームの雰囲気に合わせてメッセージの進行をいじれないのが不満です。
どうしても、Scratchでは基本的な会話は、吹き出しで表現するしかないわけです。
その他、ドラクエ風のUIは、背景黒、白字で表現するので、
リソースを作らなくてもある程度様になるのは、ドラクエ風のUIが優秀なんだろうかと感じます。
また、画像を拡大して、洞窟に入る表現をしたり、
フェードイン＝ゆうれいなどの画像効果で作ったり、色々テクニックがあるんだなと気づく作品になりました。
しかし、子供に説明するには難解すぎる。
Scratch その１
私は、子供のプログラミング学習向けにScratchで作っている。
プログラマにとってScratchは、Visual Studioでフォームを作っている感じが強い。
とりわけGUI操作でマウスの操作が多いのがストレスになる。
エディタでコードかけたらなぁーと思ったりする。
さて、どんなゲームにしろ、スプライトの移動操作はある。
すると、X,Y座標が登場するので、小学校高学年以上であれば問題ないと思うんだが、
低学年の場合はそうはいかない。
こういう過程は、Scratchに限らず、いい勉強になる。
回転するプログラムを触ることで、角度を学ぶので、
算数で分度器の存在をしらなくても、角度についてほぼ理解している。
しかし、子供の想像力は素晴らしいとよく聞くが、
思ったより、Scratchで何かやりたいという気持ちにはならないようだ。
そもそも、Scratchで何ができるんだろうか・・
そう思った私は、いくつかScratchで何か試してみることにした。
最初にボードゲームを再現できないかと考えた。
・カタンっぽいマップ
https://scratch.mit.edu/projects/248261878/
・サイコロ
https://scratch.mit.edu/projects/248482441/
作ってみると、マップやサイコロなんかはそんなに難しくないんだが、
そもそも「●●のターンですよ」とかそういうプログラムが、とても面倒だということに気づいた、子供にとても説明ができない。
ということで、もっとロジックが簡単な、
赤ちゃんでも遊べるドラムのアプリのようなものを作った。
https://scratch.mit.edu/projects/249298771/editor/
複数キー同時押し制御など頑張った。
ロジックはシンプルなので、こういう感じのほうがScratch向きだとわかる。
老エンジニアたちの挽歌４
主「予定管理したい」
この時のシステムは、Googleカレンダーを駆使して、予定を登録し、
カレンダーのタイトルや詳細に、内容がわかるように、
コロン区切りで入れる。
例えば、
講師名：生徒名：内容：科目：授業時間：休みなどのステータス：・・
といった感じ。
自作の業務システムのほうで、Googleカレンダーを読み込み、
コロン区切りをばらし、正規表現を駆使して、自前のDBに当て込むことをしている。
※自作業務システムは往年のさくらインターネットを使っている
その時にの弊害として、取り込むたびに、確定していた予定が、誰かが過去のGoogleカレンダーをいじるせいで、書き換わってしまう。
自作システムのほうで操作した内容が失われる。
あげく、受講料計算などを間違えることにつながっている。
私「かなりやばいですね」
主「どうやって対応すればいいですか？」
私「業務にGoogleカレンダーは使わないっすよね。
なので、業務システムのほうで、カレンダー機能もちますよね」
主「カレンダーのUIみたいなのって作れるもんですか？」
私「Googleカレンダー通りではないですが、fullcalendar.jsとか使えば、
それっぽいものはできます」
主「作ってみてください」
私「わかりました」
１か月後、
私「とりあえず、それっぽいものはできました」
主「いいですね、これでいいや」
A「Googleカレンダーに比べ見劣りしますね」（そりゃな・・）
私「これでよければ、業務カレンダー機能をこの画面で対応する」
主「旧システムにいれられますか？」
私「旧システムは全然手をつけてないので、ノウハウ共有するので、
Aさんか、Bさんが旧システムをメンテすれば対応できるんじゃないですか？」（無理だな）
主「じゃあ、新しいシステムのほうで対応するでいいです」
私「休み判定とかどうするんですか？」
主「どうするつもりですか？」
A「・・・・」
私「API連携じゃないですかね」
A「じゃあAPI作ればいいですか？」
私「ほかに方法思いつきますか？」
A「・・・・」
A「・・・・」
私「例えば、さくらインターネット側から、AWSのDBを読むことは可能ですが、
逆はできません。将来的に、業務システムの画面が新システムになるから、
このほうが、将来性は高いと思います。
相互連携するなら、さくらインターネットやめて、全部AWSか、APIですね」
A「APIで！」
主「一応、さくらインターネットで、AWSから参照できるように対応できるかしらべてください」
：
その後、さくらインターネットの上位プランで、一応可能になるようだが、
インフラ代が５万ぐらいになるので、断念。
古いシステムがさくらインターネットで動作し、
新しいシステムをAWSで開発するプロジェクトはちなみに４回目になる。
大体末路として、古いシステムは消滅する。
私「古いシステムをAWSに移行したほうがいいです」
主「総合的にほかのエンジニアの意見を聞きましょう」
A「大変じゃないですか、（反対です）」
B「それ（AWS)は,なにか普通のサーバーと違うんでしょうか？」
私「ふつうのサーバーを仮想化して、ソフトウェアの状態で利用します。
そのため、バックアップとかが非常にしやすくなります。
中身は普通の空っぽのlinuxと変わらないので、いったん再構築は必要となります」
B「古いシステムは特別なものをインストールしてないので、動くと思うんですけどね」
私「では移行したほうがいいと思います」
主「移行するメリットは？」
私「AWSのリソースが利用できる。特にDBの共有ができるので、データ連携とかAPIとか作らず解決可能になります」
主「デメリットは？」
私「APIの開発ですね」
私「結局、移行工数と、APIの開発工数がトレードオフ要素といった感じにはなります」
B「結局何をすればいいんですか？」
私「AWS環境に古いシステムを乗せ換えてテストする感じです」
A「動作するか保証できない」
B「わかりました。検討します」
：
その後、Bさんが持ち帰って判断材料を出し、
結局動作確認が難しいとなった。
Googleリソースなどの外部連携要因が多いのはしょうがないと思う。
これにより、API開発が必要となり。
そのAPI開発工数が半年以上かかっても完成しないとは、この時点では誰も考えていない
