APEs, Motors and Floaters, Oh My!
So, I spent some time getting back to PP:AFAA today and worked out some hacky solutions to the floaters. Getting buoyancy to look good was actually fairly challenging for my tiny brain, however I created a fairly convoluted algorithm which should supply all the requirements for the prof. This got me thinking hard about the purpose (porpoise? haha!) of Melba Toast and what exactly I am trying to accomplish with the engine. The original intention of the engine was to create a fast, reusable codebase which I could go back to for multiple games and maybe share with other developers (though i'd probably have to start commenting...) who are trying to accomplish similar goals. This is especially important for Intuition as our goal is to create multiple games on a shorter time frame in order to iterate on lots of cool ideas, find a broad market and have fun.
The problem is that engine development is not quick, it takes a lot of work and research to find optimal algorithms for every facet of functionality, and while I can work with the unfinished engine to create quick games like PP:AFAA, I have to fill in the missing functionality with hacks which don't take as long to research and work fine enough in the mean time. So this gets to my point, which is I am struggling with deciding whether to take a longer time to write solid code now and take a lot longer on development for negligible short term benefits (i.e. PP:AFAA don't really NEED collision based on separation of axis theorem or a spring system) or do I just hack it up and get it out the door? I need to learn how to do it the hard way, but I'm also a lazy american who wants it and wants it now.
The obvious third option is to use an open source physics library like APE or Motor (though i'm not sure Motor is going to be freely available) though the obvious down side of third party physics solutions is that they are not tailor made to my specific problems and I don't know their interfaces...
For now I'm hacking it, and if I need to I'll fix up the code later. That's generally the accepted choice of game development, from what I understand, but as a programmer I still hate writing code I know is bad and needs to be replaced.
1 comment:
Hack it up and get it out the door every time. No doubt about it. What tends to happen with a lot of projects is either you decide that the fancy feature you had in mind doesn't even need to be used for whatever reason, or you stumble upon something while working on the game and end up going in a different direction. At that point, several features could be cut.
Now sometimes, you actually do end up using the feature, in which case almost no one can tell whether or not it's hacked in.
This leaves a roughly 1% chance that you should have "done it right." In that case, you just refactor your code and improve your design - after you've already proven that the feature actually needs improvement.
Post a Comment