Game programming language

Of course in Object Oriented i think about :
- inheritance
- function overloading
- polymorphism
- generic types

And how will this be better than C++?

C++ syntax is cryptic and a lot of programmers don't even know the function of keywords like "const" or "inline". Contract programming doesn't exist in C++ and object pointers are a pain with operator overloading. We can get ugly code like this :
(*a) = (*b) + (*c)

Quote:

Original post by vNistelrooy And how will this be better than C++?

Being better than C++ is easy.

C++ is an old language, from a time when advanced type theory was not fully fledged enough to allow for a decent universal polymorphism while still allowing overloading. The creators of C++ did not have access to theories advanced enough to do better than the code-bloating C++ template system.

C++ owes several of its inherent design flaws to its backward compatibility with C code. The fact that string literals are of the (demon spawn) type const char *, and not std::string is one such example. The fact that 2<:2+++c]; evaluates to zero when c == "hello" is another.

C++ is a language that assumes the programmer knows what he does, all the time. As such, there are many cases where C++ will just accept a construct even though it goes against what the programmer wants, when Java would have asked for an explicit type cast, or C# for an explicit fall-through. The programmer should only be expected to know what he does when he explicitely uses a bug-prone construct using redundant proof that he is aware of it.

C++ syntax is not a yacc-generated syntax. In fact, the C++ syntax allows so many things that you will be seeing more and more "typename", "template" and other such identifiers popping all over your code to actually help the parser parse your code correctly.

