Things are Developing

I can’t believe it is only Wednesday; it feels like next Thursday so much has been going on. Java projects are done and turned in, Java final is over, freelance work is done (for now), gave a speech at last night’s Spoilrr Meetup event, trying to coordinate people buying my furniture, prepping for this week’s move back to San Francisco, building a Joomla website for a client, job interviews, informational interviews, and probably a few things I’m forgetting.

After getting file_wrangler_2 to alpha status last week, I’ve had to spend this week taking care of all the other life-things that have languished a bit during development. This means file_wrangler_2 development is delayed by a week, but as of next Tuesday life calms down again (did I just jinx it?) and I make a major push to wrap up.

Ah, it is so difficult to decide what should be in version 2.0 and what should wait until 2.1 and 2.2. That roadmap is essential for helping me keep my sanity, and I wish I could put everything ever asked of me into the first release.

I have two screencasts I’d like to upload soon. First, a file_wrangler_2 feature demo to briefly show how the new interface works. Second, the presentation I gave at Spoilrr last night was to help define for content creators what it means to “develop something for the iPhone/iPad”. As a kind of introduction to the various ways one can get content onto the iPhone OS platform, I think it contains a lot of good information. Last night’s slides are being shared at http://www.slideshare.net/spoilrr. If you are a content creator and know a group that may benefit from this information, I’d enjoy giving a high-level overview in person, gratis. I think there is a lot of misconception about the development process and I always enjoy the challenge of helping creative minds understand what technology can do for them.

file_wrangler_2 “Alpha” reached!

A big push this week to get an early version into a few testers’ hands today for an early alpha of file_wrangler_2. I’m very happy to have the program to a point I’m ready to share with a small group and after using it for a while, it is difficult for me to use other, similar programs again including my own! It is my hope that the interface I’ve developed will become a distinguishing “signature” for my utility software, so it is important to me to get it right.

It is currently running on 10.6, but 10.5 compatibility is my intention. There are some features that have been requested in the past that will not make it into the 2.0 release, but the groundwork is laid for introduction in 2.1 or 2.2. I need to make sure the foundation of the program is solid, especially with regard to the new user interface, before committing further development resources into feature additions.

I can’t help but feel a little nervous, having reached this milestone. I know a lot of people around the world have come to enjoy the original “file_wrangler” and continue to use it to this day. Nobody’s expectations for the program are higher than my own, and I certainly do commit my time and energy toward the goal of delivering a solid product with outstanding customer support.

If you have previously made a PayPal donation to file_wrangler_2 development and would like to give early feedback on the new version, drop me a line and I’ll send you a copy.

Review of 17″ Core i7 MacBook Pro (mid-2010)

My last Macintosh purchase was about four or so years ago with the first Intel-based 17″ MacBook Pro. With 1GB RAM, 100GB 7200-RPM hard drive and the almost-instantly-obseleted 32-bit Core Duo running at 2.13GHz, it is a machine that remains viable and functional. I have never had any issues with the system whatsoever. It has been a rocksteady, stalwart friend and convinced me I never need to buy a desktop system ever again. It traveled the world with me, dutifully performing its duties as dual-boot game machine, design machine, and primary development machine.

Alas, it has recently begun to show its age in the screen, making it difficult for my already-terrible eyes to focus on its dulling, yellowing image. Hooked up to my TV or an external monitor, it yet has much life in it, but for my daily on-the-go needs I’m afraid its day has come. So, he gets turned into a media center for the TV, hooked up to the QNAP NAS drive and the PS3, and I splurged on my next laptop, the just announced 17″ Core i7 MacBook Pro.

  • 2.66GHz Core i7 (displays as a 4-core processor in Activity Monitor)
  • 500GH 7200-RPM hard drive (solid state still just a wee too expensive)
  • 1920×1200, 17″ anti-glare screen
  • Stock 4GB RAM

