[INTERPOSING VOICES] OK, we're going to go ahead and try to get started. Everyone take a seat. 

Hello! 

There we go. 

Thank you. We're going to go ahead and get started. So as mentioned here, with Mike from Unity and Matt from MaxPlay. Maybe  we'll start off with each of you take a few minutes and introduce yourselves and [INAUDIBLE]. 

All right, again, my name is Matt Shaw. I've had a long sordid career in the game industry working for everything back in the day [INAUDIBLE] starting at Mythic Entertainment. I was part of BioWare, [INAUDIBLE]. I've worked on game engines ever since, well, well back before 3D aren't what they [INAUDIBLE]. 

We can't hear you! 

How about now? Oh, that's better. Sorry. Should I start again? 

Yes. 

All right, now the better version. My name's Matt Shaw. I am currently the CTO for MaxPlay, a company that makes basically a multiplayer collaborative game engine development system. We call it the Maximum GDS. 

Before that, I spent around 10 years or so working at Electronic Arts in various positions. I'd worked at BioWare, and before that I just [INAUDIBLE] and various things. I've been working on game engines and tools and way before 3D graphics were [INAUDIBLE]-- well, back before [INAUDIBLE] 3D graphics rasterizer, way back before hardware [INAUDIBLE]. And that's largely me. Mike? 

Hi. How are the cookies? 

[LAUGHTER] 

My name's Mike Geig. I am the evangelist at Unity Technologies. I started as an [INAUDIBLE] dev many years ago, mostly making government stuff, training simulators for firefighters, and whatever. And then I worked a bit in education, and now I'm at Unity about three years, first as an online trainer. 

Who here has watched any of the online videos about Unity from our website? Sweet, so chances are you've seen my work or have heard my voice. I'm the non-British guy. 

[LAUGHTER] 

And so  from there I moved on to a trained position where I travel a lot and visit customers. And now I'm an evangelist, to do a lots of events like this. 

OK, awesome. So the tongue of this is choosing the right game to do for your project. What we do is say are some of the non-obvious things that people should  be asking themselves when evaluating [INAUDIBLE]. 

Let's see. The only question I had is really it's very permanent from Mike and I was talking about. Why don't we not tell you what you should be looking for a little bit? 

How many of you ask you folk, what it is that you think you need in a project that's worth mentioning. Why would you choose [INAUDIBLE]? We have our ideas, but what's really important is what you guys think? 

Artist friendly. 

Artist friendly. So what does artist friendly mean? 

[INAUDIBLE]. 

OK. 

[INTERPOSING VOICES] 

OK, understandable. Anyone else? If you don't say anymore ideas, we're just going to tell you what you need. 

Pipeline integration. 

Pipeline integration. So give me a little more detail, man. 

Sure. So I'm not going to build the entire meeting room [INAUDIBLE] fit into that. So how well [INAUDIBLE] integrate to existing pipeline, other third-party tools [INAUDIBLE]? 

How adaptable it is. 

You refund [INAUDIBLE]. 

Thank you, Jen. I just mentioned [INAUDIBLE]. 

[INAUDIBLE]. 

[? Virgin ?] call [INAUDIBLE] and the gentleman behind you. 

The pricing [INAUDIBLE]. 

What do you prefer? 

It depends on if [? I was actually ?] engaging in [INAUDIBLE] 

Real quick, just so we  can kind of tailor the conversation as well, who here is developing for PC and Mac, desktop? All right. Mobile? Console? 

All of the above? 

[INAUDIBLE]. I know that's probably all of those, but, yeah, OK. Cool, thank you. 

[? WebGL. ?] 

I'm sorry? 

[? WebGL. ?] 

[? WebGL ?]. Ah, well, OK. That's [INAUDIBLE]. 

[LAUGHTER] 

