I wonder why we call things "frameworks" in web design but "engines" in game design. Any ideas or am I totally missing the distinction between these terms?
Engines are significantly higher level than what we call frameworks in web dev, with a lot of stuff built-in and coding being a minor requirement. Traditionally they were even genre-specific: fighting game in case of Mugen, shooter in case of Quake and Source, etc. Also, in the case of Mugen, they are mostly data-centric rather than code-centric like a web framework.
Another interesting distinction is that engines can often written in one language but offer extensibility in another, like being written in C++ and having programmers write Lua or C#. Notable exceptions exist, however. In frameworks that's quite rare I guess.
In addition to the high vs low level comments, I think another helpful connotation of the "engine" term is that you're often dealing with things that happen per frame, with many frames a second. The concept of an "engine" pumping out all these frames can be helpful.
This isn't to say that you don't write code which runs at framerate with a web framework, but often this is abstracted behind layout and user interaction concepts.
It's the opposite. A game engine is a higher level piece of software, that often requires less coding (and in certain cases almost none) than what we call framework in other development areas. Modern engines also often come with complete tooling.
However, most game engines are highly extensible, which naturally means that people will build libraries targeting those engines, for doing very specific things.
Comments
I wonder why we call things "frameworks" in web design but "engines" in game design. Any ideas or am I totally missing the distinction between these terms?
Engines are significantly higher level than what we call frameworks in web dev, with a lot of stuff built-in and coding being a minor requirement. Traditionally they were even genre-specific: fighting game in case of Mugen, shooter in case of Quake and Source, etc. Also, in the case of Mugen, they are mostly data-centric rather than code-centric like a web framework.
Another interesting distinction is that engines can often written in one language but offer extensibility in another, like being written in C++ and having programmers write Lua or C#. Notable exceptions exist, however. In frameworks that's quite rare I guess.
In addition to the high vs low level comments, I think another helpful connotation of the "engine" term is that you're often dealing with things that happen per frame, with many frames a second. The concept of an "engine" pumping out all these frames can be helpful.
This isn't to say that you don't write code which runs at framerate with a web framework, but often this is abstracted behind layout and user interaction concepts.
removed.
It's the opposite. A game engine is a higher level piece of software, that often requires less coding (and in certain cases almost none) than what we call framework in other development areas. Modern engines also often come with complete tooling.
However, most game engines are highly extensible, which naturally means that people will build libraries targeting those engines, for doing very specific things.