Telling a Tale for Ten Years

Exactly ten years ago I started this ridiculous blog as a way to collaborate with other game developers. At the time I thought I would dig deep and push out at least one title. This eventually led to the "Desktop Distractions" studio concept, and the nascent title Deskblocks. I also worked within the CrystalSpace engine as an entrant to the PlaneShift team. I just couldn't give these projects traction however, so I gave it up and moved on to tinkering.

Even though the driving force behind the blog had faded away, and even though no one else reads this blog (aside from the State of .NET Integration Frameworks post), I kept updating it. Writing - even if it exists only for your own edification - really does help with communication and critical thinking regardless of what you write about. Even though my day job has nothing to do with garage door openers, my posts on my garage door security system helped me organize the build in a way that informed the Hack Clock project. Back in 2006 I began investigating vector processing, and the resulting frameworks have helped me think about and design microservice architectures. Of course, there was plenty of venting as well with my favorite software companies being dissolved or SuSE Linux winning and failing and winning and failing again. All of this writing helped me when performing comparative analysis at work, or designing parallel architectures, or watching trends in software development.

It is hard to believe a decade has slipped by. It doesn't even seem real. I don't think I've evolved much since that one cram session in a crystal chair, but I'm glad to have my collected ramblings to reflect back on.

Can't Quit Qt

I’ve been dorking around with DeskBlocks lately, trying to find a way to get things to build & run within OS X. My ODE references were already many versions behind and the physics codebase is in need of an overhaul. Looming overhead was also the issue that Nokia was not entirely dedicated to the Qt4 platform that DeskBlocks is built upon, so I started to debate if I should find a new framework to build DeskBlocks within. I was pretty down on Nokia’s acquisition of Trolltech back in January of 2008, although it kinda made sense for the maemo platform. Still, with Nokia going all-in for Windows Phone it seemed like maemo and Qt was heading for the dustbin.

Sure enough, last week Nokia announced it was selling off Qt to Digia Oyj, even reportedly taking a significant loss in the process. Digia had already been running Qt licensing since 2011, so it’s not a huge surprise for it to take over the whole kit and kaboodle.

I’m of the mindset that this could potentially be a very good thing for Qt. I’ve seen Candyland get paved over so many times in the past decade, with big industries wrecking my favorite technologies over and over again. Going smaller may make things more agile - and it seems like many in the Linux community might agree. In a very smart move, Digia has already written an open letter to the KDE community emphasizing their commitment to Qt going forward. If they actually follow through on this dedication to the ecosystem, this could be a huge win for Digia Oyj.

Finland wins yet again.

A Return to Code

My blogging juice is running low as of late. For the past several months I have been getting paid to blog... which is weird. Now the din of typing that has usually prefaced a post here ends up being posted elsewhere. It's awesome to get paid for something you love doing, but it does mean that free time is sparse. For example, it has taken me a good four days just to write this post.

In the pauses between work and life I've been trying to look at DeskBlocks again. I still really like the idea: a physics sandbox that plays directly in your window manager and interacts with your desktop. I have a working version on SourceForge, but it requires a version of ODE and has a few bugs. I would like to ensure it plays nicely with multi-monitor setups as well, especially on dual displays with disparate resolutions.