I’ve had it for about a month now, and my first impressions are that the keyboard is a marked improvement over the previous one. A nice solid, poundable feel and I especially like how the keys don’t appear to be so easy to pop off. I never had the problem on the old system, but I’ve certainly experienced it on similar keyboards.

The build quality is phenomenal, and I can’t go back to the lid latch of my prior system now. The magnetic closure is solid, especially with the fit and finish of the aluminum case. Some complain about the sharp edges of the unit cutting into their palms, but the 17″ has a nice spacious wrist rest and I don’t find that to be a problem.

I have a very difficult time looking back at the screen on the previous laptop as well, and not even for the dim, yellow reasons. The pixel density is much higher on this new unit and everything just seems too big and chunky on the old screen. Menu options are huge, and I feel cramped using it. When I have multiple windows open in Xcode, I truly enjoy the utility of freedom in having those panes open simultaneously without needing to scroll and jump between them. And have I mentioned how BRIGHT the new display is? Almost blinding with full brightness turned on in the dark. Have we entered a time when things can be TOO bright?

I’m still feeling a little mixed on the trackpad, if only because I’m not convinced it works properly. Or maybe it is a software issue? I don’t know, but something is definitely wonky here. At times it seems not to register my trackpad clicks, requiring multiple clicks where I swear I only need to click one time. I have definitely seen it not close a window when I click the red “close window” button, even after multiple clicks.

However, the red button does visually register the click. In fact, that is typical. Clicks that do not perform the expected action (a menu choice, a window close, etc.) do VISUALLY seem to register the click, yet nothing happens. Multiple clicks on the close button do nothing, but then mouse to the minimize button and it works as expected with the very first click. Thereafter, clicking behaves as expected.

Even now I’m experiencing strange behavior with the system beyond the trackpad. My brightness and sound volume buttons aren’t working, but the Expose and Dashboard buttons do. If I go to the Apple menu and choose “About This Mac…” nothing happens. Why would that stop working, of all things? When did it stop working? The volume keys were working not ten minutes prior to writing this review, and yet here we are. I will say, though, that inertial scrolling is something I can never give up again.

The other day, the trackpad was acting SO bizarrely I thought I would need to take the unit into the Apple Store for repair. It continually acted as though two fingers were on the trackpad, unless I hit the Escape key a number of times, then the trackpad behaved normally for about 10 seconds before returning to normalcy.

Windows 7 64-Bit Professional with Aero in Bootcamp is quite nice and I dare say I may even LIKE it. I was never too smitten with Windows after XP (and XP itself kind of drove me crazy), but Windows 7 Professional is something I can get behind, though coming from XP there is a bit of a learning curve and the visual display of glassy “windows” may be taking the metaphor a bit to an extreme? That said, the OS feels solid, look good, and honestly makes a good pairing with the MacBook Pro (please enable inertial scrolling in Bootcamp, Apple!).

The speed of the laptop is difficult to gauge, because I honestly don’t push a system very hard. Build times on file_wrangler_2 are definitely faster than my previous system, but when we’re talking about a difference of 5-10 seconds, it is hard to say, “Oh my God, this system screams!” That said, Half Life 2, Episode 2 in Windows 7 runs at 1280×720 with all graphics options set to high, plays silky smooth, and revealed graphic details I had never seen before (the contorted faces of headcrab victims, for example) on my previous system. If Oblivion didn’t make me physically nauseous when playing, I’d love to see how it fairs.

So, all in all I would rate the system at a 8.5 out of 10. Given the advances since my previous system, I expected more of a “Holy cow, the differences are like night and day!” But I’m not feeling that; rather I feel more like, “This is a good, solid system. If the issues I’m experiencing get ironed out, I will definitely enjoy using this system for years to come.” Oddly enough, I feel the difference in performance more on the Windows side than in the Mac, which may just be a testament to OS X and its ability to run well on older hardware (both systems run 10.6.3).

Quick Update

