I know a bit of C++ and know about modern engines and libraries and am interested but don't know much of it.

I've noticed that back in the day when assembly was almost the standard for developing games (Nes, Genesis, Snes) that there were barley any shared engines. The only thing I've heard of is that Batman Forever on SNES and Genisis used Mortal Kombat's (Genesis port's) engine, and Super Noah's Ark 3d using Wolf 3d's (Snes port's) engine, but I imagine those games were programmed in C.

It makes me think it was because game engines, libraries, reusable/recyclable functions are not possible in assembly unlike C/C++ etc, but please correct me on whatever I'm wrong on, and if there's such thing as shared engines, libraries etc in assembly some examples or mentions would be nice.

There's nothing special about assembly that prevents you from making reusable functions, data types, etc. There are assembly developer tools such as MASM and NASM that let you simplify/reuse things more easily.

Transport Tycoon and Roller Coaster Tycoon were both supposedly written primarily in x86 assembly, though I'd wager only reusable functions involved in input and rendering were reused (those games both used pure software rendering).

Also, consider precompiled .lib files (static libraries). Regardless of their original language, they're in machine code now (Machine code is typically just a direct binary encoding of assembly language). The library is still usable by any language that is compatible with the library's ABI.

A lot of DOS games were also written in a mixture of C and assembly, where C was used for the logic and inline assembly was used for rendering, etc.

I wrote my own library in assembly using TASM for doing drawing operation which worked faster than the native graphics library that came with Turbo-C++ and I used that in several small games that I wrote.

All those developers who wrote games with assembly for nintendo and co did that because hardware was very specific, which is why nintendo should have developed their own high-level language compilers, which they clearly cba to do. The development process in which high-level language utilized goes a lot faster than that based on assembly.

All those developers who wrote games with assembly for nintendo and co did that because hardware was very specific, which is why nintendo should have developed their own high-level language compilers, which they clearly cba to do. The development process in which high-level language utilized goes a lot faster than that based on assembly.

To be fair, its a very different thing, and a lot more straight forward, to write asm for 8 and 16 bit processors, then it is for a modern processor, but implementing something like a C compiler on 8 and 16bit processors isn't very efficient.

With limited memory and resources the push for high level languages wasn't that big.

The Lucas Arts Adventures like Monkey island and Day of the tentacle used a virtual machine called scummVM. Actually I don't know if they used assembly for the engine but given the time I'm pretty sure large parts of it were written in ASM.

Also, Another world (Out of this world) was written as a virtual machine and could thus be ported to a lot of different platforms.

It makes me think it was because game engines, libraries, reusable/recyclable functions are not possible in assembly unlike C/C++ etc, but please correct me on whatever I'm wrong on, and if there's such thing as shared engines, libraries etc in assembly some examples or mentions would be nice.

There is actually a fundamental reason which caused this more than anything else. Let me first mention that I'm doing this on vague memory from the way back machine, so the details may be off, please don't nuke me for such mistakes too much.. :) Anyway, take a platform such as the Super Nintendo and go over the spec's for the CPU and memory. The processor was basically a 3.5Mhz split 8bit/16bit machine. In general this was simply the 6502 instruction set enhanced with 16 bit registers and if I remember correctly a 16bit multiplier. The problem here is the 3.5Mhz clock rate which directly maps to how many instructions could be processed per second and the lack of registers (only had accumulator and x/y index registers for general usage) exaggerated the problems. Unlike current CPU's where clock rates don't map directly to instructions per second due to pipelining, caching etc, there was no pipelining or cache on that CPU and as such the clock rate directly mapped to the number of bytes of memory which could be read and that mapped directly to the number of instructions which could be processed. (NOTE: zero page could be considered cache as it was faster to read/write from, but you had to manage it manually.)