Of course my code has rusted in the months that it has gone untouched, and the algorithms I used to constrain the physics to two dimensions (instead of ODE's three) have become antiquated. 2D is a much more out-of-the-box affair now, and building with the newer library versions brings an instant segfault on object creation. Qt has matured over time as well, and I need to leverage the newer functionality of Qt 4.7. Not to mention my C++ brain has atrophied and need some exercise.

I'm glad I wrote down most of my thoughts in a design journal - a discipline I've been doing for a few years now both at work and with personal projects. Old notes have saved me on a number of occasions, especially in scenarios like this where I'm picking up something after a long pause.

I'm not sure how much progress I can make when my development time will only come in fits and starts, but I'm hopeful I can finally release something worth playing.

PowerVR's Tile Based Rendering

I've been reading up on the iPhone's GPU and 3D rendering pipeline based on the PowerVR SGX The PowerVR pipeline is based on Tile Based Deferred Rendering and advanced Hidden Surface Removal that occurs very early, prior to the actual rendering phase. Apple's developer site has some compelling information on the PowerVR platform and how it performs well as a mobile GPU.

Occlusion detection and the culling of unseen polygons ultimately means less primitives to render, which of course equals less horsepower going to effects you never see. Removing hidden surfaces too aggressively can cause weird stuff to happen, like stencil shadows popping through textures or light blooms shining through walls. But for something with limited power and screen real estate, it makes a whole lotta sense.

I can see why Carmack has had so much fun porting titles to the iPhone - it's a kit that really makes for some nice titles. And with iPhone OS 3 having more robust p2p bluetooth capabilities, this thing could turn out to be the next big gaming platform.

Apricot Blending Crystal Space

I haven't followed Project Apricot in a while - I've been out of the Blender & Crystal Space 3D scene for a while now. It appears to have taken an interesting turn however.

It appears the final name is "Yo Frankie!" - finally available online or retail, including all the code & assets that went into the game. Both of them.

Errr... what?

Evidently the project forked - one fork was done entirely within Blender, the other built specifically for Crystal Space. There appear to be differing accounts as to why the for occured; the Blender Foundation claims that this was due to advances in Blender's own game engine, while at the same time they appear to say that there were too many technical difficulties to marry the Blender Game Engine and Crystal Space 3D. Ultimately Blender's game engine remains an entity on its own, and Crystal Space walks a separate path. It seems the Blender community wasn't happy with using an engine outside of their own doors and so they walked away from integrating with a more sophisticated game engine. Integration with other engines and projects... something that could make Blender thrive in a production environment... was abandoned to work on the more primitive Blender Game Engine.

The Crystal Core project seems to have re-adjusted its ultimate aims as well, similarly finding its initial objectives far too ambitious. That makes two flagship titles that haven't been able to reach their intended goals.

I'm wondering why Apricot and Crystal Core are both having such difficulties. My guess is that content generation can be done well, engine development can be done well, but the interoperability between the two is an equal if not greater effort. Compare the tools Eskil created for Love to the Blender + Crystal Space tools: building models and meshes in Blender can be fairly arduous and requires a lot of reference material while Loq Ariou can create meshes using freehand and UV texture mapping in Blender is a multi-step process while Eskil has created something that can do the UV mapping in a few short steps. Verse seems to be the glue that the Blender <-> Crystal Space interoperability was missing, creating a uniform way to remotely process assets and scenes.

The effort to have a Crystal Space 3D game engine within Blender would have been tough, but I believe it would have been worth it. It is definitely no easy task, but these kinds of tools are sorely needed. It is too bad Blender decided to push Crystal Space aside - I was looking forward to big things with their collaboration.

What I've Seen with Your Eyes

Eskil posted the video for his GDC presentations and they're abso-freakin-lutely amazing.

The gameplay of Love was interesting, but the video displaying the tools Eskil created are completely mind blowing. It's the stuff that actually gives you hope for the world again. The GDC tool video shows off several tools Eskil has released: Loq Ariou which allows you to create assets & models with the same ease as a pencil & scratch paper, Co On which provides scene mapping that's startlingly similar to how you might visualize things in your own mind, and Verse, a data transfer & protocol standard that allows such data to be shared instantaneously between applications.

Obviously Eskil had to create an intelligent set of tools to properly build Love within a decade, but I had no idea he had constructed such a cadre of tools that could be re-used by other developers. Not only does he speed content generation up and provide better interfaces - he goes one step further by breaking down human factor boundaries that plague every other asset generation tool to date. Just watch the video - especially the portion demonstrating shaders in Co On - and you'll see why I'm going completely nuts over these releases.

Eskil is giving back a huge amount to the community at large with these tools, and is likely opening the doors for many, many others to creatively express themselves in ways that were once prohibitively difficult. Love isn't just creating a fanbase... it's creating a legacy.

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.

Crystal Chair

I remember, still quite distinctly, one particular moment in the December of 2002. My job wasn't what it once was, and I was starting to contribute more into some random open source projects. I wanted to see what game engines "looked like," so I downloaded the developer documentation for CrystalSpace on my (now destroyed) iPAQ. It was December however - and of course I had to do a blitz of Christmas shopping.

While walking all over the mall's green turf, I tried to read the CrystalSpace HTML docs. Finally I took a break and crashed in a lounge chair inside a Von Maur and poured through half the pages I had sync'd. It was in that chair that I was first turned on to CrystalSpace's automagic "smart pointers." When things finally clicked about factory design patterns. When I finally saw how platform-independent file mounting could work. Things largely fit into place for the first time in my head, and a rush of Computer Science courses that were starting to leak out of my brain finally kicked into place. It all weirdly made sense.

I still think of that December of 2002 whenever I pass by that chair. Last year, before I aged another decade, I provided myself with a crap-or-get-off-the-pot objective: to finally have a working game out by February of 2007 or otherwise just give up the ghost. While I did some extensive hacking, spent a lot of late nights and tried to do it, in the end I just wasn't able to produce the goods. I have a partially completed project out there, but in the end I wasn't able to make it happen. I finally gave up the daydream.

I passed by the chair yesterday and thought about how fall was coming soon. Christmas shopping season. And how I'm not going to be perched in that chair pouring over docs anymore.

I've Never Been So Excited for an Apricot

Blender has been the model editor of choice for CrystalSpace for a long, long time. Most of my CrystalSpace documentation has revolved around using Blender to create content for CrystalSpace code. The two together are like peanut butter and bananas. Fantastic.

Recently Jorrit made an exciting announcement on behalf of the CS team - Blender and CrystalSpace are partnering to build Apricot, an independently developed and completely open game title. To fully understand my unbridled enthusiasm you have to understand Elephants Dream, originally called Blender's project Orange. This was an open movie project - a full movie title with all content released under a flexible Creative Commons license. Textures, models, all production files are freely available. This did unbelievable things for Blender. Not only did this give users access to professionally generated content, new documentation and a whole new realm of tutorials it also pushed the envelope for Blender itself. Orange generated demand for whole new genres of features, and kept the Blender development team pushing point release after point release to keep up. If I recall correctly, Blender's hair generation system was largely built due to demands made by artists creating content for Elephants Dream. Not only did the movie promote Blender, it made Blender a production-quality product that could demonstrate it was ready for prime time.

The same envelope is getting ready to be pushed for CrystalSpace now. That's where my unbridled enthusiasm lies; CrystalSpace has been a commercial-quality 3D engine for a while now, but now every stage of the production process will be thoroughly tested and fleshed out. While I have no doubt that this project will result in enhanced functionality grown by the demands of the game developers, I'm most excited about the tool chain being completely fleshed out. In my mind while the Blender exporters for CS were fantastic, all the corner cases hadn't been completely covered. With Apricot, model exporters should be polished, skeletal animation should be more integrated into Blender armatures, physics should be more strictly related to Blender riggings and meshes should have attributes that more exactly equate to CrystalSpace equivalents. This should make the entire end-to-end content generation process as smooth as a polished stone.

Nothing like a real-life, production quality project will take the edges off of the various and sundry tools used for development. It's amazing how much one will forbear when it's not a "huge issue," but when you encounter the same "not a huge issue" twenty times a day it suddenly becomes something worth tackling. Ideas and features may be the result of inspiration, but the remaining 99% of time spent refining a project is sheer perspiration. I'm looking forward to both projects' continued trial by fire, and seeing what has been forged once the fires have quieted down.

Blogroom Blitz

If you haven't noticed, I've taken upon myself to use this blog as a conduit for taking old articles and posts, espousing their ideas with my own, then regurgitating them for myself and all those regular readers, numbering too many to count. Mainly because I never learned how. Today, dear Rockford, is no different.

The Bad Game Designer, No Twinkie! database is online. I took a moment to read the article about how bad bottom-up game design is... something every new game developer should read. 99% of indy developers take an engine "concept" - physics, fluid dynamics, spatial sound, bump mapping, geometry shaders, whatevea... then they make that one property the "game". I do that. Repeatedly. Still am. Right now. At this moment.

Back in November, there was a round-the-world blogging event entitled "So You Want To Be An Indy Game Developer?" Crowd favorite Introversion was there, as well as our good friends at Gibbage. While the resonant theme was "don't hope to make enough money to eat whilst being an indy developer," there were some notable other nuggets to be had.

Cliffskis had some good, pragmatic advice such as maintaining a solid online presence. Content should be easily available, never move to a different URL and have stuff that is quick to download and install. Realize it will take years to be noticed, and you'll want to make sure that you leave an adequate trail to be found.

GameProducer.Net had some points that I've already discovered the hard way... if I had heard this advice earlier, it would have easily saved me nearly two years of work. Begin by making a game, not by learning how to make games. Knowing the technology is certainly part of the process, but if you stick with just the development process you won't progress much beyond writing demos and how-to's. Alongside that thought, don't re-engineer the wheel. So many fantastic engines, API's and SDK's are ready and waiting for developers... don't try to create a 3D engine on your own. Worst case, find an open source project (i.e. CrystalSpace) and help them out. Save time, grief, effort, bugs, etc. by using existing tools.

Reality From The Sidelines had an entry that could have well been ripped from the pages of this very blog. Not only is he extremely tardy in producing a title, but he moved from grandiose ideas of FPS' & believing casual games were too lowly to consider to finding casual games the best place to being experimenting with both design, production and gameplay. We both seem to realize like time is slipping away, and whatever we do, it needs to be now.

Zoombapup focused the entire post on making a single, but very striking point. I'm definitely not looking to make any cash with any titles I might release, but I won't turn down any accidental riches that land in my path. Zoomba illustrates how excruciatingly difficult any riches, incidental or not, are to glean from small-biz development. Although he uses the same concrete (as pudding) mathematics as my science teacher used to estimate the number of piano tuners in New York, the basic figures are sound. If you're wildly successful, you'd be lucky to have two years of effort translate into $100,000. More than likely, it would be -$100,000.

Never use Comic Sans.