Q&A: Why Ready At Dawn Joined The Game Engine Race

Last October, Ready at Dawn Studios -- developers of Daxter and God of War: Chains of Olympus for the PSP -- announced that it will be licensing its engine tech out to third party developers. At that time, we spoke to co-founder Didier Malenfant, who is heading up engine development at the company. Malenfant founded Ready at Dawn with Andrea Pessino and Ru Weerasuriya, who both came from Blizzard. In December, the company added John Nagel, formerly of Scaleform, to head up sales and marketing for the engine. The company revealed late last year that its engine is fully integrated with Autodesk's Maya, and more recently that it is also integrated with Perforce asset management. Now, Gamasutra presents a lengthy Q&A with Malenfant, addressing, primarily, why Malenfant and company decided to build the tech precisely as it did. He also discusses just what developers will get when licensing the engine, and how a "no bullshit" philosophy means that the company won't try to sell studios an engine that won't work for the games they're making, inviting developers to "come check it out." You guys are engaged in active development in games and you're also marketing an engine product. Do you have the resources to do the kind of support that's required for the people who license your engine? At the same time, you have your game development clients, e.g. Sony or someone. How is your approach to that going to be? Didier Malenfant: We're basically really separating the engine team from the game team. My title is president and co-founder of Ready at Dawn, but really all I do right now is head the engine licensing as a separate business. I have a separate team, a group of guys that deal with all the support. To use a marketing term, the "productizing" part, which is really just turn what we have, which is an engine that we use here internally to make our games, into a product. Even though I hate this word, it's really what it is. It's to turn it into something other people can use. That's not handled by the game team. That's completely separate. Sales and marketing, obviously, is not handled by the game team. We've already made some changes and decisions in the way that we present the technology and the tools that are different than the ones the game team made. It's really just a way for us to really have this clear separation. We do from the engine licensing point of view what's best for the teams that work with our tech, not necessarily what's best for our internal team. Our internal team is really going to slowly just become another client of the licensing branch, and that's really the balance we need to keep. It's really, really hard. It's something where we need to keep it in mind and work at it all the time, because you're right. In the past, the tendency is that it slips at some point, and you end up with something where... You know what? You're under pressure to release your titles and all your licensees go out the window because they basically have to wait [for you] to finish your stuff. So, it's something that we're definitely aware of. We're basically focusing a lot on making sure that doesn't happen to us, A, by having not as many licensees as we can handle and not more, and B, by again trying to separate the two very distinctly. How are you going to handle implementation of requests from people who license the engine? Is there going to be a process for that? DM: Yeah. I mean, the process is going to be it all depends on how many people need something. At the end of the day, it's kind of a democracy in that respect. If it's something that's a feature that's required just by one licensee because of a specific title, we tend to catch that sometimes during the evaluation process. We try to be super straightforward and honest with people about our tech. We've actually told people in the past that our tech wasn't the right fit for them, and we actually directed them to other engines because we thought that it would work better. I think that's part of also the way we try to do things differently, trying to make sure that... You know, [sales and marketing head] Jonathan [Nagel] coined the term "cramming tech down your throat", and I think it's a good image. I was telling you earlier it is a business making games, and it is a business licensing an engine, but we've never pushed it as a business, and in a way, that's a good thing because really your focuses changes. Our focus is not necessarily just sign 200 licensees by next year and basically just try to add numbers. It's really just to make sure that we can help people, and if we can't help people, we've been pretty straightforward. So, that's one of the things where if we see that, I don't know, if you're trying to do an MMO title for example, we might not be the best platform for that. If you're trying to third-person, first-person, or a racing game, that's definitely a better fit. And we try to talk to people about, what type of game are you making, what platform, and what time frame, and just give them an honest opinion. It's as simple as that, but it's really just something that I think is new to the engine licensing business. You personally have a very strong tools and engine background, because obviously Naughty Dog's Jak engine was one of the preeminent PS2 engines. So, did you found the company with this view to eventually get into the engine business, or was it an outgrowth of, "We're happy with the tech, we're developing what we think is valuable to people, potentially"? DM: I definitely started the company personally with the goal of making a really, really strong tool pipeline. I was in charge of tools at Naughty Dog, so historically, I ended up doing, that because my background was initially engine programming. I was doing renderers, and 3D engines on PlayStation 1, and things like that. When I got [to Naughty Dog], they had some amazing engine programmers that I literally had nothing to bring to the table, and I wanted to do something where I could contribute and help them out. So, I ended up doing tools, a good chunk of the tool pipeline for the first Jak & Daxter, supported that during Jak 2 as pretty much the sole tool programmer, and developed a passion for it -- really developed a passion for workflow, for not doing programmer tools, for basically doing something for your audience, the artists and the people that are going to use it, and see how little things can make their work so much easier. At the end of the day, they're the ones that do the games. We talked about on PSP, a lot of people rave about our engine and how fast it is, but even if you have that, at the end of the day, your artists are the ones that will really make it shine and make it look good, and that fascinated me. That's something I really wanted when I started tools over here, when we started the company. I wanted to build on top of, and use, everything I learned to make an even better tool pipeline, and [co-founder] Andrea [Pessino] did the same thing with the technology, with the engine. He was more on the rendering side. So, we weren't planning necessarily on licensing it, but it was something where we knew that internally, to make good games, we needed to have amazing tools and amazing tech. Then, when that was done and the game shipped, we started getting a lot of attention, even after Daxter, from people saying, "Can we use your stuff? Can we use your stuff?" You talked about tools enabling the game, and that's very true -- but very often, they get neglected. Why do you think that is? DM: Because it's hard. It's time consuming. I mean, everything in making a game is hard. The compromises sometimes are not the right ones, and people end up compromising on things that they shouldn't. It's hard. That's why middleware, at the end of the day, is a good thing for a lot of the teams out there, because it does give them a leg up and it does allow them to focus on the game, the content, and not have to do everything from scratch. I mean, six years [since engine development started], we're still adding functionality to our tools. We're still making them better for every single game that we make, so it is really, really hard. You need to have a balance between the game that you're making and the content and the technology. They kind of both need to motivate each other in a way. It's really kind of back and forth. One will make the other better and vice versa. You license Unreal Engine, and you get Gears of War. Are you able to do something like that for your engine? DM: We have basically a bunch of what we call "game libraries" that not necessarily contain something specific to our games, but our games are built on top of them. So, that's something that we ship with the engine, where you have things to handle cameras, to handle AI, and things like that. Obviously, the games themselves, the games that we worked on so far, have been published by Sony, so they wouldn't be shipped together as games. But all the base that makes those and everything that is part of a game has shipped with the engine. You've so far shipped only PSP games... This is a PS3, 360, and PSP engine. Obviously, you're moving into a place with the engine where there's no game that people are yet aware of. I mean, you may or may not have those in development, but I don't know. What do you say to people who ask, "Do you know these platforms? Are you prepared to move into that space"? DM: What we usually say to them, and it's happened, is "Come check it out." At the end of the day, like they say, the proof is in the pudding. The toolset is very similar because the tools are solid. You have the chance to play with it a little bit and see kind of the integration with Autodesk Maya and how we're trying to keep all that stuff. We try to not re-invent the wheel. No matter which platform you work on, those remain the same. They're basically the same toolset, which is actually, in our case, fairly interesting because this is the first time that you can go all the way down to PSP or all the way up to PS3 and 360 and use the same tools. Up until now, nothing else scales up like this. Scales up or scales down, depending on which way you look at it. So, yeah, we basically just offer people to come check it out and take a look. We say, "Come and look what you can do with it," because that's really what matters. "What we can do with it?", at the end of the day, historically, has been promises that ended up not getting not fulfilled because you see all these fancy demos and all these flashy things that all the engine manufacturers do with their own stuff. And then you get the engines and you try and do it yourself, and you can't get even get anywhere close to what those guys are able to do. So, really what we're focusing on is what those guys can do themselves and not what we can do internally. You've made the decision that it rests on top of Maya. That limits people's choice to just Maya, which, as we were talking earlier, isn't probably a tremendously huge deal because a lot of people use Maya anyway. But why did you make that decision? And what are the benefits? DM: In our case, it was because Maya was way more extensible than 3dsMax was. It's really a historical choice. You know, Naughty Dog was a Maya house. My experience was with Maya. We really knew very well from the get-go what we could get out of extending Maya's functionality. It goes back to another question that you had. If you're a developer that's using Max extensively, that has 3dsMax everywhere, obviously, that's not going to be the right choice for you, probably, for the time being, and that's fine. It's not necessarily about being the right solution for everybody, but you are the right solution for people that develop games the same way that you do. In a way, I do feel we do fit a hole in the engine licensing business right now, because a lot of the engines that are out there kind of have the same philosophy and the same approach to things. From the day of id Software with your proprietary editor... that kind of old model is the same, and we're very different in our respects, and we're definitely going to help a bunch of people that make games the way that we do. When I was sitting in and being showed some of the design tools and the way the scripting works, there are chunks of code that are held by the programmers and they can be sort of chained together and tweaked but can't be directly edited by designers. DM: That's another religious debate. It totally is. You'll have your game houses that are adamant about having a scripting language and about trying to make their designers programmers, which is really what you end up doing. That's something that I personally, and here as a company we've, been completely against -- because what you end up doing is you take a language that's not a real language, it's something that's been made specifically for your game, most of the time by your programmers. You give them tools that are not real tools because, again, you're not going to redo Visual Studio or anything like that on your own time, and then you give it to people who are not programmers. And how you expect no problems to come out of that, I don't know. It's something where, to me, this is asking for trouble. It's philosophical. I say "religious", but really you'll have two sides. To us, really, the power is in making sure that the people that are using the tools have the right tools to do the job they're trying to do, and that designers, in our mind, should not be learning to program, not to the extent that they have to. Designers with a programming background are great, and are really people that do very well because they have a better understanding of the tech and the things that happen underneath, but asking designers to write code, to me, is a very, very bad idea. Since your engine is built on Maya, you don't have the artists running just stock Maya. You have them running your toolset. DM: Absolutely. I mean, at a pinch, they could jump in and do some fixing, and some people are really good at it. If you need to jump in and modify somebody else's stuff or help your work flow by doing something, you have access to everything. You have access to the game just like everybody else does. It's not tool separation at the end of the day, it's really just something that's, again, driven by choices that have been made 15 years ago that were probably the right thing for PC first-person shooters, but really no one kind of questioned that and go, "Wait a minute. Is this really like the right idea? Is this..." So, we basically kind of looked fresh and did what we thought was the way that at least initially for us was internally the way we wanted to work, without limitations, without those artificial boundaries between tools. Again, it goes back to when you're talking to people that are interested in the technology. Because that's going to have implications for workflow, and the way your programming department is set to work. DM: I think what we need to get back from is this idea that somehow a middleware platform can be the end all, be all for everybody and can basically solve every problem under the sun, because I get the feeling that a lot of those promises have been made over the last 10 years, just like motion capture at one point was going to be the end all, be all, and animators were going to go away and we'll never need those guys because we're going to use motion capture. I think in both cases, people got bitten pretty hard believing that. And that's why, again, our approach is to really just evaluate and find people who we can help. And there's plenty out there, but we're not going to be for everybody at the end of the day, and that's fine. Again, we're pretty honest about that. We basically just help people out... Over their own evaluation, we'll basically guide them through the process and just make sure we can bring something to the table. If not, we're not shy of telling people, "You know what? This is probably better for you." It's impossible to do something that would cover everything. And if you promise that you do, then you're lying. If you look at some of the people who have really extended engines to do things that are not what they can do out of the box... DM: I've heard so many stories of people using some of the engines that are out there and really just, again, being under the impression that it can do the things that it didn't. What ended up happening is, yes, in some cases it was a complete catastrophe and the projects go nowhere because they're basically not able to do the work. And in other cases, they end up spending just about as much as time as it would have taken them to do things from scratch to basically make that engine do what they're trying to make it do. You hear that at GDC all the time. "This took us as long as it would have taken us..." DM: Exactly. And so I think that our approach when we started the company, and it's served us very well -- and it's kind of our company mantra -- is "no bullshit", and we've applied that to the engine licensing. We're not about making sales pitches, and we're not about trying to make you believe that you'll be able to solve every problem in the universe by using our stuff. Having said that, you know, the games that we've shipped so far, kind of speak for themselves in terms of the ability for the tech to do cool games. So, yes, there will be a lot of people that will benefit from using our stuff. Again, that comes down more to changing the way that those things are evaluated and just seeing them less as a sales pitch, as something where, you know, you're on a car lot and someone's trying to make you drive away with a car at all costs. I mean, no one seems that happy when I hear them talking... DM: I think no one is happy with what's out there right now. That's pretty clear for different reasons. But they do seem to expect to have to rip things apart. DM: Yeah. That's a bad thing. You shouldn't. To me, it's the same argument. The people coming back from that are people who have had consoles for a while. I'm a huge console guy. That's what we do. We do console games. Our engine is a console engine. But a lot of people approach consoles with what they would have wanted, as opposed to what the console is, and look at it as like, "Well, it doesn't do this or it doesn't do that", glass half empty type of thing. If you treat it as a platform, as we did with PSP... Basically, it works. Not to get too philosophical, but again, you talk about artistic endeavors and limitations and compromises and things like that. It's where the best art comes out of. Basically, you work with the tools you have. I think that we're probably going to end up helping a lot of people by making that decision for them and giving them something that in the end completely works and is ready to go, ready to use. You also talked to me earlier about the potential of extending the engine to platforms like the iPhone. I imagine you're going to be looking at places the engine can go beyond what you're already committed to. DM: Yeah. We're lucky to again have scaled up from the PSP, because that opens us up to other platforms that other people can't touch, basically, with that level of toolset and of graphical performance. You know, iPhone is one of them, the Wii is another one. Looking forward, any consoles that come out is something that we'll be able to support. The Wii is an obvious target because it's got fewer engine choices and there's still demand for high-level experiences. DM: I think what's interesting, also, is to be able to use the same toolset across all those platforms. I mean, obviously, we're not pretending that you can take your PS3 models and put them on an iPhone, but having said that, you can use the same tools to produce content for both, and I think that's really valuable. You've said PS3 and 360 but not PC, and fairly often, popular games are on all three. Are we talking about excluding the PC as a possibility? DM: Well, we do have a PC version of the engine. We've had it from day one because initially we didn't even have devkits for the PSP, so we actually developed our games on PC. And it still exists to this day. And the Maya integration is actually a version of the PC engine that runs inside of it. So, we do have it, and it's available. Right now, we say we don't support it commercially mainly because we haven't tested it on the three gazillion graphic card combinations that are out there. But it's there. It's usable, and if it's something that licensees want really bad, we'll definitely look at it and support it down the road. It does exist. I mean, you do get it as part of the package.