Worth reading the philosophy page: http://strlen.com/files/lang/lobster/philosophy.html

"The most important over-arching reason behind everything in Lobster was to make it a pleasant language to use for one single person: me, the author."

When these sorts of personal side projects come up on HN, it seems inevitable that people question whether anyone should want to use them... You probably don't most of the time. They're cool to look at, but I think the judgment of being cool comes more from a PL designer viewpoint than an end-user viewpoint...

Oh - this was done by the author of the Cube Engines a.k.a Sauerbraten.

Wouter van Oortmerssen is not exactly a Newbie. He is at Google now. This might be more interesting than I initially thought.

Another source code example: http://i.imgur.com/ZZWFkXn.jpg

Its entire source code fits in the screenshot.

From here: https://news.ycombinator.com/item?id=8659273

Jonathan Blow is also writing his own language for games: https://www.youtube.com/watch?v=TH9VCN6UkyQ

I think this is great (more languages).

Note that this is not by @strlen (Alex Feinberg)

Jonathan Blow has a whole series on YouTube discussing the language, and at one point there is even a demo of the language and the compiler! The whole thing is really exciting and the language looks well thought out. It's nice to see a system programming language where the focus is more on getting things done than on making the type system pretty.

Yep. And his demo is a little game... :) There's not enough time for seeing all those videos though.

Every language is a game programming language.

"Lobster is a general purpose stand-alone programming language that comes with a built-in library suitable for making games and other graphical things. It is therefore not very suitable for non-programmers."

What's the significance of it being "built-in"? How is that an advantage over a language with a reasonable package/module system, so that any game-making libraries can be used as easily as the standard library (after downloading it etc.).

The same benefits that PHP has or strives for (for better or worse) in making many web-programming-related functions always available in the global scope (it looks like Lobster does require includes however), plus first-party support from the language itself rather than relying on multiple libraries and authors (the language author gets to deal with that), plus a consistent API for all those things shoved onto the language author instead of the program writer. More interesting things you could do would be to add special syntax to support some domain-specific task, but looking from a language with macros that sort of thing comes across as cute... For instance the gl_ functions in this language create a control flow visible at the source level:

    gl_translate(playerpos):
        gl_rotate_z(tomouse):
            gl_polygon([ [ -0.5, 0.5 ], vec_x, [ -0.5, -0.5 ] ])

> For instance the gl_ functions in this language create a control flow visible at the source level:

How is this superior to exposing control-structure like object (e.g. closures) and implementing the GL dsls as libraries? The above isn't any more readable, with an increased maintenance cost for the writers of Lobster.

I would say that available libraries is by far the most limiting factor for most languages, including (I'm assuming) Lobster.

It can be hard to say whether sugar is superior or not without having a lot of experience / pain with unsugared or partially-sugared ways of doing the same thing. In this case I'd agree with you that closures could do the job just as well with hardly any more syntactic overhead. We're also in agreement with respect to libraries. The home page for Lobster mentions C++ interop, but it's unclear without digging in how straightforward that is (e.g. if one has to rebuild the compiler).

There's also the benefit that, if general language design decisions are good for the niche it targets (web dev/games/w/e), it'll make them. For example, PHP has weak typing because it makes writing web applications easier, and it has $variables for string interpolation.

I wonder how fast it is? A lot of game programmers hate C/C++ but feel like they can't use anything else, since they don't have the same control.

Edit: I reread the page and it says about as fast as non-JIT Lua, so probably good for a hobbyist, but not a production quality game.

Strikes me as a nice idea, but why not just build for/use an already built library for a pre-existing language?

It does look nice, I'm just not sure the tradeoffs of building in a unique language are worth it, since it doesn't seem to add all that much.

The author has a history of creating programming languages, so It's really no surprise he's made another. As for why, it seems likely based on the introduction text he was aiming to make a portable language specifically designed with game developers in mind.

I'm a bit late to comment, but I think this language is very promising for "batteries-included hacking," much like PHP or Basic. Just, it's not a woefully primitive or erroneous design like those languages. Wouter advertises the interesting high-level features up front, but the productive appeal of any language of this style is in the easing story, and I bet this can satisfy that perfectly well.

This looks like tons of fun. I know what I'll be playing with over Thanksgiving break... it will be interesting to see if this could be a reasonable platform for playing with digital synthesis and spectrogram analysis and the like.

Considering the feature list, doesn't Common Lisp also qualify as a game programming language then?