Re: Data oriented programming

I think my statement was terse and subtle enough to allow for pretty much any interpretation (apparently mostly negative). So let's expand:

I interpreted your post as "you need to design your system with <x> in mind up front." If that's not the case then feel free to ignore my initial reply.

Although based on your reply, I don't think my retort is even necessary, other than to say it's not that easy to understand the performance impact of what you do; it's much more obvious to understand performance from the perspective of what you shouldn't do. It's a very subtle distinction, and doesn't really clash with anything you said.

[And I would also argue that simply "planning early on for performance" isn't really sufficient unless the "plan" is: don't ever write code that will make performance crappy.]

MSN
From: [email protected] [mailto:[email protected]] On Behalf Of Richard Fabian
Sent: Wednesday, October 06, 2010 1:45 PM
To: [email protected]
Subject: Re: [Sweng-Gamedev] Data oriented programming

I'm not sure I actually understand what you've written there (especially the bit about "mean and not possibilities",) but I think my point is orthogonal to shipping issues. Normally, a game has either good performance or bad, and that doesn't really affect whether or not it ships. Normally it only affects what it is shipped with.

Bashing a system into submission is something I have done a number of times, but sometimes we've had to go after smaller fish to bash as the real large fish is just too hard to make good. If you don't consider the difficulty of future optimisations, then you run the risk of having to redo part of the project.

To me, it sounds like you're happy ripping systems out to replace them, and that would make sense if you're working on the same kind of code base game after game, things change, but everything kinda stays the same. That's great, you can throw away whole ways of working and introduce new stuff and see how it works, but when you're doing multiple projects in the same studio without much overlapping tech or at least without much overlapping requirements, your estimated schedules are wild and inaccurate because each project is like you've never done a project like it before. Putting performance estimations off and relying on late in the game optimisation will get you a game, but not one that is great. Something will suffer.

One last point, performance is one of those things that fuels it's own fire. Like asset build optimisations or iteration time reduction. Every time you make one of these things better, it makes the whole studio run faster.


On 6 October 2010 17:53, Mat Noguchi <[email protected]<mailto:[email protected]>> wrote:
I think you overestimate anyone's ability to predict the actual difficulties of shipping and underestimate the ability of programmers to bash a system into submission. Unless you are talking about the mean and not possibilities.

MSN


--
fabs();
Just because the world is full of people that think just like you, doesn't mean the other ones can't be right.

_______________________________________________
Sweng-Gamedev mailing list
[email protected]
http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com