So you say you want to sell your engine?


I’ve been in the game middleware business for a relatively lengthy amount of time. I’ve seen companies come and go. Every now and again I’ll see that someone decides to see a little more ROI from their internal development efforts by selling their internal tech.  This turns out to be a lot more difficult than people think and many of these efforts never make it to market. Here are some things that you need to think about before making your internal tech public:

  • Have you ever distributed your tech outside your studio? You’ll learn a lot the first time this happens. You made assumptions about directory structures, install locations, existing SDK dependencies, etc. No matter how well you think you have it covered, you’ll get surprising crashes or glitches that take time to track down. Do you have an installer? Do developers sync to your depot?
  • How standardized is your code? Do you have an official set of coding standards that your developers follow? How rigorously is it enforced? Does the code look homogenous (ie like it was written by one person)? Believe it or not, this makes a huge difference in the perceived quality of the codebase. If it looks like a bunch of people threw it together without care, that’s probably the case.
  • How well documented is the code? This isn’t just Doxygen comments, although that’s a great start. Do you have tutorials and user guides for tricky parts of the system? How easily can artists and designers get up to speed?
  • How will you support the product in the field? Do you have email support? Phone support? Who answers the emails? How do you ensure timely responses to customers? What happens when issues escalate?
  • How do you intend to capture sales? Do you have a dedicated sales team? Who chases down leads? Who builds a rapport with potential customers and makes sure that they’re happy? How do you keep track of sales that you lost and why you lost them?
  • How do you intend to maintain the product? How do patches go out? Who tests the patches? How do you ensure that the patch doesn’t introduce more problems than it solves? How do you decide what features to add next?
  • How do you test your tech? Do you have automated tests? How much manual testing do you do? How do you catch regression errors?
  • How modular is the tech? Do you just use it the way that “works for my game” or have you taken the time to test in a variety of scenarios? Can customers use pieces of the tech? What happens if they need to customize part of the tech? 
  • Who is your market? Indie developers? Casual games? AAA games? How much are they willing to pay? What does the competitive landscape look like? How many licenses do you think that you’ll sell in the first 6 months? How much is it going to cost you to build your organization to support your customers?  How is your market going to know you exist? How do your customers integrate your tech with their internal tech and other middleware vendors?
  • Do you have a demo that really shows off your tech? Is it data driven? How many different machine configurations have you tested it on? How well does it run on those configs?
  • What does your content pipeline look like? How easy is it to get new content into your tech? What are the output formats? What are the input formats? How do you handle versioning? How long does it take to see the content flow through the pipeline? Are there paths that break the content pipeline? How do you integrate with industry standard tools like 3ds Max and Maya?
  • What platforms do you support? Are you a licensed developer for those platforms?
  • Do you use any third party code? What are the restrictions on that code? GPL? LGPL? Console SDKs? How do you distribute any changes that you’ve made to that code?

That was just a brainstorm of issues and questions that we’ve had to deal with over the years. We’re by no means perfect, but I think that we’ve done a good job of supporting our customers. If you are contemplating selling your tech, do yourself and your potential customers a favor and commit to the effort. Be prepared for the time it takes to do it right. It takes some hard work, but at the end of the day I’m a huge believer in the premise that taking advantage of off-the-shelf tech saves developers a lot of time and effort when developing a game.

Advertisements

~ by shaunkime on June 24, 2008.

2 Responses to “So you say you want to sell your engine?”

  1. +1

    Making a product is very, very different than making an in-house tech. Testing, support, polish and things like that matter a lot. And you can’t just beat your own artists to “fit” into your tech either 🙂

    But making a product is also very gratifying, especially if users love it. That makes a lot of difference.

  2. While there are some challenges to making a game engine as a product — there’s also a lot of satisfaction in working on something as a product. I enjoyed working on the same type of tech in game companies, but all too often things were rushed. There wasn’t enough time to do it right, or to do it in a way that would save us time in the long run. Working on a game engine for resale – we take more time to do things right… because hundreds of development teams will soon be scrutinizing it all, using it in ways we didn’t expect. It feels good to be able to keep the workspace tidy.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

 
%d bloggers like this: