Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!


1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


spinningcube

Member Since 22 Oct 2007
Offline Last Active Oct 17 2014 02:07 PM

#5145896 I have some new habits.

Posted by spinningcube on 10 April 2014 - 05:02 AM

Very cool explanation Hodgman,

 

For the OOP/OOD debacle I think it is because I have seen much bad OOP code in production systems (I have had my own company since 2006, but admittedly I always have a strong bond to academics, I want to improve scientific data visualisation) and with lots of zealots marrying themselves to concepts that you say (inheritance for re-use, coupling, over-use of templates etc.) where they are "experts" but only experts in making the code more bloated, harder to understand and hard to extend.

 

I've seen this so many times in companies that I think it boiled down to the fact that the designer wanted to have job security by designing something overly complex and that management would never dare to touch. I have also been part of such management and seen it pushed on me.

 

I have always pushed for independent code blocks, modules and as much as possible data oriented programming not because it gives better performance (but sometimes does, in fact most of the time does as access is often linear and sequential (but that is another discussion)) but because it it allows for clean decoupling almost treating the code as some kind of scripting language doing transformations on data.

 

So yeah, when I see clean OOP code I am more than often surprised and it is mostly because the person has gone though the zealot years of OOD (what you call badly taught OOD and I agree, just that it is so dominant right now it is hard to say what is good OOD) then came out "cleansed" of such over complicated notions and has a better flexibility with design and thinking about programming.

 

I have a much easier time thinking of someone with a background with a function based (not functional lambda calculus) experience like C/Pascal will do a better job at designing software than someone with a (bad) OOD background. He or she would use the modules approach of Pascal and apply it to OOP and we would all be happier for it.

 

I am always trying to improve and to know more about OOD (a new improved way) is always interesting.




#5145791 I have some new habits.

Posted by spinningcube on 09 April 2014 - 04:29 PM

(To the guys (as a group) that try to oppose the obvious. Not the OP who is caught it in the crossfire.)

 

If you still don't get it after my posts and the post of hodgman, I am at loss of words.

 

Hang in there some 10+ years and then get back to me.

 

Cheers,

 

 

PS - and then you can buy me a beer ;-) No hard feelings fellows. You just don't want to get it.

 

PS2 - Pro tip. Look me up and see what I have achieved. Then think.




#5145438 I have some new habits.

Posted by spinningcube on 08 April 2014 - 12:03 PM

 

http://www.insomniacgames.com/three-big-lies-typical-design-failures-in-game-programming-gdc10/

I actually took the time to read the PDF out of curiosity (though, it is kind of misleading to post two links, when one is just a couple paragraphs and a link to another).

 

What I got from it is completely different from what you are saying.

[...]

 

None of what he was saying is bashing OOP, in my opinion. Referring back to the aforementioned example of a key => value dictionary, he didn't advocate getting rid of the object entirely, just redesigning how it works on the inside; the interface may even go unchanged!

 

 

So then why is the author summing it up with?

 

