Re: sparse components

for 0: OOP is great at helping you minimize one type of bug. Normally, its
the bugs to do with writing code in object oriented style.
data flow oriented development helps you debug your data flow. Have you ever
noticed that most of the time in OO debugging you're trying to figure out
"what happened", well, that's the kind of bug that data flow oriented
development loves solving, as the flow can be traced back so much simpler
than an object's life rolled back.

If you note the decision table e-mail i sent, debugging incorrect states
becomes a simple task of analysing  the decision variables leading to the
transition.

for 4: unfortunately, those crutches aren't actually very strong anyway, and
it takes years to learn how to use them properly. Keeping it even simpler
would help out a lot of the lesser mortals, and we all know anyone can get a
job working in a bank doing SQL ;)

for 5: You're right, games are most definitely not static problems, and data
flows cannot be determined before you start coding, but data flow oriented
development actually gets you that much better than object oriented ever
did, as many times I've seen OO engines fall over dead with data format
changes, but data flow oriented engines (such as SQL servers) take schema
updates and happilly carry on as if nothing worrying had happened.

On 28 May 2010 21:08, Dan Nelson <[email protected]> wrote:

> Long time lurker, first time poster.  After reading that blog entry by Mike
> Action, I have to add this:
>
> (Lie #0) Maximizing performance is more important than minimizing bugs.
>
> In every real-world game project I have ever worked on, bug counts consumed
> hundreds of times more man hours than optimization or performance work.  Any
> software engineering technique that helps a group of coders communicate and
> organize shared work, and thus minimize bugs, is hugely valuable.  OOP is
> great at that.
>
> Other lies:
>
> (Lie #4) A majority of game programmers are smart.  Smart enough to think
> about problems without "crutches" like OOP.
> (Lie #5) A game is a static problem.  The data flow connections can be
> determined during a planning stage and will not change drastically over the
> course of the project.
>
>
> On Fri, May 28, 2010 at 12:37 PM, Tom Plunket <[email protected]> wrote:
>
>> > I think really that it's the implementation of OOP that people have
>> problems with when looking for performance.
>>
>> People tend to bunch "everything" together.
>>
>> The performance requirements for something that you're doing once a
>> frame is a lot looser than the requirements for something you need to
>> do a million times a frame.  Folks who say "OOP is bad" miss the point
>> (as has previously been pointed out).
>>
>>
>> -tom!
>>
>> --
>> _______________________________________________
>> Sweng-Gamedev mailing list
>> [email protected]
>>
>> http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com
>>
>
>
> _______________________________________________
> Sweng-Gamedev mailing list
> [email protected]
> http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com
>
>


-- 
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