A New DSL for Games

[oamsath]

Hello.

I've posted here a few weeks ago about an idea i was hammering. I've refined it and removed some unnecessary features as it wasn't really needed.

I'm a last year computer science student and this idea is for my graduation project.
It is about a new programming language for games. It will be written in C++.

This new language is a DSL. this means that it will contain features specific to games only. Screen, Texture, Sound, and Model will be data types just like int, float, and double in other languages.

The main focus will be on two things:
1- Easy to learn: I intend to have a learning curve of maximum one week. It will be very easy for starting programmers to develop good games with it.
2- Fast: this language will not be translated to executable files, but will be translated into C++ using OpenGL library for drawing, and then calling MingW compiler to build the executable.

I know many people were dreaming about this idea. But all the existing languages didn't really focus on easy to learn rather that fast. I want to create THE BEGINNERS LANGUAGE for games.

I've tested many aspects and an initial design and was ready to start this project. but an experienced friend of mine asked me this one question:

Him: Did you hear of a big Gaming Software company making a language just like yours?
Me: none that I heard of..
Him: Why?
Me: I don't know. how can I find out?
Him: post on online forums and ask more experienced programmers.

And here I'm. Really need your comments.

[Serapth]

Beginner specific languages exist, in the form of Blitz or DarkBasic, as well as a number of smalltalk derived languages geared specifically towards teaching programming through gaming. ( Like Squeek and eToys ).

As to the being a C++ language generator, I think you will find that task much more difficult than you expect. Heck, even language parsers for code completion have issues with the language!

[gusano79]

I may be thinking in a slightly different direction than you want to take for this project, but in the interest of development speed and spending more time on the game aspects than language specifics, have you considered using and/or extending a pre-existing embedded language?

I'm thinking of Lua in particular. It seems appropriate for what you're trying to do; here are a few ways it relates well to your project:

It will be written in C++.

The Lua interpreter is written in C, but will compile cleanly as C++, including exceptions.

it will contain features specific to games only. Screen, Texture, Sound, and Model will be data types just like int, float, and double in other languages.

While you wouldn't be writing the basic language yourself, you can write your game engine classes in C++, and expose instances of them to Lua, which essentially achieves what you're describing (see userdata and metatables).

1- Easy to learn: I intend to have a learning curve of maximum one week. It will be very easy for starting programmers to develop good games with it.

I believe the "easy" aspect of your language will depend mostly on your architecture and object model, rather than the language itself. At any rate, Lua is simple and easy, IMO.

2- Fast: this language will not be translated to executable files, but will be translated into C++ using OpenGL library for drawing, and then calling MingW compiler to build the executable.

This is where using the embedded language would be different. You wouldn't translate it into anything; the interpreter/VM would be embedded into your main application, and it would compile and run Lua code directly. This is still fast, as all of the heavy lifting (OpenGL, sound, &c.) would still be compiled C++. Lua would only be there to tell your C++ objects what to do, then get out of the way. As a bonus, users of your application wouldn't have to have a C++ compiler on their system.

I know many people were dreaming about this idea. But all the existing languages didn't really focus on easy to learn rather that fast. I want to create THE BEGINNERS LANGUAGE for games.

As I mentioned previously, I don't think "easy" has much to do with the language itself. It's more about choosing which game concepts to represent and how you expose them through the language to your end users. For example, you wouldn't want to have them writing OpenGL calls directly, but they'd need enough flexibility to build what they want, without being too complicated... this is not a simple issue, and is probably where most of your deep thinking on this project should go.

Anyway, using an existing embedded language may not be what you want to do, but it's worth considering if you haven't looked at doing it this way yet.

Have fun with it!

--smg