[? I don't have ?] that much. 

[LAUGHTER] 

Whoever's looking at harassing them with one question [INAUDIBLE]. OK, all right, so I'll give you some ideas of what I think you might want to. Everything you all mention is fantastic for people who definitely want things to work well. 

We're in a kind of a unique situation at MaxPlay because we had a-- I guess the word is luxery-- and hardship of coming in late and looking at how other engines work and seeing what we think works and what doesn't work. And so the kind of things that we concentrated more on, you touched on most of them right now, which is pipeline, being able to get [INAUDIBLE] the game well, reduce iteration, increase your ability to iterate quickly, and see the artwork fast. 

One of the things that we hang on hat on is collaboration that allows you to basically work things at the same time with people, not have to be simply save out work, put it in source control before someone else can see it. And it's all about workflow because time is money as we know. And the better you make your pipelines and make your systems, [INAUDIBLE] people talk about to go, OK, how much of you [? do one ?] of you see developing a game if you're using something that's better tools? The answer  is you don't see anyone. We make a better product. And that's the part that [INAUDIBLE]. 

But we also kind of look at  thing like-- in some ways that basically it's kind of role playing game to be a game. You have to make the product really good for every kind of developer, whether that's an engineer, an artist, someone who's doing the pipeline or build systems. They all have game points, and so the more can try to solve those the better. And the bottom line is no engine is perfect at doing all those. 

So obviously, we see so many games, games everywhere, which you could extrapolate that that means it might be a little bit easier to make all the way around than it used to be. Absolutely. And so one of the things that myself personally I value a lot is these simple workflows that enable you do build the games, build them quickly. I am not an artist I am very much not an artist. It's staggering how terrible I am. And so the ability to take art and put it in again to do it at once in your programmer is great. 

But beyond that, what happens when you're done building your gate? It doesn't really stop there unless you're just  a hobbyist. At that point you need to turn into a viable product that makes money so that you can keep doing that? And so one of the things that I feel that Unity has done very well is, OK, you've made your game, now what? How are you going to make money? How are you going to advertise it? How are  you going to analyze what your players are doing so that you can fix pain points. You can know about the pain points even if know one else does. 

Like, if I'm a player, and I'm like, man, I just can't get past level four. Oh, OK, that's fine. But if I'm the game dev and I'm looking and seeing no one's getting past level four, then maybe there's a problem there. And so these services, these abilities to integrate with all these different marketplaces and stuff like that, all these different platforms is something that we really value, and hopefully it's something that you fall back on as well. 

Those are super important. And on top of that, in the past when I looked at game engines for evaluation purposes, when you're staring up new projects, teams look [INAUDIBLE] what's going on. The artist wants certain features. The designers want certain features. The engineers want certain features. 

And it is difficult to appease them all. But you have to look at the project. What is the project going to require? Does the engine support the platform you want to actually put the game out on? Do you have aspirations that once you've been out on that platform, you'd want to go to another platform? You're going to be stuck with it. [INAUDIBLE]. 

Also, [INAUDIBLE]? You have these aspirational dreams-- the best game anyone's ever seen. Can you actually achieve that with this product? 

And like Mike said, once you actually do get out it out and it's all great and the money's just rolling in, can you actually update the product? Can you actually advertise the product? Does it have good telemetry support in it so you can tell what's going on and make the game better? 

Right. 

OK. By the way, rather than saving your questions until the end, if people have questions they'd like to bring up while we're discussing this, feel free to just jump in or raise your hand and ask questions. I think having an interactive conversation [INAUDIBLE]. 

Mike, one of the things that you mentioned to me-- we were discussing this earlier-- is that, in general, people should stick with what they know, right? Like if they're already using an engine they're comfortable with that that's typically the correct way to go. And what conditions do you think that that's something [INAUDIBLE]? 

Well, I didn't really mean it like that. So one of the things I was talking about earlier is that a lot times, if you have a team that's predominately one technology, it can be very costly to switch to new tech, right? We all know this. Some of the most expensive parts of making games is payroll when you have larger teams. And so you have to keep paying people. 

And so what I was saying is sometimes, you look at a technology. And you say, we know this technology. We can build an application [INAUDIBLE] this technology. And so, yeah, we have some pain points. But the cost to get rid of those pain points and then discovering what new pain paints exists on the other side is sometimes not worth it. 

That being said, sometimes, the pain points are great enough. Or there is a certain feature that you need that is just not there. And in those situations, that completely justifies the cost and the time of learning new tech. 

But one of the things that happens a lot is you get a lot of people that's thinking, grass is always greener. Grass is always greener. I'm terrible with this. I can't make decisions about anything because I'm always thinking, oh, I'm missing out. 

And at some point, it comes down to the fact that sometimes, you're running a business-- unless you're a hobbyist, right? Sometimes, you have to make money to keep the doors open so you can keep producing your vision, or your entertainment, your experiences. 

And so you have to really analyze, OK, these are the things I don't like. This is how much it's going cost to transition. And is it worth it? And if the answer's yes, then it is, obviously. If the answer's no, it's no. 

I think a lot of people dive into this choice. They say, oh, you know what? I didn't like this feature. I don't like this thing. So I'm going to switch. 

And then they get to the other side, and they hit this stopping point where they're like, OK, how do I do this now? I knew how to do this but now I don't. And what's this thing? Oh, that's not what I thought it would do. And oh, I can't do this anymore? Oh, I really should have thought about this a lot more. 

Now, a lot of people do that. And it becomes problematic. And so it's an interesting time when you have people obviously from different technologies, many great engines available. I'm a game developer first, and the industry and the market as it is right now is great for devs. 

And a lot of people, they don't stop to really think, OK, what do I know? What's my knowledge worth? Because you take your own knowledge for granted. You take your team's knowledge for granted. The fact that you know a technology is-- a lot of people don't even value that. They're just, oh, we'll just learn a new technology. 

And the value that you have, the knowledge that you have, is incredibly valuable-- not only in some mystic monk way, but also in dollars. Because how much time it will take, not only to learn a new tech but how much time did it take you to learn the tech [INAUDIBLE]. 

And that's why, for anybody who's making an engine, it's up to them to come up with a good set of compelling reasons. Because [INAUDIBLE] those reasons for everybody. Otherwise, I can't even put  a straight face. Then you should switch or not to something else. And we have to offer features and techniques, or workflows, or something that actually save you time and improve your product. Otherwise, it's not worth it. 

So I think this is a good segue into one of my other questions, which is-- and this is, I guess, mainly for you, although I hope you can chime in as well. As a relative newcomer to this space, what unique value do you feel like MaxPlay offers that wasn't there previously? 

Well, we spend a lot of time on this because-- internally, we go, wow, why would I want to change? We have [? an engine. ?] So we kind of have a few pillars as to what would make the most sense-- would be improving workflows in general, reducing the cost of change, ability for-- 

An example is in our engine, when you're working in Maya, you can [INAUDIBLE] directly that uses the game engine. And as you're editing things in Maya, we're, as fast as possible, transferring that data to it. And the artist sees what it looks like  in the game engine on  the target device. 

That just saves the time of having to sync the thing-- [INAUDIBLE]. Someone makes a build a month later, then complains [INAUDIBLE]-- things like that. So we're constantly look at that. 

We're also wanted to make the engine be as fast as possible. So we had, again, the luxury of architecting the multicore runtime to take the [? edge of ?] multicore processors pretty much better than anybody else can because we start with scratch on it. And we can make it very fast. 

On top of that, we've also made it so that-- we've added collaboration, a certain [? pragmatics-- ?] we're changing collaborations so that people can actually work together. Sometimes we talk about it with Google Docs for games, but it's more than that. 

It has good controls on it so that you can invite people in quickly rather than, whether or not they're sitting in the table next to you and work collaboratively. Or they can be working from home if they're dog's sick or something. And you can actually see each other's doing and work well. 

But also, not destroy the whole [? main-- ?] you can work together in this work set, put it in, and it's [? all gone. ?] So that, again, it just makes it so that you're working faster. 

You don't have to worry about-- like, you see in some other engine flows that are more traditionally file based versus being SAS based like ours, you see people having to simply save a project, put it on a thumb drive or send it on the network, give it to somebody else. They can [INAUDIBLE]. Or they'd basically make somebody the integration captain. One person basically puts all the artwork in. So it's things like this. 

So we examine what we, in our team, big things we worked on for the last 20 something odd years and how do we just make things better? So that's really where we have our add-on, is trying to make it easier to do [? development. ?] 

So I shouldn't use Dropbox [INAUDIBLE]? 

You should see the security around here. 

You'd be amazed how many people do that. Don't do that, by the way, in case that's you. I'm not going to [INAUDIBLE]. 

So touching on something that you mentioned, I think people [INAUDIBLE] think all about the graphics side. But-- and this is going to sound self-serving, but-- 

Yeah, we also have all the best graphics. 

On the CPU side, there are a lot of things that can be done with a high-end CPU that can't be done with a [INAUDIBLE]. And we found a lot of developers have trouble fully taking advantage of that. I know that with MaxPlay, that's a unique opportunity [INAUDIBLE]. Can you talk a little bit about what these engines can provide to you in terms of fully taking advantage of the hardware that's available in any [INAUDIBLE] system [INAUDIBLE]? 

So yeah, so when we're talking about fully taking advantage of any system, one of the things-- with Unity, one of our greatest strengths-- and some people can see it also as weaknesses-- is that when we have all these platforms, what that means is a lot of times, our system's a little bit more generic. And they need to be to cover-- what, like 22-some platforms that we support. 

And so a lot of times, to get into optimization, Unity has optimization tools inside. We've got profilers and debuggers. And actually, some of the Intel stuff I saw earlier was pretty awesome. And it looks a lot like some of the tools  that we have, only much more ingrained on the device. 

And one of the best things in my mind about Unity specifically is that it's so extendable. So it's not really our editor. It's yours. You just make the changes, all these different workflows that you need to take advantage of what you want. 

That's a great plus than it is, like anything, a two-sided coin. Because a lot of times, to get into that really specific stuff, you have to extend the engine, a lot of times. You have to figure out what's important for you, what workflows you need that are lacking, and you need to have them. 

And the fact that you can is great. The fact that you can is sometimes not so great and requires quite a bit of technical knowledge to read the most out of it. And that's not just the case for CPUs. The GPU is [INAUDIBLE] memory management and all that stuff as well. 

And I think the same can be said for any piece of technology, even though we heard MaxPlay has the best graphics, as you just stated there. 

[? I put, ?] all of the graphics. 

All of the graphics. Like all seven graphics, that's amazing. But a lot of times, you get out what you put in. And I think that's true for most technology where you have to really dig in and stuff like that. 

And we have pre-processes, post-processes, and all these different buffers and [INAUDIBLE]. I'm not going to get into all that stuff. But we have the ability to tap into and optimize and change a lot of things that sometimes takes a little bit of work but really gives you a lot of power and granular control. 

So in our case, we want to give all the same things that you're talking about. But one of the things that we started with when we started from scratch was we looked at where-- we ourselves profiled the various engines that are out and looked at them. And we knew that there are techniques for doing multicore work that aren't generally-- 

So the multicore things that we doing are not rocket science. But they're pragmatic designs that are based on more modern [? ESP ?] architecture. [INAUDIBLE] meaning we actually just parallelize the work. 

There's a lot of time that's being spent on CPUs that we can take advantage of. Yeah, it's being wasted in the [INAUDIBLE]. So our system is fundamentally designed so that it's as fast as it can be. All [? systems ?] that we build all take advantage of having that stuff automatically [INAUDIBLE]. 

People do ask us. They go, well, OK, what's going to happen if I want to make some systems that are not really multicore friendly? Well, you can. You can control it and add the system's [INAUDIBLE] and actually take advantage of them, the systems, if you wished. 

Or if not, you can actually just take advantage of the [INAUDIBLE] solid foundation that we have that runs really fast. Have one small area of your frame that's slower, and then go back to being fast again. The overall end gain is tremendous win on the performance. 

And that's one of the reasons why [INAUDIBLE]. We are not on 22 platforms. That does help us on this. 

Our intentions is that we want to actually pragmatically, strategically make high performance runtimes for the platforms we do support. [INAUDIBLE]. Because we know we have to compete with Unity, Epic, Lumberyard, Crytek-- all the various systems. And so we have to have things are run as well and better. 

So speaking of [INAUDIBLE], there have been some interesting developments over the past years [INAUDIBLE] to pricing for engines where once, in order to get a high-end, AAA [? global ?] engine, you had to shell out a lot of money. And now that's no longer the case. Can you comment on what your thoughts are on this area, what it hints for the future of game engines and the industry as a whole? 

Sure. It's really complicated. Because either in the last two years we've been at Maxplay, as Dave mentioned, the cost of [INAUDIBLE] has changed [INAUDIBLE], even in the last few days-- has changed around a few times. Epic's pricing on Real has come down. I mean, there's still offering for higher end developers when they [? have it. ?] But people can use it for free and then pay back in. 

Lumberyard's available if you want to do Amazon services. Crytek has, please pay us some money or something system. [INAUDIBLE] figure out that business model [INAUDIBLE]. But perhaps it's all about services, which is a way you can make a lot of money. 

So in our case, we're looking at what makes sense. We [? have to ?] add value to it so that all the systems that are built around the engine, [? what makes ?] sense [INAUDIBLE] pricing. So it's complicated, as Mike knows, and it changes. It can change everyday. 

Yeah. 

So it is a very complicated topic. And first and foremost, as a game developer myself, I am ecstatic at the state of the market for engines and stuff like that. Back in the day, engines were super expensive. And that was one of the reasons that [INAUDIBLE] their own tech. Because you couldn't license all these really expensive engines. 

And as of a couple years ago, when the industry sort of overnight snapped and all of a sudden was like, hey, now, there are all these major contenders that are basically free, all vying for the markets and [? use ?] our product as their product. And as a developer, that's awesome. That is great. 

And so then, you have to start looking at, OK, so where does our value come from? So if now, we're saying, OK, we want as many people using our products as we can, how do we adjust for that? And we've taken on more of a services role, which again, we feel is very helpful to increase revenue gains for our developers and stuff like that. And we're really just trying to make great products that everyone can afford and use and stuff like that. 

But sometimes, it does get complicated. And more importantly, sometimes, even changes that are, at least in my mind, very positive, sometimes lose a little bit of messaging. And that leads to some confusion and maybe negative feelings. 

But amidst all this confusion, it's important to always know that we all have a passion for this. And we're all really trying to do good things for the industry and stuff like that-- messaging and products and stuff. We really try to make it so everyone can build just amazing software. 

And the bottom line is developing an engine is not easy or cheap. So someone has to pay for it in some way. And hopefully, you get a good value out of it. And so-- like I've had people come up and talk to me. And they [? run the ?] Unity model. The run the Epic model. They go back and forth on it. 

The reality is building yourself is a lot of work, a lot of work. If you've ever built one, [INAUDIBLE]. It's just a nearly endless amount of work, unless you're making a very, very small, specific demo. And even then, it's a ton. It's still faster to use an engine than it is to build it yourself, but not as sexy. [INAUDIBLE] go, this is the engine we built ourselves. 

If it works. 

If it works. 

You mentioned the support. So can each of you speak to what you currently do in the way of support and how we see the industry kind of evolving when it comes to that? 

Sure. So obviously, we're in a situation now as a game engine where we want people using our product-- obviously, right? That makes the most sense. And so obviously, we need to make it easy for that to happen. So we do, at least with Unity, we have forums. We have online learning and all that stuff that [INAUDIBLE] I have been a part of in the past. 

But what I think, for support, that it's just really, really amazing, especially coming from Unity, is just that the massive amount of people in our community, which is great. All these people that come together and they actually help support each other with these questions-- I don't even remember the number the last time we checked of how many active monthly users we have. But it's high-- hundreds of thousands, if not millions or something like that. 

And those are all the people using the product every single month and are on the forums. You ask a question. You get an answer. And you can't buy that. That takes building over many, many years. That doesn't just happen. 

And so support features, support software, support-- you know, fill out this form. We'll get back to you. Or call us at this number. We have this chat box. Those are all things that you can buy. But the community we have is something you can't buy, and it's something that's earned and built up. And in my mind, that is the most valuable asset that we have. 

We have traditional support stuff as a software company. However, the support that we can give to the community and the community gives to each other is just so, not only valuable, but as someone who's a part of that community, even before I worked at Unity and stuff, it's actually really awesome. 

Because it's just like hanging out with your people. And you're helping them. They're helping you. You're all learning stuff, and it's really cool. 

Yeah, [INAUDIBLE]. Game developers are-- theres' a broad spectrum of [INAUDIBLE]. There are people that call themselves noobs or just starting out. There are people that are veterans. In the past, it largely was all people that were like hardcore developers, that were insane coders, and knew every machine language [? possible, ?] and loved the PS3 because only the people that were super smart could work on it. 

And eventually, it kind of democratized. John can tell us [INAUDIBLE] where made our tools easier, and then people can get pretty good performance without having to know that much about the internal, the assembly and what's going on in the code. 

But there are still times, depending on your needs and your application, where you actually need to get down to the [? code. ?] That's also part of the reason why I talking about like, you have to have an engine that suits your needs well. If you need super high performance, you need a super high-performance engine. If you want the community and you're learning, now there's huge choices out there. 

[INAUDIBLE] back in the day, there was nothing you could download [? through an engine. ?] There was literally like you could go-- oh, here's a math routine for doing rasterization [INAUDIBLE] you need to start writing yourself. And you just had to build it all. 

And I love the fact that you actually get engines easily that work. You can get really good integration with tool sets like Maya and Max, and you can bring data in. And this really opens it up so that we have such a large variety of people that-- it isn't such a big barrier of entry to get into [? games ?] anymore. It used to be so high. It was literally kind of creating [INAUDIBLE]. 

So something you just said that I completely agree with is, no matter how great any engine's built, that it's not the right tech-- that it doesn't matter. You can cut down a tree with a hammer. I don't recommend it, but you can theoretically do it. 

It just takes a long time. 

So the right tech is very important. 

And on that note, so certainly in the past, it's been the case that people view certain engines as being for certain types of games, right? Like [INAUDIBLE] AAA games. Crytek is for games like Crysis. 

Would you say that that's still the case? Are engines more generic now where they can accommodate a wide range of games? What are your thoughts on that? 

Well obviously, there are people's opinions. There are precedents. There are a lot of little things that people don't see-- for instance, whether or not a game has the technology of the engine labeled on it. 

So a lot of games that come out might be built, say, with Unity or whoever. But unless you see that, made with whatever, or that logo during the splash for the game, you have no idea who made it. You have no idea of the tech. 

And I think it's just one of those things. It's a battle of public perspective and opinion more than anything. Yeah, there are these stigmas one way or the other. But there's the traditional way things have worked and people's opinions of certain techs or companies. 

And then there are a lot of actualities. And the true actuality is it's a lot more complicated than that. Yes, I personally think Unity is very good for indies. It's also very good for high-end games. But again, it's a constant battle of opinion and perspective. 

And I think that might be  one of the areas where you have a real advantage at MaxPlay is that you're so new. And there are no previous biases. 

There are not. But we do get asked that question all the time. They go, is it a first person shooter? Is it [INAUDIBLE]? Is it an outdoor engine? And we are largely making it so that it is basically very generic and you can plug it in [? any kind of system ?] as you want. 

But that's the way game engines used to evolve. I mean, Unreal was evolved because it was the engine that Epic used to make Gears of Wars and other engines. And they said, OK, this is an awesome engine. We should actually license it out to other teams. 

And then teams would use that as a foundation for what they wanted to do. That's a good step. Because if you start from scratch, it's horrible. But if you can take any kind of engine that's powerful and good and actually bend to your will yo make your game, you're well ahead. 

So in our case, like I said, people do ask us all the time, what's it for us? The answer is, you can pretty much do whatever you want. And we have all the generic stuff. And you draw triangles as you wish. Insert modules. Do this. Do that. 

And we integrate with a lot of other systems. [? We recommend ?] building everything. We integrate with an animation engine. We integrate with our [INAUDIBLE] particle systems. We're not building all that from scratch because it's just too much. But that gives us-- one, it's a super solid foundation that can actually work well [INAUDIBLE] high-performance underpinnings. 

It's also an important balancing act. Because the more generic a piece the software, the more universally applicable, the more it lacks certain oomph in different departments. And that is what it is. 

So you don't want to make it so generic that you can no longer compete at high-end. But you don't want to make it too specific that you can't compete [? against ?] many different types of games. And so it's a constant balancing act. 

The landscape is always shifting as new game play models come out, as new technology comes out and evolves, or new disruptive tech, or even new hardware-specific tech, like when Metal came  out. It was like, oh hey, now we've got to figure this thing out, and all that stuff. 

And there was all these constantly disruptive tech. And that needle on the gauge kind of moves back and forth pretty consistently all the time. And so one day, you might be the best at this pretty new thing. And then another day, you're not. So it's always just a constant struggle on valuation. 

And so if you're the type of person who just wants to label and say, this engine's for this, and this engine is for that, then I think you're missing out on some of the real value of an [? engine ?] that moves so very quickly-- is that at any given time, one engine, one piece of tech, one software, one hardware who used to be the best at this or the worst at this or whatever is now-- it's just completely shifted. And you need to be more agile, more flexible, to really take advantage of all the different high points as often as you can to be very successful, in my opinion. 

And I have seen a number of engines purposefully do demos or sponsor projects of different kinds of genres just basically, look, you can do this on an engine correctly, at least on a game. I've seen-- I know they've done pinball games. We would not have known that they can do pinball game with Gears of War. Of course they can. And it's a great game. 

That sounds like a great game. 

It was-- [INAUDIBLE] in pinball. But it's the kind of thing-- people automatically, they're trying to figure out, what's the best engine? What's good for it? [? They're ?] trying to kind of generalize-- well, I've seen it on this game. So therefore, it must be this kind of game. 

And you basically have to realize-- in some cases, game engines are very particular. But most of the modern engines are pretty good at being pretty much any kind of game you want do at this point. 

OK. We just have a couple minutes left. So we're not going to be asking more questions. I want to open up it up and see if any of you have questions for these two. 

We've answered every question you could possibly ever ask. Yes? 

Can you give us some specifics, as far as you know, what differences [INAUDIBLE]? And how does that impact [INAUDIBLE]? 

I don't think you can reliably expect us to give a non-biased answer to that question. 

That's fine. 

And I don't think any of us might be technically savvy in the other techs to really make a fair comparison. The question, for those who couldn't hear, is to ask us to say, OK, let's compare and contrast the different engine techs. 

I don't know if that's-- I mean, feel free to find me afterwards and we'll drink. I'll get drunk and I'll [INAUDIBLE] everybody for you. But [INAUDIBLE] up here may not be really a good idea to answer that question specifically. 

[INAUDIBLE] what are the strongest parts, in your opinion, and [INAUDIBLE]? 

OK, so obviously I feel the strengths are just amazing community, amazing tech, supporting so many platforms, just universal approaches to a lot of very difficult problems. As far as the negatives, sometimes our messaging gets screwed up a little bit when we're talking to such a gigantic community, which is, in my mind, really unfortunate. 

And then everyone is aware that Unity's garbage collector is not good. And we're working on it. I promise you we're working on it, but yeah. And so these are always issues when-- remember that you have to maybe be pretty strict on it. But so I would say that. But do you want to answer that? 

It's always [? going to be ?] around the same [INAUDIBLE] thing. The bottom line is it's really hard, if not impossible, to make something super easy and super ultra powerful at the same time. 

That's one of the reasons why-- as an engineer, you're  always like, wow, if I do this myself, I can  make this better. Because largely, you can. Because if you don't have to support 22 platforms, or you want to specifically go, I can spend the time optimizing for this one thing that I'm trying to do, you can rewrite large sections of things and throw away all the flexibility that makes it easy to use, and do that. So it's a very complicated balancing act to make something that's both easy to use and very powerful at the same time. 

I'll let you do it. 

That's fine. Go ahead. 

[? Why don't ?] you take [INAUDIBLE] the last question and make it a little bit more tangible. So we're a game developer. And we want something that we want something that we can quickly prototype. We want something where [INAUDIBLE]. Because I know that [INAUDIBLE]. You asked, why would we [INAUDIBLE]? 

Nobody [INAUDIBLE] on all of the [INAUDIBLE]. 

Yeah. What about if I wanted to quickly prototype [INAUDIBLE]? 

So-- 

I would, but-- 

So speaking as the CTO of a company who hasn't shipped their engine yet, I can say anything I want. So to be fair, in the past before I worked at MaxPlay, I worked at other companies which I mentioned earlier. And often, they would prototype with Unity, but they wouldn't do the [INAUDIBLE]-- depends on their needs. 

In many cases, they did. In some cases, they did not. But that was due to the prototyping practice. Then it was quick for them to do. But then they would realize, OK, we figured out what we want to do, but we don't think we can actually get it over the line with it. 

Now that has been changing in the last few years as Unity has gotten much better. But that's one of the things that does happen. Some engines are much more difficult to prototype with. So again, it depends on your needs. 

So we're a little over time. So rather than take more questions, I think we probably should wrap this up and move onto the next session. But feel free to chase any of these guys down afterwards to discuss this. And thank you very much for your thoughts and insights. 

Thank you. 

[APPLAUSE]