large scale games oop or procedural ?

[emacrisema]

I made a few games , in which I had ONLY a document class .
for ex: http://www.rockyou.com/games/games-view.php?id=83020
I've read (skimmed) Advanced AS3 with Design Patterns by Adobe Press just before the holidays . I was really proud then .
Two weeks later -surprise- I can't remember a thing .
I mean I know objects should be closed and basic blah blah blah.
But I can't apply all that (except singleton )

Has anyone coded a large scale game without design patterns ?
What's easier , make my game without them (DP) or learn them ?

Thank you

[yell0wdart]

During the game's initial design and coding, I think that question's answer will depend on your mindset. For you, who knows procedural code, and doesn't have much experience with OO design or agile development, procedural will be easier.

For a developer who only knows OO and thinks in design patterns, then OO will be easier to develop.

When it comes time to fix bugs or add new functionality to the game, then OO with design patterns will be FAR easier to maintain, regardless.

[maskedMan]

Also, trying to force OOP when you're new to it can cause you confusion and headaches. For example, you have written many different classes but they are all in fact tightly coupled (they store references to each other, or they all offer static instances of themselves to be freely modified by any other member). This tight coupling negates all the benefits of separating the functionality of the classes and is more or less the equivalent of just moving code around.

Depending on your style, OOP and design patterns can sometimes seem needless. You might wonder when you'll ever use some of the things you're studying until one day it just all falls into place. Even though your first attempts can be dangerously off-base, you have to get them out of the way sooner or later, yes?

Having said this, there's value in knowing when to break the rules. But the trick is you have to know them first. Perfectly encapsulated and well-abstracted code is lovely to maintain, but the greater the amount of indirection, abstraction, and function calling you endeavor the worse your performance will become. Then of course are the situations where you're crunched for time and you just can't stop to think of the perfect way to structure your architecture. Sometimes, things need to be done 'yesterday' as it were. Those are the times when you have to be brave and just do what needs to be done.

[emacrisema]

Well , OOP is definitely not suited for my mindset .
I'm the most lazy and disordered person in the world .
I like simple , effective / hack solutions .
But for reusability and easy debugging it seems OO is the way.
I still don't know which way to go .
I have set my goal at about one month (about 6 hours/day) to make a proper TBS (maybe with multiplayer ).I have found another oop-dp book which seems to take more time explaining the concepts , but I guess without some STRONG examples it will vanish out of my head just like the first one .

Is it time to get real ?
http://gettingreal.37signals.com/toc.php
Or just continue reading books about some OOP concepts that will take ages to get into my blood ?

Well I think you've already answered that , but ... I don't know ... maybe someone will throw some great article with lots of code that will make me the greates actionscript programmer ever

Edit: I think a "open-source" OOP coded game (uml included) might help .Does anyone know any ?

[emacrisema]

I've read 150 pages of Object Oriented Actionscript (Friends of Ed) , and I got to the flex chapter .
They are actually so annoying that they show me how to click next in the flex installation setup (that coming from a book that has OOP in the title ! ! ! ! ! ! ! ) . That's worse then calling me stupid in the face . I really wonder if I should go on ?
How deep could they go into DP if they commited this "murder" ?

Also one of them says on page 84 "I do not normally use public properties in a class and instead expose private and protected properties through getter/setter methods."

There are TONS of web articles where it says clearly " too many getter/setter are the proof of bad design" .

So should I go on reding something like this ? ... I guess not ... but I'm desperate .I need to learn OOP !!!

Thank you

Edit: Wait , there's more , they teach me how to draw a sphere ! LOL
That's it ! This book might be good for my 11 years old brother ! I quit !

[yell0wdart]

This book was fantastic in teaching me design patterns. Might not be quite your speed, but it's a great book to get you started. The code samples are in Java, but it's close enough to AS for you to apply it w/o any issues.

The trick to learning OOP is not in a book, though. You're not going to learn it until you start doing it. I'd recommend picking a couple smaller projects you coded in the past in your procedural style and recode them with OO and design patterns in mind. Keep refactoring and implementing patterns where they seem to work well. As you keep doing it, you'll learn to think that way, and it eventually will fall into place.

[maskedMan]

I get your frustration. I think a reasonably good book on the subject is "Advanced Actionscript 3 with Design Patterns". It's not too overwhelming, and even though it is by no means exhaustive it does a good job summarizing some of the most common patterns and what they are useful for.

I have (and at times like and hate) Head First Design Patterns, which is a Java book but easily applicable to AS in terms of what it teaches you. The style of the head first books is goofy and personable, but I don't think they talk down to you.

About using too many getters/setters, I think it would be useful for you to just go ahead and try it out. Go whole hog and make everything private or protected and see how you personally like it. You may find that you're suddenly thankful that you can offer access to a property via a mutable interface, or you may find it completely worthless and an unacceptable drag on performance. Only once you do it will you get a feel for why and when you should or shouldn't.

(Full disclosure time: I use get/set them all the time, but am beginning to feel compelled to use public variables in classes marked 'final' in the event that I have to use loops or otherwise iterate the structure and I know that the class has no siblings or won't likely be taking part in polymorphism. Problem is that when you do that you shoot yourself in the foot if you program to interfaces, which I am finding to be incredibly useful.)