Mike Acton. Insomniac

Tools: Build or Buy?

 

Insomniac: you should invest and build your own engine technology.  It is an investment in your people. 

 

One argument: buying lets you spend more time on your gameplay.  But that is almost never true.  Instead of concentrating on core tech you concentrate on using someone else’s core tech.

 

Engines no longer a differentiator?  Become a commodity?  Not true if it hinders you.

 

Middleware games faster?  Insomniac builds their own tech but have 3 generations of games on the current console gen.  Same with Epic.  Silicon Knights will tell you about the speed of using middleware.

 

What about the costs?  Yes, it costs.  Strong team, smart people, and you have to invest in them.  But who would say that is a bad idea?  The hidden costs of middleware – product delay, unsupported platforms, losing the most qualified people to customize middleware because they can’t learn and grow?  Cost of support (and not getting enough of it).  What if that middleware company is working on their own game, can you depend on them?  Cost of lost opportunities with your game design.  People dependant on Renderware, and then it went away.  Cost of lost preparation – what are you going to do next generation?  Will your middleware vendor be ready for the next generation?

 

Isn’t this just Not Invented Here?  It’s not really.  It’s about responsibility.  Whose bottom line does it affect when the game is late or missing features?  Who do the media and players blame?  It isn’t going to be the middleware.  Rightfully so, it is your responsibility.  Only way to take that is to do the work yourself with a team that you have invested in.

 

We all use middleware to some extent:   Maya, grep, SDKs.  When do you choose, and how?  Invest internally anywhere that is of value to your product to be better than the average.

 

Andy Burke, Insomniac

Components

 

Look to middleware to lower cost and reduce risk.  People make a big mistake and believe that these tools will just drop in.  But they never do.  It may reduce but it never eliminates.  Always takes more investment than you think it will.

 

Anything you license: get the source.  At least gives you some recourse if problems arise.

 

Be realistic about cost savings.  Not going to come in and work perfectly with no problems.  In the end, all in one solutions work really well for the people that developed it, but how well will it work for your game?  That can work for you if you are making a substantially similar game.  3rd person from 1st person, sure maybe.  But a puzzle game?

 

As your game differs from the tech you license, cost is going to go up.  Think about how different your game is.  What is the cost to make the tech work the way you need it to.  In the end it is your own ship date that matters, so what is the impact on that.

 

At Insomniac, use a component approach to solve particular needs.  Being able to drop in something right where needed is nicer.  Easier to understand since they are more limited in scope.  Even with components it is not going to be free.  Develop ways to tie this in to your own systems.  View Maya as a component – a 3d modeling and animation component.  Tried to use it in a way that it wasn’t intended for – level construction and wiring – but it wasn’t designed for it.  Very costly to try and make it do that.  Costs to implement and then also lots of bugs.  As a component though, it is much nicer, though still has costs.   Custom importer to a private format, real time comms between Maya and our level construction tool (Luna) for real time manipulation but visualize in engine.  Of course, support.  In the end a much nicer solution though.

 

Perforce is another good example.  For a long time it was all in-house revision control.  Dedicated developer, with periodic assistance.  Hard to compete as a game company with something that is their entire business.  Does the job well.  Still takes time to integrate, and ongoing costs.  It’s not open source so you can’t fix a bug, you just have to find a workaround even with responsive support. 

 

wxWidgets.  Considered many options but decided too costly to develop internally.  Settled on wxWidgets but only after analysis and thinking about the costs.  It did take a while to integrate.  Fortunately was open source so could fix bugs but also then contribute those back to the community.

 

There is no single answer.  Work to understand what the impact will be – how similar the tech is to what you want to do, what are the ongoing costs.  Think about using smaller components to answer specific problems.  Get the source!

 

 

Michael Capps, Epic Games

Licensing Middleware

 

Started out licensing for America’s Army, using Unreal license.  So a client as well as the director of dev. 

 

