Once again I'm working on an 8-bit project. This time around we decided to keep things simple from the outset and do a simple flick-screen platformer. Yet we're already three quarters of they way to the original deadline and it'd be a stretch to call what we've got so far playable.
I find the real problem is that I can never quite seem to get around to actually writing the actual game logic. I'll happily work for days writing elegant system-y type stuff but whenever I try to write game code it virtually always ends up a big stinking pile of unreadable special-cases.
Hence the reason why I created this thread. What tricks do you guys use to make the logic simple and efficient? Is application logic inherently inelegant or can it be handled with style?
To kick the discussion off I'll start by sharing a simple yet useful trick I (independently re-)discovered during the project.
My original version of the player's collision detection and movement code ended up a fragile mess just as I described above, as I kept having to add in new collision points and handle more and more edge cases yet player could still slip through the cracks in certain cases. The solution, in our case at least, was to offload the problem onto the level designer and stick with a single collision point at player's feet rather than trying giving the player a collision area. Then we merely had to widen the collision map around the edges to account for the extent of the player (which was straightforward since we had a separate collision/attribute map.)
What other tricks, great or small, do *you* know? Perhaps you've found a nice way of doing animation, a nifty method to get emergent behaviour out of simple enemy logic, how to make that big player state-machine manageable, etc.
I find the real problem is that I can never quite seem to get around to actually writing the actual game logic. I'll happily work for days writing elegant system-y type stuff but whenever I try to write game code it virtually always ends up a big stinking pile of unreadable special-cases.
Hence the reason why I created this thread. What tricks do you guys use to make the logic simple and efficient? Is application logic inherently inelegant or can it be handled with style?
To kick the discussion off I'll start by sharing a simple yet useful trick I (independently re-)discovered during the project.
My original version of the player's collision detection and movement code ended up a fragile mess just as I described above, as I kept having to add in new collision points and handle more and more edge cases yet player could still slip through the cracks in certain cases. The solution, in our case at least, was to offload the problem onto the level designer and stick with a single collision point at player's feet rather than trying giving the player a collision area. Then we merely had to widen the collision map around the edges to account for the extent of the player (which was straightforward since we had a separate collision/attribute map.)
What other tricks, great or small, do *you* know? Perhaps you've found a nice way of doing animation, a nifty method to get emergent behaviour out of simple enemy logic, how to make that big player state-machine manageable, etc.