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...

It is very easy to look at a pipeline and say "You have code, you have node graphs, you have a VFX editor and a material editor, so just use those!" But that's inexperience talking! Anyone who has been in the depths of pipeline development will know this is not feasible without a lot of time.

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!

When entirely switching genres it can sometimes literally be better to build a new pipeline from scratch rather than use an existing one, because an existing one is a ball of yarn in which you now have to surgically insert yourself to fix the bit of yarn at the middle. Possible! But time intensive.