The Animal Farm

May 29th, 2010

Book Review! : Blink by Malcolm Gladwell

About a month ago I moved into the new apartment and Laura purchased a few books; of the three that she acquired, one did not appeal at all, one was by Sarah Silverman and thus appealed negatively, and one was mildly interesting. I decided to read the most interesting of the three: Blink by Malcolm Gladwell.

A combination research, case studies, interpretation, and original thoughts, Blink’s main premise is thus: the brain does a lot of stuff subconsciously. Some of those things, ala split-second decision making, it can do really well. In certain instances the rapid thought processes can outperform calculated decision making. Moreover, a lot of problems that seem very complex on the outside - for instance determining whether a marriage will succeed or a doctor will be sued for malpractice - can be determined based on an incredibly small amount of data.

Unfortunately, the book spends about 50-80 pages establishing those points and then the next ~150 floundering, repeating itself, and making suspect connections. The first few research endeavors presented are very interesting, but when the author starts to deviate from those or is left to his own evaluations of events, he comes up short.

A quick example: In his discussion of the medical malpractice study, Malcolm manages to undermine his entire focus in the final sentence.

The text quite often goes back to the early studies, sometimes drawing them in where they’re only tangentially connected to the point, sometimes trying to show things through them that isn’t quite appropriate, and sometimes just brazenly repeating things over and over. At best it’s unnecessary padding; at worst it’s misleading.

The final 1/3rd of the book is especially painful; the author seemed to have lost his point by then and was presenting case studies, forcing in his own ideas and hoping the previous text would back up those interpretations. He all but abandons research, instead relying on his own interpretations to carry him, but he never lives up to the actual studies he presented earlier.

I can’t recommend this book. I was excited about it when I was starting, and it created some interesting talking points with coworkers, but after that it left me unimpressed. I’d suggest finding a researcher in the field to point to some good academic articles instead.

It ends in QED. You can’t argue with math.

May 29th, 2010

Explorations in Android 2

Another continuation post? And on the same day as the iPhone continuation? Crazy talk.

Developing more on Android, and here are more thoughts:

(1) Java Generics Really do Suck
No static access? No access to zeroary constructors? No array creation? No value types? Give me all the excuses and work-arounds you like; C# and C++ both have no problems here.

(2) Emulator = Slow Slow Slow
Last time I mentioned how slow the emulator was to start; now I’m mentioning how slow it is to run. These can’t be the performance characteristics of an actual device, lest nobody would get anything done.

(3) Yet Another Slow Garbage Collector
Why are you going to give me garbage collection if you’re going to turn around and penalize me for it? If, in the course of avoiding garbage to prevent performance jerks, I have to manage all my memory, you might as well give me memory management control! I am constantly perplexed by platforms (Android, Xbox) that impose language constructs and tell me I shouldn’t utilize them. Memory pools = your friend, I guess.

(4) I’m a Bit Skeptical of the Canvas
Right now I’m going through all the Canvas 2D drawing methods. There are some constructs (like Paint) that leave me scratching my head and wondering why, and there are a few methods I’d like to see but don’t. I think I may be better served going through OpenGL ES (luckily I have modular rendering code in this project, so switching shouldn’t be hard).

(5) Too Many Control Variations
One of the big pluses of developing for Xbox and iPhone (and usually the PC) is that there’s exactly one control scheme you have to support, and everything else is optional. Well, Android runs on a ton of different handsets. Will they have a touch screen? A track ball? Convenient arrow buttons? It’s hard to say. I still need to do more research about the market and see what people expect, but no part of me wants to write a ton of control code.

I’m wondering internally how hard it would be to write a cross-compiler to take restricted code from Objective-C (as a baseline simply because it requires explicit memory management, and converting in the other direction sounds like no fun) and shift it to other mobile languages/platforms, with little ‘TODO’ stubs for places where it chokes. The answer, of course, is “pretty damn hard,” though Airplay seems to be pulling something similar off? I’d just use Airplay if I weren’t worried about its relationship with the new iPhone license.

Moving into Mobile Land is… ugh…

I wonder how much I can get done with a three day weekend.

May 29th, 2010

iPhone/iPad Game Dev Best Practices 2

Continuing the miniseries, here are some more good ideas I’ve learned while developing for the Apple platforms:

(1) Beware NSTimer
Using “fire and forget” timers seems like a great idea, but it may not be ideal in a world where states transition constantly and unexpectedly. Example: something special in your game triggers a timer that causes a point pop-up to display later, but before that timer fires the level ends. Best case is you get an ugly point display on the level-over screen; worst case is the game crashes. Either use something that gives you a finer level of control or make sure you’re managing the timers appropriately.

(2) Understand shouldAutorotateToInterfaceOrientation
This method is not the appropriate place to DO anything, mostly because when it gets called is unpredictable and varies between SDKs. It’s a query only. If you want to actually do something in response to an orientation change, either listen for the appropriate message or add the appropriate delegate to your view. I forget the names of both of those right now, but you’re industrious people who clearly have the internet available.

(3) Don’t Use Apple’s Private APIs
This is expressly forbidden by Apple. There was a time when you could get away with it, and that time is over. It’s tempting, since the private APIs have some handy functionality like turning off rubber-banding on a web view or showing a text field in an alert, but you’ll get failed during review. Trust me.

(4) The iPad is Different
That seems obvious, but it’s different for a more important reason than just screen size - the Human Interface Guidelines are different. The most notable change is that users expect the iPad to “just work” regardless of what orientation they’re in - there’s no real “up” for an iPad. And when I say the users expect this, I mean Apple’s reviewers expect this too - I’ve read about plenty of people being failed for not supporting rotation properly. There are of course special cases like games where you can support only landscape (both versions of landscape, mind you), and you should be aware of those while developing. In short: read the HIG document.

(5) Regarding Facebook, Ads and Such
There are a lot of libraries that add a lot of little touches. The Facebook API is not terribly hard to implement and can get your game a little more exposure (though how valuable that exposure is is pretty open to interpretation). Ad services like AdMob can help monetize a free application. Flurry Analytics can give you valuable information about your players.

That’s all for now. I’m constantly putting together more ideas, and so we’ll probably see the series return in the future, but it won’t be a regular thing.

The Android is more fun to develop for anyhow.

|