Okay, I have a feeling that this post is going to feel a lot like a whining session since I don't have any hard numerical data to support my bullish cries.  What I have to say certainly feels like the truth however.

Developers are cheap!  There is no money in supporting developers unless you are one of the big players.  It is all or nothing.  There are a lot of reasons for this and each case is unique, but in general we developers have a certain under-appreciation for the work that goes into software development and productivity tools.  As an artist you may, at times, look at a plug-in for your favorite painting or modeling tool and decide against it.  Even if the plug-in could save you significant time in the long run, you pass it up for reasons unknown.  As a programmer you may, at times, turn down the use of a shareware or limited-access application.  Even if the application will save you significant time and headaches, you pass it up for the same reason as your artist friend and his dilemma.

Two Weeks

The problem, I feel, is that we know too much.  We know more than we should, and it sometimes prohibits our ability to accept that there might be a better solution.  The artist who refuses the shortcut thinks to himself, "I can just do it by hand in 15 minutes" even if it takes that time, every time he has to go back to it.  The programmer who refuses the fancy new tool thinks to himself, "I could code that in 2 weeks", even if his solution would be rushed and bug-ridden.  I've seen individuals from all jobs who put themselves into a bad situation because they refused to change their way of solving a problem.

A theory of mine is that we have two primary tiers of cost; the under-appreciated, and the over-priced.  Once we look past of the small and focused tools and plug-ins, we reach the behemoths.  This includes software like Photoshop, Max/Maya, and MS Office applications.  Many times, the smaller tools ride on backs of these behemoths and act as productivity accelerators designed to work in conjunction.  These applications however, are very large and complex suites of functionality that inadvertently force us into a linear path of content creation.  A developer may approach a problem the same each time, even if there is a faster way.  This could be something as simple as how a character model is started, or what software to use for version control.

When I originally founded Inland Studios, I had big dreams of making productivity accelerators.  I saw a lot of small holes in the current development pipelines and set out to build tools that would improve productivity; not instantly, but over the span of a development cycle.  I was thinking of long term benefits instead of the magic pill.  My thought was that individuals and businesses would appreciate this revised way of thinking.  Boy I could not have been more wrong.

When Normals Were New

One of my first tools was an inexpensive normal map generator.  Even though most modeling packages at the time had not adopted normal map surface transfers, I wanted to develop a tool that would prove to be different once those big players did catch on to normal maps.  Instead of focusing on a single model, I took on a project-based approach.  I allowed users to create a workspace that contained multiple normal map configurations within it.  This meant that an endless number of assets could be configured for batch processing and large builds could be kicked off before going home for the night instead of babysitting each model.  I thought it was a very unique approach to managing assets and allowed multiple users to modify dozens of assets before building their normal maps.  It was a flop.  One of the most common questions was, "This is awesome; can I run it in Maya?"  Despite the fact that the tool used a completely opposite paradigm to Maya's one-asset design, the thought of running another application was appalling to the testers.

Decals Everywhere

My next venture evolved out of tools that I had written for my own development of Zombpocalypse.  Any good zombie game needs to have dirty and bloody spats of mess on the wall and decals were the easiest way for me to do this with the technology I was using.  I found myself painfully modeling and tweaking offsets for decals in Maya.  In some circumstances, placing a decal on flat terrain was simple enough, but it quickly became unwieldy when I wanted to splash some decals onto arbitrary geometry.  My inexperience with modeling, coupled with conflicting responsibilities of coding caused me to waist endless hours on this task.  Ultimately it lead me to think that I couldn't possibly be the only person faced with this same problem.  Thus Decal Creator was born.  Though I wouldn't quite call it a success, Decal Creator was much better received by testers and external users; mostly because it did not interfere with their established working regiment.

Fix Your Junk Autodesk

Unfortunately, the poor implementation of Maya's plug-in architecture meant that the source had to be compiled for each new version (and sub-version) of Maya, even if nothing had changed in the source.  Garage developers can't afford thousands of dollars each year in software and license updates, and this unfortunately includes the development SDK's for each micro-release that Autodesk is putting out every 6 months.  All of this basically means that it's almost impossible to make a business strategy around supporting developers unless you charge enough money to offset the cost of the applications that you are enhancing.  This leads me back to my original point; who would bother to pay $1,500 for Decal Creator?  This is bordering on, "I could probably make something half as good for that hourly rate and get by".

Turning Decal Creator into a stand-alone tool would invalidate it's easy integration with a familiar work environment, and yet keeping Decal Creator as a plug-in that relies on Maya has almost certainly hindered it's potential for a wider adaptation from users of all versions of Maya.

Gamers are Easy

Finally, my more recent time spent with games has proven to be the most widely accepted.  Most gamers don't have the initial gut reaction of, "I could do this in 2 weeks" and so the perceived value is much higher for them.  Gamers are much more likely to run your application, because they don't often assume that the game is meant to run within a pre-existing framework.  Gamers are open to learning new mechanics, as long as they are rewarded for their willingness to let go of certain staples.  Gamers probably already have everything they need to play your game, so the cost to entry is only the cover price.

I originally started my company with hopes of supporting developers; my fellow people.  That dream is dieing quickly.  I'm not so sure developers want to be helped, but gamers are always wanting new experiences at an affordable cost and I guess I should go to where I am most wanted.

 [Reprinted from a November 13th, 2009 Blog on my website.]