^^BTW, Burn Zombie Burn was the 1st title to use that program, but somehow I bet it's not the last. :)

Hi,

http://www.kotaku.com.au/games/2009/03/xna_games_dont_sell_dont_make_money-2.html

I wouldn't make anything for Xbox 360 or PS3, if I was console indie dev(Well, I am indie dev...). Only bigger games can reap profit and you only have to bet your own company to make a game. Unless of course you have very large company. :)

Your investment as an Indie developer would be much safer with Sony, since it would be half the investment.  I think that has to be appealing.  Of course, you should make sure you don't have a crappy game on your hands to begin with.

@Ascended
I already read the whole deal about the Pub Fund and everything. Bandwidth costs are not covered. Sony is not a "safer" investment since you have to pay fees for every time someone actually buys your game. Xbox Live, if your game is successful and a good one like Burn Zombie Burn, will be much better for you overall when it comes to profits.

@Deneidez
Those are community games. Not indie developers. Most of those titles sell for 200 Microsoft points (about $2) so they really aren't meant to make a lot of profits. Those games are made by amateurs who just want to get their first game out in the open, and the community games lets them do it for free. When I say indie devs, I mean the likes of the developers of Braid or Castle Crashers that actually develop a very high quality game that has the potential to sell very well if given the opportunity.

Oh please!  It's an advertising fee of $0.16 per Gb.  Plus, that's only for the first 60 days. Plus, it's ONLY for demos, hence being labeled an ad fee.  Right now, Sony gets charged for publishers' demo content.  This charge is for publishers and NOT developers.  You have been poisoned.

I read that post and the slides. From what i read it does not provide an API that hides the need to plan your data structures and execution path around parallel processing but provides you an API to reduce the grunt work of delegating some rendering tasks to the SPUs. You will still need to rework existing engines to break an existing process down that is monolithic now and reassemble it before final rendering.

To get concrete they give an example of delegating depth of field preprocessing to an SPU then use the data from that to apply an appropriate blur using the GPU. But to do this you will need to coordinate a split in your execution path after the depth buffer is populated then find something for the CPU/SPUs and GPU to be doing while that is going on that will not affect the depth buffer and also is not dependent on the depth of field data. Once the preprocessing is done you need to merge your execution paths and apply the focus data returned and forward the complete information to the GPU for rendering. Figuring out what tasks can be done in parallel is the hard part, not handing a task of to another processor. If the GPU is not still rendering the last frame there is really not much it can do because you cannot have it modify vertex data because that would potentially change the depth buffer and you cannot have it apply any pixel effects because because it will just need to do it again once it has the depth of field data. Obviously you can be doing AI, IO, triangle level lighting, game mechanics, etc in the SPUs/CPU but you could be doing that if the GPU was doing this calculation too. There are lots of ways you could take advantage of this but they still require you to understand the underlying architecture and to design your application accordingly.

What developers need is an engine that provides them a model where they do not need to make hard decisions often, where they can continue to think at a high level of abstraction about their game. To give a real world non technical example think of Mc Donalds, or any local fast food restaurant. You place your order at a high level of abstraction, you say I want a combo meal #1. The order is placed and relevant parts are routed in parallel to the grill cook, the fry cook, the drink machine, and the order assembler. All the parts arrive at the assembly area and are put in a bag and handed to you quicker then they would be if one person went and did the entire process. A central shared team did the complex thinking about the problem and figured out the optimal way to process a menu order in parallel so the people crank out the order do not need to think hard.

My impression of where the game development world is going is toward this model. Not because developers are money hungry but because they cannot afford to build these engines just for their own use. Yes the PS3 dev kit continues to make progress toward this goal, as do third parties like unreal engine, but it does not appear that we are there yet in terms of fully leveraging the PS3 hardware.

And before anyone goes and makes the upscale restaurant counter example, i will believe that when I see high end games selling for ten times what the basic games do and selling to smaller audiences, because that is the real parallel (no pun intended :).

It's more thinking/planning for GREAT results!  Devs HAVE to learn how to parallelize their code and tasks to go forward on PC and PS3.  That type of talk lends itself to the public perception of lazy devs.  That's what developers get paid for.  It's...their job!  Occasionally, your job throws you a curve ball.  At that point, your choice is to adapt or get out.  This applies to everyone.  Why should devs be excluded from this sort of "natural selection" process? 

Code parallelization is the devs' curve ball.  Now, they're faced with their choice.  It will never get easier if devs don't suck it up and learn it.  The tools are here to make it easier on devs and more tools are being developed.  It's been explained at several conferences that the knowledge gained from working on the Cell travels over to the PC.  Then, devs can finally make a game that properly uses the Intel Core i7 965 XE's 8 cores (hell, even the 4 core version) to bring new forms of gameplay, A.I., physics, and graphics.

Uh noooo.  It is "bandwidth fees" and applies to all downloads, all the time.  You have been fooled if you really think it is some "ad fee".

All core i7s currently only have 4 cores.  Seriously what are you smoking?  You keep coming up with randomly wrong stuff.  They have 8 threads, but only 4 cores.

You're both wrong.

It is a bandwidth fee for all content on the PSN.  It only applies for 60 days though on non-paid content (Such as Demos) but it is a permanent fee for paid content (Like expansion packs or extra costumes or whatever). 

It's a way to keep file sizes down on the network.  Microsoft limits file sizes (Which has been a big annoyance for developers as well).  The PSN gives them the flexibility of doing essentially whatever they want (Size wise) (But now,  they are going to pay for it).  Really, it's almost a non-issue entirely that has yet to show adverse effects.    For most large publishers the fees are negligible.    The concern is for the smaller sized ones.   Which Sony gave back to them by matching their budgets.