-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- 能動的から受動的にプログラムが変化
- プログラミング指南 - Code Knowledge
- Programming style: active to passiveZ80が主流だった頃のプログラムは、すべて自分から確認しに行くものでした。キーは押されているか。キャラは弾に当たっていないか。すべてを能動的に調べて処理していたのです。基本的にはシングルタスクなので、その確認中は他のことができません。この考え方は OS でも同様で、MS-DOS の時代までは、ほぼほぼこのような能動的なプログラミングスタイルが続いたのです。Back when the Z80 was mainstream, programs had to check everything on their own. Was a key pressed? Was the character hit by a bullet? Every condition had to be polled and handled explicitly. Since systems were essentially single-tasking, nothing else could run during those checks. The same mindset applied to operating systems, and this proactive style persisted through the MS-DOS era.そこで次世代の OS として登場したのが Windows です。…あ、いや、今は apple は置いときましょう。話がややこしくなるので(汗)。MS-DOS から Windows に変わったことで、劇的に変化したのが受動的なプログラミングスタイルです。正確にはイベントドリブンと言います。キーが押されたら、そのイベントに応じた関数が呼び出されます。Then Windows arrived as the next-generation OS. (Let’s set Apple aside for now to avoid complicating the discussion.) The transition from MS-DOS to Windows marked a fundamental shift to reactive—more precisely, event-driven—programming. When a key is pressed, the corresponding handler is invoked.…えっ?? PC-6001mkII もキーが押されたらサブ CPUから割り込みが飛んでくるって?はい、そうですね、イベントドリブンです。ただ、この場合はごく限られたイベントのみでした。Windowsでは、主要なイベントのほとんどが割り込みのように飛んできます。キーが押されたよーってのはもちろん、画面サイズが変わったよとか、ウィンドウが出来たよーとか、これらが WMメッセージとして細かく定義されて飛んでくるのです。“Wait—didn’t the PC-6001mkII also generate interrupts from the sub-CPU when a key was pressed?” Yes, it did. That was event-driven as well, but the scope was extremely limited. In Windows, by contrast, nearly all major events arrive as if they were interrupts: not only “a key was pressed,” but also “the window was resized” or “a window was created.” These are precisely defined and delivered as WM_ messages.その後、ゲーム開発は Unity や Godot といったミドルウェアへとシフトしました。XeGrader PlusはGodotで開発されています。これらはゲーム内のイベントでも、事細かに通知が飛んできます。Godot ではこれらはシグナルという呼び方になっています。シグナルが発生することを発火したとも言うようです。これで、プレイヤーが敵に当たったとか、罠を踏んだとかの判断が不要になり、シグナルが飛んできたらその対応をするだけになりました。Game development later shifted toward middleware such as Unity and Godot. XeGrader plus is developed with Godot. These engines emit detailed notifications even for in-game events. In Godot, these notifications are called signals, and a signal’s occurrence is described as “firing.” Instead of constantly checking whether the player collided with an enemy or stepped on a trap, you simply respond to the signal. + Trap(Node2D) + Area2D + CollisionShape2D(RectangleShape2D) + Sprite2D / AnimatedSprite2D親となる Node2D を用意し、その子として当たり判定用の Area2D を配置します。さらにその下に CollisionShape2D を置き、内部に RectangleShape2D を設定してサイズを指定します。表示用には Sprite2D や AnimatedSprite2D を配置し、画像やアニメーションを設定します。そして最後に、何がどれに反応するかを Collision Layer と Mask で細かく指定します。A typical setup involves creating a parent Node2D, attaching an Area2D for collision detection, and placing a CollisionShape2D beneath it with a configured RectangleShape2D. Visual elements are handled separately through a Sprite2D or AnimatedSprite2D. Finally, collision behavior is defined explicitly using Collision Layer and Mask.つまり、すべてが手続きとして明示的に設定される必要があります。しかも、どれか一つでも設定を誤るとシグナルは発火しません。ログも出ないため、原因の特定も容易ではありません。ね、一見とても便利に見えるけど大変だよね?大まかにはデフォルトのままで良いのですが、少し特殊なことをしようと思ったら、その手続きがこんな感じで結構大変なのです。しかもこの例はまだ標準的な設定なんだよ。便利な機能の恩恵を受けるための手続きが複雑。なんかどこかの国の行政手続きに似てると思いませんか(苦笑Everything must be configured deliberately. If even one parameter is incorrect, the signal will not fire. Because no logs are produced, isolating the cause is difficult. The defaults work for straightforward cases, but the moment you attempt something slightly specialized, the required configuration quickly becomes intricate. Even this example represents a standard configuration. The mechanisms that provide convenience demand procedural precision—almost reminiscent of navigating a bureaucratic system.この記事が気に入って頂けたなら是非Wishlist登録をお願いいたします。If you enjoyed this article, please add it to your wishlist!
- 投稿日時:2026/02/21 05:00
-
-
-
-
-