[atinoda-kestrel]

> I think that game studios have the right model: Hire full-time tools engineers and task them with making the tool-users more effective.

That's one approach, but it's not always the right one. It's only really necessary if your studio's selling point is pushing the limits, tech-wise. If your focus is the gameplay mechanics and engine and art are secondary to that, then focusing on tooling is more of a distraction than anything else. Hence why Unity and the now-quite-cheap UE are sane choices, since they let people focus on the gameplay.

General purpose software has the same pitfall that games do: people see the big studios/development companies spending a lot of time on tool-building, and they assume that's a prerequisite, which changes the mental model from "we need to start building the next cool _____" to "we need to build the tool(s) that will let us build the next cool _____". And that's a much more expensive model.

I think it's easy to get sucked into that trap for another reason too: developers know what developers want more than developers know what users want. That's why I agree with the last paragraph you wrote, that user involvement is key. I just think that companies need to be careful that they're not simply redefining users from "users of our core product" to "developers of the tools that will let us build our core product", since there's going to be some natural internal bias that way.

[bananaboy]

With Unity, that's a common misunderstanding. Unity provides nothing aside from an engine and a very open, flexible editor. The editor gives you a way to put game objects in the world and add script components to the game objects and that's pretty much it. If you don't build tools for the level designers you end up with a mess of bespoke game objects with random components. It's very easy to end up with messy Unity projects that are hard to debug and don't perform optimally (I've seen quite a few).

If you want to build something of a high quality in Unity you need structure and rigidity, and you need level designers and artists to follow guidelines and processes. So you still need tools and tools programmers. You might not have an entire team building an editor, but you need something (and it's very easy to build custom editor tools inside the Unity editor).

[atinoda-kestrel]

> So you still need tools and tools programmers. You might not have an entire team building an editor, but you need something (and it's very easy to build custom editor tools inside the Unity editor).

No disagreement there. I just meant that you don't need to start from a blank canvas and start in on engine, editor, etc. development just to get to the point where you can do good game mechanics. Obviously even if you use a canned engine you'll still need to do some work to get your asset pipeline squared away (just as how everyone needs to do a bit of scripting/config, etc. specific to their build process for example.)

I guess I didn't explain it well, but I was trying to contrast to the web world where people [seem to] very often look at places like Facebook rolling their own frameworks and saying "we need to do that to be good!" and thus literally go on to start from scratch.

[brandonbloom]

React as Relay/GraphQL aren't from a blank slate either. Hell, nothing really is. How much to invest in what level of tooling is, as it should be, a function of what already exists, what you're trying to build, and what resources you have at your disposal.