What is the term for how much a game's code is coupled to its engine?

Question

Essentially, what is a word or phrase I might use/search for to describe how much the choice of an engine dictates the structure of your code, such as the language it is written in or the way objects much be structured, as well as aspects of what design patterns can be used or how assets are formatted?

For instance, Unity has a high amount of this coupling because, while it allows the use of C# (which runs on many platforms), it requires many object interconnections to be exposed as concrete classes and public member variables. GameMaker Studio is almost completely coupled in this way because it has its own proprietary scripting language and asset format.

Answer 1

I don't think there's a widely-used term for high coupling against game engines, yet. It is however analogous to Framework Coupling - search that term and you'll find a few blog posts discussing that topic, its pros and cons.

I suppose you could call it (Game) Engine Coupling, and most people should know what you're talking about. It's a less common problem for game developers, because compared to general software, there are fewer games that are ported across engines, or have code extracted from them, since few games last long enough to warrant that sort of thing.

Answer 2

I'm not sure there is a unique and easily-searchable term unfortunately; if there is, I haven't heard it regularly.

In my experience, people tend to anthropomorphize the code to arrive at a way to talk about this concept. That is, they will refer to the engine's "expectations" about data, "opinions" about inter-system communication, "design guidelines" about object modelling, and so on.

Typically these terms are referring to things you do not, strictly speaking, have to do (those would just be "requirements") but rather things that you should do, or things that if you do them will make your experience less painful.

You may also hear references to "best practices" within the engine; the concepts are closely related and possibly even overlap. If you're looking for a way to search online about how this concept applies to various potential engines or tools, "best practices" is probably the search term most likely to get you the results you want.

For example, the popular build system tool CMake expects you to list all your source files explicitly in its input files. While it has mechanisms that allow you to automatically glob a collection of source files, its opinion is that you shouldn't do that, and it works better when you don't (it correctly automatically regenerates projects when new files are added).