2024年6月29日土曜日

JavaScriptでゲームエンジン作ってみた

ゲームエンジン作ってみた
出てきた芽をつつくと昇天する

プログラムで、芽が突かれたらと言う判定をしていると言うよりは芽が自分が突かれた時の処理として昇天するアニメへ切り替えている
つまり、プログラムが制御すると言うよりは
オブジェクトが自分のシナリオデータに沿って動く
オブジェクト指向であり、データドリブンと言うのはこう言うことだと言う例にもなっている
マウスのクリック効果は録画ソフトがつけているので ゲームエンジンで出してるわけではない (やろうと思えばすぐにできる) まだフレームレートの計算でよくわからないところがあって、 適当に調整してしまったんだけど まぁ動いてるからとりあえずいいか・・・ 計算合わないのがすっごい気持ち悪いんだけど・・・ アニメーションはAsepriteで作った 上に飛ばすときにもう一度クリックすることもできてしまうので、判定処理を抜くルーチンを実装してやらないといけない まぁゲームエンジンは大体できてきた


どうもゲームエンジンというものがどういう物かわからないという声が出てくるので説明しておく 画面に絵を表示するとき 絵は矩形で描画する サイズは32x32,16x16など、都合のいいドット数であることが多い 描画するときにX,Y座標を指定するが、 X,Y位置に左上を合わせて描画するのが左上基点 X,Y位置に画像中心を合わせて表示するのが中央基点 X,Y位置に画像の左右中央下端を合わせて表示するのがベース中央基点 まぁ呼び方なんかどうでもいい ベース中央基点は、対戦格闘などでよく使う方法で、キャラクターの地面の立ち位置を基点にして表示する方法だ この方が画面の左右スクロール時に位置がどこなのか考えやすい だが、中央もよく使う 例えば、マウスクリックしたところから四方八方に光を散らせるパーティクル効果を表現するときは、雪の結晶のような画像をX,Y位置に画像中心を合わせて描画する このように都合に合わせて、どこを基点に表示するのか変わってくる これらをプログラムで一々調整するのではなく、Asepriteなどのアニメーションデータで雪がチラつくようなアニメーションを組み、それを再生させながら四方八方に散らせて、最後はアニメーションの透明度で消えていく という制御を、画像側主体で動かすのがゲームエンジンの基本的な考え方だ つまり、画像が自分で自分の次のフレームの画像を切り替え、自分の位置を切り替える プログラムはその切り替えるアニメーションパターンや、四方八方に飛び散る物理演算を設定するだけで、あとは画像側が勝手に動く わたしが先に示した草を引っこ抜くゲームエンジンの例では 「Mebae」「Idle」「Pickup」のアニメーションパターンをAsepriteで作っている


インターバルで草を生成するルーチンは以下2つの指定をしてスプライトを生み出している 1.MebaeからIdleまで再生し、Idleはループさせるという指定でX、Y位置をランダム生成してスプライトを生成している 2.その際、当たり判定を物理演算の一種として登録している。 マウスクリックに当たっていたら「Pickup」へ切り替え、「Pickup」が終わったらスプライトは自己消滅するように指定している 全体のスプライト数もわかるので、60個までで草を生み出すのを止めている

        function isPickUp(spr) {
            if (spr.isTouched()) {
                // Pickupが終わったら消えるように設定
                spr.setTagNames(["Pickup","DIE"]);
            }
        }

        function getRandomInt(max) {
            return Math.floor(Math.random() * max);
        }

        async function dispatch() {
            // 最大60個にしておく
            if (gPrim.primitives.length <= 60) {
                // 乱数で座標を生成
                var x = 32 + getRandomInt(640 - 64);
                var y = 32 + getRandomInt(480 - 64);
                // ["Mebae", "Idle","REPEAT"]のように指定すると、Mebae、Idleの順に実行した後、Idleをリピートする
                // ["Mebae", "Idle","DIE"]の場合はIdleを実行した後Spriteが消える
                var sp = await Sprite.build("Futaba", jsMebae, ["Mebae", "Idle","REPEAT"], x, y, 1, 0);
                sp.addPhysic(isPickUp);
                gPrim.append(sp);

                console.log("dispatched", x, y)
            }
            nextTime = 3 + getRandomInt(5) * 1000;
            setTimeout(dispatch, nextTime);
        }


