Fantastic Collision

Franklin

Hey, remember this guy? I wouldn’t be surprised if you didn’t; I haven’t made that big a deal of him since I semi-released the original build of this game made for Ludum Dare back at the end of 2013. He’s not dead, though!

Having been created "from scratch" (using HCGE) in 72 hours without a preexisting concept, it was far from perfect, especially since further-developing HCGE beyond the last public release during the competition would have violated at least one of the rules. When I had the time to go back over it and work out some of the finer details, some of the undesirable functionality had me stumped. I had to put Franklin on the back burner for a while. Just recently, though, I had an epiphany, and I knew that I had to finally move this game forward while the idea and motivation were still fresh

Object Interactivity

Managing complex collisions can be a real pain. That’s where the majority of my issues were coming from, as basically all objects in this game have to interact with each other as solid entities. One issue that I dealt with during Ludum Dare was consistency with objects that had to sit on top of each other

HCGE allows for object types to be flagged such that any instance of that type will be ignored during object processing if it’s not within a certain distance from any of the four screen edges at the time. This is an important performance consideration that some other systems don’t account for, although you can still set every object to be processed at all times no matter where it is if you need to. This in-part led to the creation of an issue in that what are considered as "Projectile Objects" in HCGE (objects that can process collision with other objects) were originally coded somewhat incorrectly - they stopped processing collisions when their position (the single point that defines their location in the level, not the entire sprite) was off-screen, and objects that were outside of "active range" couldn’t be tested for collision regardless of whether they were set to remain active

Until then, the issue had basically gone unnoticed since the most I had done with HCGE’s "Projectile Objects" was create the player shot objects for Mega Man: Triple Threat. In this case, however, there are many movable entities that can be stacked on top of each other and their states have to be persistent. The issue became apparent when a group of objects came into contact with the screen’s edge, and they were no longer regarded as solid to each other. Groups of rocks would fall through each other and exist in the same space, for example. Ultimately, I had to add a rather hackish bit of script code to the game itself to freeze objects in that condition, keeping the problem from becoming apparent to the player. This was only a temporary measure to avoid violating Ludum Dare rules, though, and afterward, I corrected the behavior in HCGE properly

Other issues arose when some objects were made to be able to push some others, especially in cases when those objects were being carried by the player instead of being pushed by the player. Most of these weren’t corrected during Ludum Dare due to the time limit, and some of them were responsible for stalling progress afterward

Mismatched Collision Sizes

Probably the biggest problem was that the rock is not the same width as the player character, which comes into play when he’s carrying it. Originally, the egg had the same problem, but it didn’t necessarily need the collision box that I gave it in the first build, so I shrank it to be common with the player. In the case of the rock, though, that just couldn’t be done

The reason that it’s a problem is that when the player is carrying an object, it’s the player that moves, and he manually updates the position of the object he’s carrying to follow. He respects his own collision box automatically, but there is no method for automatically accounting for the carried object’s collision box, and so, if it’s larger, the player would be able to carry the object partially into walls and other objects. When tossed from this position, a rock could move into and occupy the same space as another rock or the egg, or get stuck inside a wall. I discovered the problem after Ludum Dare was over, but when I had gone back to look at it, it seemed that nothing that I could come up with would solve the problem

It was recently that I realized that I hadn’t been approaching the problem correctly - I was too focused on the functionality and process order of the things that HCGE would automate and I didn’t give significant thought to the fact that I had also created some features that would allow for handling things manually at any time using the script in cases where it was necessary. I could, in fact, cause the player to respect the collision box of the object he was carrying, and therefore not carry it into walls and other objects. First, the player would have to be moved normally and update the object’s position directly just as before, but immediately after, additional tests and adjustments would have to be performed

Walls were solved by a manual level collision test using the _Reg=TileInfo(Reg) Command on each of the object’s four corners and moving it "outward" as necessary, using the same Command to test for the edge of the wall along the way. This actually caused another issue in which the object (and thus the player) would shoot far off to the side if picking it up would cause it to enter a solid ceiling, so instead of testing and adjusting for walls outright, an extra step was added to ignore ceilings. When the object is first picked up, the player is flagged to ignore wall adjustment and performs a similar test to determine when to remove the flag. The flag is only removed once the object is no longer in contact with a solid portion of the level, presumably meaning that the player and object have fallen far enough for it to have exited the solid ceiling

Using the _TestCollisions(FetchedProjectile) Command allowed for manually causing the carried object to test for collisions with other objects. Although this would trigger the same "projectile collision" functions that would occur when a "Projectile Object" moves on its own, the way I’d have to use it wouldn’t have the same precision as the automatic collision test, which occurs once for each pixel-unit of motion before the object moves on to the next. In this case, I’d perform a single test after the object’s position was already forcibly updated by the player carrying it, so I couldn’t rely on _If(Projectile_Touch_Object) to catch the moment that a side of the carried object came into contact with a side of another object as I did in the existing code. The "projectile collision" functions had to be modified to determine when the object calling it was being carried and act accordingly - it would need to instead test for overlap using _If(Object_Collide_Projectile), and when necessary, determine which side each object is on and push at least one of them accordingly. In the case of rocks, they would just push the carried object out of themselves. The egg, however, is slightly more complicated. It will first push itself out of a rock that was carried into it, and subsequently it will have to test for collision with other surrounding rocks. If it strikes another rock, it’s pushed back outside of that rock, and the rock being carried is pushed back outside of the egg

Once both types of collision tests are complete, if the carried object has been adjusted, the player is then forcibly adjusted to follow so that he remains centered with the object. This effectively causes the illusion that the carried object never entered a wall or another object, and that the player never moved any farther than would be allowed by the larger object he was carrying

Moving Forward

Those were far from the only issues that have come up so far with this project, but they were two of the most prominent. I’ve made several other fixes and improvements as well, and I’m starting to feel more confident about this game in general

I’m planning to release a much more stable demo very soon. It’s still a long way off from what it’s meant to become, but the gist of the basic gameplay is there. With the major playability issues I’ve run into solved and some of the important mechanic changes implemented, I pretty much only need to add and tweak a few presentation elements, and come up with like two or three extra levels. Otherwise, it’ll just be a slightly improved version of the game presented at Ludum Dare

In the long-run, I plan to add enemies and several new gimmicks, as well as many levels that make use of them, and even a specialized in-game level editor

Other stuff

For those who are concerned with other projects of mine, they’re still in motion. As is usually the case, HCGE is benefitting from fixes and improvements based on issues exposed by further usage, currently meaning the development of both Fantastic Franklin and "Bone Rattle". There has been more progress on "Sonic 1 Megamix" as well, and I plan to continue with it once the new Fantastic Franklin demo is ready to go, which shouldn’t be all that long from now

(Share on Twitter) (Share on Tumblr)