Gamasutra: The Art & Business of Making Gamesspacer
The Top 10 Mistakes Tool Developers Make
View All     RSS
October 21, 2014
arrowPress Releases
October 21, 2014
PR Newswire
View All

If you enjoy reading this site, you might also want to check out these UBM Tech sites:

The Top 10 Mistakes Tool Developers Make

January 31, 2013 Article Start Previous Page 2 of 3 Next

Mistake Number 3: No Clear Pricelist

You believe that your solution is priceless and may add tremendous value for your clients. You are worried that some competitors might take advantage of your pricelist. If so, here are two options: Don't sell middleware, or refine your pricelist based on your core target. In any case, the most difficult exercise is, indeed, to nail down clear and simple pricing.

Remember, also: Whatever the price of your middleware, some smart engineers will tell their producer: "Naaah. I can do much better than that in less than a week!"

As a general outline, there are a few options:

Freemium. This pricing model popped up quite a few years ago and is currently the most popular. It is combined with one of the others below. Free-to-play games are also the fastest growing segment these days. Chris Anderson, in his bestselling 2009 book Free, has spent valuable time explaining why free is a very good pricing model. There are quite a few companies and organizations that provide free technology, including to the game development world.

Inexpensive middleware (sub $1,000). Your strategy is to go "commodity." Good luck: it will be tough and will require 100 percent dedication and quite some money from investors if you want to be serious about this and make a living out of your tools, especially if they are addressing a very niche market.

However, it's a fun area to be in if you just want to serve a developer community like the Unity Asset Store, without too much time investment. Remember the average salary in Western countries for qualified game development engineers (likely you!) How much do you need to sell of your product to reach break-even?

Middle class pricing ($1,000 to $25,000). This pricing applies to professional middleware developers. Some of them are spin-offs from game studios. Some successful examples in that price range, just to name a very few: Unity, Rad Game Tools (makers of the Bink video codec and tools among others), Scaleform (acquired by Autodesk), Havok (acquired by Intel), Kynogon (AI Engine and tools acquired by Autodesk), Virtools (acquired by Dassault Systemes).

High-end ($25,000+). This category is complex to enter and currently mainly consists of a happy few game engines, like Epic Games' Unreal Engine and Crytek's CryEngine. Large development houses used to trust these high-end engines, yet they now tend to consider that the price is way too high (deals negotiated around are $1 or 2 million / game, sometimes more for multiplatform).

Additionally to a software license, a pricing based on royalties is tempting for the software publisher (you). However, developers, like anyone really, don't like to share their potential revenues. Rationally, it would make a lot of sense, but a flat fee / project or a simple developer license regardless of what is built with it is much more acceptable, and might end up being much more profitable for you.

Mistake Number 4: No App Demo

Your technology is outstanding! Everybody will agree... if they see it in action. Code doesn't sell well. Be ready to create an application that demonstrates how great your program is.

This piece is absolutely critical, yet I've witnessed the problem many times with middleware providers. The demo is your best sales tool, and can go viral if done properly. If you don't have the internal resources to get the best graphic designer or game designer to work on that project, there are options:

  1. Provide the tech free-of-charge together with support to a talented local game studio interested in your project. There are several benefits: You get some real-life feedback on the product, often requiring adaptation; you get a first reference. Obviously, if you are able to convince some big guys, you may be able to get some cash out of this project. However, keep in mind you're looking for marketing material, and larger houses often restrict external communication channels about their projects.
  2. Hire a team to build the demo. There are now several ways to hire a team at low price; one of them is to use a sourcing platform like; another one is to go to your nearest game development school and put a bunch of students on the project. The latter option will cost you more time investment, but will also let you network with teachers and a pool of talent that could work with you down the road.

Obviously, a third option is to build a complete commercial game powered by your technology, which requires quite some resources. Epic Games, the makers of the ultra-famous Unreal Engine, have understood this very well. Their app demo is a superstar triple-A video game series: Gears of War.

Mistake Number 5: No Technical Support

This may sound like a simplistic recommendation, but I have witnessed this case many times. Licensing middleware means outsourcing code -- sometimes critical code -- to you. If your client can't reach a business guy during the evaluation, it's a very bad sign for potential buyers.

More importantly, developers must be able to access a forum or something equivalent to get rapid answers in case they hit a roadblock. If your community is very small, which is natural at first, make sure you provide a good FAQ section, and make yourself available by email -- and ideally over Skype or equivalent as well -- to answer all your clients. Respond quickly -- otherwise your potential customers will not feel at ease, regardless the quality of your product.

