Re: Hooks

Richard Fabian <[email protected]>
Newsgroups gmane.games.devel.sweng
Message-ID <[email protected]>
On 8 June 2010 21:46, Brandon Van Every <[email protected]> wrote:

> On Tue, Jun 8, 2010 at 3:33 PM, Richard Fabian <[email protected]> wrote:
> > OO C++ might be nicer to look at than data oriented C++ (if it's done
> right)
> > but it seems that as it so seldom is done right, can't we just move to a
> > paradigm that newbies will be able to understand enough to not cause us
> > massive grief later on when we pick up the pieces?
>
> Why is "avoiding massive grief later" a commercial goal?
>

Because later can just as often be before the product has released but after
the coder has left. Also, Why is "enforcing massive grief later" a
commercial goal? The choice of paradigm doesn't change the up front
development cost significantly, so surely you can see the inversion is just
as valid.

Maybe you've only worked at games companies that produce one title before
folding, but all but the first one I worked at have been long term players.

Also simpler development methods can be quicker to pick up for newbs too. So
there might be a fiscal-quarter related benefit too.

Maybe OO can be quicker to pick up in a higher level language like C#, but
commercial games developers hardly ever have the option to work outside
C/C++. The idea that OO C++ is easier to code in than procedural C++ is
likely merely a bias of experience. I certainly don't remember it being
easier to start with, even though I class things up by instinct now.

-- 
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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.