JULY 22, 2008 • Autodesk has been a leading software tools provider since it was founded back in 1982.  Over the years, Autodesk has expanded its game tool software portfolio through a series of acquisitions. In February of this year, Autodesk announced it was purchasing Kynogon SA, a Paris-based provider of artificial intelligence middleware for the video game industry.  The acquisition was finalized in May and Kynogon was folded into the newly created Game Technology Group.  In order to find out more about he purchase, the new game division and Autodesk’s future plans for the game space we talked with Michel Kripalani, Director of Business Development for the Autodesk Game Technology Group.

DFC: What was the attraction for Autodesk in acquiring Kynogon? And ultimately how did that acquisition play into Autodesk’s decision to create the Game Technology Group?

Michel: Autodesk had been considering a major move into the middleware space for quite some time. Our first middleware product, HumanIK, has been available for a few years now. We took existing Autodesk technology designed for asset creation and repurposed the code into optimized libraries designed to run on the game consoles. HumanIK is based on the animation rigs in MotionBuilder.

HumanIK has been very successful for us. Ubisoft used it extensively in Assassin’s Creed and EA relies on it for many of their sports titles. So, we knew that we had touched on something. However, we also realized that if we really wanted to properly grow into middleware we needed to acquire a strong team that was already successful rather than build everything from scratch. There were certain competencies that we were lacking given the new business, distribution models and highly technical and responsive support of middleware.

We identified and acquired Kynogon for their Kynapse product and for the team. Kynapse is the world’s leading AI solution and it is a very mature product. Kynapse has been used in more than 70 titles including many AAA from EA, Sony Online Entertainment, Midway, THQ, Activision, Turbine, Lionhead Studios, etc. Jacques Gaubil and Pierre Pontevia, the original founders of Kynogon, have built a very solid company and great team. By bringing them into Autodesk and using their group as the core of the newly formed Games Technology Group, we had the foundation that we were looking for. A few of us, originally from other parts of Autodesk, have migrated over to this team as well. We hope to grow the business quite rapidly and release some excellent new offerings that will make it easier and more cost effective to produce games.

DFC: Can you give us an overview of Autodesk’s Game Technology Group? What are some of the Group’s short and long-term objectives and goals?

Michel: The Games Technology Group is focused exclusively on Autodesk’s middleware initiative. We have been tasked with developing great new middleware products, bringing them to market and supporting them.

Short-term, we will focus on the creation of believable characters. For us, believable characters require tight integration of animation, AI and physics. We call that the Character Centric Solution. We have a great start on animation and AI with HumanIK and Kynapse. Current-gen consoles are pushing the limits of all three areas. In order to maintain believability when the quality of physics increases, so must the quality of the AI and also the animation. What good is a destructible world if the AI is unable to adjust to the new modified terrain? And what good is the new AI pathfinding if the system cannot realistically show the character climbing over the arbitrary rubble scattered about the world with hands and feet that connect with the rubble appropriately?

Beyond this first task, our goal is simply to make it easier for artists and creative types to have a smooth pipeline all the way from art to engine. People are already using Autodesk tools at the front end of their asset creation process. We want to make it easier to bring richer, parametric data right into the game engine. We believe that this will reduce costs for developers while increasing the quality of gameplay.

DFC: What is your specific function within the Game Technology Group? Besides you, how many people are in the Group and who is running the Group?

Michel: Primarily, I am responsible for building our APAC business and managing some of the partner relationships. I also do a fair amount of marketing and evangelism. The group is still being run by Jacques Gaubil and Pierre Pontevia. Jacques is responsible for Sales and Marketing functions. Pierre is responsible for Product Development and Support. Each of them has many very skilled individuals in their group, although I am unable to disclose actual team size.

DFC: How tied into Autodesk’s corporate structure are you? Where do you see your biggest growth opportunities within the games space?  What do you feel gives you a competitive edge for building a middleware business?

Michel: The Games Technology Group resides within the Media and Entertainment division, which is a sizable portion of Autodesk’s total revenue. Specifically for games, we feel that much of our growth will come from middleware, thus the recent push. Our competitive edge will come from two primary areas.

First, people are comfortable with Autodesk and are already very familiar with our tools. There is a trust factor that is implied given the history that we have in delivering solid content creation packages like 3ds Max and Maya. Game developers know that Autodesk is a true software player able to offer multiplatform solutions and Autodesk has a very strong focus on games. We are already the largest software vendor in the industry. Also, they know that Autodesk isn’t going anywhere. There can be a lot of risk purchasing middleware from a small company. Just ask anyone who was using Renderware (from Criterion) before Electronic Arts bought the company.

