So this might be a little old. I found it on Kotaku some years ago and now i found the original thing on Reddit. Basically, 3 years ago, a developer made a thread on Reddit about how it is like to develop for a console. The first post is about the personal experience of the TC (some developer) but after that more developers join the thread and share their stories, experiences, insights on hardware etc. Personally i found it very interesting. Everything in there is described with simple words so even if you don't know about hardware or developing you won't have a problem getting the general idea. I will copy everything from the first post (and something from other posts) and i will post the source at the end of my post. If you find it interesting i really advise to read the whole thread on Reddit. Let's start.


PlayStation 1: Everything is simple and straightforward. With a few years of dedication, one person could understand the entire PS1 down to the bit level. Compared to what you could do on PCs of the time, it was amazing. But, every step of the way you said "Really? I gotta do it that way? God damn. OK, I guess... Give me a couple weeks." There was effectively no debugger. You launched your build and watched what happened.

Nintendo 64: Everything just kinda works. For the most part, it was fast and flexible. You never felt like you were utilizing it well. But, it was OK because your half-assed efforts usually looked better than most PS1 games. Each megabyte on the cartridge cost serious money. There was a debugger, but the debugger would sometimes have completely random bugs such as off-by-one-errors in the type determination of the watch window (displaying your variables by reinterpreting the the bits as the type that was declared just prior to the actual type of the variable --true story).

Dreamcast: The CPU was weird (Hitatchi SH-4). The GPU was weird (a predecessor to the PowerVR chips in modern iPhones). There were a bunch of features you didn't know how to use. Microsoft kinda, almost talked about setting it up as a PC-like DirectX box, but didn't follow through. That's wouldn't have worked out anyway. It seemed like it could be really cool. But man, the PS2 is gonna be so much better!

Playstation 2: You are handed a 10-inch thick stack of manuals written by Japanese hardware engineers. The first time you read the stack, nothing makes any sense at all. The second time your read the stack, the 3rd book makes a bit more sense because of what you learned in the 8th book. The machine has 10 different processors (IOP, SPU1&2, MDEC, R5900, VU0&1, GIF, VIF, GS) and 6 different memory spaces (IOP, SPU, CPU, GS, VU0&1) that all work in completely different ways. There are so many amazing things you can do, but everything requires backflips through invisible blades of segfault. Getting the first triangle to appear on the screen took some teams over a month because it involved routing commands through R5900->VIF->VU1->GIF->GS oddities with no feedback about what your were doing wrong until you got every step along the way to be correct. If you were willing to do twist your game to fit the machine, you could get awesome results. There was a debugger for the main CPU (R5900). It worked pretty OK. For the rest of the processors, you just had to write code without bugs.

GameCube: I didn't work with the GC much. It seems really flexible. Like you could do anything, but nothing would be terribly bad or great. The GPU wasn't very fast, but it's features were tragically underutilized compared to the Xbox. The CPU had incredibly low-latency RAM. Any messy, pointer-chasing, complicated data structure you could imagine should be just fine (in theory). Just do it. But, more than half of the RAM was split off behind an amazingly high-latency barrier. So, you had to manually organize your data in to active vs bulk. It had a half-assed SIMD that would do 2 floats at a time instead of 1 or 4.

PSP: Didn't do much here either. It was played up as a trimmed-down PS2, but from the inside it felt more like a bulked-up PS1. They tried to bolt-on some parts to make it less of a pain to work with, but those parts felt clumsy compared to the original design. Having pretty much the full-speed PS2 rasterizer for a smaller resolution display meant you didn't worry about blending pixels.

Xbox: Smells like a PC. There were a few tricks you could dig into to push the machine. But, for the most part it was enough of a blessing to have a single, consistent PC spec to develop against. The debugger worked! It really, really worked! PIX was hand-delivered by angels.

Xbox360: Other than the big-endian thing, it really smells like a PC --until you dug into it. The GPU is great --except that the limited EDRAM means that your have to draw your scene twice to comply with the anti-aliasing requirement? WTF! Holy Crap there are a lot of SIMD registers! 4 floats x 128 registers x 6 registers banks = 12K of registers! You are handed DX9 and everything works out of the box. But, if you dig in, you find better ways to do things. Deeper and deeper. Eventually, your code looks nothing like PC-DX9 and it works soooo much better than it did before! The debugger is awesome! PIX! PIX! I Kiss You!

