There’s a lot to be said for superficiality. The more programming work I do, the more often I find that it’s easiest to start with the outside and work your way in, rather than build a scaffold towards a nebulous and elusive goal. I find that one of the most consistently effective ways to start programming a necessary class is to first write some code that uses that class, then go in and make it behave in a way that’s consistent with the behavior you expected.
That’s tangentially related to the lesson I learned this week. Superficiality, working from the outside in, is the common thread: My new approach to resolving collision detection, a programming problem which has been a consistent thorn in my ass on this project, dating from before I even started this blog, is to output every step of the process on screen as it happens. This is an idea that I actually had some time before, which I then shied away from because of the initial time investment in setting up the graphics output and all that. Now, how shall I put this… that was extremely dumb, and I have paid for it in weeks of misguided work, as well as quite possibly months of depression.
This was a particularly silly choice given that I’m working in Flash in the first place, an environment I favor particularly because it’s so easy to get something up on the screen, an environment that’s powerful and flexible because it doesn’t take a time investment to get a little bit of text or a few vector lines up and running: An environment, in other words, almost perfectly suited for graphical debugging solutions.
Oh well. Live and learn. Next time, the first thing I’ll be asking myself is how to get something on the screen that I can look at in real time, and see where things are going wrong. This week, as I constructed a new collision system, I found some really deep and ugly shit, code I wrote years ago, which I had assumed to be perfectly usable, and which turned out to have huge holes. One set of tiles was defined with incorrect parameters, so their behavior in-game would always be inconsistent with their displayed shape. One set of tiles was completely undefined, so they had no gameplay effect at all, despite appearances.
So, yeah, I’m glad I’m taking this approach now – to the almost exact degree which I am kicking myself for not doing it earlier.
Anyway, here’s what’s up now:
This is the visual output of the collision system. Here you can see the diamond-shaped collision test object which I discussed in the last update. The faded blue tiles behind it show the tiles it’s testing collision against, the red tiles show the tiles where it detects a collision, and the yellow line represents the vector along which the character would be moved to resolve the collision. Right now, all of those resolution vectors are aligned to either the x-axis (sides) or y-axis (top and bottom), but as I develop this further the reactions will become a little bit more nuanced, based on the specific relationship between that side of the character and the tile being tested against.
There are basically three steps left to this collision system: First, that which I just alluded to, tweaking the resolution vectors into a system which I expect to provide the best results. This is going to be kind of a work in progress, and I expect that these are parameters that will take some fiddling to get just right, but I want to have all of the components in place before moving on to the next step. That next step will be, then, to reintegrate this code into the movement/collision systems, basically taking the place of the collision code that’s there now: And, third and finally, once all of that is in place, I will be returning to the problem I started with, the problem which kicked this whole collision thing off again, tracking motion along changes in terrain slopes.
After that, well, we’ll see. I really want this game to feel good to play, to just be fun to move around in in a really fundamental way. I think that’s one of the most important things to get right in any game. So, though it galls me to spend this much time on such a narrow subset of problems, I sincerely think that, in the long run, this will be time well spent.
One can only hope.