Implementing Moby: When 1 + 1 = Way More Than 2

Moby is the last of Lolo's adversaries, and the newest in the Lolo canon. With Moby comes a whole lot of coding problems and questions to answer. Like Gol, he waits in one of four directions for Lolo to pass by. Like a (reverse) Rocky, Moby will pull Lolo towards him. Unfortunately, pushing and pulling Lolo around suddenly makes Pushey code way more complicated.

Moby first appeared in Adventures of Lolo 3, where he never showed up in the same puzzle as Rocky. I’m sure this is no coincidence, because they are both complicated and they really bring out the worst in each other, so HAL once again sidestepped the issues entirely. Probably wisely. Eggerland for Windows 95 bravely tried to tackle this problem, but Moby’s behavior is subtly but devilishly different than the established behavior in Adventures of Lolo 3, so the "intended" behavior is muddled. This is nothing new, other behaviors have changed from game to game, but it always complicates Eggerworld’s quest for consistency. No shortcuts for us, we've gotta make a choice and run with it. If you haven't read up on how Rocky is his own bag of tricks, I suggest you do that now, as I consider it required reading for what's next.

In Revival! Eggerland/Eggerland for Windows 95, he makes an unmistakably 90s shovelware-sounding chirp sound

Moby has a threat region to trigger its ability, like Medusa. Moby will suction through trees and grass and the usual things, though Lolo will never be pulled somewhere he couldn't go himself, for example on top of a tree or into water. All easily achieved with existing collision logic, threat regions, and pushing mechanics we've already implemented, so I don't feel the need to cover those bits again. What comes now is the push/pull order problem.

See, what if Rocky pushes Lolo right past a Moby, what happens? Does Moby pull Lolo right out from Rocky's push?

No. The answer is no. Probably.

The big rule every pushing/pulling enemy seems to follow is that only one pusher seems to have command of Lolo at a time, and once one has claimed that status, it is locked and cannot be taken away by another pusher. Rocky gets to push Lolo around until it's had its fun. Conversely, Moby can start pulling Lolo and should pull Lolo right past an angry Rocky once suction has started. Two Mobys can both see Lolo in their threat region but one will politely wait for the other to finish pulling Lolo around before attempting its own bullying.

Make no mistake, it still sucks pretty hard to get caught like this

This code is conceptually pretty simple; Lolo’s data can store a current active “pusher” as a variable that every pusher can check. This does not solve the issue of two pushers attempting their pushes on the exact same frame though, which could introduce inconsistency if the pushers live in an inconsistent order in-memory. The quest for consistency continues.

According to Eggerland for Windows 95, Rocky's push has priority over Moby's pull. I think this makes a certain kind of sense. More than one Moby could try to pull Lolo in different or even opposite directions too, but Eggerland for Windows 95's level editor establishes an order based on the Moby’s orientation, showing that Mobys who face down get the highest priority when grabbing Lolo, followed by right-facing Mobys, then left-facing, and finally up-facing Mobys. But that's not the full story, because in Adventures of Lolo 3 the closest Moby gets the Lolo, regardless of orientation. This is actually integral behavior for at least one puzzle in that game, so I think Eggerworld will combine order and proximity, triggering the closest Moby when that's obvious and falling back on the fixed order when all other things are equal.

Just like the puzzle where Rocky pushes Lolo while Lolo pushes an Emerald Frame, what if Lolo is pushing an Emerald Frame right as Rocky is pushing Lolo while Lolo is hitting Rocky with a Magic Shot and Moby is pulling Lolo in a totally different direction and one Moby always lies but the other Moby always tells the truth but it’s a one-ounce Moby that can’t possibly carry a one-pound Lolo…

The only way to achieve a “scalable” solution when so many things could get interrupted by so many other things is to create priority on update types themselves. Eggerworld achieves this in two ways: through “post-update” updates that only happen after normal updates, and through sheer discipline of code. Post-updates means that creatures can do unlocks during normal updates and can do push-locks on post-updates. This guarantees that an enemy will never miss an opportunity to pick up a lock it’s supposed to. Actually, it gives us much stronger control over what order things occur in, if we’re careful. It means all entities can have multiple update phases in whatever order they need. More complicated, but it’s necessary.

I will spare you the actual implementation of this system because it is powerful but nitpicky, and frankly less fun to look at than many other subjects we’ve covered during development. The big takeaway is that every enemy now replicates every behavior the way you would probably expect from some game in the series. In terms of gameplay, now that Moby is finally blogged out, we’ve reached feature-completeness. Now the work can finally begin…

Or the work has already been done... Oops, sorry