さて、ゲームエンジンは画面の表示位置だけを担当するのではない 当たり判定、繰り返し、消滅、親子関係(親に追従するかしないかの指定も可)などのほかに、音声再生なども行う 例えば、何もないスプライトを親にして、その子供としてダンジョンマップを登録する 上下左右の移動で、何もない親スプライトの位置を変えれば子供の位置が全部変わる つまりマップがスクロールする 例えばぷよぷよのぷよが、自分の上下左右に自分と同じぷよがいるかどうかを調べ、自分の体を変形させる(その際、変形用アニメも用意されていればスムーズに変形する) こういった、例えばをプログラムだけでやることの愚かさがわかるだろうか? ゲームエンジンを使えば、スプライトが自分で考えて自分の姿形を変え、消滅したり、新たなスプライトを生む出したりもできる ゲームエンジンのシナリオデータだけで、自分がやられたら、子供をたくさん生み出すような敵も作れる 子供は子供の攻撃パターンで動くこともできる 物理エンジンの一種として登録させることができる ゲームエンジンがあれば、
これらを全部同時に動かすことができる
RPGもシューティングも格闘ゲームもパズルも同じ組方で実装できる
ゲームの仕事が来た時に
その都度似たようなプログラムが組みたいならやればいい
わたしはその機種ごとにゲームエンジンを作ってからゲームを作る

ブラウザでよいのなら、ブラウザに特化したゲームエンジンを作り、
スマホにも対応させればよい
G123など、すでにやっているではないか?
あれを作ればいいだけのことだ

 

2024年6月27日木曜日

Duet Web Controller Camera Setting(Microdia)

3D PrinterにつないでいるRaspberryPiにUSBカメラをつけて

Duet Web Controllerから見れるように設定した

※まず、Duet3 に接続しているRaspberryPiにSSHで接続し

1.mjpg-streamerをインストール

sudo apt update

sudo apt install snapd
sudo snap install mjpg-streamer

2.設定
sudo vi /var/snap/mjpg-streamer/current/config


INPUTOPTS="input_uvc.so -y -r 640x480 -d /dev/video0"
PORT="-p 8080"
DAEMON="true"


3.カメラを接続
snap connect mjpg-streamer:camera

4.mjpg-streamer再起動
sudo snap restart mjpg-streamer

これでブラウザから
http://192.168.XXX.XXX:8080/を開いてページが表示される
Streamのところを見るとカメラの映像が見れるはず

続いて
5.Duet Web Controllerの設定
設定→全般のところのカメラのURLに以下を入れる
http://192.168.XXX.XXX:8080/?action=stream

2024年6月23日日曜日

Easeus やられた・・・

SSDのクローンして書き込んでお引っ越しまでできたのだけど

4kアライメントの調整もやってみたら全部吹っ飛んだ・・・

おいおいおい・・・

2024年6月16日日曜日

詳細設計書きたくないと言う話

https://togetter.com/li/2384729

今いる現場でも、四年目あたりの人が同じようなことを言っていた

そもそも、BD、FD、CD、UT、ITなんて用語を知らなかったようだ

基本情報の説明にもあるのだけどなぁ、、、

基本設計から結合テストまでのウォーターフォールについてのドキュメントをIPAがまとめたのは2007年

当時の元気な大企業がよって集まってまとめたものだった

ところが、大企業は各々の文化があり、うちはこうまとめる、よそは知らんという感じで、中身の粒度やフォーマットなどはまとめられないままだった

