New language features have a place in game code?

[Jimmy Valavanis]

To Jimmy Valavanis:
I would really recommend that you learn OOP and possibly get books and take some courses on this. A full software engineering course would be best, but it will take significant time, maybe years. You'll learn that many of the points that you are making here are not true and are mostly due to your lack of knowledge on the matter, which actually you have admitted yourself.

I admit that I'm unfamiliar with the most new features mentioned here but I'm not unfamiliar with OOP, as my thesis back in early 90's was involving a lot of OOP programming using Borland Pascal 7.0.
I still keep in my bookshelf a couple of my old OOP books (not only pascal but also C++). And I've actually read them all

Long story short: no, procedural programming is neither more efficient, nor it is the best approach at software development, on any possible level. There is no single application that you'd want to develop using procedural approach, trust me on this.

The point is that I don't really like OOP, maybe the majority avoids procedural approaches, but I do like programming this way. Of course I'll re-use a component, or a class to develop something fast, but when I want to write code (not when I want to make a programm to do something - when I want to make something to enjoy making it) I prefer the procedural way.

OOP, though great if you understand it isn't necessary to make a game, but like Lifepower says, it isn't the "best way." You have to work with what you know, however learning new things is always handy. There is a flip-side to this though.

Making games it's my hobby, not my profession. If I have to learn new programming techniques, or even new programming languages, for my job as a software engineer, sure I'll do my homework.

Code should aid the programmer in their creations, not take them over. My advice is to be cautious when adding code to your game projects that are in-progress that is new to you. It's great to learn new things, but to actually finish a project, you need to pace yourself and don't over-exceed your knowledge with research beyond what is needed to complete your current project should you actually wish to finish it. You'll find that this will keep you productive, while allowing you to still learn a few things for each project should you choose to keep pushing your programming knowledge.

Let's imagine a fisherman: He uses a sophisticated trawl with a GPS, a super-tech radar to track the fishes and he is fishing with nets to gather as many fishes as he can to make the living, but during weekend he prefers his little boat and a simple hook because he likes fishing this way. He'll gather less fish, or he 'll need more time to gather many fishes, but he'll enjoy it!

I didn't really mean to get into older concepts like OOP, however since we already broached the topic, I do think it was one of the greatest things to happen to the original Pascal syntax. I, myself have a bit of a hybrid style of coding though. I love writing objects and fleshing them out with all the procedures and functions required, but I hate getting too complex with OOP. I find that you can spend hours and hours designing the "perfect" object class and at the end of your day you may have this great code that can do wondrous things, yet where is your actual game in all of this?

Well, I just love writing procedures instead of involving objects, especially with multi-level hierarchy. In addition, when I'm developing something for myself as a hobbyist I tent to be as low level as I can. Maybe sometimes I'm reinventing the wheel, but that's the way I like it ! I like my "USES" section to include only my code