Darkened Software

Archive for January, 2011

Why game development Middleware pitches are wastes of time

by on Jan.31, 2011, under Development, Industry, Lessons, Programming

I am a really big fan of Middleware as there are many things I never want to be an expert on and just want to pay money for them to work.  I really wish that during the process of trying to obtaining said software I did not have to sit through the dreaded “Middleware sales pitch”.

Why do we have to sit through them at all:

Unlike other industries most game middleware companies will not just let you download their SDK, see if it works for you and then let you pay them money if you so desire.  They insist on coming and giving you a presentation before they even allow you have access to a time limited trial version of their SDK.  This makes very little sense, if I am coming to you to download your SDK then it is very likely I do not need to be sold on it.  What I need is time to integrate it and see if it solves my problems, you forcing me to meet with you is actually slowing down your eventual goal of selling me anything.  The only good thing you could do is bring with you so much information about best way to integrate it and other best practices that saves me time in my investigation.  But sadly these sales pitches do not contain this type of information…

Even worse sometimes we are forced to sit through them even when we are not interested in the middleware being presented.  For example someone above you in the org chart decides they like middleware X and unless you want it to be forced on you and your team you need to go to the presentation and ask the right questions to get it shut down.  These are the worst meetings possible as you have to piss off the presenter by asking “bad” questions and also make your boss feel like you are effectively dumping on his idea. 

How can we make them better:

Its unlikely we can make such meetings go away but maybe we can convince middleware providers of what they really should be providing in these meetings to make them a little less painful or more useful. 

A way too standard middleware presentation:

  • Most middleware presentations start of with a great little store of how middleware company x came to being.  Some guy in his mother basement had a mission to solve problem X and after years of blood and tears he has grown solution Y into the coolest company ever. 
  • Then they tell you just enough about how they solve the problem to sound impressive but not really give you enough information to see if it will work for your case.
  • Next they show you a bunch of really bad demo’s because they are not game developers and are too cheap to hire real game developers to build them examples that might prove anything at all.
  • They tell you about a bunch of companies that are using it but have not shipped any games on it yet.
  • They answer any questions about features with the standard “That is in the next version coming out this summer”.
  • They answer any tech questions with “It is easy”, “Send us an email, We will get back to you” or “Can’t answer that as it depends on the level”

But does this do us any good, they are telling a story of thier accomplishments and how wonderful everything is which makes them feel good but does not really help us in our struggle.  They need to remember that in order to get our money they need to tell us a story that makes us believe everything in the furture will much better than it is now.  The only way they are going to do that is by understanding our problems and convincing us they can and are dedicated to helping us solve them.

What are our problems:

  • Time ( the complete lack of it )
    • We don’t have time to write all the software we would like to
    • We don’t have time to find and hire all the people to build all the software we would like to
    • Most of us have very unmoveable milestones that we are under contract to hit.
    • Most of us have teams of people that are waiting for software to be done so they can be productive
    • When we have issues or questions we can not wait on answers we need them a long time ago.
    • Games are highly iterative and anything that slows down the pipeline is scary ( crashing / reliability / slow builds ).
  • Resources( aquire &  managing )
    • People with specific skill sets are hard to find.
    • People in general are hard to manage.
    • Large amount of hardware and software resourcs is a huge maintance cost
  • Money ( the complete lack of it )
    • There is not a lot of profit margin in most developer contracts so the team can not afford to be wrong very much.
    • Developers do not just get 20 million to do a game up front, we get a little bit each milestone which is usually just enough to each the next milestone.
    • Also our requirements change quite a bit over the project so we do not like to spend a lot of money up front as we can not get it back when things change.

So if they were designing a presentation that would tell us how they can solve our problems it seems like they would start the presentation off with a few questions:

  • Is there any experiences in your games you feel need improvments?
  • Is there any parts of your game development process that you would like to improve?

Then instead of giving us a shot gun overview of everything the have ever built they could focus in on solving our problems and concerns.  Now that they have our goals in mind how can they make us believe they can solve our problems.  The last part of the their problem is how to take us down the path between our problem and believing they can solve it in a way that is worth us paying them money. 

Most presentations really fail in this area as they might start off by showing us a very limited demo that only proves that their system will work in a most limited case.  Then they jump back to the very start of the process and show you how to set up the tools, build the assets and get into their simple test level.   The problem is from the very start I am not convinced it will work in my case so I am not going to give you my full attention to your demonstration. 

The improved presentation:

  • Show me that produce X can solve the problem at the scale and complexity I will be faced with.   This might mean going out and getting a game developer to build real world levels for you to demo with and not just showing us your internal test levels.   
  • Next show the real run time costs, be able to bring up memory, cpu stats.  I am not going to listen to the rest of your details if I do not believe that what your showing me could ever co-exist with my game.  Absolutly nothing turns a developer off faster than hearing “I do not know” to our critical runtime questions. 
  • Working backward show us the pipeline that gets the goods into the game.  If we do not know that it will not turn our finely tuned pipeline into the bottle neck of production we are not going to listen to anything else you might say.  Remember Time is our #1 development problem
    • How long does it take to run and how much will it add to our iteration time?
    • Can it be distributed?
    • On average how long does it take to integrate into a tool path?  Provide both examples and references.
  • Next part is the content generation iteself, again this must be shown on a real world examples.  I need to be able to determine total time for my game and how this might change the makeup of my development team.  If I can not figure out how long it would take me to process our assets then I am not going to risk switching my system over to something that is suddenly going to require massive outsourcing or hiring.  Remember Resources  is our #2 development problem
  • Support, turn around time, escalation procedures, avalibility ( I work nights & holiday, are you guys there too? ), ability to help debug, bug patching, source if needed, how often releases, how far back in releases do you support, how quickly do you upgrade to new console libs? 
  • Total Cost and payment schedule, what is the price for everything between now and when we are scheduled to ship.  There is way to much hidden costs in these presentations and we are always hearing things like $40k per platform.  But then 2 weeks later we send an email and get informed that email support is another 10k per year and god forbid if you ever need to get someone out to help you do last min debugging during ship.  Also can we pay over time so that is it does not completely restrict our budget?  Lastly Money is our #3 development problem

 These changes to a more customer concerns focused presentation would move middleware meetings off my list of least favorite development activities and might even make them finally useful.

Leave a Comment :, , more...

Looking for something?

Use the form below to search the site:

Still not finding what you're looking for? Drop a comment on a post or contact us so we can take care of it!

Visit our friends!

A few highly recommended friends...