I’m a bit overdue keeping up with the blog lately, so here’s just a quick update on the goings-on (going-ons?).

file_wrangler_2

Lots of good progress has been made over the past two weeks with file_wrangler_2′s user interface. Some big breakthroughs, some design reconsiderations, some learning… it all amounts to a pretty interesting way of dealing with files and filters and renaming procedures. The long and the short of it is that Macintosh users have certain expectations on “how things should work” and I want to adhere to those expectations as much as possible. This means digging into areas of Cocoa that formerly weren’t so important to me. It has been a lot of work, but I believe the payoff was well worth the effort. What I have now is a toolbox of modules that represent filtering and renaming tasks (or intentions, as I think of them when developing). Clicking on a tool adds a miniature interface to the main window in a “well” devoted to one category of task. So “filtering” has its own “well”. These miniature interfaces look like little blocks, similar to Dashboard widgets I suppose (that’s a bit of a stretch) and the blocks may be reordered and rearranged by drag-and-drop, similar to how the slide ordering in Keynote works. Blocks move and slide out of the way to make room for your drop location. Changes to the well are instantly reflected in the file list, which is big, front-and-center, and clearly the dominant focus of the app.

A speaking arrangement

I will be giving a 10-15 minute talk tomorrow at the inaugural get together for a new Meetup group called “Spoilrr” started by Robert Pratten. I’ll be speaking about “How creators get their content onto the iPhone & iPad – a look at the development process, timescales and revenue flows”. Creating content and getting that content into consumer hands are very different processes. In the realm of transmedia, many wish to leverage technology to tell their stories in new ways. My talk will be a kind of primer for storytellers about how to work with a developer to make, distribute, and make money off of these new media explorations. We’ll be at Sandbox Suites on Tuesday, April 27 starting at 6:30 p.m.

Reviews

Two impending reviews in the works. Recently bought two new computers and I’d like to share my findings, especially as compared to one another. First up, Apple’s new Core i7 17″ MacBook Pro represents the latest-greatest of the high end of things and has been quite a dream so far. That will be followed by the absolute opposite end of the spectrum with a 4-bit computer that must be programmed in machine code and is giving me newfound appreciation for what happens inside the computer. I wish to understand at a more fundamental level what my code does to the machine, and I have to say I’m enjoying beyond expectations the older architecture.

Review of “Racing the Beam” by MIT Press

Racing the Beam by Nick Montfort and Ian Bogost, published by MIT PressThe difficulty is legendary, yet I can’t say I ever truly “understood” the troubles in programming an Atari Video Computer System, or Atari 2600 as it is better known. MIT Press’ new series “Platform Studies” aims to choose a target system and examine how the construction of that platform dictates the growth and maturation of its software. Great artists struggle within the confines of their chosen medium, and this is just as true in software as in physical media.

Their first examination is the Atari 2600 and its “television adapter interface” (TIA) in the book Racing the Beam by Nick Montfort and Ian Bogost. To say I was enthralled is a complete understatement. I found the book a quick, enjoyable read that didn’t get bogged down too much into the arcane, while not shying away from digging deeply into the machinations of the TIA to show the challenges faced by developers on that system.

One would be hard pressed to find a developer today who really understands what is happening behind the code she writes. We’re so accustomed to writing to software APIs which themselves are written upon a software API which is itself built upon a software API which is built upon an OS which is built upon a kernel. The 2600 and its TIA were basically a direct link between program and television electron beam. The system had no operating system and so each game essentially became a custom-tuned, handcrafted series of assembly language calls that did one thing and one thing only: play one particular game.

Reuse of concepts was important, but reuse of code seemed to be almost an impossibility. Some code relied upon happenstances of other code to feed registers appropriate information at appropriate times. When you have a system with 128 bytes of RAM (!) the programmer must essentially try to outrun the television scan-line, feeding it the color and position of pixels in a kind of JIT manner.

