“Why are you only writing games for iPhone and not for Xbox too?”
It’s a good question that my friend asked me recently and I really didn’t have a similarly good answer, so having recently got my bearings with C++ I thought it’d be worth skipping swiftly onto C#. And while I’m only a coupla days into my faffery with XNA, I’ve noticed some interesting things about how, lately, my coding style has… well, regressed!
For example, a year or so ago I would’ve told you that lists are The Answer. Coming from a Blitz background I naturally tended towards solving everything that possibly could be solved with doubly-linked lists with the lovely lil’ buggers. The thing is, once you move into the mobile realm, object persistence becomes really important because instantiation is so costly. On iPhone you’ve also got to contend with the fact that garbage collection is half-arsed (the worst kind of arsed) so that, as well as taking time, object creation and deletion is FRAUGHT WITH DANGER. The sensible developer, therefore, soon realises that creating a pool of objects at start-up and leaving it the hell alone until the application terminates allows one to avoid a whole minefield of performance issues.
Of course this begs the question “If you’re not going to take advantage of the flexibility of linked lists, and given that modern arrays can contain objects, why not just use arrays. Like in the eighties?” And while the issue is kinda moot under Cocoa Touch (because arrays and lists are conceptually merged into the NSMutableArray) it is a consideration that I have brought back with me to the desktop: The particle system in Vaders, for example, eschews dynamic object creation/destruction in favour of a persistent linked list with newly assigned particles being split to the back of the list — this could well be a memory-management nightmare for STL under the hood and therefore wholly inappropriate for mobile devices, but it was hella simple to code! Porting the game to XNA I’ve gone back to arrays completely, with each entry maintaining a reference to the next and the element considered “first” traversing the circle as each particle is activated. It was a bit more work than list-splitting, but offers a pretty much ideal combination of persistence and utility.
And sometimes I just sit, look at my code and go: “Fixed size arrays? In 2010? Really?!”
But yes, don’t be embarrassed. If it works, it’s right. We really don’t have to use swanky language features if they aren’t necessary and carry unwanted baggage (which the Xbox garbage collector kinda does). This is a philosophy which I have resigned myself to wholesale where the particle system is concerned. Leaving the specific collection class aside, I had actually planned to write The Mother Of All Particle Systems for VadersXNA because, on the surface, this seems like an ideal area to apply modern language features like inheritance and generics.
Only it’s not. Not necessarily.
The thing is, explosions aren’t fire and fires aren’t smoke and smoke isn’t fireworks. Not remotely. While you might think a particle is a particle is a particle, the members and therefore parameters required by different kinds of efficient particle vary wildly. So much, in fact, that expressing them in terms of an extended common class, to a generics noob, is far from trivial compared to simply duplicating an existing class and editing it to taste. So, each kind of particle in VadersXNA is its own distinct class and, yes, that is something that will have OOP aficionados clutching at their chests in horror… but y’know what? It’s performant, fast to implement, easy to maintain and it works.
As a kid I remember an L-Cars comic strip where one of the characters had constructed a massive, warehouse-filling machine. He sat casually in front of the behemoth, fag in mouth (hey, different times!), tapped a foot-pedal and — click! — it lit his cigarette. Sometimes, with modern programming languages, we create complex solutions for problems that really aren’t worthy of them. Here’s to matches!