   books, OOP & crossposting SDL tutorials & here
  After some thought I realized that the questions I asked Tim (from the sdltutorials.com) should be more fruitful if shared with a larged audience.Here it goes:==========================================After finishing the Maps's tutorial I got struck (once again) by the uniqueness of Tim's approach. Almost all SDLs tutorials I ever met never really cared about a OOP approach to the design of a game. If I can say so, the Maps tutorial is empowering. Now I have a much better ideia of what is going on in a 2D game.So, after the flattering, comes the question:As to dip my feet on water, my ideia is to create a Everyday Shooter clone, using OpenGL primitives as the "Tiles". But I want to create that using serious OOP and learning more about memory management and multimedia systems development.So.. where can I learn more about this? I've bought already many books on C++, some on game programming, but all this scattered information still doesn't make a whole. When there is a focus on OOP there is not on an actual game. When there is a focus on game programming, they don't use OOP or 'real' design for memory/project management.There is some books I'm eyeing, like game coding complete and Game Engine Architecture.. But I dunno if it will be of use.What about you Tim, what was the road you took? College related experience or hand-on experience?Cheers!Fabio   
  OOP is about modeling problem domain and encoding it using language idioms and features.The only way to use correct abstractions is to thoroughly and completely understand the entire problem space, and be able to express the relations between various parts.For this reason, "serious OOP" has mostly failed. Majority of world has moved to dynamic languages which do not emphasize typical OOP concepts, large-scale Java projects have moved to IoC and DI designs, which are closer to either procedural designs, a lot of work is being done using LISP-and-its-legacy languages, for bulk data processing message- and array-based approaches are used."Serious OOP", as embodied by JEE has failed in practice, since it breaks over long term. It has its use in rigid bureaucracies where everything is dominated by process, and where results need to be just barely passable with regard to some specification.Final nail in the coffin of "serious OOP" was unit testing. Perfect and by-the-book OOP makes it next to impossible, since all resource allocation is completely contained inside opaque implementations. This requires absurdly complicated scaffolding to test even the most trivial things (interface + abstract + concrete + concrete test for each and every class), or it requires deliberately breaking encapsulation in inconsistent ways.For everything else, encapsulation, polymorphism and other OOP ideas are applied as needed, or avoided if necessary.The era of big paradigms is mostly over. If anything, the buzzword of today is RESTful design, but that applies to web space. Everything else is covered by third-party libraries which are glued together as needed.tl;dr; Effective OOP and similar buzzwords cannot be taught apart from basic guidelines, they emerge from experience. But focusing strictly on it is pointless, it doesn't add value. Instead, focus on learning how to solve actual problems. Understand what the "maps tutorial" actually achieves, not how it's coded - that is not what tutorial is teaching.   ;  *looks around at a landscape of people doing serious OO domain modelling and building hefty software projects for it in an agile way**looks at Antheus*Huh?;  My only gripe with his code is him using #define for constants instead of const.   ;Quote:Original post by Katie*looks around at a landscape of people doing serious OO domain modelling and building hefty software projects for it in an agile way*Can you write the above experience in form of a tutorial. So that beginners will be able to read it, and accomplish the same?Can such models be developed by someone without domain experience?Will the results be effective?Isn't the prerequisite to effective OO understanding of the domain, which can then be expressed in any form, including OO? Does the opposite hold? Does thorough understanding of OO paradigm allow one to model a system without domain knowledge?Specifically this:Quote:But I want to create that using serious OOP and learning more about memory management and multimedia systems development.There is nothing OO about memory management. One can throw various patterns and hope they work. But whether char * memory_block is contained inside a class, or a vector or whether it's allocated globally is a consequence of requirements. Or perhaps new works as default memory manager.But none of this is OO. OO may be used to later provide the abstractions or encapsulation of the logic. But it all starts with requirements.So rather than starting with Let's make SDL OO, a better approach would be to start with determining what needs to be done in the first place. "Everyday Shooter Clone" is a rough start, but using OpenGL means that SDL might not be needed. Is portability a requirement, does SDL bring any benefits? Or would a different framework/library be better.The only reason one would put OOD on a document is due to either existing infrastructure (SDL is C library, so it's a counter-indication, SFML would be relevant alternative), due to team's familiarity with OO techniques, or some other reason.Quote:they don't use OOP or 'real' design for memory/project management.Because they don't need to. It's "good enough". 80/20 rule. Apparently there is no need to introduce encapsulation, abstractions, etc... OOP is one way to express the design, but by no means the only, nor does it bring any advantages by itself. Some systems are suitable for strict separation of concerns, others are not.   ;Quote:Original post by ExcessNeoMy only gripe with his code is him using #define for constants instead of const.there is some c style file opening & closing. But I find it good actually, so I can tune the code in other directions, since it is really straightforward.   ;Quote:Original post by AntheusIsn't the prerequisite to effective OO understanding of the domain, which can then be expressed in any form, including OO? Does the opposite hold? Does thorough understanding of OO paradigm allow one to model a system without domain knowledge?You really got a point here. I've downloaded some OO code and it really is pretty hard to go 'backwards' following an already formed structure. When there is no manual provided, I usually use Doxygen to create a fast and lean manual and go following the classes & their inheritances from bottom up. But still not an easy feat without some domain knowledge. Quote:Original post by AntheusSpecifically this:Quote:But I want to create that using serious OOP and learning more about memory management and multimedia systems development.There is nothing OO about memory management. One can throw various patterns and hope they work. But whether char * memory_block is contained inside a class, or a vector or whether it's allocated globally is a consequence of requirements. Or perhaps new works as default memory manager.But none of this is OO. OO may be used to later provide the abstractions or encapsulation of the logic. But it all starts with requirements.I know! what I mean is that I'm always worried about not knowing what a Smart Pointer really is (and how one should use it) or worrying because I havent read the GoF patterns's book. And yes, I'm always worried of where should I should use the stack vs. the heap, when/where/how should I call the memory allocation code. Should it be in a class? what about the pictures? does a class contains it or a data structure should hold it. Such questions are -really- halting my further (personal) development...Quote:Original post by AntheusSo rather than starting with Let's make SDL OO, a better approach would be to start with determining what needs to be done in the first place. "Everyday Shooter Clone" is a rough start, but using OpenGL means that SDL might not be needed. Is portability a requirement, does SDL bring any benefits? Or would a different framework/library be better.I've choose SDL because I found "pure" openGL+GLUT a little daunting. I've dip my feet with Ogre too, same thing. The library is so huge that to even show something on screen there is 100s of code lines! I'm planning on using SDL as structure to work with the sound/controls/general management and use openGL to draw everything on screen... And I want definitely work with portable code. Quote:they don't use OOP or 'real' design for memory/project management.Quote:Because they don't need to. It's "good enough". 80/20 rule. Apparently there is no need to introduce encapsulation, abstractions, etc... OOP is one way to express the design, but by no means the only, nor does it bring any advantages by itself. Some systems are suitable for strict separation of concerns, others are not.that's cool. I was so worried trying to relate all this tiny pieces into a OOD mental framework that I got really stalled.thanks!;Quote:Original post by draconarI know! what I mean is that I'm always worried about not knowing what a Smart Pointer really is (and how one should use it) or worrying because I havent read the GoF patterns's book. And yes, I'm always worried of where should I should use the stack vs. the heap, when/where/how should I call the memory allocation code. Should it be in a class? what about the pictures? does a class contains it or a data structure should hold it. Such questions are -really- halting my further (personal) development...Why on earth did you choose to program in C++ if you don't like asking such questions?   ;Quote:Original post by DevFredQuote:Original post by draconarI know! what I mean is that I'm always worried about not knowing what a Smart Pointer really is (and how one should use it) or worrying because I havent read the GoF patterns's book. And yes, I'm always worried of where should I should use the stack vs. the heap, when/where/how should I call the memory allocation code. Should it be in a class? what about the pictures? does a class contains it or a data structure should hold it. Such questions are -really- halting my further (personal) development...Why on earth did you choose to program in C++ if you don't like asking such questions?no no no. that's not really what I meant. I mean that all those questions seems at time so overwhelming that take to a halt: I'm always asking myself if I should read just another book or start 'hacking' my way to some game, as to see what will happen.   ;Quote:I'm always asking myself if I should read just another book or start 'hacking' my way to some game, as to see what will happen.With design, make the best decisions you can. Is the issue that you can't determine an answer at all? Or that you aren't certain you are making the right choices?You have requirements. Determine possible solutions that fulfill requirements. Compare and contrast solutions. Go with "best" as much as you can determine it. You'll make mistakes. Some designs will be disastrous. And you'll learn.I recoil in horror at the kind of code I wrote 10 years ago. So many design flaws, but at that time, I just made the best decision I could. I worked through problems, came up with a solution I could justify, and implemented it. And I got better over time.Put in a sincere effort. And learn from your results.   