わたしのブログ

２０１７・１０・２６・Ｔｈ
＊
 前書き
＊
　世間知らずと言われた時は、世間から目を背けたけど、世間を早く知りたいと思った。
　世間に是非を問う気が無くなってからは、世間は平気だった。
　世間は人それぞれだから。
　世間を探しに、新しい旅に出たくなった。世間はいつでも、待っているから。　
　（旅に出たくなった。新しい世間を探しに。遠くまで、いつまでも。）
＊
 世間は人それぞれ＃１６
 「んまぁ、衆議院選挙があった訳ですが、その間、北朝鮮問題とか―――無かったでしょ？終わったらまた再開とか―――ウソなんだって、実感してもらえましたか？『うるさいうちは大丈夫』『気が付いたときはもう殺られてる』―――コイツ、ヤバいってなったら、先ず暗殺でしょ？被害が最小だし、一方的だし、加害者とは気付かれないんだから。逆に被害者は、あ、ヤバいって時は遅いんですよ。ディスプレイの現実世界なんてメディアが作った都合のいい窓口で、キミに見つめていてもらいたくて―――健気なんだけど、うざぁ！・・やっぱり自分の世界は自分で作ろうぜぇ！的な。個人的には、原発ですね。電気をいかに安く自国に供給出来るかが、先進国を豊かに出来るか、否か、だったので、原発ゼロを謳った党は軒並み敗退。まあねぇ、『もんじゅ』ね、本当は実験炉の『常陽』をそのまま作れば、何の問題も無かったんですよ。『ふげん』は最初から作らなければよかったんですよ、同業者が仲間割れを起こすような環境が、昔は良しとされたんですね、・・今は言える、今なら言える、ダメはダメ、バカどもは、やっぱ、バカ、偉きゃ、シロでもクロになるぅ～、常に頭（かしぃ～ら）はぁ～、トンマノォ～マントォ～・・う～らの畑に、ビルが建つぅ、どーんな事でも、腹が立つぅ―――嗚呼、この頃は、しみじみ・・しみじみですよ」
