Why does Unity have no official gameplay framework?

Question

As a generalist developer, I have made many server and backend apps and also client-side UI apps. Most of these environments have a certain architecture. For example, in most backend apps, even in different languages, we have MVC that helps us structure the project in many different types of projects.

Probably you may say that frameworks make a developer limited. But they make developers much faster, as they don't need to think about architecture. They also reduce mistakes of the team as they prevent overlapping mistakes and reading the code as different projects have same standards.

I recently started using Unreal, and it seems that it follows the same rule. For example, it provides the gameplay framework. Classes like GameState, GameMode, and CharacterController are part of the gameplay framework that forces the developer to write code in the right place.

Why does unity have no such official framework? There are many plugins and tools that are written for Unity, and all of them provide different approaches.

Some examples: Zenject, VContainer, and... for dependency injection, DI helps with loosely coupled code, but many believe that it slows prototyping. So still singleton and Service Locator.

There are many different types of MVC and MVVM frameworks that work completely differently. Recent Unity NetCode official tutorials have used VContainer for DI, and they answered me it's because the system lacks a good framework.

Answer 1

1. There's no one-size fits all system.

For example, you use MVC for your backend. Other teams might use MVP or MVVM or HMVC or MVA...

Unity attempts to be as flexible as possible. In some cases this means not including a built-in implementation of something because there's no one solution that will work for everyone. In other cases, when they do attempt to build a system that works for everyone, they end up with very complex packages that have a higher performance cost and are difficult to make changes to.

2. Growing pains

Unity started out as an indie engine targeting indie developers of various skill levels. They entered the market as a less expensive alternative to existing engines like Unreal and started with a much smaller feature set than what they have today.

As time has passed, bigger studios have been licensing the engine for bigger projects and with bigger expectations. The Unity team is now scrambling to add new features and overhaul legacy features that don't scale well or meet modern expectations. They've encountered a variety of issues from trying to grow too fast, such as feature fragmentation and systems that just don't work well together.

3. Limited resources

Hand-in-hand with the previous point - the Unity team only has so many staff members they can allocate to so many features. If you asked around in the Unity community, I think you'd get a general consensus that the Unity team is already trying to develop too many things at once. Many features already languish and die in the "Experimental" phase. Adding a general gameplay framework would mean one more thing that they have to allocate developers to, and one more thing they'd be getting complaints, feature requests, and bug reports about.

4. Backwards compatibility

These days, the Unity team tries very hard to maintain backwards compatibility with legacy projects. In my personal experience, migrating a project from Unity 4 to Unity 5, or Unity 5 to Unity 2017, is an absolute nightmare. However, upgrading from 2017 to any newer 20xx version is much easier.

Of course, this is a double-edged sword. Backwards compatibility allows games to be upgraded to newer versions of the engine so that they can be published on the latest platforms. However, it means that the Unity team is stuck supporting legacy features, and afraid to make major changes that would improve the engine but break backwards compatibility.

5. The Asset Store

The Asset Store is a core part of the Unity team's business model. Features that aren't built into the engine can be developed by third parties and sold on the Asset Store, where the Unity team gets a percentage of each sale. This gives the Unity team some incentive not to build certain features into the engine, because then the relevant asset packages would stop selling (and the creators of those packages might be very unhappy).

That said, they are gradually adding new things to the engine that used to only be available from third parties, and occasionally adopt a third-party asset as an official engine feature (e.g. TextMeshPro).