I want to start a business creating middleware for indies but I'm having trouble putting together a business plan. It's something I would enjoy doing; I've already developed several small game systems and associated tools (my last project was a 2D skeletal animation system with an editor) and I see some potential to scale that up somewhat and create something of real value for people. I'm already in the process of reworking and upgrading the animation system I've already built, and I have a few more ideas for systems and tools that would be both interesting projects and potentially useful to others. My goal here is to build systems that are useful and interesting while helping other people build their dream games. I'm not intending to go full-time with this (at least, not yet) but I would like it to be a source of income.

I know that there already exist many middleware providers that cater to the indie crowd at some level (Unity, Torque, and RakNet come to mind), but they all seem to be providing fairly comprehensive packages. What I'd like to do is something more narrowly focused (like the aforementioned 2d animation) and put my effort into making the tech and supporting tools more polished. What I don't know is if there's a market for that sort of thing, or how to approach it.

Since starting a business from a position of ignorance is rarely good practise, I'm trying to figure out is what the market is like. Would independent developers be willing to drop cash on a library and/or toolset that is fairly narrowly focused, and how much are they willing to spend? What sort of distribution model would work best... attach an up-front licensing cost? Give it away for free then get money from donations or support fees? There are so many possible ways to approach it, but none that immediately strike me as ideal.

I'd appreciate any insight you guys could give me.

Sure, people buy middleware.


They buy it when the product is already mature and already debugged and is also cheaper to use (in terms of total cost over it's lifetime) than it is for them to develop their own.

You don't start with such a system. It often takes years to build up to that.

Most good middleware starts as a system within real products. The good feature gets isolated and built upon.

It is unwise to simply jump into a market with no idea what is going on, no idea what the market wants, no idea how they will use it, and then start selling your vaporware product.


First make a game. Figure out the needs you actually have.

Perhaps you are using a networking library, but it doesn't meet all your needs. That is a great place to start. Now you can decide how to develop a better networking library that meets those needs. Or maybe you discover the audio library doesn't do what you want, and you think you can bring to market a system as easy as fmod but with th power of wwise. At this point you now have a real problem that you can solve, and that turns into a middleware business plan.

It is unwise to simply jump into a market with no idea what is going on, no idea what the market wants, no idea how they will use it, and then start selling your vaporware product.

I absolutely agree. That's why I'm asking these sorts of questions!

Most good middleware starts as a system within real products. The good feature gets isolated and built upon.

First make a game. Figure out the needs you actually have.

Perhaps you are using a networking library, but it doesn't meet all your needs. That is a great place to start. Now you can decide how to develop a better networking library that meets those needs. Or maybe you discover the audio library doesn't do what you want, and you think you can bring to market a system as easy as fmod but with th power of wwise. At this point you now have a real problem that you can solve, and that turns into a middleware business plan.

I have built games with the sorts of systems I want to improve on. For example, the animation system I mention is evolved from the setup I slapped together for a game I built a few years ago, and is something I'd like to use an enhanced version of for my current project. It struck me as something that could save people a lot of time. While many people have put together homebrew systems of a similar nature, there was nothing out there I could find that compared to what I had built in terms of functionality and ease of use.

However, while it did prove useful for a single, unpublished project, my expectation that it would be useful to others is fairly speculative. Would you still argue that my perspective here is too limited?

I have built games with the sorts of systems I want to improve on. For example, the animation system I mention is evolved from the setup I slapped together for a game I built a few years ago, and is something I'd like to use an enhanced version of for my current project. It struck me as something that could save people a lot of time. While many people have put together homebrew systems of a similar nature, there was nothing out there I could find that compared to what I had built in terms of functionality and ease of use.

However, while it did prove useful for a single, unpublished project, my expectation that it would be useful to others is fairly speculative. Would you still argue that my perspective here is too limited?

Probably a bit speculative, yes.

A library is built and extracted from a series of games. I've watched code reused in several shipping titles, and I wouldn't really call them a reliable library until they've been used in three or four titles. At that point they've accumulated all the critical features and are basically solid enough to stand on their own.


So let's assume you will eventually have a library that has been vetted in several projects. We'll ignore how you have developed the library and proven that it is adequate for general purpose use.

The next step is to discover are your customers going to be.


As you mentioned there are many excellent game engines out there available for free to anyone not making significant money, and are inexpensive to those who are earning enough profit. They have large user-supported communities with significant existing resources.

If a developer doesn't want an engine, there are many good component libraries for networking, audio, graphics, etc., all available for free and under friendly terms. Many of these also have significant established user bases.


So who is your customer? Are you providing something so sufficiently different that it doesn't fit any of those markets?

There are hundreds of tiny graphics libraries out there in addition to the major ones. If you are a niche product that isn't satisfied by any of those then I wonder how many potential users are out there.

So now you can identify who your customers are: They are game programmers who are savvy enough to create a game without a game engine. They are hobbyists with almost no budget. They have very specialized needs that cannot be met by an existing huge body of work.

Next question, how many of those people are out there? If they are savvy enough to make a game without a major engine, will they also be savvy enough to get by without your library? You have to provide a service that is better than them doing it themselves.



So where does that leave you? You have a very small number of potential customers, probably only a two-digit number or a low three-digit number. These potential customers have almost no budget and would generally do it themselves rather than pay for it. Finally, you would need to attract those few customers; you cannot compete on price, you cannot compete on community support, you cannot compete on established track record, so you'll need to find something else to draw them to you.


Without a track record of being used successfully in games middleware has a very high risk.

That's why (as I said in the first post) most good game middleware starts as a system within real products, and it often takes years to build up to that.

So I suggest you build up a series of real products first, and once you have proven out your system you can look at marketing the components.