Sigh. And I am reminded forcibly of why I hate dedicating entire weeks to programming! Not only is the work sometimes a drag – I like programming, but it’s easy to get intimidated and/or frustrated by some of the problems that come up, and I have to manage my time more carefully to ensure I have large blocks of time where I can rely on some degree of clarity in thought – but it frequently needs to be redone. It’s entirely possible for the net result of a week of progress to be “well, I tried a couple of different solutions, but they weren’t really cutting it, so I’m basically back where I started… but hey, at least now I know those won’t work, right? …right?”
That’s basically exactly where I’m at now.
Now, that’s not to say this week was devoid of genuine progress. I actually made some tweaks to the animation systems and jump behaviors which will probably stay in the game for the entire life of the project, possibly with some fine-tuning in the future but with the basic traits I added intact. So, you know, that’s something at least, and makes me feel a bit better about…
Okay here’s how it went down: My main task for the week was to make a system where the character tracks the surface of the ground and, for example, rather than running off the edge when a straight surface dips downhill, running down the slope of that hill. My approach to this was to treat the surface of the ground like a railway, so that when the collision detection system flags her as touching the ground (a calculation which is already used frequently elsewhere in the code, such as in determining whether she can jump or not), her angle of movement begins to parallel the angle of whichever piece of ground she’s standing on. This system was basically functional, but I ran into some issues when both lower corners of the character were interacting with different slopes, resolving which one should take precedence. This isn’t that big an issue, but something started nagging at me: If I solve this, then what?
I’ve been running a standard axis-aligned bounding box collision system, where the shape of the character is a static rectangle, and I knew that this wouldn’t be tenable in the long run. It looks like garbage, as the sprite for the character floats over the surface of the hill, and though that could be addressed by just changing the draw location for the character it also creates problems like mentioned above, where the surface tracking gets confused. Basically, this is an approach which has outlived its usefulness.
Which sucks, because it’s the easiest approach, and because I’d solved it, dammit.
The bad news is: I’m going to have to rewrite a lot of my collision code to implement, basically, a diamond shaped character. This creates a lot of more complex situations where I’m testing slopes against slopes rather than points against slopes: The calculations for this aren’t too overwhelming, but along with the complications that come with lining up tiles to collision meshes and all that stuff that has been a headache for me so far in making a functioning collision system could provide a formidable challenge. Not only is detecting collisions more difficult, resolving them is less obvious: Simply nudging the character up out of a slope isn’t always a satisfactory solution when the same algorithm should be making her fall off a cliff.
The good news is: Once I do manage that, since there will at that point be only one point of contact with the ground, tracking movement along the surface will become an almost trivially easy problem. Admittedly, one I need to wade through a really difficult problem to get to, but that will make it a relief to eventually get there.
Thus, despite me opening this with stating how frustrated I get sometimes by dedicating entire weeks to programming, it appears I will be dedicating another entire week to programming.