この投稿で議論されているように、コードの直しが発生する細かすぎる仕様書はメンテされなくなる

仕様書の書き方もよくわからないまま修正したりすれば、さらに意味不明なドキュメントが出来上がり、コードと乖離してるんだよねと言うよく見る状況になる

Javaな人たちは、詳細なんてものはコードからリバースすればいいじゃ無いかと、DoxygenやGraphvizを使ったり、コードからUMLのクラス図を作り上げるようなツールを使いまくって乗り切ってきた

単なる間に合わせだ

このやり方で果たして品質が上がるのか?
もっともな疑問が湧くだろう

大企業様はウォーターフォールをすれば品質が上がると言う論文を自社の社員に大量に書かせて、あたかもこれが一般的なものであると言う根も葉もない根拠を作り上げた

でも、やはり気づくよね?
無理がありすぎる

そんな折、アジャイルが提唱されたのはほぼ10年前だろうか?

イテレーションを繰り返して少しずつ作って行ったほうが早いし、コーディングも綺麗になると言い始めた

だが、わたしは知っている
ゲーム業界は特に仕様書を重視しない
都度コーディングしてディレクターに見せて、指摘を取り込むことを繰り返しつつ、全体スケジュールもきちんと視野に入れた舵取りが行われていた

つまり、ゲーム業界はスーファミ時代からとっくにアジャイルだった

だが、アジャイルだとしても、やはりコーディングする人の技量に左右されまくり、部分部分で全くレベルが違う事態になる

ゲーム業界ではそれでもリリース日があるので、動けばオッケーなレベルで出荷していた

この点どう考えられているのかと
アジャイルについて書かれた本を読みまくったが、お前らそれで物が作れると思ってんのか!と説教したくなった

わたしはそのやり方で失敗しまくった例をたくさん見ているのだ

そうしたら最近だと、アジャイルとは結局何をやっても良いんですよ、うまくいかなかったら工夫してうまくいくようにさせるんですと言い始めた

わたしがそれを聞いた時の感想

おいおい、それができるまでお前ら何度も失敗することになるが、それ、ハウツー本にならんじゃないか、、、

わたしが品質を上げるために重視しているのは、コーディングのレベルだ

コーディング規約ではない

フレームワークと言うものは
ドメインをきちんと取り決めてあり
どこで何をすれば良いのか分かりやすくなっている

これさえも出来ないエンジニアは多い
フレームワークへの理解が足りないから
せっかく用意されている仕組みを使えないのだ

コーディングする人材が勉強不足過ぎるのだ

コーディングとはある意味すごく単純だ
出来ることは代入、条件判定、ループくらいのものだ

しかしコーディングのお題を与えると、人によってすごく短いコードになったり、膨大なコードになってさっぱり意味がわからなかったりする

イベントドリブン、ドキュメントビューアーキテクチャ、モデルビューコントローラ、オブジェクト指向、DDD、機能指向、アルゴリズムとデータ構造など、、、

今迄数多くの概念が提唱されてきたが
マイクロサービスなんてものを見ると、モジュールベースで、機能指向でより単純化されているし、こんなものをasp.netやSpringで作るとしたらバカくさくてやってられない

わたしが言いたいのは
シンプルに考える事の重要性だ

まず画面をシンプルにする

お客様は画面しか見ない
我々も画面でしか表現できない
まず、業務システムなら機能はそこそこで紙芝居画面を作りそこでオッケーをもらったら作る
作っててダメならまた見せる
これの繰り返しで品質は上がる

次にデータの持ち方をシンプルにする
データベースはそこそこ意味があったが
それでは足りなくなっている

XMLやJSONカラムを使った方がシンプルになる場面が多いのに、旧態依然としたSQLしか知らない輩が偉そうにテーブル定義を作る