(Lie #1) Software is a platform
I blame the universities for this one. Academics like to remove as many variables from a problem as possible and try to solve things under "ideal" or completely general conditions. It's like old physicist jokes that go "We have made several simplifying assumptions... first, let each horse be a perfect rolling sphere..."
 
The reality is software is not a platform. You can't idealize the hardware. And the constants in the "Big-O notation" that are so often ignored, are often the parts that actually matter in reality (for example, memory performance.) You can't judge code in a vacuum. Hardware impacts data design. Data design impacts code choices. If you forget that, you have something that might work, but you aren't going to know if it's going to work well on the platform you're working with, with the data you actually have.
 
(Lie #2) Code should be designed around a model of the world
 
There is no value in code being some kind of model or map of an imaginary world. I don't know why this one is so compelling for some programmers, but it is extremely popular. If there's a rocket in the game, rest assured that there is a "Rocket" class (Assuming the code is C++) which contains data for exactly one rocket and does rockety stuff. With no regard at all for what data tranformation is really being done, or for the layout of the data. Or for that matter, without the basic understanding that where there's one thing, there's probably more than one.
 
Though there are a lot of performance penalties for this kind of design, the most significant one is that it doesn't scale. At all. One hundred rockets costs one hundred times as much as one rocket. And it's extremely likely it costs even more than that! Even to a non-programmer, that shouldn't make any sense. Economy of scale. If you have more of something, it should get cheaper, not more expensive. And the way to do that is to design the data properly and group things by similar transformations.
 
(Lie #3) Code is more important than data
 
This is the biggest lie of all. Programmers have spent untold billions of man-years writing about code, how to write it faster, better, prettier, etc. and at the end of the day, it's not that significant. Code is ephimiral and has no real intrinsic value. The algorithms certainly do, sure. But the code itself isn't worth all this time (and shelf space! - have you seen how many books there are on UML diagrams?). The code, the performance and the features hinge on one thing - the data. Bad data equals slow and crappy application. Writing a good engine means first and formost, understanding the data. 



#5145435 I have some new habits.

Posted by spinningcube on 08 April 2014 - 11:55 AM

The only good thing about OOP is data encapsulation and the best case scenario for OOP is binary interface classes where the user has no access to the inside code.

 

When it comes to inheritance I am basically against both shallow and deep ones as both create a co-dependence on some pre-set design and therefore consequently create problems with code re-use as you are stuck to a certain pattern.

 

For example the gravity function would be re-usable but not a gravity class given that the in parameters are raw data such as arrays of floats or similar. What is even more interesting is when it comes to performance where OOP basically has to pack it and go home.

 

The root of all evil and the great temptation to do wrong is as hodgman pointed out, the article pointed out and as I have pointed out Object Oriented Design.

 

OOP in itself is just "a neutron bomb kit" but combined with OOD we get the real danger :-) Then the neutron kit is assembled and presented as something great when if fact it will just blow up and leave a wasteland to the code.

 

OOD in this case being UML design, finding objects from problem specifications etc. Basically what many program design books are preaching.

 

The best of both worlds is possible and as pointed out several times OOP when treated as structures or the very naive part of OOP is used can be a good tool.

 

One example I can come up with is a recent project where I did a 3D voxelisation of a brain. The brain model was in fact based around a tiny structure of voxels. I fed them to different functions that did the voxelisation, the bounding volume hierarchy, ray tracing etc... And it was all done without the bounding volume hierarchy knowing about the brain or even voxels for that matter.

 

I have some quite nice large functions that take the voxel data as in parameters and transform this data into other structures. It's beautiful.

 

At the same time having some form of OOP was good for the brain model where I hid the 3DS loading in another class and lo and behold I did use sub-classing for the GUI system as it made sense to have some parts virtual functions.

 

When OOP comes up however most of the time OOD is implied and that has killed many promising projects by over-engineering problems with complexity that was never there.




#5145346 I have some new habits.

Posted by spinningcube on 08 April 2014 - 08:24 AM

Nice example hodgman!

 

 

PS - I should make you my personal PR spokesperson ;-)




#5145337 I have some new habits.

Posted by spinningcube on 08 April 2014 - 08:10 AM

My interpretation of this is that the more you idealise your problem and your problem domain using objects, the more you stereotype your problem and you in fact create a new one, that might actually be harder to solve. For example as in the slides with the chair, why is there a chair object that you can act upon, rather than a game object that happens to have a "sitable" tag?

 

I still use objects such as mesh, grid etc... but I try as much as possible to make them not contain the data but rather be a table of functions that take data as parameters. The more you contain the more "dead" your code becomes.




#5145324 I have some new habits.

Posted by spinningcube on 08 April 2014 - 07:34 AM

That is just me being me ;-)




#5145318 I have some new habits.

Posted by spinningcube on 08 April 2014 - 07:11 AM

http://www.insomniacgames.com/three-big-lies-typical-design-failures-in-game-programming-gdc10/

 

Maybe :-) I'm just too much of an idealist trying to wake people up by shaking up their beliefs.

 

I hope someone actually reads the link and takes home a betterment to their coding style and design thinking.

 

Cheers,




#5145308 I have some new habits.

Posted by spinningcube on 08 April 2014 - 06:49 AM

http://www.insomniacgames.com/three-big-lies-typical-design-failures-in-game-programming-gdc10/

 

Haha!

 

Oh it's refreshing how programmers react with their gut, religiously bashing what they cannot understand or have a blind spot to. Talk to any game (or non-game) programming veteran and they will show you how

 

OOP design leads to zero core re-use (this is sold as the big thing but in fact more than often leads to code trashing)

Function based and data oriented is plug-and-play

OOP for simple data encapsulation is ok. (I never said I don't use structs or templates and other "naive" OOP concepts)

How thinking of objects and object-to-object interaction leads to more complex code while data transformations leads to less complex.

 

No this has nothing to do with entity-component which in my mind is also an OOP fallacy. Hah! Now I just upset two hornets nests...

 

If you actually read what I have in the link (will take maybe 40 min) you see it's from seasoned programmers from Insomniac games, with the best programmer working environment in the industry. Is that a coincidence? Maybe they actually think less stereotyped and more free about programming?

 

Meditate on that :-)

 

PS - why do I even bother...

 

PS2 - The reason I think OOP is used in programming is to increase code trashing, design cycles and increasing complexity such that more money can be demanded from clients. I think that was the original factor ;-)




#5145293 I have some new habits.

Posted by spinningcube on 08 April 2014 - 05:22 AM

