Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Super Meat Boy leaves database wide open

forums.somethingawful.com

Post reply on HN
Print view View original

31–40 of 99 posts

Re: Super Meat Boy leaves database wide open

#31

Post by timdorr »

kevingadd wrote: post #24
citricsquid wrote: post #11

Earlier quoted context omitted.

Asking the database administrator in you, what's the most efficient way to do it? Queue and push updates every 10 minutes?

If I had to use the database, I'd probably aggressively shard the data so that it's spread across multiple databases/tables. That way the load of counter updates could be spread across machines. I'd probably also store the counters in a separate table from the rest of the levels, for the same reason, but also to ensure that the rest of the information about a level isn't locked during every increment. Of course, this…

MySQL locking behavior depends on the table engine/type you use. The old MyISAM format is table-level locking. InnoDB is row-level and supports all the "big boy" RDBMS features you'd expect to be there (like foreign keys...).

Also ideal is to have the client not update the number of deaths on each attempt but only either on completion of the level or at a timed interval. No need for that date to be real-time, so it can be aggregated.

Re: Super Meat Boy leaves database wide open

#32

Post by badclient »

z92 wrote: post #13

So what would be the solution? He used a password protected database connection and put the password compiled in binary. If I was doing it I would have probably done the same. How else can it be done? Use web service? That would still look "open" to someone digging inside the compiled binary and getting the keys.

With a web service, majority of the potential abuses would be related to being able to manipulate your own scores and records in the db. That isn't that big of a deal in this use case since we are dealing with games.

Most simply the web service can require a 20 char unique key every time it is taking a request from a client. You can find yours using a sniffer. But it'll be hard to guess others'. This is the most basic implementation.

Re: Super Meat Boy leaves database wide open

#33

Post by socksy »

zyb09 wrote: post #30
dangero wrote: post #22

I'm going to dangle myself on a limb here. 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…

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.

Re: Super Meat Boy leaves database wide open

#34

Post by funkah »

zyb09 wrote: post #30
dangero wrote: post #22

I'm going to dangle myself on a limb here. 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…

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.

Exactly. There's no need to equivocate, just call this what it is -- lazy and incompetent.

Re: Super Meat Boy leaves database wide open

#35

Post by forrestthewoods »

benologist wrote: post #19
forrestthewoods wrote: post #18

Earlier quoted context omitted.

I know next to nothing about this kind of stuff. If I wanted to create a stats + user generated level database system akin to Super Meat Boy (and I do) do you have any recommended resources to read?

It depends on how deep you want to go yourself. At its easiest you could just drop Playtomic [1] in, we have support for most gaming platforms.... obviously I'm quite biased towards this option. :) If you want something more flexible and you're doing mobile you can check out Parse [2], they're a custom database with a REST, iOS and Android APIs. If you're using Flash, HTML5 or Unity3d we have a bridge that lets you u…

Great response, lots of good information, thank you!

Re: Super Meat Boy leaves database wide open

#36

Post by drewblaisdell »

dangero wrote: post #22

I'm going to dangle myself on a limb here. 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…

The thing is, we would never have heard about this if the developer wasn't a pompous ass and tried to claim that the way he is doing it is "fine".

Re: Super Meat Boy leaves database wide open

#38

Post by Retric »

citricsquid wrote: post #11
kevingadd wrote: post #8

The idea of doing an UPDATE on the custom levels table every time someone dies in order to increment the deaths counter terrifies the database administrator in me. That'll scale REAL well. Yikes.

Asking the database administrator in you, what's the most efficient way to do it? Queue and push updates every 10 minutes?

The easiest way to have a counter that is both correct and fast is to split things up into multiple separate counters and then count them. So for a simple example: User ID mod 50 = 7 so lock row, 7 increment row, 7 unlock row 7. Want the total? sum (all rows).

You can also get fancy with lock row 1, lock total, update total = total + value of row 1, unlock total, set row 1 to 0, unlock row 1. Repeat row 2...50. The advantage being even lower latency access to a number that is withing X seconds of being correct.

PS: Both of the above can be split across multiple cores / machines. But, for a less accurate but still reasonable have the client a = (rand (0,100)), b = rand (0, 100 + a), if b == 7 update death count by (a + 100). This only increments the counter 1 time in ~150 times while avoiding counters that are always multiples of some number. Just be careful of off by one errors.

Re: Super Meat Boy leaves database wide open

#40

Post by Groxx »

socksy wrote: post #33
zyb09 wrote: post #30

Earlier quoted context omitted.

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…

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.
Post reply on HN