The Animal Farm

May 31st, 2010

Dear Established Readership

Hello readers of this blog, my name is Ricky. As a former roommate of both authors of this site, Brian has somehow conscripted me into service as well. Let’s talk about me, shall we?

I’m a reformed software engineer currently working towards a masters in electrical engineering at West Virginia University. I enjoy video games, movies, math and motorcycles. And pickles.

Hopefully I’ll have something to add to the conversation that isn’t entirely inane drivel.

I refuse to leave closing messages no one will understand.

May 30th, 2010
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.

May 22nd, 2010

Explorations in Android

Decided to go ahead and take a crack at porting See the Light over to Android. Here are my first impressions:

(1) I have no love for being locked into a platform by way of the language it chooses to support. Android’s Java is no exception. I’ve read about some C++ support which would increase cross-compatibility, but Google recommends not using that for full applications, so I haven’t explored it too deeply. Rewriting code = No Fun.

(2) The emulator is Garbage. Multi-minute boot times for a cell-phone emulator in the 21st century? I can grab a PS2 emulator off the internet that churns faster and more reliably. And it really is quite unreliable - my app actually starts about 50% of the times I hit the launch button.

(3) Eclipse > XCode. It feels good to work in a proper IDE with a real debugger again.

(4) The time between downloading the tools and getting up and running with a brand new project was pretty minimal. That’s not much different with XNA or iPhone dev these days; I’d probably rate them all about equally.

(5) Community interaction is solid. Whenever I’ve Googled something, the answer is usually within the top 5 links. That’s been a far cry from the painful iPhone searches I’ve done. XNA is about as good.

(6) Standard library is a little lacking compared to XNA, but then Android isn’t as game-centric. I had to rewrite a few geometry classes and work out how to do some intersection tests that XNA is kind enough to provide. I can’t really compare it to iPhone SDK, since I haven’t dived that deep into the graphics code.

Still getting my feet wet, so I haven’t formed excessively strong opinions, but give me time. Oh, give me time.

Not if you wanna get on VH1 one day.

May 21st, 2010

Is There an Android in my Future?

I’m faced with a dilemma.

There are two competing platforms. There’s iPhone, the current “market leader” so to speak. It’s supported by an evil empire.

There’s also Android, the up-and-comer that’s been making significant headway. Perhaps not as widespread, but it’s gaining ground and also supported by a friendly company.

Both require about an equal startup investment - with the iPhone I would need to acquire a Mac and I could steal someone’s iTouch, and with the Android I would need to purchase an unlocked dev phone.

Both are developed primarily in languages I have no real love for - iPhone in Objective-C, which I’m actively using and with which I have grown fairly familiar; Android in Java, which I haven’t used heavily since 1.5 but know pretty well.

Both have markets I’m wary of - Android’s is smaller and I know virtually nothing about it, but conversely iPhone’s is pretty saturated and I’ve heard nothing good about it.

See the Light and Word Duelist need a new audience, and I need a new one-man-friendly platform. I’m shying away from Windows 7 right now, though it would definitely be the most straight-forward port. I’m not, however, sure what direction I want to go in quite yet. Suggestions? Anyone want to donate a dev device?

You have to adjust the loop-locks.

May 21st, 2010

iPhone/iPad Game Dev Best Practices 1

I’ve been mulling over a few relatively Good Ideas while doing iPhone dev. I have more than one post’s worth, so here’s, well, one post’s worth, with more to follow:

(1) Localize Late
Localization will inevitably involve interface changes to suit each language, and thus you’ll be left with multiple versions of the interface. If you then have to change something non-language specific like adding a new view, you have to change that in every unique interface, which is painful at best and problematic at worst. If possible, it’s best to save localization for the last step.

(2) Avoid UIImageView for Representing Sprites
It might be a knee-jerk reaction to make a sprite have an associated UIImageView for display and animation purposes, but this slow. Slow in a way you’re pretty likely to run into.

(3) Test Early and Often on a Device
The emulator is nice and convenient and terribly misleading. It basically has infinite speed and storage as far as an iPhone game is concerned, and thus if you’re having speed or memory issues on a real device, they might go unnoticed for too long. Testing on devices of different qualities is also recommended, as you’re a lot more likely to run out of memory or have severe performance issues on a 2nd gen iPhone than you are on a modern iTouch.

