New language features have a place in game code?

[Eric]

Generics are very useful for containers, they help maintain strong typing and reduce the number of casts. Outside of that, they can get a bit obtuse (IME). The built-in Delphi generics are quite inefficient though, so those are probably not a good idea in game code (not to mention the compiler isn't very good with them, and you can end up with weird internal compiler errors or huge executables).
For simple containers, they compete with arrays (dynamic or not), which typically have less overhead, and can be just as strongly-typed. So for games, I would say they're good outside performance-critical code, and the with caution.

Duck-typing I'm not a fan of, it's just too easy to let a dragon that can quack & walk into the pond (with devastating outcome).
Also many terms (in human language) are just too ambiguous, a good deal of programming is about removing the ambiguity to express what needs to be done clearly.

Await and asynchronicity are both useful and impractical for games, useful because it means you can use multi-core more easily, and impractical because unless you're on a console, you can't assume a certain number of cores are at your disposal, nor how much time it'll take to do something. So they can only be used for stuff peripheral to the game (like pre-loading textures, reducing wait between levels, etc.), but can't be used for anything time or frame-critical (unless you bump the requirements to things like "quad-core CPU required and I mean a real quad-core not just a dual-core with hyperthreading")

Nested classes, well the only practical use seems to be for enumerators, apart that, they just get too verbose and too specific.

for..in loops, they save some typing and improve clarity, I use them whenever I can

final methods & sealed classes: I use them mostly to guarantee a class isn't subclassed, which means you can do "if obj.ClassType=TSealedClass" rather than having to use "in". It's a micro-optimizations though, and may not be relevant in general, but it can have its uses.

anonymous methods: can be quite useful and reasonably efficient, though in the case of Delphi, be wary of compiler internal errors.

[Jimmy Valavanis]

Hmmm, most of these new features seems complete new to me.
Generics must be the C++ equivelant for function templates, right? You can save some typing, but nothing more. Really, besides the max and min functions where else can I use it? I'd prefer to rewrite some code.
Oxygene's await keyword and nested classes...., well, I don't know what are these, really!
For..in loops. Come on, this is javascript, not pascal! Besides I'm trying not to use for loops at all, instead I like writing while loops using for the exit-loop-contition some pointer checking (perhaps a bit faster code).
final methods: Unfortunatelly I don't know what's this.

Even when I'm using forms, not only in games, I'm trying to stay 'procedural", without using objects/classes. Also as an old school programmer I 'm not used to some newer features. The only, let's say, year 2000 era feature I'm using are the optional parameters with default values.

[pitfiend]

I never used any new feature since delphi 7. Some time ago I migrated some customer applications to delphi 2007, just to improve UI with that fancy glass stuff on windows 7. I stay away from generics, anonymous and unicode, we don't need that. For loops, I like while/repeat ones 'cause they are flexible, you define elegantly when they must exit and didn't breaks readability as the break clause in for loops, it's ugly as using goto... yuck!

[SilverWarior]

Even when I'm using forms, not only in games, I'm trying to stay 'procedural", without using objects/classes. Also as an old school programmer I 'm not used to some newer features. The only, let's say, year 2000 era feature I'm using are the optional parameters with default values.

Do you know that each form, control, component is objec/class? So while you think that you don't work with objects/classes you are. The only difference is that you only use existing predefined classes and don't define new ones by yourself.
But object/classes are whats making object orineted programing language to what they are. When used properly they can be verry powerful.
For instance. Lets say that you have your own class defining some ingame character. This class can contain various properties and even methods.
Properties act similar to variables but the main difference is that you can assign special so caled getter/setter methods to each property. In setter method you can for instance validate that new value of this property is valid before you change it to a new value. In getter mehod you can even calculate the result from several different variables. The best thing is that all this is being done automaticly.
Methods can be used for executing some special parts of code wich is related to this class.

For more info on classes I recomend reading:
http://delphi.about.com/od/oopindelp...elphi_oop4.htm
http://delphi.about.com/od/oopindelp...elphi_oop6.htm

Or even better go trough all Object oriented tutorials staring with
http://delphi.about.com/od/oopindelp...elphi_oop1.htm

[Jimmy Valavanis]

Do you know that each form, control, component is objec/class? So while you think that you don't work with objects/classes you are. The only difference is that you only use existing predefined classes and don't define new ones by yourself.

Obviously, if someone uses forms and components is working with classes. But I prefer to write the core/functionality of each program without using oo and just use the VCL for the user interface. It's, let's say, my personal way of programming. In most cases when I'm using classes is when I have to make a component, in fact I'm still using components I've made a long-long time ago, some of them are still in my old page (http://www.geocities.ws/jimmyvalavan...phi/index.html). But as I said, I prefer "procedural" programming.

But object/classes are whats making object orineted programing language to what they are. When used properly they can be verry powerful.

Sure, but on the other hand there is nothing you can do using classes that can not be done procedurally. I'm talking on problem solving / solution aspect.

For instance. Lets say that you have your own class defining some ingame character. This class can contain various properties and even methods.
Properties act similar to variables but the main difference is that you can assign special so caled getter/setter methods to each property. In setter method you can for instance validate that new value of this property is valid before you change it to a new value. In getter mehod you can even calculate the result from several different variables. The best thing is that all this is being done automaticly.
Methods can be used for executing some special parts of code wich is related to this class.

Data validation can be done as well as without using classes. An, well, nothing is being done automaticaly, you still have to write the code for the class. Instead of writting a procedure that evaluates a result from different variables you write the "getter" function. Instead of writting a "setter" funcion for your class, you write a validation function before setting the data. It's the same thing.

Now imagine that you have a few hundred available fuctions to define the behaviour of you character. What will you do? Write a class with hundreds of member functions, all in the same unit, having a 1MB source code unit, or using functions and split the source code into more units? From my point of view the second solution seems easier to maintain.

[LP]

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.

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.

[WILL]

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.

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.

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?

[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

[LP]

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.

I agree, there is YAGNI principle that describes exactly that.

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!

In this case, OOP is the little boat and a simple hook, which later you can upgrade to GPS and super-tech radar. But, you are trying to fish with a fork swimming in an inflatable toy. Sure, it can be a fun sport, but you won't get much fish, if any.

P.S. Jimmy, please try not to get offended, there is no need to multi-quote everything and argue about what you don't know or don't fully understand (remember unskilled and unaware article). My suggestion to you was to try and learn new things, which could be fun and you might even get surprised.

The fact is, you can use OOP for the smallest applications and create elegant code, that later you can extend, modify and even reuse. If you "think procedural" and use OOP mostly as a data type (e.g. objects for data) or only because you have to, this approach is called anti-pattern. If you want to keep closed-minded about it, nobody is forcing you to try new/better ways, just keep using what you know.