EverEnding DevBlog 108: Tangled Web


Things have been a bit chaotic with the holidays, but I have the inter-entity collisions basically working. I say basically because they detect each other properly and they block each other properly, but some issues have come to light regarding how they interact which I’m still figuring out.

When I designed the entity update system, I made one big dumb assumption, which was that entities would not change except by their own code during their update loop. Obviously, any kind of entity interaction breaks this assumption badly. If I’d realized that I was making this assumption in the first place I probably would have seen that coming, but it didn’t occur to me. We can probably chalk that one up to a lack of experience. Anyway, as a consequence of this misplaced assumption, the player entity’s info, after being modified in the inter-entity collisions, isn’t visible to the player until she goes through another complete update loop, by which time a lot of that info has been reinitialized. Thus, even if I tell her she’s standing on a floating platform, she can’t hear me because by the time she checks to see whether she’s on a platform another behavior has written over that with info telling her that no, actually, she’s still falling, because no platform has been found yet.

Today’s work time was spent half figuring out that this was what was going on and half trying to ponder some kind of a solution that didn’t break anything else, and I think I’ve arrived at one. Basically, I’m going to flag each behavior as either unsynced or synced − unsynced behaviors work exactly as behaviors do now, where I iterate through each entity and iterate through each behavior of that entity through until I reach the last behavior of the last entity. Synced behaviors, however, will stop after updating, then iterate through all of the other entities that possess the same behavior until they reach that behavior and update it before proceeding as normal.

This may cause some issues and may be a bit tricky, particularly in instances where a synced behavior is encountered while updating to sync with another behavior, but it seems like the most logical solution and shouldn’t require me to tear up a lot of existing code, just get this one bit of logic working. Once I get this working, I can then settle in on the more specific applications of this work, such as moving platforms, destructable walls, and melee attacks.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: