Sometimes, the Bear

I only just realized the name of that bear. But mostly, musing about the Situation idea.

I always thought the saying was “Sometimes the bear bites you”, but I just realized that it might be a warning about a specific bear: “Sometimes, the bear, bites you”. So if you encounter a bear whose name is Sometimes, I recommend keeping your distance. In fact, now that I think about it … but I digress.

I was thinking this morning in the waking hours, about the Situation idea, where we have some kind of Situation thing that accepts one or more objects as its parameters, and checks a Situation-specific condition, and if the condition is met, executes some Action things. (I say “things” because I’m not sure at this writing whether these are objects or functions or what.)

Let’s make it a bit more concrete. Invader shots impact the InvadersPlayer and the RobotPlayer in the same way:

invader shot hits invaders player
- remove invader shot
- remove player
- explode player
invader shot hits robot player
- remove invader shot
- remove player
- explode player

I would think that we’d like to deal with these together … but perhaps that’s premature optimization. But for our thought process, we should keep this duplication in mind.

We’re assuming that we cannot modify the Fleets object, so although I thought of wrapping it yesterday, today, upon further consideration, I think that’s off the table. However …

We can certainly have our game coin add whatever objects we want to Fleets, including a SituationManager or a bunch of Situations, whatever. Suppose we have a Situation in the mix …

No … let’s go wild for a moment. Suppose we have a SituationFleets object and in our game coin we add that to Fleets, and everything else, we add to our SituationFleets. It would have to forward all the update, tick, draw messages, of course. (It occurs to me that if there is only one object in Fleets, it will probably not send any interact_with messages. No matter, we can always add a dummy object if we need to.)

The SituationFleets object could keep the real game objects partitioned by class or any other desired aspect. So when appropriate, probably during the interactions part of the cycle, the SituationFleets would iterate through the current Situations, allowing them to assess their conditions and execute their actions. It would pass itself to them, the way Fleets does, so that if they want to add or remove objects, they could do so.

At least while we phase this idea in, some objects might need to be added to the real Fleets object. Meh, deal with that if it happens, discard the concern for now.

A bit meta …

It sort of seems as if the situations will generally concern instances of two different classes. Our Invader Shot Hits Player Situation is concerned with an instance of InvaderShot and an instance of InvadersPlayer. I think we can assume that the SituationFleets thing will probably keep things separated by class and will be coded to process things by class. No, that doesn’t seem quite right. It seems better to me if the SituationFleets just went through the objects pairwise, like the regular Fleets does, and then did a selection from all the Situation instances to pull out the ones pertaining to the specific pair.

So maybe the Situations are indexed by the class of their first “parameter” and then indexed again by the second. We know there are really only two to be concerned about—I think—because the game works pairwise now. And the idea is that if the pair need to know more about the overall “situation”, they can ask the SituationFleets for information.

Think about the point …

The point of this idea would be to better express the joint behavior of two objects (possibly more but two seems enough), with the supposed result being a substantial reduction in the code of the system. If we are not going to get a code reduction (or at least some amazing new clarity of expression) we wouldn’t do this.

So therefore …

I think we’d need to spike this idea, perhaps as a separate new “game” under the current framework, to get a solid sense of whether it’s better. At this moment, I don’t see enough of the idea to be ready to try it out.

I’m not giving up the idea … and I’d certainly like to find a way to collapse the code with some new idea … but for now … more musing is needed.

See, we do think about design. Did you ever doubt me?

See you next time!