Friday, October 22, 2010

Gizmo goes Pro

Today Gizmo goes Pro.

I am opening the door to pretty much anyone who wants to play with it.

You can check out the X-Pilot forums for more details of how to work with it and which tools you'll need.

See ya there...

Thursday, April 29, 2010

Fault Lines

At what point does commercial advantage start turning into emerging liability?

At time of writing there is a flurry of activity surrounding the XPlane2Blender scripts.

My colleagues and I have had access to a modified version of these scripts for about a year now, I modified the scripts to provide a way to automate the creation of manipulators in 3D cockpits.

The scripts were modified to suit the workflow of our artist Tom Kyler, you can blame him if you don't like the way it works.

We've shipped a couple of products that make use of these scripts to create some of the most immersive cockpits to be found.
What we haven't shipped already is very far down the development pipe.
I feel we have extracted quite a lot of value from the mods Tom and I made.

However, we're starting to see a competing branch of the scripts emerge on the .Org.
The need for these scripts has reached the point where people (Dan, Mike G, a couple of others..) are making an effort to make it happen.

This is good, it makes the sim stronger, we have higher quality products, people will do unexpected and amazing things like they always seem to do with new tools...

But it's also bad.

It's bad because the way that each script works to create manipulators varies slightly. Very slightly. Stupidly slightly.

To see the OBJ8 + Blender + X-Plane format "fracture" over what is literally the difference between calling an object property "mnp_dref" or "manipulator_dataref" seems completely absurd to me.

It's worrying for a couple of reasons, some of them are noble, some are purely commercial concern.

First and foremost it is concerning because it takes a huge amount of time to create this art.
Detailing these objects and filling out these forms is long, tedious, mostly thankless work.

If we have new talent emerging to create content for X-Plane, and they learn how to use the Org scripts, and they create a library of content, and they come to us at X-Aviation (I work with X-A...) and want to work with us on a team project, we have a problem.

Either their library of work doesn't work with ours, or ours doesn't work with theirs.
Somebody has to go through and re-detail the work with manipulators.

X-Planes history* is littered with this kind of trashing of content formats and it's not done any favours for the sim. (* Most formats are very stable now!)

It's not just the exporter either, I am creating additional tools that assist with either content creation or DRM protection. To have the data fracture is just painful for everyone.

The other big concern is that as time goes by our scripts and our workflow may well become a liability, OBJ8 has grown several features over its lifetime.
Maintaining the scripts and updating them to support these features has become my responsibility, the content authors working with the tools I've made should be able to expect this.

It is probable that with communal effort and attention from sympathetic and multi-skilled** programmer, the Org scripts will grow to a more advanced state than our own.
The margin we continue to hold, if any, is debatable.
Indeed I am trying to have that very debate on the Org at the moment.
(** Mike G is making a valiant effort but by his own admission does not deeply understand all facets of the X-Plane content pipe..)

By sitting on our scripts our one-time advantage could quickly become a somewhat serious disadvantage.

Even if I continue to polish our scripts so that we maintain the technical lead, we will still have diverging work flows. Eventually this is going to bite us in the ass. (See previous mention to teamwork and asset libraries.)

As I see it the time has come to share the scripts, to bring both methods together.

The Org script and workflow has only just become available, there are probably less than a dozen people in the world trying to explore it, the time to merge is now. Before people have invested too much time creating work for one set of workflow or the other.

The x-plugins branch of the scripts already has seriously detailed, shipping, payware cockpits tied to it, to try and switch now would be horrific.

The .Org branch of the scripts is new, the data is stored in a way that lends itself ever so slightly more to a conversion script. There are also less projects using it. The only serious one being the ERJ, that I know of.

On the flip side, we could just continue to sit on these scripts.
Within weeks of now the Org script will be fully stable and mature***, content will start being created with the org-way...
Content that we've already created, that has leveraged the advantage of working manip scripts, is currently in the final stages of development or has shipped already.
(*** The Org scripts are already highly functional, they have some Python call requirements that exclude PPC Mac users, and there are a few hackish things in the src code, but they may well be fully capable of writing a complete, working, manipulated OBJ8 file already. I'm not sure, I'm on a PPC Mac.)

So, content being created from this point on, that would "leverage any value" we have by with-holding our scripts, doesn't really have that much advantage as the Org scripts are almost on par anyway.

Where a year ago withholding the scripts provided 100% advantage, now it provides perhaps 5%, and as detailed in previous ranting, will very likely soon be a liability.