So the gameplay is novel in this game? Would anyone mind explaining it to the rest of us?

I guess you base technical merit on compatibility with other OSes. If a .NET language made it 10x easier to develop applications than any other language I could find, I'd be sold. Yes, write-once-run-anywhere is important, but it's just a piece of the pie.

He's not my hero. I'd prefer to work for someone who would regrettably (or not) do this instead of be proud of it.

THIS is nothing. Once I created a railway rifle with nothing more than a crutch, fission battery, pressure cooker and a steam gauge assembly.

I stumbled upon this video game controller "family tree". http://www.axess.com/twilight/console/ Not that interesting, but relevant.

Um, source? If this were true, wouldn't we still be single celled organisms right now?

And, IMO, the story takes a negative turn near the end. I don't think it's a coincidence. Although a story CAN be good regardless of the battle system, I think the battle system has a huge effect on your impression of the characters. After all, you spend most of your time with these characters in battle, not in cut scenes. They shouldn't be replaceable cogs.

This is why I consider Final Fantasy 4 to be the best in the series and Final Fantasy 7 to be near the bottom. 7 gave me the choice to never use Aeris. Unfortunately, I made that choice (it was pretty arbitrary; everyone is a replaceable cog in that game, after all). As a result, when she died, I didn't care much. It was like a random NPC in a town died. If she was a key part of my team, I think I would have felt different.

As an indie game developer, I'm concerned about this problem. I need people to play my game for their feedback. But, if I let them play my game early and they don't like it at that time, they may be unwilling to try it in its future state. Seems like a catch-22.

Does turning a blind eye to the fan made games cheapen the brand?

On another note, I don't know much about Japanese culture but isn't making fan fiction knockoffs of things practically legal over there? I hear that Dojinshi (fan fiction comic books based on copyrighted characters) is so ubiquitous, there are actually large conventions for them [citation].

You see, the trick is, kick someone's ass the first day or become someone's bitch. Then everything will be all right.

I think you both have a point. A game can be fun even though tons of people are selling gold. But if tons of people are selling gold, it suggests THAT PART OF THE GAME is not fun.

It doesn't work that way. I suggest you read the Mythical Man Month.

That being said, I think they most likely do have a hiring problem. How the hell are you supposed to sharpen your saw when you work 80 hour weeks?

Is the quality of a game and the morale of the team worth sacrificing to deliver the product on its arbitrarily chosen completion date?

Jane Q. Public: Either you didn't read the comments of that blog or you're spreading FUD. Here is a comment from Alex Payne from that article:

Hoo boy. First of all, I hope you've had a chance to read my general reply to the articles about my Web 2.0 Expo talk [1] and this response to a vocal member of the Ruby community [2]. I sound like a pretty unreasonable guy filtered through the tech press and Reddit comments, but I hope less so in my own words.

Secondly, the quote at the top of your post is from my coworker, Steve Jenson, who's been participating in the discussion on this post.

On JRuby: as Steve said, we can't actually boot our main Rails app on JRuby. That's a blocker. Incidentally, if you know of anyone who has a large JRuby deployment, we'd be interested in that first-hand experience. If you don't, it might be a little early to say it would solve all our problems.

It's also incorrect to say that the way JRuby and Scala make use of the JVM is exactly the same. Much like our other decisions haven't been arbitrary, our decision to use Scala over other JVM-hosted languages was based on investigation.

On our culture: if you'd like to know about how we write code, or how our code has evolved over time, just ask us. We're all on Twitter, of course, but most of the engineers also have blogs and publish their email addresses. There's no need to speculate. Just ask. There's not a "raging debate" internally because we make our engineering decisions like engineers: we experiment, and base our decisions on the results of those experiments.

It's definitely true that Starling and Evented Starling are relatively immature queuing systems. I was eager to get them out of our stack. So, as Steve said, we put all the MQ's you think we'd try through their paces not too long ago, and we knocked one after another over in straightforward benchmarks. Some, like RabbitMQ, just up and died. Others chugged on, but slowly. Where we ran into issues, we contacted experts and applied best practices, but in the end, we found that Kestrel fit our particular use cases better and more reliably. This was not the hypothesis we had going into those benchmarks, but it's what the data bore out.

We get a lot of speculation to the tune of "why haven't those idiots tried x, it's so obvious!" Generally, we have tried x, as well as y and z. Funnily enough, I was actually pushing to get us on RabbitMQ, but our benchmarks showed that it just wouldn't work for us, which is a shame, because it advertises some sexy features.

Personally, I'm extremely NIH-averse; I research open source and commercial solutions before cutting a new path. In the case of our MQ, one of our engineers actually wrote Kestrel in his free time, so it was bit more like we adopted an existing open source project than rolled our own. Pretty much the last thing we want to be doing is focusing on problems outside our domain. As it so happens, though, moving messages around quickly is our business. I don't think it's crazy-go-nuts that we've spent some time on an MQ.

I hope my colleagues and I have been able to answer some of your questions. As I said, in the future, please consider emailing us so we can share our experience. Then, we can have a public discussion about facts, not speculation. Perhaps, as commenter sethladd suggested, the onus is on us to produce a whitepaper or presentation about our findings so as to stave off such speculation. Time constraints are the main reason why we haven't done so.

[1] http://al3x.net/2009/04/04/reasoned-technical-discussion.html
[2] http://blog.obiefernandez.com/content/2009/04/my-reasoned-response-about-scala-at-twitter.html#IDComment18212539

This begs the question: Why aren't there more open source game artists?

http://unlimitednovelty.com/2009/04/twitter-blaming-ruby-for-their-mistakes.html

This blog post takes the attitude that Twitter didn't move to Scala because ROR had a problem, but because the in-house messaging system Twitter created performed poorly. The author does not work at Twitter but many of the Twitter developers (including Alex Payne) respond in the comments. I found the article to be very interesting and the comments even more so. They give a sense of how much research Twitter did before this change.