Second, we have a tremendous amount of knowledge and IP that is already in place for game creation. We will leverage our existing content creation tools to ensure a smooth communication between the run-time space and the asset creation. There is tremendous value here.

DFC: What do you see as the biggest changes currently taking place in the middleware market? How are production pipelines changing today? Also, what are developers telling you are their biggest challenges and tool/technology needs?

Michel: First off, the biggest change is that the middleware space is growing rapidly. Developers realize that they simply cannot afford to write everything themselves. It is not efficient from a risk standpoint, nor is it beneficial from an opportunity cost perspective. Game developers need to focus on aspects of their game that are differentiating from other games; the things that will make their game unique. The days of differentiating a game by the physics engine under the hood are over. There is no reason to write a physics engine from scratch. There are many good physics engines available and most do the job quite nicely. The same will be said about animation and AI in the future. The low-level code is something that does not need to be custom written for each game.

We see that pipelines are getting much more complex. The number of tools hooked in, the number of processes in the system and the number of output formats are all increasing at a fast pace. More importantly, the market is more and more fragmented. Besides “traditional” console games, we now have casual games, online games, Wii games, etc. Developers need multi-platform technologies that help them address these multiple segments. This is one of the main reasons why middleware is taking off. Purchasing middleware is a risk mitigation technique. Developers have to limit the number of “unknowns” in any given production pipeline.

We hear many requests from developers. A large number of the requests are tied to our content creation tools. However, on the middleware side, most people simply want greater efficiency and shorter iteration speeds. Put another way, they want to get the iteration loop as tight as possible. There is only so much that Autodesk can do on the art creation side of things. We needed to jump into the runtime code as a way to help solve this problem from both angles.

DFC: Do you see developers’ notions of “off-the-shelf” middleware changing or is there still a mental roadblock for developers who believe it is better to develop technology internally?

Michel: We absolutely see a shift. There are very few games today that are developed without using middleware technologies. In fact, we know of many games developed using almost 20 different pieces of middleware. How many people are writing custom physics engines these days? The answer, from our perspective, is very few. And why is that? It is because Havok, Ageia, Bullet and others have solutions that are good enough. Similarly for AI, Kynapse penetration has been very impressive these last 3 years with seven of the top 10 developers using it.

Piece by piece, component by component, developers realize that there are easier, more cost effective ways to get games out the door. Autodesk already provides some of these component technologies. We are not looking to build a monolithic middleware system. Developers do not want this. However, if we can provide a solid suite of middleware components that can be “mixed and matched” then developers will be interested in our offerings.

DFC: How are you pricing Autodesk middleware tools? Will you have a consulting service component available to companies?

Michel: If people have pricing questions, it would be best for them to contact us directly. Send a query to middleware@ autodesk.com and someone will get back to you. We also offer a consulting service component to our middleware products for people who may want the extra assistance.

DFC: The FBX format has been around for a number of years and has become a core building block within the Autodesk tools. What are the major advantages to developers of the format? How does it compare to Collada? Supporters of Collada argue that “open formats are better” because it allows the developer to use tools from a number of vendors where as a format such as FBX is geared at Autodesk-only tools. How would you counter that?

Michel: It is important to understand that there is a major difference between FBX and Collada. Collada is a data interchange format. It is good, but it is limited. FBX is much more than a data interchange format. In addition to the flexible FBX file format, the FBX family of tools contains a set of libraries and translators that allow data to be understood better. Many of the Autodesk proprietary functions used in tools such as 3ds Max, Maya and MotionBuilder can be read and interpreted by FBX. Because of this, we can substantially limit data loss and degradation. As a simple illustration, assume the following scenario; data is coming from an application that uses a particular f-curve. FBX will capture this rich data. If the data is going into an application that can understand the same f-curve format, the rich data will be passed in. If not, then keyframe data or interpreted data will be passed in. This flexibility ensures that there is a greater likelihood of having rich data passing between applications. This is the core mantra of FBX.

And, with regards to Collada, we do have a Collada exporter and importer from FBX. We view this as a sub-set of the entire FBX initiative.

DFC: Autodesk has a large group of third-party developers for its staple products 3ds Max and Maya. Do you know how many plug-ins there are right now for these products?  Will those play into Game Technology Group’s goals at all?

Michel: It is true that we have a very large third-party developer network for 3ds Max and Maya. I would not be able to give you exact numbers on the size of the community. As great as this foundation is, I do not expect this to play into the Games Technology Group’s goals. We have a very different business model.