Playstation 3: A 95 pound box shows up on your desk with a printout of the 24-step instructions for how to turn it on for the first time. Everyone tries, most people fail to turn it on. Eventually, one guy goes around and sets up everyone else's machine. There's only one CPU. It seems like it might be able to do everything, but it can't. The SPUs seem like they should be really awesome, but not for anything you or anyone else is doing. The CPU debugger works pretty OK. There is no SPU debugger. There was nothing like PIX at first. Eventually some Sony 1st-party devs got fed up and made their own PIX-like GPU debugger. The GPU is very, very disappointing... Most people try to stick to working with the CPU, but it can't handle the workload. A few people dig deep into the SPUs and, Dear God, they are fast! Unfortunately, they eventually figure out that the SPUs need to be devoted almost full time making up for the weaknesses of the GPU.

Wii: A back to basics experience. I had the joy of working with the first ones which were really a fancy GameCube, and it was very easy to use and debug. It did require 3 USB ports and you could not use a USB hub... so you had to find a PC with 3 or more USB ports, and at the time, this was rare. Moving files onto the Wii from a PC was a bit slow and painful, but it could virtually access your PC through one USB cable. The debugger would sometimes miss meaning that you might skip a breakpoint. The compiler / debugger was changed about a year after the Wii came out so all of the pipeline and tools had to change. The performance was rocking, is spite of what so many people claimed: It was better than the XBox and we could do a lot of other things. On Madden 07, we had motion blur, reticular lens, bloom, and bilinear filtering ... running at 60 fps. We eventually gave up motion blur because our frame rate dipped occasionally and 60fps was a requirement. Overall, this was one of the easiest, and rawest pieces of hardware I worked on.


https://www.reddit.com/r/gamedev/comments/xddlp/describe_what_developing_for_each_console_youve/

EDIT*I will try to explain what some of the words mean. Note that i am not so experienced myself so i apologize if i make any mistakes and i hope a member with more knowledge about these things will help.

Debugger: This word seems to appear many times. A debugger is a program that is used to test and debug an other program. Debugging is the process of locating and fixing errors or bugs in a computer program code. By debugging a program (for example level editor, how characters respond etc) is to find what's wrong with it in case it doesn't work like the way you want it and then fix it.

GPU: Graphics Processing Unit. A computer chip that basically performs mathematical calculations mostly for rendering the graphics. In other words it's your graphics card (Nvidia, ATI).

CPU: Central Processing Unit or simply processor is the ''brain'' of any system since it performs most of the calculations and that's why it is the most important element of a system. (a famous manufacturer is Intel for example)

DirectX: Microsoft DirectX is a collection of APIs (application programming interface = a set of protocols and tools for building software) for handling tasks related to multimedia mostly for game programming and video, on Microsoft platforms.

PIX: Performance Investigator for Xbox. It's a performance analysis tool from Microsoft to help the developers maximize the efficiency of applications. Microsoft released it for Windows as part of the Microsoft DirectX SDK(see above) to aid game developers.

RAM: Random Access Memory. Basically a data storage, a RAM allows data items to be accessed. The bigger the RAM is, the better is for developers. You don't need to wonder why most developers ask for more RAM.

High/Low latency: You may have heard this when it comes to network connections but here it is referred for the RAM. A low latency will have small delay times and the high latency will have longer delay times.

SIMD: Single Instruction Multiple Data. It basically operates on multiple data elements together.

Apologies for the huge wall of text.

No idea what any of that means, but interesting anyway.

NemZ wrote:No idea what any of that means, but interesting anyway.

Same here, but at least I learned that debuggers are a big deal for game developers.

The PS3 description matches up with everything else I've heard about developing for the console. I was a bit surprised by the part about the PS2 though. Never knew it had 10 processors.

Okay, i updated the original post to include some explanation of what some of the words mean (CPU, GPU, RAM). Unfortunately the first post is huuuge so i don't know how many will actually read it (if anyone at all).

IronEvangelion wrote:The PS3 description matches up with everything else I've heard about developing for the console. I was a bit surprised by the part about the PS2 though. Never knew it had 10 processors.

Sony is known for using ''exotic'' hardware for Playstation (except Playstation 4). This explains why Sony games look really great (Gran Turismo, Shadow of the Colossus, Uncharted, God of War, The Last of Us) since they know better the hardware. Third party developers had a rough time, at least during the first years for each console but when they grasped the system they could do great things. For example Final Fantasy XII looks amazing for a Playstation 2 game.

A.T. Fish wrote:Same here, but at least I learned that debuggers are a big deal for game developers.

Oh definitely, they're really useful for tracking down particular types of bugs.

Interesting read. I know about PS3/4 and X360/One from a QA perspective but seeing the dev side is cool.

A.T. Fish wrote:Same here, but at least I learned that debuggers are a big deal for game developers.

They're a big deal for any serious software developer.