C++ lacks a decent module system (in particular, the forward-declaration requirement is bad), and its access restriction constructs are incomplete (there's more to live than private, protected, public) and interact badly with templates.

C++ leads people to believe it is cross-platform while this is not the case. While the main platforms (on the i386) do have fully compliant C++ compilers in the form of g++ this is not the case for other platforms (such as embedded platforms without exception support, buggy RISC processors that do not allow functions that are too long, or Symbian OS which prevents static variables and as of yet does not have a stable STL implementation available). Not to mention space probes, which only have C compilers installed.

C++ implements OOP in one of the worst ways possible (although maybe that of Objective Caml sucks even more). Look at C# or Java for decent OOP implementations, or CLOS for a complete OOP implementation. Also, C++ fails to properly implement functional programming (neither did C#, but at least it works a little bit better).

C++ enforces a low-level mentality in beginners because of the false assumption that "closer to machine code" implies "higher speeds". That assumption is only true for small portions of code (say, a 50-line routine) on which professional coders spend a lot of time on (1-2 weeks). Spending 2 weeks per 100 lines of code in C++ is an excellent way to spend 10 years finishing a bomberman clone. Most of the time, what is better is a higher level language with the possibility of inlining hand-optimized low-level code into critical areas.

What kind of advantages would a language have over C++ then?
- Reference semantics
- Readability enforced by compilers
- Semantics more adapted to game development (such as events, garbage collecting)
- Faster (easier when you have a higher-level language).
- Less bugs through the use of redundancy of bug-prone constructs.

So we should have a language with code clarity enforced as Python, OO-Implementation like CLOS or Eiffel, Contract programming like Eiffel and fast memory management (smart pointer in non cyclic data structure). I don't think that a total GC system is a good solution because of the loss in performance and in control. Game are usually using non cyclic data structure so a good smart pointer implementation should be sufficient and for other objects manual deletion could be used.

Worse is better, so C++ wins.

Quote:

C++ is a language that assumes the programmer knows what he does, all the time.

I thought a programmer should always know what (s)he's doing, especially if (s)he's playing with highly complex and powerful languages like c++.

C++ was designed at a time when programming was a task performed only by educated programmers who knew what they were doing and were doing by proffession, and not by programming-hobbyists (like mois) who just love to code and have never finished a single project.

Blaming C++ (or C) for things it cannot do, when still prevailing more than 20 years after its birth, is at least ungrateful, in my opinion.

C/C++ where not designed to program for games or for the internet. It was designed for all of these purposes.

I have to work with Java for my current Job and I dislike the OOP and otherstuff of that language. I do like C++ much better.

But what I really don't like about Java is that you tend to do things like
well let's ... I want to do this ... mhhh ... might class A be good for that? ... ohh then I need to put things in class B ... use that with class C ...
and so on ... from a speed perspectiv this is really bad.

I agree that C/C++ should not be the first language to learn (mother language effect).

C++ has it's flaws!
I leard that you should you the language that fit's the job.

Quote:

Original post by Snatch ... And perhaps : - Smart pointer integration ( for example you could have a "new" operator like C++ but also a "newSmart" which create an object which could be deleted automaticaly ) - Possibility to create event in an object the same way we create methods or attribute - Operator overloading ( I love this syntaxic sugar ) - All the object we manipulate are pointer (the same way Java does) - Native compiler (or compiler to C like Eiffel ?) If you have any idea please give it to me !

Smart pointer integration: Why not create ur own version of newSmart, maybe say thru templates? I've not done it but I dont think it will be that difficult...

Quote:

Original post by thecrow21 Quote: C++ is a language that assumes the programmer knows what he does, all the time. I thought a programmer should always know what (s)he's doing, especially if (s)he's playing with highly complex and powerful languages like c++.

Such programmers do not exist. Everyone loses their concentration once in a while.

Quote:

C++ was designed at a time when programming was a task performed only by educated programmers who knew what they were doing and were doing by proffession, and not by programming-hobbyists (like mois) who just love to code and have never finished a single project.

Even an educated programmer can forget a "break;" in a switch case or call an overloaded function without realizing that an implicit cast will occur. Sure, these kinds of things are stupid mistakes, but they happen not because the programmer is uneducated: they happen because no human being will ever be able to produce enough concentration to write flawless code for eight hours a day, five days a week.

And even then, a programming language is a tool. An elitist language that can only be coded correctly in by the best programmers is just a very lousy tool, no matter what kind of coffee it makes. Making sure that an obviously bugged piece of software can only be compiled through sheer persistence against dozens of errors reminding you that you're doing something wrong is an excellent idea, and makes for a great tool.

Quote:

Blaming C++ (or C) for things it cannot do, when still prevailing more than 20 years after its birth, is at least ungrateful, in my opinion.

The only way to go forward is to constantly criticize what has been done, and to remember the mistakes so you don't repeat them.

Quote:

C/C++ where not designed to program for games or for the internet. It was designed for all of these purposes.

Which begs the question: why are they still used for things they were not created for? Wouldn't creating a new tool for the job be more efficient?

I often ask myself, "why do I keep coding in C++"? And sadly, the only answer I can find is "Because that's the language I know best."

A language is never "only a tool", it always constraints and shapes the way we think about problems.

Quote:

why are they still used for things they were not created for? Wouldn't creating a new tool for the job be more efficient?

Anyone defining a function or class creates words of a language to describe solutions for his problem domain. The programming language only gives a starting set of words and a lot of rules on how you can or can't combine them and what syntax you have to use.

Creating a new programming language isn't a good idea in general. Why do you think the creators of the new language will do a better job than those who created the languages that exist now?

Quote:

Original post by Trap A language is never "only a tool", it always constraints and shapes the way we think about problems.

When you only have a hammer, all the problems are nails... Of course, as with any tool, no language ever matches perfectly a real-world problem. That being said, however, it is much better to use a language close to the problem being solved, so the constraints don't choke you.

Quote:

Quote: why are they still used for things they were not created for? Wouldn't creating a new tool for the job be more efficient? Anyone defining a function or class creates words of a language to describe solutions for his problem domain. The programming language only gives a starting set of words and a lot of rules on how you can or can't combine them and what syntax you have to use.

This reminds me of the game "taboo". Implementing a thing from almost scratch in a language is acceptable, I guess. However, when each definition needs to be contorted so you can implement by hand the features you need into your language, this waste of time is not acceptable anymore. A clear example would be using C versus sed. Both are turing-complete languages, but I would not attempt to write a math library in sed, or a html-highlighter for source code in C. Sure, you can build the tools you need from the tools you have (as in most programming languages), but in the end they'll still end up being more awkward than those native to other languages.

Quote:

Creating a new programming language isn't a good idea in general. Why do you think the creators of the new language will do a better job than those who created the languages that exist now?

They can do better, if only by not repeating the errors of previous languages. Also, science is moving forward, and pretty fast. Type theory, static analysis and several other nifty areas of computer science have changed (or appeared) since C and C++ first came around.

I've seen this kind of threads from time to time asking for ideas to create a new language. All of those threads come to a simple conclussion that C++ is all that is required.

The problem in this kind of threads is that the central point they are missing is that GAME PROGRAMMING is not a 'TASK' but an 'OBJECTIVE'. Let me explain.

If you want to program a script... do you use Phyton? Lua? you chose any of them because its their purpose. If you want to create graphical effects, do you use HLSL? GLSL? you choose.

But game programming is not a task. Game programming is the union of many libraries/languages in order to create an interesting experience for the user. The language you use to unite all the scripts/graphics is your own choice. You cant create a 'game programming language' because you are missing the point.

C++ is not the only language for game programming. If anyone doesn't have enough experience to use it then he can use any other language. Theres Java ot .Net for example, great options. But its as good choice as VB or Pascal/Delphi.

I've used a large number of languages, I think I know more than 20 programming languages (with variations). But in all this time, the only language that has let me do just anything with no complications is C++. So unless you create a programming language that can do
LPFIRSTPERSONSHOOTER lpFPS = new FIRSTPERSONSHOOTER(DIRECT3D);
lpFPS->run();

Then I will just keep using C++.
Luck!
Guimo

Despite all it flaws (real or perceived), C++ is perfect for game programming for two reasons:

1. It is adaptable. Platforms change, but the language remains (mostly) the same.
   
2. It encompasses a wide range of software abstraction -- from bit-twiddling to meta-programming and OOP.
   

Anyway, there are plenty of applications where C++ is not the best choice. In those cases, just use something else.

It encompasses a wide range of software abstraction -- from bit-twiddling to meta-programming and OOP.

That is right C++ is adaptable, but when you try to "adapt" it with things like meta-programming you are not doing C++ any more ! Modern games are complex and contain code in shading languages, script languages and others. But the main part : "the glue" is nearly always done in C++. But C++ is not adapted to this, for proof we can think about problems of dynamic library in C++. If ugly thinks like COM or XPCOM have appeared it was because C++ is not good as a glue !

DarkBasic.

I'm not saying that DB is good, great, bad, or otherwise. I am pointing it out for the people that say you cannot create a game programming language.

CoBol, RPG, C, etc weren't all created solely because people wanted to make a different language. They were created to fit different needs.

A good example is the 'evolution' of programming languages. In Pascal or C++ when you wanted to make a window for the Windows platform, you constructed the window, assigned its attributes and then you were able to code the contents within it. Once Windows became commonplace, those steps became repetitive and redundant. Libraries were added for it and eventually the next level of the languages showed up. The evolution was Visual C++ and Delphi.

One can always take an existing language (C++) and add libraries to it, but that doesn't necessarily make it faster or easier to use the language for a specific purpose.

Creating a game programming language simplifies a lot of background tasks so that the programmer isn't dealing with the background aspects and only deals with what it is he needs to do.

There's a different between programming a game and getting a game programmed.

If your job is to get a game programmed for Windows using DirectX, you'd probably want all the background stuff done
- the draw surface understood and easily definable
- memory allocated for bitmaps, images, and such
- routines built in for handling animation
- collision detection variables
- and a host of other things so that you do not have to reinvent the wheel or unecessaily type out things that should be understood for drawing to the screen and managing multimedia objects.

If your desire is to program a game, however, you might not see the advantages of a game programming language because it is handling things that you might want to handle yourself. That's the difference between a mechanic/tech and an end user. The mechanic wants a dash of gauges and controls to manipulate the fuel/air ratio from inside the car... the manual transmission car. The end user wants to turn a key and go. Their task is to drive to their destination, not to control every aspect of the driving.


Now, many of today's programmers are much the same as the end user above. That's why RAD programming is a selling point for quite a while now. The programmer has to or wants to make a game. Their concern is completing the game... the destination. "malloc" is an obstacle. Defining draw surfaces is an obstacle. They have a contract to make the little ball go ping on one side of the screen and pong on the other side... preferrably with a whole lot of cinematics and cutting edge glowy effect and shiny thing.


But to get back on track, while the person focused on programming a game would much rather the control and functionality of C++ where he can pick and choose his libraries and optimize his code, the person whose goal is to get a game programmed would opt for a game programming language that handles the background things for them.
- memory allocation
- common algorithms
- polygon/wireframe handling routines
- instructions specifically for shading/lighting
- one line initialization/setup/definition of surfaces/layers/collision/etc

I am not sure a RAD game programming language will interest "real" programmers and for the other I think they perfer using FPS Creator than a language.
What we need is a programming language which replace C++ (with its speed), but more clear and simple in order to reduce the debugging stage. I think that Eiffel is great for that but :
1) All objects are GC and i think that we need to have control over this (like in MC++)
2) Syntax is too far from what wa are used to see (C/C++ Java C# have the same basic syntax for loops or conditions).
3) Developpement environment are not really ready to use.

If it doesn't have DWIM support, I'm not interested.

Personally, my dream language for anything would be an updated version of Common Lisp, with all the baggage from days before standardization removed and cryptic abbreviations turned into spelled-out-symbol-names. It'd also be nice if everything was organized in namespaces ('packages') instead of having every single built-in symbol residing in a single place.
As far as what should be added, It'd be cool if it included all the functionality of the C, C++, and Java standard libraries and also contained the parts of boost that Lisp doesn't make obsolete (such as the os-independant path system). It'd also be nice if it had some standard way to define external functions declared in other languages. Obviously things like calling convention might need to be system specific, but there is no reason it can't be standardized anyway ("of the form (extern function-name function-location (arguments) :calling-convention cdecl), where cdecl is system-specific" or something like that).