From my perspective it's not the language that matters so much as what sorts of things can be done concisely in it.

Back when I learned to program it was using BBC Basic. One of the features which made a huge difference to me was the way so many things could be done in a line or two. Just using MOVE and DRAW could achieve visible results quickly, which is vital for kids.

My daughter's starting to take her first programming steps (she's seven) and the main thing which frustrates her is the needlessly arcane syntax of most languages. The only programming she can do by herself so far is using Web Turtle. It's main success being that it's so simple to do get results which aren't just error messages.

[Sales etc.]

I think the whole cooperative idea is a really bad one. Some explanation:

There are various things one might want out of a cooperative. Publicity for your game. Handling the mechanics of sales. Providing inter-developer support. But all these things are either better provided by other means or are not actually things a cooperative could provide any more efficiently.

Sales etc. - Insofar as this is useful it would actually be a nuisance for the cooperative. Someone would have to register it as an entity able to accept credit cards sales. There would have to be policies to deal with complaints/returns. There would have to be responsibility for legal issues which could arise. Inevitably, restrictions would have to be imposed on developers as to the terms and conditions they could offer. And who hosts downloads? The cooperative? Then what happens with things like demos where the data costs are not necessarily covered by sales? Assuming developers are free to continue selling from their own site as well, what stops them exploiting the free resources of the cooperative but then selling more cheaply from their own site? There would have to be rules. Who's going to run a big operation like this for free? (And it would be for free, since the cooperative would not be in a position to pay a salary.)

Publicity - What every developer wants is for the world to hear all about their game. But that's not how publicity works. Someone still has to prepare screenshots and videos, send email to journalists, create buzz about the game prior to release. It's a lot of work which the cooperative is clearly not going to take on. Sure, it can give page space to a few games each week, but sites like TIGSource and indiegames already do a good job of that. If you think they're overlooking good stuff, what mechanism would prevent this cooperative from doing the same? (In fact it would be worse, since members would expect balanced coverage and so weak games would get overhyped, as was the case on Manifesto.)

Support - TIGSource is already excellent for this.

What a cooperative might do is be divisive in terms of who was prepared to join. Would there be inter-community political storms over things like IGF judging for co-op vs non-co-op members?

I feel SMS payments aren't entirely ethical... at least not if you're making games directed towards kids.

Why not? Parents should cap their kids' phone bills anyway if they have any sense.

My most popular flash game has been played over 10 million times. A flash game I made in a week has so far been played 2 million times.

Not much to say to that except: congratulations!

$6.50 per 1000 plays is an improvement, but still only comes to $6500 for a million plays, which means it doesn't really change the income level of Flash games.

I'm a huge fan of D myself and I'm fully aware that the following links may be a major repell for many people

I found them very worthwhile, thanks. 

Also I've done some experiments with OCaml, which is faster than Haskell as well as less dogmatic in its functional approach, and it was promising at least

One of the most complex programs I ever wrote was in OCaml (not a game). Its raw development speed for algorithmic stuff is hard to match (assuming you understand functional programming).

However, the downside for parallel programming is that you have to be quite disciplined in OCaml not to use imperative-style side effects everywhere. This, of course, breaks the inherent advantage that a language like Haskell brings to parallel programming.

Also, most games are naturally imperative in nature (dynamic user input!) and as such true functional programming isn't a very good fit. These days I'm happy enough using any language with good support for closures. That allows me to write in a very functional style when I want to without most of the costs.

Is Javascript allowed into this?

That's the 'J' in AJAX!

Incidentally, anyone who's comfortable with Javascript should definitely consider using Actionscript, since they're basically the same language.

You can actually send data from the server to the client without using polling and so forth. It's called Cometd, or reverse AJAX. However, there are a lot of costs in using this technology as you often need to use virtual server hosting, which can be a lot more expensive than standard web hosting.

