MrSwiss wrote:This doesn't mean that I don't understand the code, what I'm currently not seeing is:
*the advantage* it's supposed to *deliver*. (in a way, that procedural can't)
grindstone wrote:Meanwhile I understand the intention, but the implementation is still all Greek to me. From my actual point of view this is unnecessary complicated.
That's ok. I won't waste my time arguing on this one. You can always ask google
about this, and seek the answers that better line up with your way of thinking, be it that OOP is a piece of crap or is the be-all end-all of programming paradigms. Or you can just see it as a way of expressing a solution
that offers advantages and disadvantages, like everything else in life =D
fxm wrote:Now I regret to have sparked such a debate here in this topic that was not intended for it.
Why? It was only a matter of time. In fact, I was pretty surprised it took so long ;)
grindstone wrote:Why that? The way how the communication is implemented is undoubtedly relevant for such a game.
Indeed, but I'd say that it's a little early to worry about those things yet.
You didn't, it was bound to happen with paul doe onboard, since he's all OOP (and, not procedural).
Btw: I tend to agree with Boris the Old's: Five simple Rules
on using OOP.
Interesting, but I prefer S.O.L.I.D.
@all other people, reading this thread:
I don't want yet another stupid argument that leads to nowhere and having to justify
every little snippet of code I post is just ludicrous
. If you think that OOP sucks a$$, then fine, don't use it and throw all the crap you want at it. If you think that OOP is a blessing from the heavens, you'll soon awaken from your dream.
But if I'm actually the problem
here, then just tell me and I'll immediately return to minding my own business and stop contributing anything to this thread at once.
Let's focus on the design
aspect of the game for now, shall we? Things such as ideas, concept art, gameplay aspects, that sort of thing. Implementation details
will come at a later stage. Agree?