   Oppinions on a particular OOP Game Structure
  I was recently googling around, trying to find some guides to read through on ways to implement the OOP techniques that I am learning about in my studies. I want to be able to begin planning and programming my projects in such a way that I get to practice these ideas. While I was searching around, I ran into the following guide:http://www.devmaster.net/articles/oo-game-design/It looked quite meaty and well written, but I noticed the date published was 2004. I'm not really sure how drastically these sorts of paradigms change over the years, or how valid any of what was said really is.I was curious, for anyone generous enough to take a quick skim over that article, what your personal opinion on this particular article was, as well as if it's a good place for me to start learning about OOP as it relates to game structures.I have this strange (irrational?) fear of finding material on the subject, learning it in and out, and then later finding out that what I've learned is far from optimal or even "right". I can't really explain why, but I always have this feeling that I'm "learning OOP wrong". In this sense, I guess I'm looking for some guidance from more experience programmers, so that I don't start heading east when I should be going north =)--Kitt   
Quote:Original post by KuroKittenI have this strange (irrational?) fear of finding material on the subject, learning it in and out, and then later finding out that what I've learned is far from optimal or even "right". I can't really explain why, but I always have this feeling that I'm "learning OOP wrong".That's nothing to worry about. The only* way to get better is to do things the wrong way first, then you will appreciate the "right" ways. I sometimes fear i am doing things wrong, especially in my game since i have no experience in game programming so i don't know how the design should look, but it doesn't matter if it's right or wrong as long as i am constantly evolving and improving the code to make it better.* Ok, maybe it's not the only way.   ;  OOP didn't changed the last decade. There are newer and better UML (UML=unified modelling language, a language to describe OOD(esign)/OOA(nalysis)) tools to help you designing your software, but the main idea didn't change at all. Learning OOP from the given article seems to be a valid way to get into OOP.Have fun :)--Ashaman   ;Quote:I was curious, for anyone generous enough to take a quick skim over that article, what your personal opinion on this particular article was, as well as if it's a good place for me to start learning about OOP as it relates to game structures.I didn't read the whole article, but based on what I did read, I'd recommend that you take what you can from it, but not consider it the 'last word' on OO game design, as it were.There are many ways to approach software design as it applies to games. The article you linked to just represents one person's take on the subject; there's really no 'one right way' to do it. In fact, I would say that in the time since that article was published approaches to game software design have grown even more varied.In particular, I'll mention the idea of component-based entity systems, which I'm a big fan of. At its most abstract, such a system can represent the entities in the game using a database of component objects; the concept of an 'entity' in this context is reduced to nothing more than an ID or a series of messages linking components together. This is a fairly radical departure from the more standard inheritance-based approach, and is something I'd recommend looking into if you're interested in OO game development.I would also recommend that you read this article, just to get a different view on things. The article you linked to presents ideas for creating a generic framework with which virtually any game can be made, but IMO this is a little optimistic (and perhaps not particularly helpful). IMO, the best way to learn good OOD principles with respect to game programming is to work on actual games, but of course YMMV.   ;  According to Steve McConnell and my own experience, object-oriented design is a 'wicked problem'. This means that you will have to design your application in order to find out what works well and what doesn't work at all design-wise.Don't be afraid to just jump in and start coding, you will always have the opportunity to change your design on the go. Additionally, you'll probably make some bad decisions and experience the consequences first hand, which is a great way to develop an OOP 'common sense'.If you are unhappy with concrete parts of your program or something just doesn't feel right, post it on the forums and discuss it with other programmers.To put it simply: Just do it!   ;  Thank you everyone for their replies. So, from what I can understand, it sounds like this is a decent article to read over and absorb, but perhaps I should look around a bit more for something more "fitting", as it were.Does anyone perhaps have any solid recommendations on good texts to read through for some good advice on OOP design, particularly as it pertains to a game structure?Quote:Original post by jyk[snip]I would also recommend that you read this article, just to get a different view on things. The article you linked to presents ideas for creating a generic framework with which virtually any game can be made, but IMO this is a little optimistic (and perhaps not particularly helpful). IMO, the best way to learn good OOD principles with respect to game programming is to work on actual games, but of course YMMV.Thank you for the link jyk! I have been pointed to it many times, and I must say, I wholeheartedly agree with what is being said. There was a time where I thought what I wanted was to build a game engine, but that time is gone. My goal now is to really just build a game, but I would like to be able to have my code look as wonderful as I possible can from the get go, so I'm just trying to figure out what sorts of designs work well, and which tend to cause problems =)   