I'm not following your logic here. Flexible & simple > less flexible (and more simple)? But simplicity > flexibility??
And doesn't a deferred renderer precisely show the trade off of flexibility for simplicity?
I don't think that in
the current generation, to achieve the same goal, a deferred renderer is simpler than a forward renderer to implement.
Even for the simple reason that you still need to render some parts of the seen with a forward renderer (transparency), so you actually need to support both.
My understanding is that in this situation, they chose a deferred approach beacuse they wanted many lights in the scene, which is a perfectly understandable requirement and they sacrificed many other features for this.
For me, in general, given a certain set of requirements, a simple design is always preferable to a more complicate one and a flexible design is more prefarable than a inflexible one. Often these two forces are pushing in different directions so you usually have to strike some kind of balance, and I almost always tend towards simplicity anyway.
Which means that in the curent generation, I would avoid a DR, because, in my opinion, it's too complicate to implement given a certain goal and too inflexible to achieve that goal. If the goal is many lights in the scene, I would still go for a forward renderer, but this is my personal preference given my experience on the subject.
On the other hand, if you consider a DX10-like GPU, I would probably prefer a fully deferred approach: I'm actually writing a DR engine (again!) on DX10 this time for my own pleasure in my spare time to try out a couple of ideas and indeed it is lovely.
To me, the very definition of an optimized system is a focused system. Focus means trading in flexibility for some other bonuses. You try to be a jack of all trades, you end up being a master of none.
I agree with you on this. I'm not advocating implementing every possible feature for the sake of it, actually the contrary. I'm advocating keeping things simple and as flexible as possible (because requirements will change!) , without being tempted by the dark side of coding
Artists should be provided with some powerful and extremely simple tools to use (we shouldn't harm their creativity giving them some overfeatured piece of unnecessary complicated crap to work with), but we shouldn't aim to give them everything they ask for or all the flexibility they want, in fact a few restrictions and limits are exceptional ways to give a game that particular special look that your game and your only game has,and it also stimulates artists creativity as they manage to find novel ways to use existing tools and technology to do something they were not designed for (snow shader used to shade water ftw!)
Well, I can't say no to an artist, I really can't. I always answer yes, I can't help it. Unless the hardware can't do what they ask, and in that case it becomes really painful for me to say no. That's why I was the only coder at the Art of Crysis presentation. I like them. I really do
So, if an artist asks something and I can do it and have time to do it, I do it. I'm not a big fan of the concept that limits stimulate creativity. I don't believe in this. I think that simple and flexible tools stimulate creativity.
