No it didn't. The total costs also include amounts the leaks wouldn't reflect because they would've been baked into the initial development of the game, i.e engine overhauls to support other SDKs like DX12U.
No, as I said, as seen in the leaked documents the original PS5 game and the port are separate projects with separate budgets.
The engine overhaul, if needed, is done in the porting project, because it's part of the job of a port.
Even Sony said multiple times that they had external teams for the PC ports to make sure the lead dev teams like Insomniac could focus only on PS and not worry about PC, and also the (Nixxes) porting team talking about
their job with Spider-Man.
Again, you don't make a port for Spiderman 2 to Windows & Steam in 15 months unless you already set up the engine and pipeline for that port ahead of time...which would be baked into the costs of the original budget. This is just common sense.
If TLOU was released 10 years later on PC wasn't because the port took 10 years to be made. It's because Sony strategically thought that the point to release it was then.
The engine -most of it- was already ported by Nixxes in their previous Spider-Man and Ratchet ports. And as I said, even in the console games that never get released in PC, they have internal a rough PC version to test and debug the games there specially in the early stages.
That don't have all the scalability, all the GPUs/controllers/etc. support, recent DX12 features or upscaling stuff, several PC or console specific things etc.: it's just what they need to test and debug the console game on the PCs of the devs only, they don't do anything to run it in all PCs as laters the porters will need to do.
No, you saw the costs for what was allotted to studios like Nixxes to bring the game to PC, but that would've included various assets and code already set with some degree of compatibility on that platform, baked into the costs amortized to the PS5 version.
We saw the budget of the PS version, which means all the money they spent to make that version in all the studios and Sony teams who worked on it.
And we saw other budget for the PC port, which means all the money they spent on the PC port in all the studios and Sony teams who worked on it. Which basically is Nixxes, a handful guys from Insomniac (pretty a person from tools/engine to solve questions or support, someone from UI to solve questions or support, and a producer to send them material and overview everything) and then the marketing/PR/CS stuff.
It only costs teams like Nixxes a handful of million to finish up work on the port and get it ready for Windows & Steam; other actual costs (i.e developing various textures and assets to future-proof for eventual PC release with various scaling options) would have been done while working on the PS5 version.
Insomniac makes the game for PS, which includes having an internal rough, basic PC version for test and debug purposes, but that misses most things required to be a commercial game, like performing decently on a consumer level PC.
Nixxes makes the port: prepares it for PCs without shared memory, for Nvidia and AMD modern renderers, makes it scalable adding different texture packs and extra visual settings, adapts things like AA or RT, adds support for many controllers and keyboard controls, adapts it to multiple resolutions and its UI, changes the PS OS specific things for the Steam specific things (trophies, etc), fixes whatever is needed and a gazillion things more.
ND themselves said they retooled their engine pipeline to better accommodate PC. They've said that. It's on record.
No, they didn't. And Iron Galaxy ported their games, not ND.
So now you're saying 'computers' instead of PC? Because you do realize a PC is an IBM-compatible, right? A computer can be anything. The Amiga was a computer. The 68K was a computer. SHARC systems are computers. SPARC systems are computers. The Atari Falcon is a computer. NONE of those are PCs as in being IBM-compatibles with x86/x86-64 or Windows at their core, though.
Because -at least some teams- in some cases didn't use IBM x86 PCs to make their 8 and 16 bit console games, they did use other computers. Like the Commodore Amiga you mentioned. I'm personal friend of some of them. One of them worked in GB, NES, MS, GG, SNES, GBC, GBA games, including the first console game ever made in our contry (a GB game).
As an example, back then for GB they had a GB emulator. They had to manually erase and flash the EEPROMs, which took time, each time they wanted to test it in a GB (at the beggining they didn't have official devkits/testkits, had to make everything by themselves).
Why are you using them interchangeably, when PCs historically meant IBM-compatibles running DOS/Windows on x86 processors?
PC means "personal computer" and today they are the same. But yes, back in the 70s-90s there were other computers that weren't 'PCs' (x86).
I'm debunking your idea that ALL development is done on computers, especially PCs, especially since you're probably insinuating Windows-based systems.
Many coders use Linux instead of Windows but yes, all games (console, PC, mobile) are made today using computers (or 'PCs' if you want to be specific, sometimes in Mac if you don't consider it a PC). Specially in the early stages of the development.
It's in a more advanced part of the development, closer to the end, when you need to implement the console specific stuff and then using your PC, you connect remotely to the devkit, which in theory it is mandated to be in a secure room as demand some console maker to compile and debug there the console build.
Which can be tested on a testkit, which is basically a modded retail console prepared to run unsigned games (in the past were loaded via CD-burned disc or via network, nowadays everybody uses the network). They are cheaper and are the ones that use the testers. In case of Xbox, you can mod a retail console bought in a normal store to turn it into a testkit.
That part is false. If such were the case, we wouldn't need specific hardware SDKs like what the PS5 itself has.
Hardware SDKs don't exist.
As its name says, SDK are
Software
Development
Kits, a group of tools, apps, libraries etc. you use in your PC to make games for a platform.
As an example, recently I made a Mega Drive game for a gamejam on my laptop using the SGDK, a fan made, open source SDK to make Mega Drive games. It includes stuff to compile the code, adapt art or sound resources and an emulator with useful debugging stuff. The result is a ROM you can use in emulators, in an Everdrive or similar to play it in real consoles or, as a few weeks a friend did, burn it into EEPROM cartridges.
I think you're letting your anecdotal experience working on PCs conflate your understanding of the actual dev scene, especially for AAA games, and especially when going further back in older generations. It also kind of has a recency bias on your part.
I work as gamedev since June 2005. Initally cell phone games, later also PC downloadable games before Steam even was a thing. Later PC browser games and smartphone games. Got bought by a top AAA publisher that obviously also makes console and PC games, getting merged with an older consoles+PC games studio of that company that had in our city. Beyond devkits, testkits or prototypes of things like VR headsets, as an example I saw some top AAA game running in real time on a PC -which had can't remember if 24GB or 32GB of RAM like 10 years ago- a couple days after it was revealed in a E3 conference (it was of my company but I didn't work on it).
Later I left to do indie PC & console games (one of them for VR) supporting other teams or making our own stuff, while also being a gamedev speaker at universities or mentor in gamedev incubators, or museum curator for gaming history exhibitions or conference (mainly focused in national games, sometimes interviewing or hosting round tables to some of the pioneers of my country).
Obviously during all these years I made many friends or had coworkers who worked in many places. As an example, the guy who coorganized with me the 'private/petit-comité' gamejam where my team did the game posted above, is the same that burned the game. That guy worked as 2nd party for Sony in the PSP/Vita/PS3 times. In the gamejam we had people from an Activision studio, from a Blizzard team, IOI, CCP Games and more. There was a guy from a NA Sony studio who wasn't there because couldn't take some days off.
Right. The engine already used commercially on PC = part of the initial version's development was spend in adjusting the engine to support a future PC port. That's a cost attributable to PC which is not going to be reflected in the cost of the port coming after the initial game's release!
Pretty likely you'd need a NASA PC to run the game decently, and that builld pretty likely had AMD specific code not ready to run on Nvidia cards and things like that. Who knows how the code of games like these PS4 games was.
These internal PC debug builds normally are pretty basic buggy etc. Need a lot of work to port it to PC as a commercial game, this is why they hire specialist dedicated studios to do so, who may spend like a year working on it.
Why are you bringing up UE or Unreal?
To show as example things you may know. And well, UE is the engine of Days Gone, Returnal and Sackboy adventure.
When I said that not all game dev takes place on a PC, I obviously would've by association suggested that console-specific engines would've been included in that statement.
I'm not talking about engines like Unreal or Unity because I know chances are that's going to be a console/PC multiplat from the jump. But even in those cases, you will have a lot of games that still heavily utilize the console-based devkit hardware, and not just at the "tail-end" of the development like you're suggesting. The reason why is because various parts of the game logic need to be tested early on to make sure there is performance on the target hardware (the console) to accommodate those engine features.
Yes, some parts of the game need to be tested early on devkits, and they are. Particularly engine specific things, normally related to visual tech stuff. Some guys, particularly engine coders, use devkits for these things.
But most of the stuff, mosty the things that are done by the people who make the game itself and not the engine, normally don't need the devkit until pretty late.
It may be some teams who everybody may use it since the start, but it would be pretty unproductive. Specially back in the time when you had to burn builds in a CD to test it.
You're treating it like a waterfall process; I've done database design in the past and even from that limited time I did, you learn that the waterfall method is inefficient.
Yes, waterfall has been outdated for way over a decade.
So with game development, a lot of studios working on console are CONSTANTLY going back-and-forth between working on PC (or computer) hardware, and working on the game via console devkits, which in most cases might be hooked up to a computer (not necessarily Windows-based or even x86-based i.e some might be running ARM) via ethernet or some PCIe linker cable, running SDK packages provided by the platform holder.
Well, nowadays some people work on their PC from home and connects via VPN to the office and compile remotely in the devkit. And some people plays these debug builds via streaming.
It's historical revisionism at best (and it's usually coming from people who never, ever played PS3 MP games).
