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 3 of 3
 

Mistake Number 6: No Source Code

This one is controversial. If you're building intellectual property and are working with both lawyers and investors to back your company, it will be a painful decision. However, a little empathy will help you make it happen. Game developers hate to debug (in general) and tend to have a really bad time when they hit a problem and are not capable of solving it themselves.

There is a solution that some smart developers have been able to capitalize on: price source code access at a premium price. This is the case with Unity, for example.

All in all, remember you're providing a component of a shippable product that will be the entire responsibility of its developers (or publishing partner). Being able to ease QA and post-sales support is valuable.

Mistake Number 7: No Multiplatform Support

There is a growing trend for players to expect to seamlessly play the very same game on multiple platforms, from their smartphone to their PC and television (whether consoles or smart TVs) without paying for their game on each platform. Even more traditionally, though, developers are looking for true cross-platform technologies, easily portable, in order to maximize their revenue potential.

Therefore, if you build a new amazing rendering pipeline or the next artificial intelligence tools, you must keep this in mind. Your technology will only be attractive if truly multiplatform, or at least easily portable.

Mistake Number 8: No Customization or Service Offering

“I don't want us to be a service business!” said the lead developer of the middleware package to his boss. Your idea is to build this middleware and make money automatically by licensing the software. It's a great idea, really. But you will fail if you stick to this.

Apart from a very few exceptions, all middleware providers end up servicing their largest clients well beyond what they planned. The main reason: you need revenues to survive and grow. These high-added-value services include training, consultancy, premium support (like 24/7 access to a developer), custom feature development and complete project development.

While at Virtools, it took us a few years to accept this idea and allocate some dedicated resources (sales and a custom development team) to offer additional services to a few key, targeted clients. It was not always easy; the service team was sometimes considered lower tier, while the core R&D was obviously Premier League.

However, if we hadn't done it, we would have had to call it a loss, and move on to the next project. In addition, our middleware wouldn't have ever reached the level of quality it did: Having an internal team building a product with a middleware is the best way to ensure it's actually really usable.

Mistake Number 9: No Clear Legal Agreement

You know this little box you tick to confirm you accept the legal terms of your product during the installation process? Actually, this matters, and guess what: it's often related to the bad business guy who will sign the check or hand over his duly completed credit card form to buy your stuff.

There are a few critical rules in the End User License Agreement (EULA):

  • Make sure somebody in your team owns the EULA: she or he is the go-to person if you plan any changes in your business model, pricing, or features.
  • List open source components integrated into your product, if any.

Overall, make sure you allocate some budget for an attorney to assist you with this critical step. There are tons of templates you can find on the web (this one, for example, looks good), which is useful as a start but cannot be an end.

Mistake Number 10: Not Being Ready to Sell Your Technology Outside of Game Development

By targeting the electronic entertainment industry with your technology, you are ready for the worst possible environment. However, once you crack that nut and perform in this market, your technology will go well beyond -- in industries that are sometimes less demanding, easier to work with, etc.

Unless you only target gaming console platforms (if so, read a few articles about the decline of these little boxes and reconsider), your middleware should be able to sell to a few very interesting industries, like the military business (e-learning and serious games), the architecture business (to create amazing sales tools). As an anecdote, I remember exhibiting at GDC in 2004 or 2005 and summing up the leads we got at the end of the show. Over 30 percent of the qualified contacts were in a business related to the military. These guys know where to get the best tools -- trust me.

Conclusion

If you are discouraged by the above checklist, sorry! I hope you will at least realize that there are some barriers to entry when it comes to providing professional middleware and tools for the game development market. If your ambition is purely to share your knowledge without generating revenues, you can post your code or tool on a marketplace and increase your reputation.

If you are ready to get started, that's great! Working with the most creative and powerful game studios is really exciting. You get to see what's coming next in terms of hardware and software innovation, meet brilliant developers who love your product and motivate you every day to work harder with your team, and get the most added value that's possible. Have fun!


Article Start Previous Page 3 of 3

Related Jobs

Trion Redwood City
Trion Redwood City — Redwood City, California, United States
[10.21.14]

Senior Graphics Engineer
WB Games
WB Games — San Francisco, California, United States
[10.21.14]

Sr. Software Engineer, Android
WB Games
WB Games — San Francisco, California, United States
[10.21.14]

Software Engineer, Platform
Crystal Dynamics
Crystal Dynamics — Redwood City, California, United States
[10.21.14]

Audio Lead






Comments


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.


none
 
Comment: