Sometimes, the choices you make regarding software behavior during development are driven not by user requirements, or even by your personal notion of cool, but rather by limitations imposed by the technology you are working with.
Printer Friendly displays a splash screen whenever it is called to action. The splash screen is displayed in the trial version with a delay and a nag message, for obvious reasons, but it is also displayed in the registered version of the software, without a nag message, and with a very tiny delay.
This was done not because I love showing off the Printer Friendly logo whenever a user wants to print something (although it is cute, and a good sum of money was spent on designing it), it’s done purely to hide a technological dependency. The Internet Explorer extension framework allows me to only take the functionality of Printer Friendly to the point of making the page “friendly”. What it doesn’t allow me to do, is to make the final “print” call without having a window that hosts and additional Internet Explorer embedded control inside of itself. I’m stripping out the details here so as not to bore you, but rest assured, the easiest way to achieve what Printer Friendly needed to achieve (in a reasonable amount of time), was to send the final result through a secondary Internet Explorer control.
Now, how was I supposed to do this without opening up a new Internet Explorer window for the few milliseconds that Printer Friendly needed to make the final print call?
And so, we have the splash screen. It’s there in the trial version (a dual-purpose use justified by both a technological and a marketing need), and it’s there in the full-version. In fact, there is one more piece of stupidity stemming from the fact that a splash screen is required even in the full-version of Printer Friendly – the delay. There is a hard-coded imposed delay of about one second before closing the splash screen in the full-version of the software. Printer Friendly only needs the window for a fraction of that time, but I can’t have the customers seeing a weird flash of a window opening and immediately closing every time they try to use the program.
And yes, I have thought about launching a “hidden” window for this purpose. And no, it does not work (one of the details I’ve stripped out above).
The second example came up this week during development of Asteroid Jane.
The mechanics of Asteroid Jane are quite simple. Jane is out there…in space…on an asteroid…trying to make a living by mining minerals, gems, and other goodies. She releases a big hook attached to a rope, and hopefully pulls back something of value to meet her quota…imposed by…I don’t know…the asteroid mining cartel.
What’s the technological limitation? The BlackBerry screen resolution combined with the notion that items of value contained in the asteroid have different weights – meaning that if the game is to be at least the tiniest bit realistic, a heavier item would have to take longer to reel in.
With the largest resolution of 320×240 pixels, there isn’t much wiggle room available. Add to this, the required areas put aside for things like level statistics and Jane herself, the wiggle room become even tighter.
With such a playing field, smooth animation becomes tricky, as a jump across even a single pixel is very visible. At an imposed speed of 30 FPS, the hook releases and reels in without any weight attached pretty smoothly (with some trickery). With an additional weight, and no sub-pixel calculation available, the only alternative is to skip logic processing frames (but not rendering frames) in order to slow down the reel-in animation of the hook to simulate weight.
And here is the problem. The 16×16 sprite is crossing an area of 180 pixels (at most), diagonally (a 90 degree drop straight down isn’t really a problem – it’s the shift of both the x and the y coordinate that kills you). With such a small field, an update and rendering frame can produce a smooth reel-back. Skip even one frame, however, and you have a jittery mess on your hands. But you have to skip the frame to simulate slow-down due to the weight of a hooked asteroid goodie.
Enter the trick / game feature that makes this possible (although in reality, would have been unnecessary had the technological limitation not been there). Jane will now take “rests” during the reel-in. The reel-in will take place at the regular speed for all items, no matter the weight. But if a hooked item is heavy, Jane will stop reeling the hook in every few frames, and let the hook and the attached item “slip back” a few notches. Both the reel-in and the slip-back take place at the same speed, so the animation is smooth, but because of the slip-backs, it takes an overall longer amount of time to reel-in a heavier item than it does a lighter one.The result is a cool effect, and forty extra minutes of required development work.