Warning: Declaration of C_DataMapper_Driver_Base::define($object_name, $context = false) should be compatible with C_Component::define($context = false) in /home/geomys0/public_html/wp-content/plugins/nextgen-gallery/products/photocrati_nextgen/modules/datamapper/class.datamapper_driver_base.php on line 0
So, middle of last week I finally bit the bullet and gutted out a lot of the prototype code in order to start rebuilding it smarter, something I’d been planning to do but putting off since before Thanksgiving. Got detoured into spiraling complexity for a couple of days with the redesign, but back on track now. Gone is the original hackey SelectionManager, replaced by a TouchInputManager, designed from the ground up to work properly with multitouch. The old line drawing code was a complete encapsulation failure, with bits and bobs spread across multiple files that it shouldn’t have really been touching, creating painful inter-dependencies that I was having to work around; new version cleanly wraps things up in a self-contained way, while providing the means to extend the behavior with custom events defined in project-specific scripts. And the re-engineered prefabs for cars and characters are structured much smarter, keeping their various components from having some of the problematic interactions they had in the original, and making the code for entering and exiting vehicles tremendously cleaner and simpler than it was before.
While caught up in the complexity spiral, I committed a cardinal sin and spent a day optimizing some code I hadn’t even bothered to profile; finally profiled it earlier today, and at first the results looked bleak, it was not even showing a 10% boost in performance compared to SendMessage, and I was feeling pretty stupid for wasting a whole day on it. Then I realized – I was profiling only one specific situation, when the message is sent and received. So I set up some test cases for the case of sending a message which nobody is listening for – which is much more common, given the volume of messages sent by the new input manager – and in that case it was blowing SendMessage away!
With the new touch input scripts, I think I could throw together a basic clone of Flight Control in a day or two; only feature I would have to add is the detection and verification of landing vectors relative to the runway, but it would be pretty easy to implement using the events the existing line path classes do provide.
Entirely new feature, implemented a system to automatically path around small obstacles, using dynamically-generated circular, elliptical, or rectangular border paths, which can be rotated with their objects. It’s overkill, from the last phase of my complexity spiral, but ultimately it produces exactly the behavior I was needed (and more), and is cleanly integrated as an extension of the touch input and line drawing scripts, so I’ve kept it in and slashed all the other systems it was originally built on top of. This bit resolves what was the biggest frustration point in the early prototype builds, so I’m highly optimistic that once the rest of the code is integrated with the new input foundation, it’s gonna be a lot more fun and a lot less frustrating.
Still quite a few things to implement, but everything input-related is going to be easier than it would’ve been using the old system, and the new code seems to be a lot more solid, so won’t have to keep duct taping everything to prevent it collapsing as I add features like I was before.
On the asset front, have the first sets of assets coming in from my artist now, and they look great! I’d started to feel like my programmer art was pretty good after staring at it for so long, but any delusions about that were shattered once I had some proper graphics coming in to compare them to. Will have all the graphics I need for the playable demo by as soon as the end of this week, though there’ll be a lot more graphics to get done after that.
So things are moving along pretty well, I have to say!