Since it falls on some deaf ears.

 

http://www.insomniacgames.com/three-big-lies-typical-design-failures-in-game-programming-gdc10/

 

https://d3cw3dd2w32x2b.cloudfront.net/wp-content/uploads/2011/06/threebiglies2010.pdf

 

Short version:

 

(Lie #1) Software is a platform
I blame the universities for this one. Academics like to remove as many variables from a problem as possible and try to solve things under "ideal" or completely general conditions. It's like old physicist jokes that go "We have made several simplifying assumptions... first, let each horse be a perfect rolling sphere..."
 
The reality is software is not a platform. You can't idealize the hardware. And the constants in the "Big-O notation" that are so often ignored, are often the parts that actually matter in reality (for example, memory performance.) You can't judge code in a vacuum. Hardware impacts data design. Data design impacts code choices. If you forget that, you have something that might work, but you aren't going to know if it's going to work well on the platform you're working with, with the data you actually have.
 
(Lie #2) Code should be designed around a model of the world
 
There is no value in code being some kind of model or map of an imaginary world. I don't know why this one is so compelling for some programmers, but it is extremely popular. If there's a rocket in the game, rest assured that there is a "Rocket" class (Assuming the code is C++) which contains data for exactly one rocket and does rockety stuff. With no regard at all for what data tranformation is really being done, or for the layout of the data. Or for that matter, without the basic understanding that where there's one thing, there's probably more than one.
 
Though there are a lot of performance penalties for this kind of design, the most significant one is that it doesn't scale. At all. One hundred rockets costs one hundred times as much as one rocket. And it's extremely likely it costs even more than that! Even to a non-programmer, that shouldn't make any sense. Economy of scale. If you have more of something, it should get cheaper, not more expensive. And the way to do that is to design the data properly and group things by similar transformations.
 
(Lie #3) Code is more important than data
 
This is the biggest lie of all. Programmers have spent untold billions of man-years writing about code, how to write it faster, better, prettier, etc. and at the end of the day, it's not that significant. Code is ephimiral and has no real intrinsic value. The algorithms certainly do, sure. But the code itself isn't worth all this time (and shelf space! - have you seen how many books there are on UML diagrams?). The code, the performance and the features hinge on one thing - the data. Bad data equals slow and crappy application. Writing a good engine means first and formost, understanding the data. 



#5145019 I have some new habits.

Posted by spinningcube on 07 April 2014 - 07:38 AM

My take on this. As long as you move away from encapsulating data in objects and rather work on data in its rawest form and sending them to functions - the better.

 

However what I see in your approach is some form of super-object-oriented or semantics based rule language. As I abhor OOP and especially OOP design based principles, this would be the pinnacle of bad programming practice as it cements the use of objects that make the problem more complex and harder to solve.

 

Sorry to sound so harsh, but I really believe that what you do will bite you in the end.

 

You just create massive confusion like this and your code would become unmaintainable.




#5144980 Networking for cheap from a Personal Cloud Device?

Posted by spinningcube on 07 April 2014 - 04:36 AM

I personally think that building a tinier PC with just the minimum amounts of processing power you need for a game server would be cheaper than getting a cloud storage system in itself. Well, maybe not, but you can easily get a very good server for 400 USD or less. The lower the power (the lower the heat) and the less the noise of the fans the better. On this you can trust me (that less noise and less heat is a blessing), sitting in a room with 10 nodes at the moment with super silent 65W Hashwells. 




#5141462 Uniform grid traversal

Posted by spinningcube on 23 March 2014 - 09:58 AM

Forget it. Future proofing code is the source of all procrastinations (trust me, I am fighting my instinct to do the "smart thing" every day :-) ). When you want to write your improved algo you will know better how to adapt and how to change it. No need to write a thesis about ray intersection abstraction or bit pattern matches. The code used in production renderers using octrees and sparse voxel octrees (whih I think are just a fad and so does John Carmack ;-) ) is so human unreadable that it hurts the eyes. It's layers of hack on hack of bit pattern shifts and masks that you won't know what is going on.

 

Long story short. Just implement what you have and think of speed and other data structures later.




#5140752 Uniform grid traversal

Posted by spinningcube on 20 March 2014 - 02:16 PM

http://www.cse.yorku.ca/~amana/research/grid.pdf

 

/thread ;-)




#5138928 Software rendering tutorials/examples

Posted by spinningcube on 14 March 2014 - 06:10 AM

Fabian Giesen also touches upon the same technique that I mentioned in my first post, that is rendering with half spaces. It's the approach best suited for a software renderer and is used in top of the class software driver implementations. To approach software rendering today with a scan line rasteriser is fun as a hobby project but will lead nowhere as the real speed comes with multi-threading and therefore from a binning or tiled based approach.






PARTNERS