Article Start Previous Page 2 of 3 Next

Related Jobs

Rumble Entertainment, Inc.
Rumble Entertainment, Inc. — San Mateo, California, United States

Technical Product Manager - Platform (Chinese Fluency)
Zindagi Games
Zindagi Games — Camarillo, California, United States

MOBILE Art Director
InnoGames GmbH
InnoGames GmbH — Hamburg, Germany

Mobile Developer C++ (m/f)
Treyarch / Activision
Treyarch / Activision — Santa Monica, California, United States

Senior UI Artist (temporary) Treyarch


John Byrd
profile image
A great article, and I agree with everything on the list... but I can't believe you left this one out:

Mistake Number 11: No documentation or sample code.

Martin Zimmerman
profile image
I think good examples, good documentation, and access to source code should all go together. There are fewer things more frustrating than samples or documentation that are out of date.. And good examples are critical. I can't count the number of times I have wanted to do something basic, that was glossed over in sample leaving out the critical bit needed to make something actually work. When that happens being able to read the existing source to find out what is going on is critical.

Lars Kokemohr
profile image
My personal pet peeve are samples that use dozens of features instead of showcasing exactly one.
Some middleware developers seem to think that even the most technical demo has to impress the managers and game designers.

Virgile Delporte
profile image
You are totally right, it would have deserved such title -I integrated this into mistake number 2: "no easy access to evaluation copies" but it's not visible enough. Thanks for sharing your thoughts!

Virgile Delporte
profile image
@Martin: you are right, but to be precise this should be called "sample code", not source code. Delivering full source is something much more difficult to accept for a software vendor. Properly documented and up-to-date sample code is however very useful. In addition, by delivering sample code, you don't upset investors who don't really like a middleware company to deliver source code :)

Martin Zimmerman
profile image
I know it is a difficult proposition for some vendors to accept, but I was definitely referring to actual source code. I consider including what you term "sample code" a given. Each vendor can choose for themselves, but by not including it they are ceding a major competitive advantage to open source products.

Jonathan Jennings
profile image
number 4 is the biggest killer in my experience, if you can't make a decent product with a framework or tool that YOU developed why should I be able too? It doesn't even have to be an extremely elaborate demo but just a solid application of your tool can be the difference between me mentioning it as a valuable tool to my producer or simply cycling onto the next competitors product and putting your product as a potential solution in the back of my mind .

Henrik Strandberg
profile image
I'd add as #11: do NOT sell or promise anything that is not already done, DIDDLY-DONE and in the can. You will spend more time managing your schedule, backlog, priority list and roadmap than writing code, and at the end of the day, everyone will still blame YOU for not delivering on time, and THAT'S why their whole project is slipping. So even if you have a roadmap you feel great about - don't use it in a sales pitch, and don't ask anyone to pay for vaporware.

But yes... key accounts may need customization or branched one-offs - as bullet #8 lists. This brings me to my second DON'T: be wishy-washy. Rather, be super-detailed about exactly what you will deliver, when (=i.e. what time, not just what date), in what shape, to what environment, to meet which specific functional requirements and user stories, etc. Even if it's a royal pain in the ass, you really want to have those discussions up-front. Your customer has a lot of dependencies and especially late in a project, the acceptance level for late "surprises" is, well, low.

Lastly - recognize that everything in this list is the responsibility of one or more dedicated product managers; not your engineering lead, CEO, intern, producer, or bus dev guy (although they all need to support the product managers and vice versa).

Evan Simeone
profile image
This is an excellent list and has value beyond game middleware and tools. The vast majority of these mistakes apply to a broad range of B2B software offerings.

Frank Kane
profile image
Totally agree on most points, but one question - you mention a couple of times that pricing should be simple and transparent. This isn't exactly standard practice; many middle-tier middleware companies require you to contact their sales staff before divulging their pricing. Why do you think having a price list out in the open is important?

Virgile Delporte
profile image
Hi Franck, thanks for bringing up this point, which is a sensitive one. If you put yourself on the other side of the fence as a technology buyer, nothing more frustrating than not knowing how much you may be spending if you decided to go ahead and license middleware or tools. As a buyer, you don't want to have to talk to a sales guy who will try to extort information from you before giving a number you have the feeling he just made up for you. With the explosion of social network platforms, you cannot prevent people to talk these days, and they might start mentioning your price in public -not disclosing relevant information many times. My recommendation is to be transparent -which shows you're easy to do business with. This is another reason why Unity3D was so successful pretty early on. If you don't do it, your competitor will do.