If you consider the constraint that the indie programmer may have had incomplete skills to set up a proper service, saw this method as faster for any number of other reasons, or didn't want to maintain a proper web service, I think this could very well have been the right approach at the time. Judging from how much money this game has made, I think that's hard to argue with since time to market should have been the number 1 concern at the time and early on he needed a way to make sure people were able to complete all the levels and measure the difficulty curve.
When the developer responded that it didn't matter, that may have been because they don't need that data any more and don't even look at it.
In good tradition the most critical comment is the top voted on HN. Yada Yada indie life is hard, but no one with a right mind would think of connecting the client directly to the remote master database. This is just so WTF on so many levels, you can't help but wonder how they even managed to produce such a good game after all.
Yes, it seems obvious to web developers and developers that are used to working with databases and CRUD apps, but that's one set of skills over a particular domain. Game development tends to emphasise a whole different set of skills — those of efficient graphic rendering, for example.
A points table is no doubt a last minute add on in a field that certainly wouldn't be the expertise of a small indie developer (no-one goes into game development for their love of CRUD apps, after all). They needed a database so they used the most popular, in a way that probably seemed the most appropriate for their application.
Ah, but remember, they've "done this stuff for a while now". Either they know and don't care, or they don't know and they're claiming they do. There's no good way out of this, they're messing up potentially catastrophically regardless of the truth.
Not knowing, being informed about it, and arrogantly blowing off that information is inexcusable, unprofessional, and deserving of all that scorn.
It would have been very easy to say, "Thanks for bringing this up, we will look into it", instead of being condescending and ending up looking like an ignorant jackass.
I can't imagine anyone specializing to such an extreme. If you want to make multiplayer games, for example, you have to know this stuff.
Every competent programmer should be familiar with basic security principles. It's then your responsibility to educate yourself about how to apply those principles in a given situation.
No, you don't. I work for one of the top social gaming companies around right now and programmers do specialize to a ridiculous degree. The programmers who write code for the actual game are rarely web developers. It's simply a different domain.
I can confidently say this because I'm a web developer in a studio of game developers and most of them don't even know how to run mysql locally. They aren't stupid, they could, if they spent the time to learn it. But they are much more interested in improving the efficiency of their A* pathing algorithm.
Well, it's fair to say that programmers specialise, but presumably you're only working on the website, and the game developers are only working on the game. TillE was right - if you are going to implement this stuff, you should know what you're doing, or at least seek advice from people who do.
Regardless, the super meat boy developer made a pretty basic mistake, which you could perhaps defend with your argument, but he then refused to engage with someone who was reporting a vulnerability and trying to help. To me, that's pretty astounding.
Game development especially has a lot of well meaning customers who haven't got a clue what they're talking about (a lot of kids). Whilst he probably should have listened, it's understandable why he may have dismissed a random on twitter.
The guy took a stack trace of a segfault. If a guy comes up to me, tells me I have a glaring security flaw, and shows me a stack trace of my own code to prove it, I'd be an idiot /not/ to give him at least a few minutes of my time, no matter what community he comes from.
This is true, whilst you might not expect them build a beautifully layered J2EE or RoR solution with full transactional integrity, a few hours with some basic PHP tutorials would not have gone amiss.
This is especially spooky since MySQL contains a few scary features like System() not to mention that anybody could connect and write a script to do massive crossjoins (as indicated in the original thread) I'm sure any decent game developer would understand the implications of O(n!) but they were probably blissfully unaware that these features even exist.
I doubt that Notch would have made such a schoolboy error :)
No, he corrected it after it had been an issue for some time and was negatively impacting his customers' enjoyment of what they had purchased.
Throughout Minecraft's development, "barely good enough, and sometimes not even then" has been the externally visible modus operandi. That so many players put up with customer abuse is unfortunate, not least because others will consider Notch's slipshod development practices and infantile product management goals to which one might aspire.
This is just so WTF on so many levels, you can't help but wonder how they even managed to produce such a good game after all.
When I started working in Industry™/The Real World™ I learned a lot of important lessons in How Things Are Actually Done™. One of them was how much software was just held together with duct-tape and string.
So yes, you can produce a good game and think that this sort of DB access is a good idea.
You must be popular and attractive because these kind of mistakes get normal people fired. This thread makes my stomach hurt thinking I might work with some of you.
Oh I'm not saying it's ethical or the right way to do things, just that it's common.
For example, there are loads of companies with very poor backup policies in place, or with all their eggs in one basket. There are loads of companies without any real 24/7 'on call' system.
For every person who is fired for doing some quick hack like this, there is someone who will be fired if they don't "Get it working today" (i.e. they'll get fired if they don't do the quick hack)
I'm about halfway through my first android app, and all the research I did said the same thing; never, ever connect directly to your MySQL database. I just wrote my own PHP script to deliver the results via JSON, it took me a few days to figure out but it wasn't that difficult.
If you read Edmund McMillen's formspring page, you'll see that there are several disconnects from a development perspective about super meat boy. Such as them not being able to reproduce builds from source.
Maybe you could argue that it was the right approach at the time. But deciding that the data doesn't matter anymore is not cool, you have to take care of your paying customers or else you lose credibility.
If you consider the constraint that the indie programmer may have had incomplete skills to set up a proper service, saw this method as faster for any number of other reasons, or didn't want to maintain a proper web service, I think this could very well have been the right approach at the time. Judging from how much money this game has made, I think that's hard to argue with since time to market should have been the number 1 concern at the time and early on he needed a way to make sure people were able to complete all the levels and measure the difficulty curve.
When the developer responded that it didn't matter, that may have been because they don't need that data any more and don't even look at it.