Slashdot Mirror
Conflicting Reports of PS3 Programming Difficulty
xenongamer writes "It appears there isn't any type of concensus regarding the programming difficulty of Sony and IBM's upcoming Cell processor. From the article: 'Although few doubt the relative power of the Cell microprocessor, many have expressed concern over the chip's asymmetric design, which makes programming for it a potential disaster ... One such man was 3D artist Josh Robinson, who was fired from his position at Sony just weeks after making a public, negative comment about PlayStation 3 development on his Internet blog.'"
The debate currently centers on whether it's very difficult or extremely difficult to program for the PS3.
Does God treat us as servants or friends? Check my homepage.
Difficult. http://games.slashdot.org/article.pl?sid=06/01/31/ 1510249
I'll side with him before I side with some random nutjob. Most game logic doesn't need or want too many different threads; requiring multiprocessor use to get the most out of the system is just overcomplicating things.
Games have gotten much more complicated over the years. Not long ago, anybody could make a game that was on par with the best. Then, It became too hard to make your own game, the best you could do was make mods to existing games. Now, games are so complicated that only people who want to spend tons of time can even learn how to make the mods. Now with the PS3, games will be so complicated, that not even the developers will be able to make them.
Anthropic principle: We see the universe the way it is because if it were different we would not be here to see it.
Who wouldn't want 7 SPEs?
Crazy developers..
"Oh boy"
The guy was an ARTIST fired for for saying less than flattering things not only about an early development box, but the product he was working on. His opinion about how hard it is to program counts for nothing, he's not doing it, everything was heresay. His primarily complaint was that his game was not taking advantage of the PS3 because they were putting schedule before quality. Anecdotally he referred to other companies that may be doing the same. Nor do I give any attention at all to someones COMPETITOR who claims it is "a nightmare".
I wouldn't give him much air time, I'd rather hear from developers actually working with it. Those who have detailed architectural drawings, APIs etc. Even (especially) if they have to go to great lengths to achieve anonymity. Those guys would know what potential may or may not exist. This article does not give us information on that, the closest we come is a chief architect at a game haus who says he likes it. He's probably closer to development than the others, but still not reliable (since he's on record) and unless title inflation has gone mad, not someone directly doing the work.
A non-story.
I thought all the PlayStations were difficult to program for. I remember reading somewhere this was a reason why games didn't advance all that much over it's lifespan. I imagine it takes a lot more work to squeeze out all the power.
And do you think that Nintendo doesn't have DRM (essentially, an anti-piracy scheme) on it's games for the R?
But Nintendo's not trying to establish their secure media as the new industry standard.
Swing and a miss...
The same thing was said about the PS2. The developers of Oddworld switched from the PS2 to the XBOX early on, citing the fact that the PS2 was too hard to code for. There was widespread concern then that the PS2 was going to be too difficult to be viable.
How about everyone wait for the system to actually come out before making judgments on it?
What I've heard is that they have a development environment for the Cell processor (now released) that has at least a working compiler. If that's true, then they've already gone beyond what was available for the PlayStation 2, at least at the level of programming the Linux kit.
Craig Steffen
Craig Steffen
http://www.craigsteffen.net
OK, Dumbass article award for mistating the issue using misleading evidence: The person fired _wasn't a programmer_ and had no knowledge of programming beyond claims made by others.
They've always had an anti-piracy scheme. It's called "Don'tUseCurrentPCStorageMediaForAllYourGames(TM)" , sometimes called "common sense".
Nintendo games have some of the least anti-piracy protection systems out of all 3 current major systems. The only reason why you don't see them pirated so often is because more people would rather simply buy the game and system since they'll generally high quality. (In comparison to Sony's 'quantity over quality' or Xbox's hit-or-miss methods.)
Point - Multiprocessing systems are the general direction computing is going in. The new Mac's use it (core duo) , the PC's Hyperthreaded dual core's. Xbox 360's and of Course the PS3.
That said - Asumming the 360 has "Symmetric" architecture and the PS3 "Assymetric" as the guy is implying.
Lets discover exactly what the difference is between the two.
My understanding is that Symmetric multiprocessing (Xbox 360) gives each processor identical levels of responsibility for processing tasks. For example - on a linux SMP system the kernel will try to balance processes equally across each processor. Only if an application process is specifically written to thread its own tasks across both processors will it be shared across them. This is why having a multiprocessor computer rarely makes much difference to a uniprocessor machine unless the game is specifically written to take advantage of a multiprocessing environment. Games like this are currently rare.
Taking a look at Asymettric procesing... (PS3) This allows us to give each processors specific tasks. For example we could dedicate 1 cell chip to running say the AI for a game, another for the Player physics and the rest for graphics and sound. This actually makes the design of the system considerably simpler and easier to abstract - although it could be argued that it reduces the overall performace of the system. Good job then that the PS3 has more than twice the amount of processors as the 360. However the same can be said for the PS3 as the 360 - Unless games are specifically written to take advantage of a multiprocessor environment there is little advantage in having them. Both consoles are going to require a new mindset and learning curve before either will reach their true potential. This has always been the case and so long as technology keeps changing will continue to do so.
I'd like to add to this that ID Software is not traditionally a Playstation development studio. There are only two releases I can think of - Quake 2 (PSX) and Quake 3 (PS2). They are traditionally a PC studio - and their experience of development therefore lies in this area. XBox 360 is designed with this in mind. It does stand to reason that Carmack's team would agree with this - simply because the Microsoft Development platform is what they have been doing for years. Id like to hear what a tradional Playstation dev studio says about the 360 as a development platform, or Nintendo for example.
Pick any console from any manufacturer. compare a launch title with another title on the same platform later in its lifecycle. In most cases there will be significant improvements this shows only that it takes time - (and library updates) to climb to the top.
Despite all of this I have to say that what matters most of all here is not how powerful one system or another is. What really matters are the games. At this moment in time I can't justify buying a new console just because it has better graphics or sound. Those things matter less and less as time goes by- The game plays the same no matter how many more polygons it is or isnt shifting. Lets be honest here - leaving visuals and sound out of the equation - what kinds of gameplay can be created now that could never have been done prior to these next generation machines? Perhaps the answer to that question can hinted at by looking at the kinds of tasks most suited to multiprocessing systems.
Electronic Music Made Using Linux http://soundcloud.com/polyp
It's been five years the PC/Dreamcast/Xbox crowd has been hoping that tired old "hard to program" bullshit would have some effect on the console market. I guess they believe if they keep repeating it's gotta 'stick' eventually.
Having worked on console games for a very long time, I've watched people desperately try to get console developers and publishers to believe that meme.
I have first had knowledge of and a rough idea of a huge number of console project budgets and schedules from a mix of projects I've worked on, near, or from people I know throughout the industry.
There isn't any difference in project budgets, lengths, or team sizes for PS2,GameCube,Xbox,PS3,360 titles.
Sorry. I know that isn't what a certain crowd wants to hear.
Salary is almost always the largest part of a game development budget - usually by a wide margin. Any significant difference in either team size or length of time a company/publisher has to pay a team to get a project out the door would make that platform a massively attractive to target titles for. Even something as modest as ~20 percent smaller teams or projects lengths could result in hundreds of thousands of dollars in development money saved that goes straight into profits.
This bogus meme seems to be one of the crown jewels of 'bad stuff about the PS2/PS3' for the PC/Dreamcast/Xbox crowd and I doubt they will ever willing give up trying to get developers and publishers to believe and then we will target their platform with our games.
Ain't gonna happen. Give it a rest. Find something new. The 'hard to program' line isn't just old, it's boring.
It could well be both at the same time.
After all, the Cell sounds complicated and powerful enough that there's probably some quantum in there somewhere.
Strength through redundancy and over-design
in the qoute from the web site he just says it's not mature enough (i.e. there isn't enough done yet to really program for the hardware). I haven't had a chance yet to read the interview.
Hi! I make Firefox Plug-ins. Check 'em out @ https://addons.mozilla.org/en-US/firefox/addon/youtube-mp3-podcaster/
Luckily the PS3 now uses OpenGL as its graphics API, which should make it a bit easier to code.
We've all heard the crap about programming difficulties. It came up with the previous PlayStations, some were even skeptical of the 360 and there are people out there wondering how difficult it will be to program on the Revolution.
We'll hear the same crap about the PS4 and beyond.
But there seems to be ragging of the author, but you can't blame the guy for doing his job. He found a story, followed up on it, etc. Put it up because it is news worthy. How much shit do you read on every news site that's the same thing over and over. Sports is my cup of tea and reading about Terrell Owens for six months made me wanna stab the guy. But people read it and continue to fead it. I mean hell...it got slashdotted.
The deal you have on consoles is that you get more performance by programming "directly to the metal", and the hardware is cheaper to produce because they can concentrate on including what is necessary without dragging along a lot of legacy hardware or designing towards a specific API.
How difficult it is depends really on what you want to do. You can work on a high level and get a reasonable result. You can optimise everything for the last bit of performance and get an excellent result. But no matter on which console you work, or if you work on PC, going the extra mile for performance or effects is never easy.
On PS3 I'd use the extra cores for example for things I'd do in a vertex shader on a PC, A* or for physics calculations. That means I've got my input data (vertices, triangles, contact points, forces, particles, whatever) and I do a limited set of relatively simple operations on them. I can write and debug this in C, optimise it on a single core, and then split my input data into several sections and run the code in parallel. But there would be only a limited number of engineers exposed to that. For example I'd have one guy optimising the A* pathfinding, and 3 or 4 guys writing AI code and just query the optimised code in their scripts.
But in the end, this is not different from what I do on Xbox or Revolution.
The important thing to take from all of this is that the slashdot editors are DESPERATE for new info on the PS3 and will put ANYTHING up.
Actually, I'd guess the Slashdot editors realize that we PS2 fanbois will hit on anything that might contain some real news about the new console, and the usual flamewars will ensue. Oh, you are new here. :)
You mean like the GDRoms in the Dreamcast, Sega tried it? Ok thats not really the same, since Dreamcast could play normal CDs, which is what allowed the Pirates to exploit. Even the GameCube can run Pirated games, I think but it not easy or the games that stable.
What a load of crap. I was right with you until you mentioned that team sizes were the same between old-gen (ps2, xbox) and next gen development. All the major publisher-developers are boosting their teams hugely for next gen. And budgets are inflating, to suit.
"I was right with you until you mentioned that team sizes were the same between old-gen (ps2, xbox) and next gen development. "
I didn't read it as saying that at all. It sounds like team sizes were the same for PS2,Xbox,and GameCube - not including next gen consoles.
"There isn't any difference in project budgets, lengths, or team sizes for PS2,GameCube,Xbox,PS3,360 titles."
Seems fairly unambiguous to me...
Seriously though, try creating a game on an NES with the constraints developers faced back in the 80's. These new systems have it way easier, they don't have to cram code into 8-16k cartridges that run on an 8-bit processor.
With all this programming power, and graphics and sound all sorted out, what's needed is a game that makes full use of the processing power needed for AI.o n genre
I present to the next-gen game genre:- The Too-many-things-on-the-screen-requiring-calculati
TMTOTSRC games for short
So what we need are next-gen versions of
http://kevan.org/proce55ing/zombies/
and an updated version of...
http://www.classicgaming.com/rotw/crossroads/
READY.
PRINT ""+-0
Threads have never been fun to work with for most CS students. Be it Java or C++, they can be a pain. But with the most recent CPUs and the dreaded CELL processor, It's time to learn how to work threads beyond splitting processor time, and learn how to use multiple cores at once..... I see no way it can't be more difficult then previous generations if the developer has access to what each SPU does (I think that's the name of each sub-core), and programs for the system properly. The degree of increased difficulty is the issue though. I'd hate to be a programmer stuck in a situtation of "You have this single SPU to work with. Not much speed. But you must do this much with that little speed".
In undeveloped countries, the consumer controls the market. In capitalist America, the market controls you.
he's already go the penis of a man, thanks to "Uncle Eddie"
Now, all I have to ask is -- how the FUCK is that even possible? The PS3's specs beat the Xbox360's in every possible way!
A lot of the theoretical power in the PS3 comes from multiplying the power of each processor times the number of processors. Actually being able to make use of parallel processing power is notoriously hard. Usually one step of a computation depends on another. Programming for concurrency is in general a nightmare. Games will be buggier and much harder to develop if they want to make full use of the parallel cores. Sorry, no free lunch here.
Comparing the specs of the system is not straightforward. You can't just do something like a 0-60 mph benchmark like you would for a car. I don't think you are up for it, but if you want to get an inkling of the tradeoffs involved, here's a link: Microsoft's Xbox 360, Sony's PS3 - A Hardware Discussion
I feel sorry for the developers who have to make their games portable for both systems. I suspect we will get a lot of lowest-common-denominator games. It will be interesting to see if Sony can make a game that shows off the PS3 in a way that the 360 can't match.
Of your paycheck
From SONY
Fucking plant.
Type 1 thinks in "i_unknown" theoretical concepts, tries to create a framework to rely on and then starts looking what the metal is capable of.
Type 2 looks at the metal, plays around with it, reads the manuals, plays around a little longer to make sure everything needed is understood, and then evaluates the possibility to use either a supplied framework (customized if needed) or to create a new framework.
I had my fair share of type 1s, I had my fair share of type 2s.
Type 1 had problems with the console-programming more than often, the perfectly crafted framework had to be duct-taped to the metal because it implied functionality that simply wasn't there, thus delaying delivery dates.
Type 2 sometimes got lost in the possibilities of the metal, but delivered results.
Before you start to flame me now: the type 1 approach is valid if the feature-set of the hardware is known and tested, but, if dealing with metal of not-so-tested capabilities, type 2 is needed to make sure there are no surprises later. To make my point: I had to fight with a type 1 at one time because the framework he invented didn't match the features of Nintendos GC. For him, this was no problem, "let's create another thousand classes and it will work." He did not understand that programming on metal, read consoles, is different from programming on a PC with an OS.
Maybe its time for the studios/programmers complaining about difficulties to evaluate the number of type 1s vs. the number of type 2s in the team. It won't work without a good mix of both and clear cut responsibilities/planning before.
just my 2 cents
""There isn't any difference in project budgets, lengths, or team sizes for PS2,GameCube,Xbox,PS3,360 titles."
Seems fairly unambiguous to me..."
Actually it is true.
The 360 is best described as Microsoft's second current gen console. It is best thought of as an Xbox that supports higher resolution but with smaller disc space.
That is how publishers and developers are treating it.
The 360's real world performance, compared to it's on paper specs, is not that much higher than current gen consoles. Memory bottlenecks is the main culprit and the ATI card has turned out to be a bit of a dud. That is why you hear about games that have a custom/special version in the works for the PS3, while the 360 is getting the same game as the other current gen platforms.
A modern 3D video game ought to have: [snip] That's 5 threads at a bare minimum.
You missed one or more AI threads. All this talk of threads misses some of the more interesting (and difficult) areas of threading - messages and synchronisation.
Your sound effect thread will have dependencies on the character's position in the world and on the events going on in that world. This will include information from the physics thread (for collisions and explosions) and from the core world data area. This is probably most easily handled as a message queue of sound events - just stuff sound events into a sound event queue and forget about them - let the sound thread consume them FIFO-style.
Your AI thread will have dependencies on the physics thread (for moving object information) and on the general world data (for static objects and terrain info). Your AI thread can probably survive having just read-only access to the physics moving object data but you might want to have a (short-lived) latch on those structures if your AI thread requires stable data access. Your AI thread may have to update parameters in the physics data set to cope with changes to actors movements or vehicles motion in the AI decision tree. This will require write-latching to those physics data objects. Your physics thread requires accurate information from the input thread (handling the controls).
I could go on, but you should already have the picture - threads give you parallelism but they also require careful management of shared data structures. Threads may require synchronisation or information passed through message queues. Getting all this right, minimising hot latches (often by breaking a single latch into finer grained latches) and still running consistently, predictably and believably is not easy. Having a good toolkit which provides these features for you can make this a lot simpler for the developer but unless such a framework already exists, you probably will have to write your own.
Cheers,
Toby Haynes
Anything I post is strictly my own thoughts and doesn't necessarily have anything to do with the opinions of IBM.
I take from your post that you've never written a modern commercial game?
We console/arcade engineers have been writing concurrent engines for multi-chip systems for a long,long time.
There is a wealth of tough problems in game engineering. Concurrent execution and synchronization isn't one of them.
I can state from personal experience that programming for the PS3 is not as difficult as people make it out to be.
;)
I have a background in PC game programming and have come up to speed on the PS3 in less than a month.
You have to know:
- computer architecture
- how to program with multiple threads
- how to manage DMA transfers
- how to write tight, vectorized code
But that's the case if you're making a high-performance game on a Win32 machine anyway.
And if you've been doing VU coding on the PS2, the PS3 is a breath of fresh air.
The Nvidia graphics chip that you can program with Cg should make PC
graphics programmers feel right at home.
Trust me. It's not that bad.