もちろんそれで動くものは作れるが
よくインサートされた内容を見てみろ
しっかり階層構造になってるだろ?
ならば何故二次元で考える?

今までやったことがないから?
以前はこれでうまく行ったから?

だからお前らのテーブル定義は
出来上がった瞬間に中古物件になってるんだよ!

階層構造を理解できないと言う事は
勉強不足なのだ

新しいSQLの拡張をもっと勉強するべきだ

最後にフレームワークの使い方
どのフレームワークもMVCだろうが
言語によって実装は結構違う
一通り自分でゼロから作ってみてほしい
自分でCMSやECサイトは作れるか?
対戦格闘ゲームサイトは作れるか?

出来合いのECやCMSを使うか?
AWSが用意してるゲームサイト用の機能を使うだけで満足か?

それで中身がどう動いているのか理解できるのか?

全く勉強不足なのだ

プログラマは以前より多くの知識を要求されるようになった

特にセキュリティに関してはガンガン勉強しなくてはならない

BD、FDでその辺りを書ける人は見たことがないし、今まで通りの仕様書の書き方では、かなり粒度を細かく書かなくてはいけないだろう

さて、このように人が全部やるとしたら勉強不足に起因する課題だらけだけど、最近はcopilot様が現れた

時代としては詳細設計はぶっ飛ばして良い時代になったと思っている

だってダメなところはcopilot様が教えてくれるじゃないか?

最終的にcopilot様がオッケー出せば良いんじゃね?とさえ思い始めている

はよ、自分でコーディングしない時代になってもらいたいものだ

copilot様、あとはよろしく

2024年6月2日日曜日

ライ麦の部分的収穫

ライ麦の穂だけ摘んだ
成長度合いにバラツキがあって
しかもこいつ、まだ青いのに種が根本から落ち始めていた
麦色になるまで待ってたら
おそらく種採れない

このまま乾燥させれば
叩くだけで落ちるはず

庭にはまだ半分以上残っているのだけど
現時点でこのフェルト鉢の半分まで収穫できている
フェルト鉢は直径39cm高さ30cmのいつものやつ
持ち上げるとそこそこ重い
これなら余裕でパン焼けるだろう

ダッシュ村で三瓶 明雄さんが教えていた様に、種の選別をするべきだった

このライ麦は緑肥用の種なのだけど
今見直してみたら本当にいろんな種が混ざってる

選別してやらないと良い種を収穫できないし、収穫時期もバラつくと言うことなのだろう




2024年6月1日土曜日

ライ麦試しに剥いてみた

ライ麦の穂を6本くらい剥いてみた
まだ乾燥しきってないのだけど
穂を逆撫でするように指でモミモミしたら種がポロポロと落ちてきた

左が収穫した種
真ん中は種まきに使った種で表面が赤いのはゴム質の粉がまぶしてあって、鳥に食われない様になってるらしい
右は剥いた後のクズになった穂

撒いた時の種より大きい種が多いが
乾燥したら赤いのと同じくらいの細さになるのだろう

全部収穫すれば
ライ麦パン一つくらいは焼けるだろうか

庭のライ麦はまだ花粉が見えてる穂も混ざっていて
生存戦略的に成長がまばらなのかも知れない


それにしても昔の人は
稲藁使って俵、草鞋、綱、籠など
いろんなものを作っていて
本当にSDGSだったのだなぁと感心する

このクズの方は
もう少し細かく切って
イチゴを植えてあるフェルト鉢の表面に撒いておく
保水効果、乾燥防止になって
その下には粒状の土が出来上がるだろう
虫や微生物の働きでそうなるらしい

ちょっと不思議なのだけど
死にかけてた様に見えたアーモンドの木が
今年は豊作になっている
枝も出てきてすごく元気だ

周りにライ麦を撒いたのがよかったのだろうか?
たいして肥料もやってない

ライ麦の根は土中深くまで届くらしく
その周りに根粒菌が増えたのかも知れない