(4) Use Instruments but Don’t Trust It
Instruments is The Tool for iPhone profiling. Which is unfortunate since it will lie to you. Use it often to gather benchmarks and spot memory leaks, but don’t trust it to tell you the whole truth. Make sure you check the iPhone logs and output messages for memory warnings to supplement your benchmarks.

(5) Invoke memory warnings
There’s no better way to spot trouble areas than when a program runs out of memory. When a low memory warning triggers, the iPhone will dump a lot of its unused memory and try to keep going. If your program doesn’t crash in the near future (not necessarily immediately), you’re doing good. If your program does crash, it’s very possible you’ve got a memory management problem hidden somewhere that needs to be addressed. Common culprits are failing to retain an object that you access later. Keep in mind that, while the iPhone simulator does have a “simulator memory warning,” option, it doesn’t behave the same way as it does on the device, so things which quietly keep working on the simulator will go down in flames on the phone.

(6) Frequently Test Application Interrupts
When an app is interrupted because of an SMS message or just falling asleep, weird things can happen. Notably the sound system likes to become corrupted and needs a restart. It’s good to find these problems early, since they can be irritatingly persistent.

OK, that’s all we have time for. This won’t be a long-running series like my game polishing posts, but I have at least enough to fill another post in the near future.

Did you calibrate it to binary white?

May 7th, 2010

Donnie Darko 2?

Named s.Darko and starring Donnie’s sister?

Are you kidding me?

Really. Are you kidding me?

You’re kidding me. That’s the answer. I know you are. You must be.

May 6th, 2010

Why Must Interface Builder Be So Fundamentally Broken?

It seems like every day I have a new problem with Apple. I’m not going to touch on their corporate evil (which has, in no uncertain terms, surpassed every other operating system developer) or their gross hubris (if you want to talk about Jobs’s “Thoughts on Flash” with me, make sure it’s not among polite society). I’m fighting my battles where I can fight most effectively - in the tech field.

Interface Builder is broken. It’s not broken in a small, subtle way that you might miss. It’s broken in a rather large, ugly way.

It has no concept of Build Targets.

For those uninitiated, most IDEs - including XCode - have a notion of a Build Target, where each target specifies what is going to be built and how. The part you really want to focus on is “what is going to be built.”

I’ll take a common example: iPhone versus iPad. Assuming you have 2 different SKUs here and aren’t using a Universal app (that idea still makes me a little nauseous), you have a different set of assets per target. To ease coding and interface setup, it’s a perfectly natural thing to name those assets the same and rely on build targets to sort out which asset to use.

Except, as I just stated three paragraphs ago, Interface Builder doesn’t have the build target metaphor. So what does it do? It just picks one of the assets to show during interface setup. Which asset it shows is rather arbitrary; usually it’ll show the iPhone assets while setting up the iPad interface. Which makes it pretty much useless for actually setting up the iPad interface.

You can get around this, of course, by either (a) naming your iPad assets differently and hooking up your entire interface again, or (b) temporarily deleting your iPhone assets from the project and restoring them after the iPad interface is finalized. Both of these solutions aren’t solutions so much as they are dirty, error-prone hacks.

Let’s take it a step further though - the problem also exists with localization. You have a bunch of assets, and those assets are localized among a bunch of different languages. When you’re in Interface Builder editing a certain language’s interface, it’s natural to believe that IB would be showing you the appropriately localized images.

That belief is rational and wrong. What image will be shown to you? I don’t know, but you can rest assured there’s a good chance it will be wrong. Sometimes you’ll get a mix of the correct images and incorrect images. In short, you’re never really sure what your interface is going to look like until you run the application, and if that’s the case you’ve lost any benefit of having a visual editor.

These are not minor problems. They are real workflow-shattering problems. They are problems that make developing large systems unreasonably difficult, and “developing large systems” is precisely where you want as many things as possible to be not difficult.

With all this said, I’ll admit I don’t know how other tools do it. I’ve never had to setup a multiplatform localized interface in WPF. I know how Interface Builder does it, though, and I know Interface Builder does it poorly.


Ice Cream Social = Success+!