Questions about porting games in general

[digitallogic]

There are many games that were featured on all systems back in the '90s, most commonly sports games, but there were others, like Mortal Kombat, DOOM, etc. I know the Doom engine was portable, but I don't know what engine the original Mortal Kombat games used. When I tried to find it, all the results were about the newer versions. All I could find was that the new Mortal Kombat 1 used Unreal Engine. The closest I could find was this site. It just says gameplay engine.

I have always been curious about the relationship between game engines and console designs. My first question is, were game engines designed from the beginning to be able to be ported to all the other systems/consoles? Were consoles designed to be compatible with existing game engines? This goes hand in hand with the first question.

I've just always wondered how game devs were able to design a game so that it runs on so many hardware architectures. My second question is, how were they able to port a game that was already designed or in progress to a console that didn't exist before they started making the game?

My third question is what exactly determines the portability of games? Like, how would you make it so that it can be ported to say the Saturn, the PlayStation, and the N64? Does the game engine determine what it can be ported to?

I would be grateful for any expertise on this. 🙂

 

[digitallogic]

I started looking up different topics, and found some information about old graphics systems. I learned that they didn't use any portable graphics libraries back then, and they didn't port the games. They had multiple projects going on simultaneously for each platform. That's a major bummer. Well I guess I can forget about making a game that can run on multiple consoles 🙁

 

[sonichu]

Doom was written in C with portability in mind. Mortal Kombat was written in assembler for the arcade cabinet.
Before C got widely adopted around 5th gen typically, if you wanted an engine that would be easy to port, you would write a virtual machine. So then you would just have to port this VM instead of each particular game, but you paid with the performance.
Though some systems were quite alike so you could use the same codebase with differences just in video and sound output and controller input. For example ZX Spectrum, CPC, MSX and SMS were all Z80 systems. Amiga, Atari ST, X68000 and Genesis were all 68k systems and Jaguar had it as a support chip.
Commercial multi-platform engines started to show up with the 5th gen.
Today, to write a multi-platform game, if that's your goal, like Tetris or PacMan or whatever, you could use available libraries or engines like Turbo Rascal for the older systems - YouTube or BennuGD for PS2/Dreamcast - YouTube
They tend to be kinda wonky though. Bennu is a pretty slow and buggy VM.
Or just write it in C and keep the limitations of the target systems in mind, like resolution, palette, fixed-point math, etc. and periodically port it over to the primary target when you hit milestones. And then to the rest.

 

[Jasvy]

I think you are trying to fit a modern development concept into machines and years where that concept just did not exist yet. The concept of "engine" is something developed during the 90s. An engine is a framework that provides common tools to make things happen. For example, Unreal Engine provides the tools so the developers can focus on what they want to do instead of how to do it. They use the engine to do things and the engine makes its magic to create code so that things are done on the machines where it is supported. Is more complex than that, but you can make you an idea.

An engine is not the best way to do anything if you want raw performance. But in modern hardware is the way to go, because it is preferible to have easier tools to work. You sacrifice performance, but the development procedure is easier and affordable in time and cost. Some companies create engines for specific machines, as Sony has done recetly in some of their first party projects. That way the performance lost is lower. Usually, the wider the spectrum of different hardwares supported, the lower it performs on each server. Keep in mind that modern hardware is madly powerful, so you can afford to lost performance. Nowadays games are incredibly complex, and you need to keep technical things as easy as possible.

But that was not the case for 8 and 16 bits machines. Back in the day, developers usually coded in raw assembler code. This is the way if you want (if you need) to get every piece of power the machine is capable of. The fewer layers between code and hardware, the higher performance. So there were no comercial "engines" as we know it today. I think the first time I listened that term was applied to Doom. Obviously there were other "engines" before, and some teams had common tools to make games. Developers recycled assets and sometimes you could see that a game is a previous one with some changes. Some old 3D games had to implement engines as well. But the concept is not the same.

So, I thing the answer is that Mortal Kombat does not have an engine as we understand it today.

 

[Jasvy]

That is the reason why 8/16 bit multiplatform games look so diferent in diferent consoles or computers. They were just re-developing for each one. If the original hardware was close to the new one, you were lucky, and the port could be close (in the case you had access to the original code and assets). If not, then you could have major diferences. But that was part of each hardware soul, and each port could have its own highs and lows. I love it.

 

[Tiviat]

There are many games that were featured on all systems back in the '90s, most commonly sports games, but there were others, like Mortal Kombat, DOOM, etc. I know the Doom engine was portable, but I don't know what engine the original Mortal Kombat games used. When I tried to find it, all the results were about the newer versions. All I could find was that the new Mortal Kombat 1 used Unreal Engine. The closest I could find was this site. It just says gameplay engine.

I have always been curious about the relationship between game engines and console designs. My first question is, were game engines designed from the beginning to be able to be ported to all the other systems/consoles? Were consoles designed to be compatible with existing game engines? This goes hand in hand with the first question.

I've just always wondered how game devs were able to design a game so that it runs on so many hardware architectures. My second question is, how were they able to port a game that was already designed or in progress to a console that didn't exist before they started making the game?

My third question is what exactly determines the portability of games? Like, how would you make it so that it can be ported to say the Saturn, the PlayStation, and the N64? Does the game engine determine what it can be ported to?

I would be grateful for any expertise on this. 🙂

MK Character cards

..Fek..has it REALLY been THAT long ago !!!! The character card, was probably just a scan of a page from that awesome short lived Mortal Kombat 1 comic book. But as they have said, even if you get ahold of all of the assets(all of the backgrounds and character sprites and text sprites), you'll be totally stuck with translating assembly on both of the porting ends of development. Btw, your best bet would be to obviously get ahold of the Genesis code(if you only could that is).

