Modifying Existing Over-engineered Systems for Fun and (Profit?)
August 16, 2012 
Development, Games 
esdin 
no responses
Tagged with: Engineering • Lazy • Occam's RazorI’m currently working on an under wraps project with a few friends, and one of the systems designed very early on is a FocusManager and an associated CameraMover class. The system is created in such a way that, when you click on an object, the FocusManager uses associated camera information and a built in graph to smoothly interpolate over to an appropriate orientation. This means I can place ‘FocusObjects’ all over the place and at weird orientations, or parent them to moving objects, and the camera will always gets where it needs to be.
This is an iOS title, so I wanted to make sure everything happened Auto-magically. As per my last post, I’m a huge stickler for minimal control schemes on iOS, and so everything in this title is controlled with taps, drags, and swipes. Now, as it happens to have happened, until very recently I was using these systems to their full capability. Multiple objects parented to other objects were navigated in 3D space, with intermediate spherical motion CameraMovers allowing the player to rotate around and then focus on objects with planar movement properties. It was all very nifty. As usually happens in these cases, design revisions recently came down the pipeline asking for something entirely different. Now, all objects are co-planar, and there’s a requirement to ramp between them in order. A simple left or right swipe moves the player up or down the object hierarchy, hovering out above the existing CameraMover’s transform, and clicking focuses on the objects as it used to.
The great thing is, even though this behavior is remarkably different than the previous approach, all of the information I needed was already there. A new “MultiMover” class, inheriting from the basic mover, contains an ordered list of existing movers. While the associated object has focus, the FocusManager uses it’s CameraMover transform data, and internally, the MultiMover maintains a current index for which CameraMover to copy and offset. On cases where it is not in focus, the MultiMover gets notified which object has focus, and checks to make sure its index matches up with that object, so when we return focus to this ‘super parent’ multi-mover, it hovers above the appropriate object.
This kind of engineering is unnecessary when you have a solid design document from the get go, but during rapid development, being able to use the same systems in novel ways (without kludging up your code base) can save a lot of time when deadlines are fast approaching. If I hadn’t separated out the systems earlier on, then I wouldn’t have been able to use them in novel ways, and the same refactor would have taken days instead of hours. While I never recommend using a nail gun when you know you need a hammer, you can still use the big guns to tap in a picture nail. And yes, it was fun. Now who wants to pay me?
