Hardware what is exaclty done in "porting" a game

[Dominator211]

I know it has to do an architecture change and changing the in-game settings so that it works with the hardware. But how do the companies do it and it is it really as much work as they say it is.

 

[FAST6191]

Depends what game and what platform to what platform, or possibly what programming language to what language and what engine/library to what engine/library. If it is really old or the power difference is great enough you might also be able to wrap it in an emulator instead.

It is such a broad question and a complete answer is possibly along the lines of "game programming, learn it. Best do it for PC, console and handheld while you are at it". Once you have done that then you will understand what it entails, or at least could entail on the technical side of things. The legal side of things is another beast again; your music, libraries, engine*, network code, in game advertising/brands, videos, likenesses and more might have to be renegotiated, to say nothing of what each company demands (will Nintendo allow your ultra violent and controversial game on their platform for instance?).

*there is a reason that people pay attention when Unreal say we are not porting our engine, or this version of our engine, to a given device. While not impossible to port to a new engine or remake things well enough to work it is not going to happen on the kinds of budgets that most people using the unreal engine in the first place are playing with.

As for companies... it is probably about as much work as they say but I can think of no excuse for things not being on a PC outside of legal woes.

Architecture change is a less useful term here. Companies making devices decide upon the architecture, not the one making the games (at least outside of working groups wherein the first group asks game programmers what they will want in the coming years). You might have to account for a different system architecture but you don't "do an architecture change".
Similarly "changing the in-game settings" is also not a terribly useful term -- they might well be able to be left alone. Porting from a high power device to one with lower power or a different type of power you might well get similar effects to playing with settings as PC gaming types tend to imagine it -- if your PC port has shadows from all the light sources in range calculated in high settings mode but simpler models for shadow for medium (though obviously less demanding on the same device) then your console port might default to the PC's "medium" settings for that and in turn be able to play the game. As one setting might not do it

The change in architecture is something you have to deal with -- if you assume you have a modern PC CPU with a modern PC graphics card, lots of hard drive you can use at your leisure, an enormous amount of RAM and a full operating system to handle all sorts of oddities then moving to a console without an operating system (might not even have the ability to decode music), no storage or slow read only storage (if you are reading from an optical drive...), a limited amount of memory and more modest CPUs and GPUs then you might well come a bit unstuck. More subtly then despite the PS3 and 360 having similar performance as far as numbers crunched per second if you looked at the way they handled graphics and the amount and type of resources assigned to each it was a bit different. If you designed your game with one device in mind and found the graphics memory was ultra fast to fill in then you might have taken a different approach to one that was slower but had more memory available.

This is all known, boring and basic to any game programmer though so they often try to design it such that all the devices they are looking at for it will be able to get versions more easily.

 

[Traace]

porting to PS3 is really painful. The PS3 can utilize SPUs helping calculate graphics. That is something most companys never managed to do right when they ported from Xbox 360. Because the 360 has a simpler CPU architecture and the buildtools are integrated into Visual Studio it was more used by devs then a PS3.

 

[Dominator211]

Lets say one wanted to port to the nintendo switch. How would that work

 

[mightymuffy]

That's not really narrowing things down either: Fast's near-biblical length post gives you plenty details... The Switch is ARM-based architecture, nothing like PS3 troublesome like Traace is saying, but porting a game from Wii U? That's PPC-based. PS4/Xbox One/PC? x86-based. 3DS? That's ARM... And we're not even scraping the tip of the iceberg here. Better to google this if you really want to know and read up what you find for a few hours...

 

[FAST6191]

That gives you an end goal but there is a world of difference between porting a GBC game to the Switch (while you could write an emulator if you look at what Square Enix are doing with their mobile phone/tablet ports and the graphics mods they are doing, to say nothing of things like https://www.gdcvault.com/play/1023470/-It-s-Just-Emulation , then it is not always just that) and porting the latest system grinder PC game.
Similarly the difference between system grinder PC game and run of the mill PC game that will work on more systems. The Switch has a fair bit of grunt behind it but it is certainly no high end PC or modern console.

We will ignore the legal aspects and financing aspects for this one, though it is no small part of the process in the real world and maybe even the greater trouble for such things most of the time. For a simple example though if I give my porting team a job for a year then it is however much that is, if the result if a Switch game that sends 10000 copies I might make a profit but if I could have instead ported another game that sold a few hundred thousand in the same timeframe my investors will be jumping down my throat wondering what I have been up to.

The ARM thing then. Modern ARM is doing more and more but if you want to go back to the GBA then its ARM CPU could not even do division ( http://problemkaputt.de/gbatek.htm#arminstructionsummary ), there are ways to get it done but it was not there. Going up to the DS then floating point (the main way these days to do fractional numbers, very useful if you are doing full movement true 3d games) was not easy to do on it. Equally most people probably don't have to consider things at instruction level any more.
http://switchbrew.org/index.php?title=Tegra-X1 which means https://developer.arm.com/products/processors/cortex-a/cortex-a57
So a fairly modern device with no great shortcomings and thus you are likely more concerned with the amount of data it can crunch rather than the types that are best to feed it. It is still relevant, especially for something like my shadows in a PC game example above.

I mentioned engines before. If you use an engine off the shelf (and buying in Unreal is cheaper than spending 5 years making your own, not to mention they will have 5 more years on top of that by the time you are done) then you check to see if yours or a compatible one has been ported to the Switch already.
Engines are not like making PC mods, though it is not so very far removed and much like a mod will hopefully work between different PC systems then you can get a lot of the way there with this sort of thing. A nice overview can be found https://www.gdcvault.com/play/1011911/Developing-Licensed-Games-Do-It

While a game engine might be nice you would hopefully also have the development plan.
It will run something like this
While code telling me something like https://github.com/pret/pokered/blob/37ded1d150197b3784bc351eeeb0a8d9713c2e35/engine/battle/core.asm is almost vital for such a project (as a filthy ROM hacker I can pull the finished product apart and figure out how it works but it is very slow and nobody will want to do it for a commercial game really, indeed that very link is the result of some people doing just that over many years and that was for something as simple as pokemon on something as simple as an original gameboy. As Sega lost the code for Sonic it kind of does things like this these days which is part of the reason Sonic ports are not so common and often quite iffy.).
If the development plan gives me the maths the governs it all like https://www.dragonflycave.com/mechanics/gen-i-capturing
Then I can rewrite that maths in my own time according to the whims of the system, no worries about pulling apart the original code and figuring out how it works and why people did what they did (by the way the game industry is not renowned for its top tier coders that write code that anybody can read and reuse in 10 years like people have to in other businesses).

I am again starting to write loads and nothing I have written here a game porting type would not be able to tell you from memory when blind drunk. I could possibly go into more detail about a specific port but then you would only know that specific port.

Also while I am linking my favourite articles relating to game development I might as well link https://magic.wizards.com/en/articles/archive/duels-planeswalkers-all-about-ai-2014-02-13 , if nothing else it should allow you to understand why the handheld collectible card game implementations are so weak on the AI front or so weak in the deck customisation side of things. Though actually the following link might be better, and actually if you can't explain why I linked this then it is an indicator of how much you have to learn before you will start to make real headway into the question you have asked

 

[Dominator211]

dude im sorry but you have way to much time on your hands to write "epic" responses

 

[FAST6191]

6 paragraphs is epic?

Anyway I type fast, most of that was from memory or easy to construct for any given device and it provided me a chance to put some thoughts together that might have been a bit scattered in my head otherwise.