Post

Folks have mentioned teams need to stick together over long periods, to make sure they can keep their knowledge and expertise and apply that to future games. This is true. Similarly, the tools & pipeline also needs to stick together. You cannot just grab an FPS game pipeline and make an RPG.

There are always tradeoffs to be made in pipelines. Some things will be easier, which will make other things harder to do. This is also a big reason so many different editors and engines exist: They all make different tradeoffs, and so different people prefer them for different projects.

Often times a studio gets to ask not to make the games they are good at, but instead to 'Fill up the portfolio' from the publisher. So the studio is asked to, for example, make a live service game even though the studio is very good at singleplayer games.

Sometimes this is reflected back on the studio, because the studio pitches a bunch of games, some of which they are very good at, but others they know their pipeline and experience isn't good for. But it's the publishers that greenlight. If they decide you do live service, now you have to do it.

This isn't just a problem for the experience of folks at the studio, who haven't made games like that before, but it's also the pipeline. For example: A cinematic FPS pipeline is very good and focused on first person perspectives, blending those into cinematics, and up-close environmental detail.

If you suddenly decide to make a live service racing game with that same FPS game pipeline, it will seem like it's functioning on the surface, but it's not. There are actually loads of workarounds present. Hidden workarounds. Those are Watermelons: www.youtube.com/watch?v=mQGO...

Because while you are able to use that code, suddenly for a racing game you have to re-adjust cameras, which also means adjusting the 3Cs, which requires a lot of testing and iteration for user adjustable camera angles: Third person, in-car, and front bumper. This is very time intensive work!

We have seen many studios run into these problems over the last few decades. Yes, decades. This is an ancient pipeline problem that somehow keeps being repeated, similarly to how well function teams getting separated despite it being an obviously bad thing to do.

I mentioned tradeoffs earlier: When you switch genres, suddenly the tradeoff discussions that you had about the pipeline 5 years ago, do not make sense anymore moving forward. You have to revisit literally years old code, to now make a different tradeoff. Which has a domino effect. It costs time!