Re: sparse components
Warrick Buchanan <[email protected]>
| Newsgroups | gmane.games.devel.sweng |
|---|---|
| Message-ID | <[email protected]> |
#0 - I wouldn't disagree with the first part (As long as your game isn't a dog) but I would highlight that OO isn't the only tool in the box for communication and organisation (Not that you said it was). Also I think its interesting to look at what more functional approaches do in terms of unit testing and task allocation within a team. Taking that into context with opinions on singletons is also interesting. #4 The majority of humans are dumb and those that are smart are dumb in many different ways. But in my experience game developers actually have the passion to want to do their job right or learn to do so which has to be a good thing. I think the whole argument is that too many programmers have been taught to think purely in terms of _just_ OO which is a subset of a larger frame of understanding, not that it isn't a valid subset to put into use. #5 That seems a bizarre statement suggesting that people said the requirements of a game will stay static over the duration of project. I don't believe that was meant at all and is obviously unrealistic no matter which view point you hold. I think if you work out your dataflow during the initial planning stage and revise it as your project evolves you will be in a much better position. On an interesting side note I think this works well with methods such as AGILE etc. From: [email protected] Date: Fri, 28 May 2010 13:08:36 -0700 To: [email protected] Subject: Re: [Sweng-Gamedev] sparse components 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 _________________________________________________________________ http://clk.atdmt.com/UKM/go/197222280/direct/01/ Do you have a story that started on Hotmail? Tell us now _______________________________________________ Sweng-Gamedev mailing list [email protected] http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com