You could basically fetch or store 3.5 million bytes of memory per second. In the case of a simple NOP (0xEA opcode, I'll never forget that one) instruction this meant the CPU loaded the piece of memory pointed to by the PC, incremented the PC and setup the instruction processor on the first cycle. The second cycle of the instruction performed the actual NOP work, which of course did nothing. So, you have just split the 3.5 million clock cycles in half to 1.75 million per second with the fastest "do nothing" instruction on the CPU. Most instructions could take significantly more clocks and as such you generally ran less than a million instructions per second. So, using round numbers, assume your typical code could run 300,000 instructions per second, average of about 3.5 cycles per instruction which is somewhat realistic as I remember it, and you want to target 30FPS, you have only 10,000 instructions to use each frame. Oh, but there's still more loss, you have to update any hardware/graphics typically only during the vertical blank or you cause tearing and other undesirables and of course there are interrupts etc taking up some of those instructions. So, you might only be able to use 7000 instructions per frame and still hit 30FPS.

So, why were the engines not made reusable and generic? Quite simply because any *generic* code was refined down to do only exactly what was needed in order to fit into the hard limits required to maintain a given framerate. In the process of refining the code you are obviously removing any concept of generality involved. There really were no other reasons, it wasn't a language issue and no compiler could touch the required level of optimization, it was just the only practical way to do things at the time with the available tools.

All those developers who wrote games with assembly for nintendo and co did that because hardware was very specific, which is why nintendo should have developed their own high-level language compilers, which they clearly cba to do. The development process in which high-level language utilized goes a lot faster than that based on assembly.

At least in the case of the NES and SNES, development in high-level languages is unrealistic, owing to low clock speeds (1.79 MHz and up to 3.58 MHz, respectively), limited register counts (1 general-purpose and 2 index registers), small stack space (256 bytes for the NES, up to 8 KB on the SNES), and in the case of the NES small RAM (only 2 KB) and compiler-unfriendly bankswitching to increase the effective address space.

It's no coincidence that the first console to see significant use of high-level languages was the Sega Genesis, whose 68000 CPU has a much more compiler-friendly architecture. (For example, some Genesis EA sports titles were programmed in Pascal rather than assembly.)

I know a bit of C++ and know about modern engines and libraries and am interested but don't know much of it.

I've noticed that back in the day when assembly was almost the standard for developing games (Nes, Genesis, Snes) that there were barley any shared engines. The only thing I've heard of is that Batman Forever on SNES and Genisis used Mortal Kombat's (Genesis port's) engine, and Super Noah's Ark 3d using Wolf 3d's (Snes port's) engine, but I imagine those games were programmed in C.

It makes me think it was because game engines, libraries, reusable/recyclable functions are not possible in assembly unlike C/C++ etc, but please correct me on whatever I'm wrong on, and if there's such thing as shared engines, libraries etc in assembly some examples or mentions would be nice.

What you're seeing is largely due to the fact that the idea of a "game engine" is relatively new in terms of game development - in the era when games were predominantly programmed using assembly, people didn't really talk about "engines" per se.

Part of this is that people didn't really talk much about "engines" before the era of 3D games and especially before the 21st century, where the sheer amount of code that can be reused from game to game increases drastically (due to 3D graphics being far more code-intensive than 2D graphics) coincidentally more general-purpose solutions become feasible (due to increased RAM and more powerful processors). Another part of it is that what we now call using an engine was just called code reuse back then, and was as a rule done in-house rather than with engines licensed from 3rd parties.

But make no mistake, large amounts of code were reused. For example, Square released 3 Final Fantasy games on the Famicom in Japan, and all three share significant amounts of code*. Square's SNES RPGs also have a lot of code in common. Super Mario Bros, Metroid, and Kid Icarus share code. Most Capcom-made NES games are built on one of two code bases depending on when they were developed.

As a general rule, any game made in the 8- and 16- bit eras will share a decent amount of code with other games from the same developer on the same platform (Batman Forever on SNES and Genesis and the Genesis port of Mortal Kombat II, which you mentioned, were developed by the same studio, Probe Entertainment), and this trend increases in the early 3D era up to the modern day where many games are built upon large collections of general-purpose code - which we now call "game engines" - that are often licensed from other developers (much like Wisdom Tree licensed the Wolfenstein 3D SNES code from id software to make Super Noah's Ark 3D).

---

* This includes, for the first two, segments of code that serve only as placeholders for English-language ports - one of which never got made. The NES port of Final Fantasy uses different bankswitching hardware than the Famicom original. The Famicom games have code that does nothing in the Famicom version, but can be easily changed into code that controls the bankswitching hardware used in the NES version of Final Fantasy without changing code size or performance.