I imagine it's applicable to other realms of programming as well, like web programming. We should question if we really need something on the page, or if there's just some way to fake it or get away with doing less. Or same with scheduling notifications to be delivered. Does it really need to be real-time? Or can we just cheat a little since the tolerance is much higher?
Sure, we call this caching. Imagine you have a blog with comments. You can generate the page for each user when he wants it, and then it's a real view onto the data that you have available. Or, you can generate it once a second and just serve the stale version -- not much can happen in one second. Making that compromise is the difference between handling 10 requests a second and 10,000 requests a second. Almost always a good tradeoff.
(Doesn't NYTimes do this?)
This can be used to add fancy animations, add an actual embedded video over an image of an empty video player, add comments to the end of a blog post via AJAX. Most people won't even realize you're giving them static content initially.
Not taking this into account causes unusual UI lag, frequent dropped initial clicks, fast responses from the server but slow page load times, or visual "chunking."
Anyone reading: that's my game development blog, I'm starting an iPhone game dev studio and documenting the progress of starting it up and making the first game, day by day!
Check it out if you're interested in game dev and feel free to ask any questions!
Video of me making the game:
I'm far from an expert, but if you have any questions I'll try to answer them.
If you're looking for a GUI as opposed to a programming API, in addition to the fine options above, my startup (http://www.stencyl.com) also does this and is based on Sparrow (and Flash for exporting to the web).
However, I'll be realistic and say that if you're making an RPG, you'll find it much easier to build it by hand.
The basic version is free, so you can use that for development. When your game is ready to ship, you can upgrade your license to an iOS one and then convert and ship your game with it.
If you want to stick with XNA, there's an interesting project to port XNA to iOS platforms (http://rockethub.com/projects/752-exen-xna-for-iphone-androi...), and there's XNATouch too. I haven't looked into those yet, but if you complete your game on XNA, by the time you'll be done there might be a viable solution to easily port your game to iOS.
Check it out, and let me know if you run into any problems. It's not finished yet, but the first four courses will give you a good foundation. I should have the next two courses posted within a week or so.
We made a Monkey Island-style point-and-click (well, point-and-tap) adventure. It was a fairly complex project, but Cocos always felt empowering rather than limiting. Happy to answer any questions!
About the game: http://launchingpadgames.com/games/scarlett/
Exactly, I think that's default programmer-logic. "If there's a drop, it must have a splat." I used to do some programming but I'm more of an artist than a progger so I figure writing about little artsy tricks like that might help other devs out. It can be rough trying to fit cool stuff onto tiny phones haha
Luc: I'm a pixel artist at heart so I love color cycling, but ya, appearing in front of another layer blows it up. Also these days I don't think iPhone games use palettes much...I know older cel phones needed them, but for iPhone I seem to be able to get away with just using big ol' .PNGs with no palettes (which rules, 'cause I can get anti-aliased edges).
Like I'll be posting my financials for the month soon, even though I know they're going to be negative since my game isn't out yet haha But it's the principle of the thing, getting into the habit of keeping accurate records.
Glad you like the blog! I'm shooting for daily-esque updates so pop in again in a couple days!
Update: There it goes!