Wednesday, February 20, 2008

Procedurally Generated Pinkslips

Penny Arcade's recent podcast featured a rant - no... more of a reckoning... versus Spore. I find Spore's idea of dynamically generated content interesting, mainly because of my bias towards one-man development teams and procedurally generated content. But Mike and Jerry don't want to see artists and writers out of a job... and the concept that zombie algorithms can build music or images is looked upon with disdain. To them games are an artistic outlet for modelers, musicians and authors. But to developers they can seem like a growing necessity that a garage studio simply can't bankroll.

Eskil Steenberg's Love is described by Rock, Paper, Shotgun as "...lavish impressionistic artwork brought to life... in motion it was suggestive of a smokey, dynamically lit version of Okami." Dynamic terrain deformation and procedurally generated assets allow Eskil to wrap some amazing gameplay into what looks like a surreal and compelling atmosphere.

Not only does this mean that players get to glimpse into chaos, they get to play with it. And anyone who names such an ambitious effort after "For The Love Of Game Development" inspires hope in a lot of indie developers.

Tuesday, February 19, 2008

UML Hell

I've been searching for a UML editor for a while that I like. So you don't have to, I installed (or tried to) several UML editors and took each for a spin. I needed some diagramming mainly for collaboration and presentations... and my choices usually broke down into a) crappy but usable or b) pretty but unusable.

  • Poseidon for UML Community Edition is "free," but you have to register the product. I dislike typing. Didn't install it.
  • Gaphor wouldn't even install or run with my Python setup. Tried for 15 minutes then threw in the towel.
  • Umbrello I've actually used for some time now and consider it my favorite UML editor. When it doesn't crash. Which it does. A lot. I used both the KDE 3.5 and KDE 4 versions, both enjoy the segfault.
  • UMLet remained up, but the UI just didn't do it for me. It was more a random collection of widgets than an enforced UML diagramming tool.
  • Violet was one I really, really like. It was simple to the point of minimalism, which I like. However it had some serious UI bugs that made all elements change their text attribute at the same time.
  • Dia isn't a strict UML editing tool - it's more of a casual diagramming tool. It works really, really well when you want to brainstorm or braindump ideas. But I was looking for something that strictly enforced UML patterns and let me define attributes, methods, classes, sequence diagrams, etc.
  • ArgoUML, once again, is the only one that can make the cut. This is the open source relative of Poseidon and includes a ton of functionality. ArgoUML has been under active development for years and years, and continues to be the only big player on the block. And with Java WebStart deployment it's exceptionally easy to get cross-platform installation on everyone's machine.

    So ArgoUML is still the hands-down cross-platform favorite, with Dia playing a different role yet still the only other contender. At least I finally freakin' settled on one for good.
  • Monday, February 18, 2008

    Intel Killing the VPU?

    I had faintly heard grumblings of Intel loathing Nvidia, but I didn't really put 2 and 2 together until listening to Gordon Mah Ung on this week's No BS Podcast.

    Good ole' Gordo spelled out why Nvidia ultimately acquired AGEIA - because Intel deep-sixed Havok's use of GPU's that had been in development for several years. While Havok was an independent company they worked with both ATI and Nvidia to support GPU processing of their physics API. Once Intel bought them the interoperability was tossed in the trash. I'm sure this was a pretty big dig at the GPU makers.

    So Nvidia purchases the #2 player in the market to ensure this doesn't happen again. Let's see who enjoys the #1 spot in shipping titles during Christmas of '08.

    Eff the Function Lock

    Dear Microsoft:

    The Function Lock key was a funny joke at first, but now it is just immensely annoying. While I love nothing more than spending 15 minutes figuring out why my F2 key stopped working, I really need to move on with my life.

    If you want another lock key, try using the scroll lock. I haven't used it in a hundred years. You can have it if you want.

    Sunday, February 17, 2008

    Make a VPU Socket Already! Get It Over With!

    My lands. If the floating point unit took this long to become mainstream I'd be using a Core 2 Duo with a math co-processor still.

    Not to go all Halfhill or anything, but it has appeared that a vector co-processor or VPU's on-die were an immediate need for at least the past two or three years. Both Nvidia and AMD are bringing GPU's closer to the CPU, and it at once appeared that AMD's multi-core platform has included VPU/FPU/integer math/memory controller/CISC/RISC/misc./bacon&swiss together to take many types of tasks and integrate them under one die's roof.

    And now that Nvidia has wisely acquired AGEIA and their PhysX platform it seems a general purpose vector processing platform is getting closer. A standalone PhysX never took off on the consumer marketplace, and purchasing another Radeon or GeForce just for physics processing (as both AMD and Nvidia were touting at electronics expo's) never caught on either. But a generalized, open-platform physics API that takes advantage of unused GPU cycles would definitely catch on. Spin your GPU fan faster and get real-time smoke effects... sign me up.

    Nvidia has been extremely forward-thinking with their Linux drivers, and I hope they continue to be trend setters with the PhysX API. The PhysX engine and SDK was made freely available for Windows and Linux systems prior to Nvidia's acquisition, but hardware acceleration currently only works within Windows. Since Nvidia is porting PhysX to their own CUDA programming interface, it seems entirely probable that the Linux API would plugin to Nvidia's binary-only driver. And why not release the PhysX API under GPL? They could port to CUDA (whose specification is already open, available and widely used) then reduce their future development efforts by letting a wide swath of interested engineers maintain the codebase as needed.

    Widely available drivers, development kits and APIs will help drive hardware sales in an era where Vista w/ DirectX 10 adoption isn't exactly stellar. I won't invest in being able to run Crysis in DX10 under native resolution for a 22" LCD, but I will invest to get more particle effects or more dynamic geoms. At that point you're adding to the whole gameplay proposition instead of polishing up aesthetics, with continuously diminishing results.

    Saturday, February 09, 2008

    Encryption Would Be Easy... If We Let It

    Whenever something sensitive comes around my desk on a slip of paper I can't think about how much more accessible and secure the info would be if it was passed around using public key cryptography. After all, it has been seventeen years since the more than capable crypto advocate Phil Zimmermann made the case with PGP. Surely by now all e-mail clients can now securely pass info back and forth using some asymmetric key algorithm, right? Right?

    Well, yes... unless you're freakin' Outlook. And of course what to 9/10 enterprises mandate you use? Outlook. Fantastic.

    Now I've been able to sail under the radar with Evolution, which sports both excellent WebDAV support and public key encryption. I've got the best of both worlds in Linux. However the rest of my correspondents aren't so lucky - they need to use a Windows e-mail client that can book conference rooms and schedule appointments in Microsoft Exchange. So... stuck with some variant of Outlook.

    About a year ago I went out on a quest to find an interoperable public key encryption plugin for Outlook. I tried several clients... and all failed. I went out looking again and the playing field hasn't changed a bit.

    First you might notice that there were several Outlook plugins originally vying for PGP/GPG abilities, but they have largely atrophied or merged. OutlGPG became GpgOL from g10, but executable distribution was moved to Gpg4win, meaning that GPG distribution became the single player. The only other option would be G DATA's GnuPG-Plugin, but aside from being over five years old it was never that great. And Gpg4win wasn't much better - it too could only do plaintext, and even then as an attachment.

    All Linux and Windows mail clients that have some remote sanity use MIME to encode their encrypted payload, and yet Gpg4win (from what I've been able to find) refuses to do so. At best I get an attachment which I need to decrypt separately.

    Now look at Thunderbird, KMail or Evolution. All can encrypt and decrypt inline, natively, within the mail browser. And it works seamlessly without any additional windows or superfluous UI components. This isn't rocket surgery.

    Until someone out there makes an interoperable GPG plugin for Outlook 2003 that works with OpenPGP MIME compatible messages, no one will adopt public key encryption.

    Maybe that's the whole idea.

    Sunday, February 03, 2008

    Designing Head Patterns

    When I saw Jason McDonald's design patterns quick reference guide I marked out. I forwarded the link to everyone I knew who heard of the Gang of Four and printed out a nice, one-page color version to keep. I almost freakin' framed it. I liked how succinct it is... it gives you the class diagrams so your brain is instantly sparked, and just enough description that you still have to think analytically about the pattern.

    A few people asked me about the original Design Patterns book and a few others mentioned how much they liked Head First Design Patterns. I have to sadly admit - I originally wrote off the Head First series as just another "X for Dummies" clone, but now that I read the RMI section of their Java book and read the first 100 pages of their Design Patterns book I have to admit I judged... sigh... a book by its cover.

    The RMI section was actually fairly straight forward and illustrative and even included an informative chapter that included Jini. The Design Patterns book has done a good job of explaining the Decorator pattern, something that I can't do with a pencil and paper in front of someone. Both books have been good references for me to pass along to other developers.

    If only there was a pattern to remove outdated cliches two paragraphs ago.

    Friday, February 01, 2008

    Trying to Work (Together)

    Photo by Jerry Daykin, re-used with permission from the Wikimedia ProjectI'm currently bashing my head against a wall. Both physically and metaphysically.

    Nothing is cooler than Jini. However, unfortunately nothing is more obscure than Jini. It is something that exists etherally as a specification, not necessarily (although occasionally) as an implementation. It's the how, not the what. It's an adverb. Or something. My brain is lightly fried.

    See, you can start with Jini's reference implementation via the starter kit, which exists as a concrete example of the specification. However, the last release was at the end of 2005. This is probably due to this implementation being picked up by the Apache Incubator and turned into Apache River. Apache River does seem to be under active development but has yet to issue an official release and has distributed just one release candidate.

    Alright... so the Sun/Apache standard implementation is in transition. Who else has Jini services ready? Rio is a java.net project that appears to be both flexible as well as standards-compliant, so it appears to be a contender. There even appears to be moderate development traffic. However the stable binaries don't seem to match the current on-line documentation, and I haven't been able to download the latest milestone release. It does appear to have Spring integration however - and may yet be a contender. But until the documentation syncs up with the latest stable release, it's a bit hard to follow.

    Cheiron also has an implementation with Seven that is Jini-compliant, and appears to be receiving some good development traffic as well. I'm still researching how to go about implementation, and their docs currently match up with their releases. I'm trying to (still) read their documentation and see what I need to do to get up to speed. It appears that most people discussing Jini in forums use Seven Suite as their implementation of choice, although Rio has a strong following as well due to its ease of Spring integration and nice administrative tools.

    But for me this means I'm writing a helluva lot of "Hello World" and "Echo" applications, reading until my eyes bleed and trying to figure out how to get this all to work under a local development environment. Jini has been around forever... maybe I'm just having a hard time catching up with the rest of the world.

    I'm hoping Spring Integration makes this all a bit more straight-forward for complete knobs like myself. Please oh please tell me they're adding Jini into the next milestone. Having ubiquitous services over a self-healing network is just too good. I'd love to be able to scale just by plugging in a server and walking away.