As the system could not hold an entire line of data in memory, let alone an entire screen, we must surely appreciate the efforts that looked at these limitations as challenges to overcome, not barriers to creativity. Consider the game Pitfall! (one of six games covered in the book) and its 256-screen wide map of exploration. Now consider that the entire map (which is location consistent, not random), its graphics, its gameplay, its sound effects… all of it fit into 4K.

Also consider that another of the profiled games, Adventure, fit in 4K as well and only had a map of about 30 screens (warning, linked map graphic at 30K is 8.5x larger than the entire original game). Comparing the world size and graphics fidelity, we can clearly see that programmers gained more and more mastery (and by mastery here I do truly mean a deep understanding and ability) of the machine. Racing the Beam seeks to illuminate this process for us and does so very well. Perhaps the highest compliment I can pay the book is to say that it sparked in me a desire to tinker with some Atari 2600 code. Not so much because I wish to make a game for it, but more to appreciate that as a programmer I am always programming a machine, no matter how abstracted that level has become for me. To appreciate that, I feel I must actually do such a thing at least once.

For understanding the machine behind the code, I must also recommend the No Starch Press series Write Great Code. I found the books to be well-written and also found myself challenged to reconsider some of my daily programming challenges in terms of the machine. Not from an implementation point-of-view, but more in the sense of, “Do I actually know what the code I’m writing does?” As an intellectual pursuit, considering how I would cram the state of a chessboard into as few bits (I do mean bits, not bytes) as possible proved almost liberating in its tightly focused scope.

I also felt that Racing the Beam helped me put into words what I find so boring about video games and media these days. It really boils down to there not being any limits nor boundaries to consider during the creation process. There is no longer any real reason to create art that looks abstract when it is so EASY to make it look real. Just take some digital photos, scan in some 3D geometry, map the textures and you’re done. We can see this lazy approach by just looking at the plethora of look-alike games and look-alike graphics. The “gritty, urban” environments that dominate the game worlds, the “gritty, urban, stubble-headed” characters that populate them, the orchestral soundtracks, the lifelike sound effects… all of this stuck onto a Blu-Ray disc that holds 30GB. There’s not really any constraint in storage, and while the Cell processor of the PS3 is difficult to program, it isn’t really presenting “limitations” unless absolute reality is your goal (and it often is, and so it is seen as being challenging).

Basically, we’re at a point in game design where if you can think of it, it can be done. Why put much deep thought into a project concept when your first concept is instantly possible? There is nothing to struggle against. Nothing to harden yourself against. No boundary to constrain your vision. No limit. This seems like such a great idea, and yet Barry Schwartz’ The Paradox of Choice builds a compelling argument that it may not be all its cracked up to be from the consumer level. Perhaps this also holds true at the creator level?

And yet, on a machine like the Atari 2600 with its many limitations, entire genres were born and an entire language for gameplay was created. I can’t help but wonder what a generation raised on games that are literal interpretations of reality must build in the future. When I can’t tell the difference between Madden 2010 and a televised game, I have to wonder if this is actually progress. Isn’t going back to reality the regressive state? I am all too aware of the games that try to do something different. We all know this short list by heart (Rez, Space Channel 5, Portal, World of Goo, Ico, Shadow of the Colossus, et al)  precisely because it is so short.

I would love to see an iPad enhanced version of this book, taking cues from the The Elements for the iPad and AppStar GamesTechnical Wizardry series for the iPhone. Seeing living representations of the machine and its code, giving the reader an opportunity to tinker and tweak register settings, then seeing live changes in a running game would really get some of the more technical points across. All said, it is a great book and a must-read for anyone who programs and has an interest in video gaming. If you’re older, you’ll recall the system fondly and learn a lot about a machine you thought you knew. If you’re younger, seeing the roots of gaming’s visual vocabulary may kick your thinking off in new directions and build an appreciation for the deep, rich history this young hobby already enjoys.