Wow, nice discussion and a lot for me to learn... :)

I tried to mix up some of your input with stuff I've got from literature and would be happy if you could give me some feedback on the result...(as you might have noticed: english is not my native language, but I hope it's readable) :P

The term "game engine" arose in game development in the first half of the 1990s.

By this time there was no compiler capable of translating a game written in high-level-language to machine code that would run on the slow processors of the available PCs and consoles at appropriate speed and fit into the low memory of those machines. To make games meet the speed- and memory-requirements they were programmed in assembly. So porting an existing game to an alternative hardware-plattform always required to rewrite its whole code to the assembly-language of the target system.

Nearly every game for PC and console by this time has a monolithic software-architecture. The parts of the code for game logic, rendering, etc. are highly interdependent and - together with graphics- and audiodata - form an entity which is hardly seperable. To maintain (debug / optimize) such game-software gets increasingly time- and cost-intensive with the amount of code. Due to the dependencies between the parts of the code they are game-specific and thus not reusable for the development of a new game without further effort. So the development of a new game, except for the low amount of reusable code from existing games, mostly starts from scratch.

[to be continued...]

Best regards

koS.

i think there should be made a distinction between reusing code and using a game engine. In theory you can use a game engine without needing access to the code, right?

i think there should be made a distinction between reusing code and using a game engine. In theory you can use a game engine without needing access to the code, right?

For my understanding "using a game engine" is a major kind of reusing code, i.e. by using the physics-system of a game engine you reuse the code you or some other wise fellas wrote in advance. :)

"By this time there was no compiler capable of translating a game written in high-level-language to machine code that would run on the slow processors of the available PCs and consoles at appropriate speed and fit into the low memory of those machines. To make games meet the speed- and memory-requirements they were programmed in assembly."

No, this isn't true. Some games were written in C during the late 80s, especially on the more powerful platforms. Many were not. But you can't truthfully say "no compiler" could make games that ran at "appropriate" speed, and especially not in the early 90s.

It's also not entirely true to say that porting an old game - even one written in assembly - required a complete rewrite. Lots of home computers in the 80s ran on either a Z80 processor or a 6502 processor - as such, you could port between machines that had the same processor relatively easily, e.g. by changing the graphical routines and other I/O procedures.

You probably mean "At this time", not "By this time", too.

Wow, nice discussion and a lot for me to learn... :)

I tried to mix up some of your input with stuff I've got from literature and would be happy if you could give me some feedback on the result...(as you might have noticed: english is not my native language, but I hope it's readable) :P

The term "game engine" arose in game development in the first half of the 1990s.

By this time there was no compiler capable of translating a game written in high-level-language to machine code that would run on the slow processors of the available PCs and consoles at appropriate speed and fit into the low memory of those machines. To make games meet the speed- and memory-requirements they were programmed in assembly. So porting an existing game to an alternative hardware-plattform always required to rewrite its whole code to the assembly-language of the target system.

Nearly every game for PC and console by this time has a monolithic software-architecture. The parts of the code for game logic, rendering, etc. are highly interdependent and - together with graphics- and audiodata - form an entity which is hardly seperable. To maintain (debug / optimize) such game-software gets increasingly time- and cost-intensive with the amount of code. Due to the dependencies between the parts of the code they are game-specific and thus not reusable for the development of a new game without further effort. So the development of a new game, except for the low amount of reusable code from existing games, mostly starts from scratch.

[to be continued...]

Best regards

koS.

I'd take issue with most of this as being, basically, incorrect and unsubstantiated. It will probably be good enough for a school project or something, though.

The term "game engine" was used well before the 1990s. The term comes from analogy with the engines that drive cars, which were around for quite some time, and thus the comparison was readily available. The 1990s are simply when the term started to become popularized outside the industry itself, with the advent of more public licensing of studios internal engines as middleware and the like.

We were definitely using high-level languages in the 90s, even for consoles, although perhaps not everywhere and for everything. Games were not written 100% in assembly and thus porting them did not require rewriting the entire thing; porting was still difficult for other reasons, however.

I also take issue with the statement that "nearly every game had a monolithic architecture" and that everything was "highly interdependent." Also with the statement that this game-specific conglomerate was not reusable (it often was, in many ways, as has been pointed out several times in the thread). There are, in fact, NES games where it is very obvious that huge portions of another game were reused to make a new one. Sunsoft's games (Batman and Shatterhand, for example, and Blaster Master and Fester's Quest) share significant codebases.

The term "game engine" arose in game development in the first half of the 1990s.
By this time there was no compiler capable of translating a game written in high-level-language to machine code that would run on the slow processors of the available PCs and consoles at appropriate speed and fit into the low memory of those machines. To make games meet the speed- and memory-requirements they were programmed in assembly. So porting an existing game to an alternative hardware-plattform always required to rewrite its whole code to the assembly-language of the target system.

As several of us have said, although the term 'game engine' may have been coined by some wordsmith in 90s, game engines were in use from the early days from the early 80s, and probably earlier in terms of arcade machines.

Overall I think your timescales are off by about 10 years:

