Rotary-Dial |
 |
GO LOAF!
A month ago today, I had the distinct pleasure of going to see Archers of Loaf on their reunion tour in New York City. They were amazing -- every bit as much as they were back in the 90's when I saw them a Roseland, Tramps, Maxwell's, Irving Plaza...
They played almost everything I wanted them to. Among those: Strangled by the Stereo Wire, wrong, Audiowhore, and Dead Red Eyes. I would have liked them to play Telepathic Traffic, backwash, and the 3-song stretch on All the Nations Airports of Worst Defense/Attack of the Killer Bees/Rental Sting. But after 2 hours and as many encores, I can't really complain.
This show was better in ways than those back in the day. First off, the smoking ban is a flippin' godsend. No longer do you have to shower immediately after leaving a show. And equally nice: there was only one opener. In the 90's you'd to have to sit through 4 bands before the headliner came out. Here's to not punishing the fans.
And to top it off, I was feet away from Eric Johnson, and was able to grab his setlist. Yeah, I'm that bastard.
A great review of the show is over at Spectrum Culture. The writer captures the feeling of having been there, and has some interesting commentary about how the band, the scene, and the symbiosis they share, have changed since Archers' first run.
Live! (long "i")
Our server move is done, and the new site is live now. Still grappling with a few loose ends, so bear with me as I figure things out. The main feature I hope to implement soon is a sound player with songs from all the old Rotary-Dial bands (similar to what's on the pointfive site). Nostalgia!
The seed sprouts...
June was a month of reinvention for me in many ways. Individually, I started a new job in a completely new technology, and began a personal Android side project (more on that elsewhere). But more importantly for those of you reading this, I decided to change the vision and purpose of Rotary-Dial, while simultaneously changing web hosts and migrating it to new technology. It's been a lot to take on at once, but honestly I find it more effective to overhaul everything at once--including long-held mentalities--than to incrementally tweak and change. Cerebral moss tends to grow in the corners that aren't getting light, so to speak.
I started Rotary-Dial in, what? 1997? Something like that. Over the years, the website took shape much like an under-weeded garden (yes, ladies & gentlemen, apparently the analogy of the day is plants). It grew and spilled in fits, eventually becoming a mish-mosh of Perl, PHP, Flash and flat HTML. I avoided content managers because the customizability was low. Certain areas--such as the pointfive page, were a little easier to manage because I implemented XML feeds to drive the content, but it still wasn't a snap. As a software developer, this always irked me, but since it wasn't my day job I just lived with it.
Now, enter Drupal. As I redeploy Rotary-Dial, gone will be the custom-to-the-punctuation site whose teeth slowly go crooked as browser versions increment. Though the programmer in me feels like I'm selling out to use a content manager that I didn't build myself, Drupal is pretty rad. First off, it's open source, which agrees with my sensibilities and ($0) budget. Secondly, it's about as modular as it gets, has a thriving community, and has plenty of capability for custom code should I get the itch.
Plus, as a programmer, I'm at the point in my life where I'm not interested in doing stuff I've done before. Yet when you're running a site--especially one like Rotary-Dial that isn't updated every day--that's what you're doing 90% of the time. Rehash. I'm confident Drupal will be the solution for that particular headache.
So in I dive, both feet. What better way to shed the moss and briars?
A Programmer's Progress
A programmer's progress can often be represented thusly:
foreach(step_forward) { |
For the last couple months, I've been working on prototyping an Android game. I've been interested in exploring indirect control schemes for games (kinda-sorta like Lemmings, if you've played that). It seems especially fitting for mobile interfaces... it annoys me when touch-screen games require precise control that's difficult to achieve on such a small device. I started with Java, then was turned toward Processing (which is really just a layer atop Java) by a friend and accomplished Android developer, Matt Parker.
After a few weeks, I had the movement down I wanted, but as I fleshed out certain routines such as collision detection and physics simulations, I felt like I was reinventing the wheel. I knew other people had done this before, and had done it better than I could. That's when I discovered Box2D, a open source C++ physics engine, and its Java port JBox2D. Several physics-oriented games (including Angry Birds) use this library, so it seemed like the right direction to go, but it would require reworking pretty much everything. Still, that would take less time than recreating all these functions myself. So, cortex to the grindstone, I continued.
After working with the engine a bit, I really came to like it. Even the vector object (Vec2) and methods worked better than Processing's default PVector. But I'm no physics genius, and the library isn't exactly straightforward. Thankfully, there are some excellent tutorials out there, and some clever folks have even written wrappers to make it easier to use with Processing. One of these was BoxWrap2D. This would require yet more rework, but I was knee deep by now so onward I slogged. A week later, I had things working to a point and began testing on my Droid X. Nothing would move on the screen. After some research, it became clear that BoxWrap2D just doesn't render on Android yet (which is understandable; the author considers it a "pre-alpha" version).
This was a most frustrating setback. I was sick of reworking the same things over and over again. I got over this quickly when I discovered Fisica: another, more elegant JBox2D wrapper. There are a few things I don't like about it--like most coordinate methods take float x, float y parameters, while I'd find Vec2 preferable, and the underlying JBox2D objects are protected--but those things aside, it's decently straightforward and runs on Android. Now I'm hung up on some hopefully minor points (sensor collisions, dynamic body scaling), and think I'll have an updated prototype in a week or so. Next post, more talk about gameplay and less about all these under-the-hood details.