Another potential downside to this approach is that the server achieves this by keeping the HTTP connection open. If your game has a lot of players this can get quite rough on the server. Also I suspect (although I haven't tested this) that the server would be unable to detect disconnections as it could with sockets.

Good stuff Farbs, you interview really well! 

I agree. I spend a lot of time looking at variable names and functions for classes in the .h files. I can't imagine having to search through all the actual code to find that information.

I assume everyone will just laugh at me if I use the word "documentation" at this point?

-toggle off methods and objects until the game starts working nice again.
-toggle the other items back on to be sure what is causing the bottleneck

This is the approach I favour in the absence of a good profiler.

One additional trick which can help a lot is if you have a section of code which can't be switched off without breaking your program, try running it multiple times instead.

I very strongly recommend AS3.

Not only is it just better in every way once you know it, but it's really not that much harder to learn. There's plenty of example code on the web, so you shouldn't have trouble getting started. Also, it's way more future proof. AS2 is already deprecated, really.

World of Porncraft!

I hear they called it "Second Life". :D

If you take the time to learn the more advanced features, particularly the things that are possible with templates, it's hard to beat the power that C++ offers.

Power is difficult to quantify in this respect, though. The usual reason people give for wanting higher level languages than C++ is development speed. And yet I've met lots of people who develop faster in C++ than any other language, so for them this motivation simply wouldn't apply. But this isn't a feature of C++, it's a feature of these programmers.

Then there's the issue of bugs and crashes. Some people are so good with a debugger that they make C++ look stable and reliable. My hat's off to them. I don't think I could ever do that. But again, it's not a property of the language.

bateleur: I actually don't know what in GML will allow me to ignore key events, that is, what code will be executed if I do set a disableKey flag. The only thing I can think of is somehow setting up a timed loop (though I don't know how to do that, either -_-) with no key detection code that will start when the animation starts to play, and then stop when the animation is done.

I'm not suggesting that you ignore key events, I'm suggesting that you set a flag which is examined within your key event handler and which causes the handler to execute different code via something as simple as an "if/else" structure.

Unity isn't a language

Well OK, fair point, but had I substituted "Javascript" in there (or any of the other languages it supports for scripting) you'd have just looked at me funny!

Flash isn't a language either, if you want to draw such distinctions.

It has compilers for Windows, Linux and Mac OS at least, if that's what you mean?

No, not really. I mean sure, that's nice, but as a games programmer that's only about half of the platforms I care about. Xbox 360, PS3, Wii, DS, iPhone... C++ targets everything and Flash isn't far behind. Even Unity might already be more relevant than D.

Do you think we will be using C++ until the end of time?

This is an interesting question. I suspect the clue lies in the way that development is already carried out using scripting languages to drive engines written in less convenient languages. Use of C++ will decline as more programmers come to realise it's the wrong tool for their job. However, it will remain the right tool for some jobs, it's just that the range of sensible C++ projects will decrease.

It's easier to see if you look at a language like PERL. As the language grew up and more and more libraries appeared, usage rose. But then with the rise of AJAX and PHP a lot of web developers realised that PERL CGI wasn't the best solution for them anymore. Use of the language went into rapid decline, not to much because the things that replaced it were better, but because most of the people who once used it didn't really need the power it offered.

I would be surprised if 99% if the programs written in C++ worldwide would have been better off written in some other language. But the remaining 1% includes the majority of commercial software, so I don't expect the language to disappear any time soon.

As for D, it looks good, but I don't have any plans to write software in a non-portable language any time soon. Life is too short.

when I do get it to play out, how do I ignore addition key events?

Usually the easiest way to do stuff like this is just to set a flag. So your climb code would include something like "disableControls = true" and then you use something like "if (keyPressed(right) && !disableControls) {walk right}".

Writing Flash stuff I prefer to cache local copies of important singletons as instance properties. This has the key benefit that if I later decide I want them not to be singletons anymore it's very easy to make the change.

The downside is that it makes my instances slightly larger, but that's not going to be relevant unless I'm making tens of thousands of instances.