3ds Max and Maya are software products that can be extended with plug-in technologies. Middleware entails a different business model, though. Kynapse and HumanIK are sold as a set of libraries and source code. If people need to extend functionality, they simply write new functionality into their own codebase for their game. It is unlikely that most developers will want to share this specific code with others.

DFC: How do you see Autodesk tools working when supporting various different game types – casual games, MMOs and virtual worlds, AAA titles? Will you look at focusing tools for different categories or is there a different strategy you have in mind?

Michel: With respect to the asset creation tools, all developers need the same things: fast, stable, efficient tools. Our individual tools are getting more specialized, but I would not say that this is driven by genre related issues. It is more a nature of their unique architectures. Mudbox, for example, is an excellent high-poly modeler. It is able to perform at the speed that it does because it is independent from 3ds Max and Maya. It integrates well with both, but it needs to be standalone in order to get the performance that it does. The days of a single, monolithic, content creation package that deals with everything are fading away.

It is in the middleware space that we will see greater differences by genre. Clearly, HumanIK and Kynapse only apply to games that are doing complex character animation and need AI for the non-player characters. In this sense, we will look for opportunities that cut across multiple genres, but we won’t limit ourselves. If we see a great opportunity for a “sports games only” piece of component middleware, we will consider it.

DFC: You have mentioned that according to industry trends, roughly 20% of art assets are currently being outsourced and is on target to hit 40% by 2011. What is prompting this outsourcing trend? What are the development issues with more outsourcing?

Michel: Team sizes are growing at an incredible pace. Developers are having trouble keeping up. If a developer ramps up with a large enough team to get through “the crunch period” then what do they do with all of those employees when the crunch is over? It is a tough question. Margins are too small to keep large teams on the payroll permanently. A system has to be in place to let people easily ramp up and ramp down.

Perhaps more importantly, there is the real factor of cost. There is a portion of a game that is unique, complex and difficult to create. These tasks will remain in-house. But when you have 200 similar cars that need to be modeled and textured to specs that have been outlined, why not find someone else to do the grunt work at a cheaper price? It all comes back to the question of efficiency again. The bottom line is simply that games are very expensive to create and people are finding any way they can to bring the costs down. Outsourcing is a very real solution to this problem and we expect it to be here to stay.

DFC: From what you’ve seen with game studios is there is the typical development budget for the games you produce? What are the most expensive components of development? Do you see that changing over time?

Michel: This is one of those questions that is very hard to answer out of context. As a ballpark guess, I would say that we are seeing many AAA next-gen (PS3, Xbox 360) budgets in the $10-25 million range. Of course, there are exceptions on both ends, especially with the growth of casual and Wii games. It is rumored that GTA IV cost over $100 million to make. If this is true, it sets quite a high benchmark.

I believe that the art assets are some of the most expensive components. It is an issue of complexity really. Games require very complex assets; high resolution geometry, high res texture maps, complex data maps (ambient occlusion maps, specular maps, normal maps, etc.). As if this wasn’t enough, the quantity of assets has skyrocketed as well. Consumers are expecting larger and richer games. The combination of these two factors creates almost a ‘perfect storm’ for many developers who are struggling to keep their production costs in line.

DFC: Are there any development trends you see that run across different geographic regions. For example, what trends do are you seeing currently in Asia – China, Korea, Japan (other emerging regions) verses development in North America and Europe? Because they are trying to “catch up” are they more open to middleware… is the development philosophy different? Also, what about Eastern Europe and countries such as Brazil, what kind of development are they doing?

Michel: In China and Korea we are still seeing a large amount of PC development. There is some console development, but the vast majority titles that we see are PC based. Also, in China, we are seeing a very mature outsourcing market. This is particularly true for Shanghai. In Japan, most development in geared towards the consoles. The PC and MMO markets are almost non-existent. With respect to middleware, we are seeing opportunities worldwide. The market need is very high. Our largest challenge with countries outside of North America and Europe is language, but we are beginning to tackle these hurdles one by one.

DFC: Kynogon has built up a good business in simulation markets beyond game development, such as military, security and industrial markets. Will that technology end up being leveraged further within the larger Autodesk corporate umbrella?

Michel: Absolutely. Not only will we continue to grow the stand-alone existing business in simulation markets, but I think it is fair to expect that Kynapse will have an impact on many of the Autodesk products. It would be safe to bet that many of the Games Technology Products will impact other Autodesk solutions. Autodesk sees gaming as one of the leading technologies for innovation. We plan to apply what we learn wherever we can to help the overall corporate strategy.