Here in the UK the first home computers were the sinclair ZX80 and ZX81, former of which had a massive 1K of memory. The games market only took off with the 16 / 48K sinclair spectrum (late 1982?), the BBC micro and the C64. From the outset games on the spectrum were often in a series from writers, obviously reusing components. Examples include manic miner -> jetset willy, ultimate (now rare) games, etc etc. There were even text adventure engines, such as 'the quill' which a couple of friends sold a game with, without writing any code. As I understand it from an old boss who was active in the 80s, they often developed on a more powerful computer with more RAM (perhaps even a different CPU, I'm not sure). I'm sure there will be people on here who worked professionally in that time, and can fill you in.

Although I personally had a hiatus in the late 80s / early 90s, I have no reason to believe there weren't decent compilers available at this time, for C and pascal (the Amiga users will probably know more), and I suspect the transition from mainly assembly to higher level languages mixed with assembly may have taken place earlier than you suggest:
https://en.wikipedia.org/wiki/History_of_compiler_construction

Certainly I remember playing with compiled turbo pascal, pascal on unix, borland c in the early 90s I guess? There were loads of interpreted higher languages from 1980 (basic mainly) in built to the computer's ROM, so having them compiled isn't a stretch, especially seeing as C was invented and compiling in 1969-73.

Nearly every game for PC and console by this time has a monolithic software-architecture. The parts of the code for game logic, rendering, etc. are highly interdependent and - together with graphics- and audiodata - form an entity which is hardly seperable. To maintain (debug / optimize) such game-software gets increasingly time- and cost-intensive with the amount of code. Due to the dependencies between the parts of the code they are game-specific and thus not reusable for the development of a new game without further effort. So the development of a new game, except for the low amount of reusable code from existing games, mostly starts from scratch.

This is conjecture .. from when I started in the early 80s there was separation of logic / assets / routines and a heavy emphasis on reuse. It has always been this way, afaik, aside from a few 'my first hello world games'.

There were also networked games long before the internet. We developed multiplayer games on BBC micros using the school's econet, this would have been around '85 / 86, and used hardware scrolling by changing the screen memory address.

@Kylotan

I actually got this from "Game Architecture and Design" from Rollings and Morris. They write about the 80s "There were no good C compilers then, and the few that did spring up did not produce code small and tight enough to be usable for games. This meant that porting a game to another platform required a complete rewrite." and later on "Doom heralded the beginning of the C era of game programming. Watcom, the makers of the C/C++ compiler used to write Doom, must have experienced a huge boost in sales...". So I thought it would be ok to write "no compilers". :/

@Josh

I understand your opinion but I can't rely on any experience in the game industry of the 90s and so I have to trust books and acknowledge the information I get from experienced people like you guys. :) I'll write that the term "game engine" arose in game development and became popular in the 1990s then. As both of you don't like the "assembly only"-statement I'll try to relativate this a little. You actually don't like the whole second paragraph, though... :) I don't say that nothing of the game-specific conglomerate was reusable but that it required further efford to get reusable parts from it. About the "monolithic architecture"- and "highly interdependent"-parts: I think it was Gregory in "Game Engine Architecture" who wrote that DOOM was the first games that made a clear separation between engine-specific code (rendering, etc.), game-specific code (game logic) and art assets. So it should have been one of the first games who had a component-based or modular software-architecture and most of the earlier games had a monolithic-structure for my understanding... :/

@lawnjelly

Thanks for your comprehensive and interesting input. I actually wanted this text to be short...some kind of "opener" but by all feedback I got from you guys I start thinking that "digging in the history of game engine" (:D) is a dangerous endeavor that can't be handled within two paragraphs. Maybe I would be better off taking DOOM-engine as an example and go on to "modern game engines"... ;)

Best regards

koS.

I understand your opinion but I can't rely on any experience in the game industry of the 90s and so I have to trust books and acknowledge the information I get from experienced people like you guys.

I'm not stating opinion, your assertions are factually incorrect.

About the "monolithic architecture"- and "highly interdependent"-parts: I think it was Gregory in "Game Engine Architecture" who wrote that DOOM was the first games that made a clear separation between engine-specific code (rendering, etc.), game-specific code (game logic) and art assets.

He'd be wrong about that. It is absolutely arguable that DOOM was not the first to do this.

So it should have been one of the first games who had a component-based or modular software-architecture and most of the earlier games had a monolithic-structure for my understanding... :/

No, this doesn't follow logically from the previous statement (even assuming the previous statement were true). There are more ways to build software than "monolithic, everything depends on and is coupled to everything else" and "component based." There is a huge continuum there and we as an industry have move along it nonlinearly and smoothly over time. The concept of these discrete jumps that you see referred to like in Gregory's book are just oversimplification to structure another point or hyperbolization.

You need to find a few more sources before you make your write up. The text you have written as pointed out is factually wrong. People have already pointed out that there were a multitude of games written in C in the mid to late 80s and early 90s well before DOOM.

Also just because a game was written in Assembler does not mean that a port required a complete rewrite. The majority of Amiga games were written on the Atari ST and then ported (unfortunately this meant that there were a lot of games that didn't utilise all of the Amiga special tricks :( ).

As for DOOM being the first game to separate engine code from game code this is just plain completely untrue.

If you are going to write about this stuff then you need to do some actual research and not just rewrite a paragraph from a book that seems to be incorrect in the first place.

Well, I actually did a lot of literature research but there are not many books or scientific papers that cover the entire history of game development and those who do it don't focus topics like reuse or game engines. I could name you a few sources that state that there was little to no reuse and developers didn't even aim for reusability before the 90s. At least the last statement didn't make it to my text as it felt too wrong for me. ;)

I thought I could point out when the first reusable game engine was established and how game development changed with reusable game engines but this seems to be quite impossible - especially if you have to do it in about 5-10 lines of text. I'll think about another "opener" for my text as I don't want to write something that's oversimplified and factually wrong.

But another question: How comes, that Space Rogue / Ultima Underworld or DOOM are often said to be the first games that based on a reusable game engine? Was one of those maybe the first licensed engine or the first 3D game engine?

I'd like to thank all of you guys for your input so far... ;)

Best regards

koS.