Intentional separation of game team and engine team so they have to go through the same support mechanism.

 

Shared tech yields better games.  All about abstracting away details.  Avoid machine language, use Windows.  Middleware lets you not worry about platform details.

 

If you don’t have an engine, cost-savings argument is simple.  License for less than build, even amortized across multiple titles.   Content is the most expensive part of any next-gen game!  7x the content in UT3 vs UT99.  Content can start right away, you aren’t throwing stuff away.    Less engine tech revision.

 

Majority of dev teams already have free access to some engine tech.  Half of Epic’s customers fall into that category, of having tech but licensing UE3.  Why?  That tech needs modification for the next title, but so would an off-the-shelf engine.

 

Cost savings aren’t the only reasons to license!  Middleware is battle tested.  Shipping is where rubber hits the road.  Tons of testing on all platforms.  Testing all code pats.  “A 300 Warrior”.  Tough to get that benefit yourself.  More stable – ever cut a few corners during ship crunch?  Those cut corners go in a different branch.  Thousands of smart coders looking at this tech.  Tools and interface are the bread and butter.  More emphasis here.  When we show it to devs, coders don’t like it but the artists love it – that’s how they sell engines.  Good tools are double duty – selling engine + useful for internal games.  Big investment in automation that most devs can’t afford.  Better documented and support than internal tools.  Internal guys have games to ship.  Feature richness – you get features you’d love to have but wouldn’t build yourself.  More modern – long cycle of feature lock in normal dev but middleware never stops.   Better optimized – bigger your base technology is the more leverage there is to things like having nvidia make your engine fast.  As big as you are you are never as big as all the Unreal titles.  External teams like XDK use middleware as reference.

 

Not just engines, even when rolling your own engine tech there are some smart components to license.  Physics solvers, for example.  Epic uses middleware where we can.  Integrated Partners Program. 

 

Smart licensing: managing risks is key to game development.  Any external dependency is a risk.  Has the tech shipped before?  Shipping is where reality sets in.  Can you ship if they close their doors or fail to make promised updates?  Epic gives source code access to licensees have the option to fix ship blockers themselves. 

 

 

Yannis Mallat, Ubisoft Studios Montreal

Emotion and Innovation

 

Bambi.  Emotion Sells.  Bambi is 66 yrs old, 1942.  Not linked to technology. 

 

Ubisoft:  “Creating the best games of the industry”.  Want to sell a lot but before we can sell them we need to create them.  Mandate is not about building technology.  Tech alone doesn’t sell.  Statement in favor of innovation.  Our best bet is to innovate and provide emotion, that’s how they make great games.

 

So, how to innovate?  Three layers:  tech innovation, content innovation, tools innovation.  Tools are the missing link.  How do we provide the creators with the best tools to express their vision?  Next gen is content driven not tech driven.  Technology yes… but.    Why can the same engine be used for top-end games and mediocre games?  Does good tech = good games?  How many gamers by games for their technology.  Tech is important but it’s role is to serve the creative talent.

 

“Refactor the Renderer”  -- what does this even mean to non technical people?  This is not the right war to fight.  The game code that is not in the technology will be good enough to make the game good and different from competition.

 

Tools, tools, tools.  Developed with and for the creatives.  Execution not a barrier anymore.  Must be built in house!  Generic tools do not allow for creative ideas, at best they allow generic content for generic games.  Think about the CGI world – ask them about generic tools.  They build their own pipelines.  Tools are the translation of technology into innovation and emotion.  Code is not emotion.

 

Apple – not bought from tech, but from the emotion that it generates.  Nintendo – could you possibly have less technology approach?  Focused on innovation and the talent of their designers.  John McEnroe – greatest tennis champs ever, but did it all with a wooden racket.  All about the talent.  Racket tech to help people play generically.  Talent generates emotion.

 

Technology is not a deciding factor at this point anymore.  Talent, Innovation and Emotion are.