＊
　久々に、ブログです。はい、久々と言うとＣ＋＋６．０のエディタは僕のスタジオって感じでしたが、自分のプログラムは実際、「忘れたところは、忘れてます」です。よーやく、判定情報を転送するところまで来ました。そんなに、難しい？・・それは条件に寄ります。
＊
　〈　僕の格ゲー心臓部概要図：ＣＰＵ戦専用：対戦用エンジンには全く必要無し　〉
＊
　『以前の動作とこれからの動作確認＆表示管理』：プレイヤー
　↓ 
　『キャラクターの動作管理＆発動＆表示管理』：プレイヤー：入力受付情報転送
　｜
　｜　ここでプレイヤーのフレーム数をデクリメント
　｜　キャラクターの判定計算データを構造体に転送
　↓
　『飛び道具の以前の動作とこれからの動作確認＆管理＆表示管理』：プレイヤー
　↓
　『飛び道具の動作管理＆発動＆表示管理』：プレイヤー
　｜
　｜　飛び道具：プレイヤー＆敵のフレーム数をデクリメント
　｜　発動は『キャラクターの動作管理＆発動＆表示管理』に依存
　｜　動作終了（終了、ループ、次のモーション）は独立
　｜　複数あるので関数をループさせる：デクリメントの重複をインクリメントして修正
　｜　プレイヤーは飛び道具が無くとも、必ず１回はループして、敵の飛び道具を全て確認
　｜　この時は、デクリメントの重複をインクリメントして修正は行いません。
　｜　飛び道具の判定計算の情報も構造体にプレイヤー＆敵ともにここで転送
　｜　
　↓
　『アルゴリズム』
　｜
　｜　プレイヤー＆敵の状態確認、可能な敵の動作を決めます。
　｜　キャラクターの判定計算データを構造体に転送
　↓
　『敵キャラクターの以前の動作とこれからの動作確認＆表示管理』：敵
　↓
　『敵キャラクターの動作管理＆発動＆表示管理』：敵キャラの動作変更
　｜
　｜　敵キャラクターのフレーム数をデクリメント
　｜　敵キャラクターの判定計算データを構造体に転送
　｜
　｜　＊同時に起こる現象としての修正＊
　｜　『アルゴリズム』ごしに見た、「敵の飛び道具のフレーム数」は、
　｜　敵キャラクターのフレーム数が、まだデクリメントされる前に、
　｜　既にデクリメントされています。『アルゴリズム』によって、
　｜　可能な動作を決定するので、本来、『アルゴリズム』より前に、
　｜　敵のどんなフレーム数であってもデクリメントすると、『アルゴリズム』を境に
　｜　矛盾が生じます。そこで、「飛び道具の発動のみ依存」とあるので、
　｜　敵の飛び道具の最初のデータがここで転送される時、そのフレーム数に
　｜　＋１して左辺に転送します。つまり『アルゴリズム』より後にデクリメントされる
　｜　敵キャラクターのフレーム数と同様に、あたかもデクリメントされたように修正します。
　｜　しかし、この時まだ、『アルゴリズム』による、敵キャラクターの「動作の決定」による
　｜　例えば、敵の飛び道具が終了してしまったら、画面に存在しない、初期化となりますが、
　｜　正確には『アルゴリズム』の後からデクリメントする敵キャラクターにとってみれば、
　｜　「存在しない」事も論理的には矛盾しますが、計算的には画面に描画される前なので、
　｜　問題は起こりません。
　｜　次の動作やモーションは？それの〈　その説明　〉は下記で↓
　↓
　『飛び道具の動作管理＆発動＆表示管理』：敵
　｜
　｜　発動は『敵キャラクターの動作管理＆発動＆表示管理』に依存↑
　｜
　｜　敵の飛び道具のフレーム数が１の時、デクリメントします。既に「修正」により、
　｜　１度インクリメントされているので、ここで±０に修正を戻します。これに伴う、
　｜　新たなデータ転送をここで、敵のみ再度、行います。
　｜　関数の条件文で、インクリメントしなくても済みますが、後々の調整を考えると、
　｜　この関数の条件文を忘れてしまうと、動作の構造体の数値の扱いが極めて
　｜　困難になります。この計算の後、動作終了を行います。
　｜　｜
　｜　｜〈　デクリメント：敵の飛び道具のフレーム数が１の時　〉
　｜　｜
　｜　｜〈　インクリメント：デクリメント↑で伴う、最初のフレーム数　〉
　｜　｜
　｜　この順番と条件に従わないと、この修正が全くの±０どころか、
　｜　心臓部そのものが、機能を失います。
　｜　｜
　｜　↓
　｜　動作終了（終了、ループ、次のモーション）は独立↓
　｜
　｜
　｜　＊同時に起こる現象としての修正＊
　｜　『アルゴリズム』ごしに見た、「敵の飛び道具のフレーム数」は、
　｜　敵キャラクターのフレーム数が、まだデクリメントされる前に、
　｜　既にデクリメントされています。『アルゴリズム』によって、
　｜　可能な動作を決定するので、本来、『アルゴリズム』より前に、
　｜　敵のどんなフレーム数であってもデクリメントすると、『アルゴリズム』を境に
　｜　矛盾が生じます。
　｜　なので敵の飛び道具は「動作終了（終了、ループ、次のモーション）は独立」
　｜　であるので、次の最初の敵の飛び道具のデータ（終了であれば修正はいりません：存在
　｜　しないので、初期化です）が、ここで転送されるので、そのフレーム数に
　｜　＋１して、左辺に転送します。
　｜　
　｜　〈　その説明　〉
　｜　発動以外はここで管理されているので、『アルゴリズム』前に敵の飛び道具の
　｜　動作が終了して、『アルゴリズム』前に何らかの動作（例：何もしない）とあっても
　｜　『アルゴリズム』のあと、敵キャラクターの動作が決定、もしくは、「次へ」となって
　｜　フレーム数がデクリメントされた状態から、改めて、判定＆飛び道具判定構造体に、
　｜　敵のみ情報を転送することで、この矛盾を解決します。敵の飛び道具の管理が、
　｜　敵キャラクターの管理とは独立しているので、敵キャラクターの動作が決定しても、
　｜　敵の飛び道具が、敵キャラクターの動作に直接は影響を受けないため、
　｜　これらが可能なのです。
　｜　
　↓
　『判定計算』
　↓
　『判定計算による結果＆それに伴う表示管理』
　↓
　『拡大用のサーフェースに書き込み』
　｜
　｜　背景、ＫＯゲージなど、スクロール修正されたＢＧを表示
　↓
　『拡大関数』
　｜
　｜　必要があれば拡大
　↓
　『拡大用のサーフェースをバックサーフェースへ書き込む』
　｜
　｜　プライマリーサーフェースとフリップしてディスプレイに描画（表示）
　↓
　『デバイス入力受付関数』　
　↓
　最初にループ（終了もしくは完了）：やったぜ！・・実はルーズリーフ、丸写し。
　でもぉ・・３０枚近く書き直しました。うん、完成しても、最初からビルドして
　コンパイルして、実行、出来たって事は、今の１度も無いので、それはいいです。
＊
＊
　エントロピーの回転、それがプログラミング・・です。最初とか終わりって存在しません。突然、ある何かの全てがエントロピーとして出現しては、消えます。でも人間では、受け入れられないので、心の準備とかやって、実行→ループ→終了と言うことにしています。実際はループに入る準備、ループから出る準備、ループから出る、です。
＊
　今回は、他に複数の攻撃判定＆やられ判定（とりあえず３個：実際は旋（つむじ）に２つしか使いません）が有りますが、これ自身はデクリメントされないので、それに、ループさせる場面はないので、一括転送ですね。飛び道具が複数（今回は１０個：２ケタにしてみたかった）、プレイヤーとその敵、それぞれにあるので、ループが必須になります。ですが、このループがあるおかげで、作業は更に大変です。フレーム数をデクリメント（１つずつ減らす）してゼロになったら、次へ（終了、ループ、次のモーション）としてあるので、かなり簡単に説明しますが、例えば、プレイヤーから、敵の飛び道具を見た時、つまり、敵の判定を計算する時、プレイヤーのために、敵はその飛び道具をデクリメントして、データを転送しなくてはならないからです。同時に起こっているようにゲーム上では見えますが、一つずつ順番にしか計算できません。プレイヤーが１０個の飛び道具の判定を、敵の１０個の飛び道具の判定と照らし合わせる時、敵はプレイヤーの１０個の飛び道具のために、敵の１０個の飛び道具を１０回デクリメントしてしまうのです。つまり、プレイヤーの０番（配列は０から数えるので）の飛び道具でデクリメントして、１番目でもデクリメントとしていくと、９番目では既に敵の飛び道具のフレーム数は１０個ともマイナス１０されています。これが仮の敵のフレーム数だとしても、０番→１番に行くと既に正しくない、敵の仮のフレーム数になってしまう訳です。もし、そのデクリメントで動作終了（終了、ループ、次のモーション）ならば、場合によっては画面に存在しません。もちろんこの問題は、情報が転送し終わった後、敵の飛び道具のフレーム数をインクリメント（１つずつ増やす）すれば、プレイヤーの飛び道具の１番にループしても何も問題なく解決です。
＊
　しかし、問題はまだあります。１０＊１０＝１００もループさせたら、処理落ちしちゃうだろーＷｉｎ９８の頃なら！でも実際は、今回、プレイヤーに飛び道具が無い・・。しかも敵２の旋（つむじ）だけ。
　アルゴリズムも大変です。先ずプレイヤーの動作をＣＰＵが知らなければ、ＣＰＵは応対できないからです。複数飛び道具＆複数判定のせいでアルゴリズムは更に複雑になって行くのは仕方が無いです。発生はキャラの技として扱われますが、その後は、独立した分身として扱うので、でもまぁ、いずれは、こちらの関数だけになっていくと思います。「判定はＸ軸的に頭で、そのままＹ座標的に地面の足です」的なぁ、説明が出来なくなるのかなぁ・・。
　今回は、飛び道具の状態の変化を調べ、表示および判定、ダメージ情報の根本的な転送、でした。まだまだ作業は続きますが、ここが一番の難関だったと、きっと後でそう思うと思います。既に、専用の構造体を用意していたので、ループ中に存在していない飛び道具はスキップする関数は作ってあり、コメント文として、既に書き込まれています。実は、プログラミングの趣向が、プログラムを始めた最初の頃と逆で、既に出来上がった直接プログラムに書き込める部分から、先に作っていってます。そのための細かな作業の関数は宣言してますが、{}の中はまだ白紙です。そしてですが、上記に書いた内容は、エディタでビルドしてコンパイルしても、まったくエラーとしては検出されない話なのです。
　以前なら、プラクティスモードに入った瞬間に、プログラムが止まるか、強制終了でした。それを３、４日かけて何とか動くようにして、安心して落ち着いて考えられるようになってから、本当の解決と言う流れでした。なので、落ち着くまで１週間ぐらい、三鷹から、秋葉原に行ってゲームとそれ以外の文化を見て帰ってきたり、上野の美術館に５時間いたり、狭山ダムまでミニベロで、１日かけて行って帰ってきたり―――でも、環境的には昔の方が良かったかも・・。ただ、東京都市部はやっぱり今も嫌ぁ。ビルとか、巨大な墓石にしか見えない。でも、本当に、そんな墓地とか有るらしいし、その土地の人の価値観ですよね。
　実際、格ゲーの心臓部分ですが、毎回不思議な感覚です。論理的にありえないと考えた状態から、同時に起こったと仮想するので、プレイヤーから見た敵、敵から見たプレイヤー、それらが同時に起こるものとして、その情報を専用の構造体に入れて、計算。結果も同時に起こったものとして表示するワケで、その結果を得意げに眺めると言う―――もし、相手がいなければ、結果は変わらないのに、相手がいるので結果が相手次第になり、相手も同じで、こちら次第の結果を出していることになるワケで、・・んあぁ～、僕ぁ、神とかそー言う質（たち）じゃないから、イヤァ～。でもプログラミングって間違いとか、何点とか、そー言うの無いです。ただ単に自分の思う通りになったか、まだならないか、なるまで頑張るし、それでいい。だから、ワークスペースの中は僕の完璧な世界。誰だってそんな世界を持てるのに、ＰＣは今では容易に手に入るだろうに、何のゲーム作るの？って、そこですよね。
　エレキギターやめようって思ったのも、こー言う曲を作らねば！ってそー言うのが無い。本当に好きなら、〈　僕の格ゲー心臓部概要図　〉とか、やっちゃうワケだからね。だから、時間もお金も無駄に感じてしまう。ホント、現金な性格なので、見返り無い事は出来ません。でもこの頃、ヒトって見返り求めてるって感じします。なので、親切な人ほど、どんな見返りを求めているのか、でも大体の人って―――嗚呼、本人に自覚が無いパターンだよ。後になって「最悪ぅ～」とか言われちゃうんだよ、先に見返りを提示してくれれば、それなりに頑張るのに、ＫＹとか、常識とか、取引にそんなモノは通用しない、特に個人にはぁ！・・でぇ、言ってもムリな要求だからとか、期待しすぎて考える暇も無かったとか―――そー言うヤツに限って、「ガキだなぁ」的な対応すると、すごい目で睨むんですよ。・・神ってぇ、キミ達のこと・・かな？
　あー、ビットマップですね。頭（後ろ）・・デカイ！・・ので、小さくしました。後頭部を丸く、後ろ髪を細く、短く、そーしたら、斜め後ろもあるので、それも。そうしたら、横ですか、横顔（頭）だけ、後ろ髪が重たいです。後頭部強調したら、見栄えが良くなったので、横顔も後頭部を丸くしたいです。これは、大分前から、描き直そーって思っていながら、「一瞬だからいいや」って先送りにしてました。今回の「何が何でも今年中に更新」では、「旋（つむじ）」だけの実装なので、と言うか、これだけでもゲームデザインは可能なので、実は絵は「颪（おろし）：旋から裏回りキック」まだです。ついでに「風斬り（かざきり）」は着地まだです。・・颪と同じ絵かも。
　扇風機を片付けたら、ギターも片付けるので、結構大変です。ここが、正念場かなぁ。ギターを置く場所が大変ですが、ネックさえ、触らなければ何とかなるので。・・なんすかねぇ、最近、ギターのヘッドを壁に立てかけて、ネックを曲げるのが流行りなんですかねぇ。スタンドもネックを支えるスタンドが流行りっぽくて。アニメ見てても、それはイヤかな・・。どーにもならない変形ギター出して、ネックツリーのスタンドとかちゃんと使ってるんでしょうか？無知識無教養とかそー言うレベルでは無くて―――ネックだけにソリが合わない。・・ですかね。引き際ですね。エレキギターは一先ず冬眠させます。