The workflows of indie developers and larger studio developers are much different, right?
RZ: I don't know. From some point of view, yes.
EK: But I think the larger teams using Unity benefit from the fact that they have an engine and tools already, and that scales down the team fairly massively, I would say. So they can still manage to develop games for consoles with a fairly small team. I think in some way we're defining what triple-A teams are, as well, by providing a very smooth toolset for triple-A developers.
RZ: Some people, now, in Unity, are coming from backgrounds working with big teams and big budgets, what you call triple-A. I think what you see, is you'll realize the workflow that big teams usually have, it's not like people are in love with this workflow -- these big teams. It's just that they're just rolling this way. For them it's easy to just say, "Ah. Well, whatever. We already invested one year in this workflow and everybody already knows. We don't need to optimize it to be more intuitive."
Usually how the big teams work, the people themselves are not really happy about that, usually. It's just that, "Well, it's good enough," and they continue. When it comes to Unity, we try to do it differently. We want when you work on a bigger projects, you feel the same indie feeling to it. When we talk even with very experienced people who are using Unity, they use this term "playful" or "fun." They actually feel work is fun now, instead of just being work.
EK: Most successfully within gameplay -- I think that's something in Unity [that] games that are growing in. It's not as outlined as it usually is in a triple-A project, that you document it first and then try to achieve that result. In Unity, I think, gameplay has a tendency to evolve in a more playful manner.
That's because of the tool?
EK: Yeah, I think so. Rather than building technology many times from scratch, they can start elaborating very early on, on the mechanics.
RZ: With things like that, it's probably more interesting to talk to actual developers than with us. They would probably explain it even better. But that is something we hear, from quite some experience with the work. They enjoy working in this way.
So, we kind of want to be the fuse -- with Unity, traditionally, it's easier to enter and easy to make a small game for indies. We want to at least drag as much as possible of that feeling towards the bigger teams. And then the big thing is functionality. We are more implementing [features] for the bigger teams, and dragging that towards a little bit more user friendly, and make it more indie-friendly, or smaller team-friendly.
It's making the high-end features accessible to indie people. Trying to mix things up, so these divisions are fuzzier.
RZ: Yeah. And I think you can see that nowadays. Quite a lot of people are going from triple-A to form their own studios and make some small games. Some small companies go to web and start to multiply, becoming bigger and bigger. You see lots of people going in both directions. It makes sense for us to try to blend between those two groups, and get the experience from them.
It's not like we have this certain goal to blend between or drag. It's something that happens naturally for us -- there is a certain amount of people very active in giving the feedback to us. We are working with certain teams, like Madfinger, that give feedback to us, and influence us in a natural way. It's not like we have this goal set, ourselves. It's more what we actually see happening.
Rather than competing with technologies like Unreal, it sounds more like you're looking at the demands of developers.
RZ: Yeah. That is something we want to do. We try not to look at them. I mean, there is no way you cannot look at that. Of course you see that, but we try not to overanalyze [and] just implement something because they have.
EK: Our overall goal is to always provide the smoothest and most easy-to-use tools for developers to make games, and we don't interfere with cultures or try to dig too deep into game design, or influence how game makers are developing their games, but more provide the means for them to make the games as quick, and flexible, and joyful as possible. We try to listen in as much as we can. It's a bit of a learning process.
It sounds like while you're not trying to dictate anything -- what you want to do is let them influence you.
RZ: To a certain degree, yes. Of course we have...
The classic quote you hear all the time lately is that Henry Ford said, "If I asked my customers what they wanted, they would have said a faster horse." So, you can't exactly…
RZ: Of course, you can't really. If we just listened to what people want, we would have to do everything in various ways. [laughs] It probably happens. We listen to feedback. But then we have certain ways to pick certain directions all the time.
EK: That's why these triple-A developers become a very good source for us to listen to, I think. They tend to have a lot of experience in using a variety of toolsets, and developing their own proprietary tools, maybe, before that. That's why it's a very simple way for them to directly communicate with us, and try to get those features that they're accustomed to into Unity.
I think it was [Unity COO] Nicholas Francis who said, looking at feedback, something along the lines of "people are looking for specific things, but what we have to do is take a step back and figure out how these things correlate." They might be asking for one specific thing, but if you go back a step, you can see that it's people asking for different things that can be encompassed by the same feature.
RZ: That is a plus. It probably was in the past more that way: at some point we were kind of scared what would happen if we had a big customer, and we didn't want to have two big customers who would influence us too much.
But once we had quite a lot of small customers, and nowadays we have various sizes of customers, and since we get quite a lot of feedback, we can see these general directions in certain ways. Like, bigger picture in some ways, which helps to rethink and maybe do something not exactly how people asked us, but something hopefully better.
EK: Something a bit bold. Something that we can continue building on as well. A feature that is a new take on it, but still will still supply the demands they have.
RZ: If you would look at our process, how many alpha phases and beta phases we have usually, for a certain product -- it's probably kind of public information, but if you're on the beta list you know how many iterations we go through.
Time-wise, it's quite a long process before the feature goes from alpha, being presented to some people, then to the bigger beta group, and then ends up in the public release. There's quite a lot of iterations, which we get feedback. We get almost complete feature functionality, and then people bang on it, try it out, give feedback, and we see if it makes sense for us.
It's a lot of iterations, where we're getting feedback and iterating on this. Of course, quite often, there were situations where we did something quite differently from what people expected, or what they wanted us.
At the end, what matters for us is to have actually good features and that people are using it. We didn't want to cater them specifically to cater for them. We wanted to solve a problem for us, most importantly. We want to solve a certain problem, and then people can use it.
Solve a problem in a way that creates an effective tool.
Regardless of how it's been done before, or if it's something people were anticipating.
RZ: Exactly. That is our ultimate goal, to achieve that.