I started looking up different topics, and found some information about old graphics systems. I learned that they didn't use any portable graphics libraries back then, and they didn't port the games. They had multiple projects going on simultaneously for each platform. That's a major bummer. Well I guess I can forget about making a game that can run on multiple consoles 🙁

They had no real choice but to have the project going for all platforms back then, because all of those "engines" had to be literally translated in proper running assembly on like 3-5 different platforms. No pretty C compilers back then like GNU, or VS Code or even Visual studio. All those guys probably had to write individual tools to handle each type of component..first....and then it had to spit out assembly in that cpu's specific language and sprite data. It was completely crazy....to not only create the tools to do crap, but then had only various assembly languages to learn and utilize in a specific deadline. The Disney's Aladdin game was a prime example of a custom job for both consoles. The SNES couldn't handle the sheer compuatation of the Disney sprites on the MD, so they had to let someone else do the SNES version. However, the SNES clearly had a better music score.

....We don't really have to do that anymore with the modern tool chains we have now. All we have to do is create a bunch of stuff, and stuff it down the mouth of a particular toolchain, and shove it out the door(sort of). And then see how it runs and optimize accordingly if needed. However, doing it their way, creating custom tools allowed for them to start optimizing from the beginning of the project start, versus forcing the toolchain to do it for us. So I'm kinda in favor of their particular way of game development as it allowed them to make miracles😀

 

[Tiviat]

That is the reason why 8/16 bit multiplatform games look so diferent in diferent consoles or computers. They were just re-developing for each one. If the original hardware was close to the new one, you were lucky, and the port could be close (in the case you had access to the original code and assets). If not, then you could have major diferences. But that was part of each hardware soul, and each port could have its own highs and lows. I love it.

Alot of the differences between the 16-bit MD/Genesis and the SNES/SFamicom versions of games, was because Sega thought it was a good idea to basically attempt to shrink down the mega popular 68k/Z80 arcade board combo , and try and stuff it in a basically $200 box. But it ended up being their achilles heel in the end, but ONLY when a 68k arcade port wasn't gonna be released into the wild, and a Sonic or other 1st party game where to launch. SNES TMNT4 and MD-Hyperstone Heist were 2 completely different games, but had differences that made them unique. So ,sometimes re-inventing the wheel isn't really a "BAD" thing

 

[Jasvy]

Sure. There are a lot of examples. The TMNT games are indeed two different games, and both of them are great (although I prefer Turtles in Time). The same applies to Castlevania. Bloodlines is a blast, just as the SNES games are. But some others are supposed to be exactly the same: Mortal Kombat is an example. There are so many of them: Desert Strike, Super Street Fighter, Another World, Flashback... they are the same game, but they are different just because they run on different hardware. I don't care which versions are better. The point is that they are different. And that was a real blast. Each machine had its own feeling, its own identity. The same music would sound different on the SNES, Mega Drive, and PC Engine. They showed different screen resolutions, different colors, different scroll layers, and different sprite capabilities... so different graphic approaches had to be used. Some ports would be better on one machine, and some on another. And a lot of them were not better on any of them. They were just different.

Nowadays, it is impossible to see differences in multiplatform games (at least if you don't have bionic eyes).

Coming back to the topic, in the 16-bit era, companies provided tools to dev teams in order to make things easier. A good example is the infamous GEMS, which was a framework to make music for the Mega Drive/Genesis, widely used by western studios. The results were horrible in almost all cases, but the tool was there. You could call it a "sound engine" only for the Mega Drive.

 

[digitallogic]

There's a lot of cool stuff here. I'm learning a lot, thanks guys!

 

[Tiviat]

Sure. There are a lot of examples. The TMNT games are indeed two different games, and both of them are great (although I prefer Turtles in Time). The same applies to Castlevania. Bloodlines is a blast, just as the SNES games are. But some others are supposed to be exactly the same: Mortal Kombat is an example. There are so many of them: Desert Strike, Super Street Fighter, Another World, Flashback... they are the same game, but they are different just because they run on different hardware. I don't care which versions are better. The point is that they are different. And that was a real blast. Each machine had its own feeling, its own identity. The same music would sound different on the SNES, Mega Drive, and PC Engine. They showed different screen resolutions, different colors, different scroll layers, and different sprite capabilities... so different graphic approaches had to be used. Some ports would be better on one machine, and some on another. And a lot of them were not better on any of them. They were just different.

Nowadays, it is impossible to see differences in multiplatform games (at least if you don't have bionic eyes).

Coming back to the topic, in the 16-bit era, companies provided tools to dev teams in order to make things easier. A good example is the infamous GEMS, which was a framework to make music for the Mega Drive/Genesis, widely used by western studios. The results were horrible in almost all cases, but the tool was there. You could call it a "sound engine" only for the Mega Drive.

Of course, todays games are near identical on platforms because gaming hardware drifted away from being "custom hardware" and are now mostly "off the shelf" pc parts, which makes porting a breeze with Visual Studio and GNU toolchains.

Japan had all the "cool stuff" to make music for the MD, I mean the same machine that cranked out grainy Western audio, is the SAME machine that was outputting that club Streets of Rage 2 soundtrack. Its hilarious as to how much a good sound tool would make, versus GEMS that was popular with Western Studios. Midway used the popular 'Debabalizer" to capture the footage for the 1st Mortal Kombat game. And it was used on Pit Fighter, N.A.R.C., Super High Impact, and several other games that used full motion video in 16-bit videogames. Midway found a better video capturing software to create Mortal Kombat 2