Our 3 weeks of Theme Suggestions have ended! With over 5000 suggestions, about 4200 with duplicates removed, we need your help to find the Top 80 themes for the next round!
Enter, the Theme Slaughter.
How it works is simple. We give you a random theme from the remaining 4200 suggestions, and you tell us whether it’s a good theme or not with a click. You can use whatever criteria you like to decide, but do consider that a few thousand game developers need to make original games based off the theme. And some themes have happened before.
By mid-week we do a purge, removing the lowest rated themes from the list. As a result, the quality of themes you receive should get better as the week goes on. We still need your help to separate the good from the bad though!
That’s all for now. Go slaughter some themes!
EDIT: Tuesday’s Purge! After over 420,000 votes, roughly 850 of the lowest rated themes have been removed from the randomization.
EDIT 2: Friday Purge! After over 650,000 votes, we gut a whopping 2500 more themes, bringing our active total to about 800. FWIW, there are roughly 35 votes between the lowest and highest rated themes of those that remain. We’re taking the top 80, so every vote still makes a difference. 
If you’ve already voted on thousands, there’s a very good chance you’ll only see themes you’ve already voted for. Any votes you make herein will probably overwrite an old vote, so you wont see your total go up anymore.
Love that you can edit mistakes!
Also, KITTENS!
It would be so great if the two buttons could be mapped to keyboard keys too.
For anyone interested, this is what I ended up adding to the page.
A is for Yes, S is for No
document.addEventListener(“keyup”, function(evt) {
var s = String.fromCharCode(evt.keyCode);
// console.log(s);
if(s == “A”) {
kill_VoteIdea(1)
} else if(s == “S”) {
kill_VoteIdea(0)
}
}, false);
Use the Left/Right Arrow keys, and the space bar to select.
Didn’t realized the support was already built in, that’s awesome. Thanks!
I just got a tweet from someone that did the exact same thing, so I’ve added a “TIP: use the arrow keys and space bar” to the page.
Could you please make it so that you can’t see the theme duplicates (if not for this Dare, then at least for the next one)? I swear I’ve seen at least a few repeated themes already (down to identical spelling and capitalisation), and I’d like to slaughter through as many unique themes as possible, which due to probabilistic thingamajigs gets harder and harder as more themes have been voted on. ^^’
I’ll try :). The main thing holding me back was coming up with a good algorithm.
You could just cycle through the theme list, rather than picking random themes. This would prevent repetition.
Assign everyone a random starting point (User.ThemeIdx), and a random stepping number [User.ThemeStep], which is a relatively large prime number (4 decimal digits)
Then every time that user clicks the slaughter, do User.ThemeIdx = (User.ThemeIdx + User.ThemeStep) % NumThemes
since there is almost 2000 voters for 4200 themes and client can already detect new unique client, they can just start like two/three themes apart from each other. It would only require DB to remember one additional number which would say where the voter ended in list. That way it’s guaranteed (unlike the random approach) that everybody would vote on everything (assuming each voter would cast at least two/three votes)
Hmm, how about algorithm/flow like outlined below? It might be tricky to implement (especially since it involves altering the client), but I think it might allow themes uniqueness while not causing too much performance hit.
1. Darer #X logins to Slaughter site, prompting server to come up with a theme to suggest for user #X.
2. On server side:
a) get $themes associative array that contains all valid themes in the current slaughter, in the form [theme ID] => [theme title]; the array can be retrieved from database or cache or whatever (probably some sort of quick access cache)
b) get $themesVoted array of theme IDs that user #X voted for; if it’s stored in table like Votes with userID and themeID columns, it’d be probably something like “SELECT themeID FROM Votes WHERE userID = X; “, or similar ORM-generated query
c) find $themesUnvoted array of theme IDs that user #X has yet to vote for; I imagine in PHP it would go like “$themesUnvoted = array_diff(array_keys($themes), $themesVoted);”, i.e. all valid IDs from $themes array that aren’t in $themesVoted array
d) randomly pick $themesToSend array containing, say, 100 IDs; I dunno, it could involve something like “array_rand($themesUnvoted, 100);”, except you might want to check whether there are more than 100 themes unvoted in the first place
e) send an array of ID-theme pairs in JSON response (like {“id”:7777,”theme”:”Kittens”}), possibly with other data; assuming each theme record would have length of 50 on average, it makes for measly 5kB, which is ~6 times less than Slaughter site source, anyway
3. Once Darer receives the JSON with ID-theme pairs, on client side:
a) shuffle the array of ID-theme pairs and store it for later use
b) display the first theme so that Darer can judge it
c) when Darer votes, send to server theme vote information and display the next theme in line
d) rinse and repeat, until you run out of stored themes; then ask server for another batch of 100 themes
What do you think about that? I’m guessing such approach should do the task well enough. Maybe I could implement and pull-request it myself, if I knew my way around that Ludum Dare source repository (is even that “ludumdare” thing on GitHub up to date…?).
I’ve detailed what I’ll probably end up doing here:
https://github.com/ludumdare/ludumdare/issues/45
The main issue was trying to do it entirely in an SQL query, and unfortunately nested queries can get a little greedy. I’d also forgotten than internally MySQL and MariaDB do random … not so great. I was trying to avoid doing queries that require iteration over all themes by the database server, but I realized that’s probably why random is so slow (and by slow I mean micro seconds vs nano seconds). So my solution is to move the algorithm to the main server (not the database server), and keep a copy of your “my voted themes list” in RAM for a couple minutes. That way, though the first random theme may be a little slow, every subsequent random theme should actually be faster to fetch (no need to talk to the database). And every time you make a vote, reset the TTL of the RAM cached copy of your list, so it appears seamless to anyone actively voting on themes.
Originally I was going to do the “brute force slow way”, but send sets of 10 random themes at a time, to hide the overhead. I can still do that with the better algorithm (and it’ll be way faster).
Anyway, I wont get to it this week. I was supposed to do my taxes last week, but *cough* I haven’t started yet.
Or, you could just use sorceress’ algorithm, which is super easy and super efficient. (The approach you outlined on github is neither.)
I think I mentioned elsewhere that I really don’t like the linear option. Plus the more spread out things are, the more themes overall people get to sample. If you watch social media we see some fun ones pop up, and adding an order to it would stifle that a bit. Some people also like to refresh the page to get different themes, and linear would break that. Eventually I’ll add a button.
Like I said, I hadn’t come up with an algorithm I liked. Performance is super-important to me. I’ve configured the servers and am building the software a certain way to maximize that. I wanted a memory-free option, but if I have to use memory, then I want to eliminate bottlenecks (server < -> database server communication).
All in all we’re talking maybe 20 lines of new code, but that combined with the handling of the ‘out-of-themes’ case, and testing it, it’s not the algorithmic nuances that are the issue. It works one way right now (an SQL query), and it changing away from that is what’s work.
By what you’ve written here, I’m not sure you’ve looked at my algorithm. 😉
Ah, I misunderstood. I missed that you actually meant adding prime numbers. I saw decimals mentioned which threw me off. My bad.
It’s a good idea, but unfortunately it doesn’t work when we purge low rated themes during the week. The resulting Ids you get from summing primes break when the mod value changes. A workaround would be to specifically renumber all themes, but you’d then have to check when you landed on a purged theme or not, and keep stepping until you find one that’s available. That kinda ruins the elegance of the algorithm.
I do like the idea. But since I purge low rated themes, it breaks.
Ruin the elegance? Typical case will be like 2 passes! 😀
do {
User.ThemeIdx = (User.ThemeIdx + User.ThemeStep) % NumThemes;
} while (!ThemeSuggestion[User.ThemeIdx].Enabled);
The add and mod is super-cheap. To me that’s elegant because it’s simple. You can use it on any array so long as the size doesn’t change.
The check, though conceptually it can be thought of as an array index, it’s an operation that requires extra permanent data per user and per element, per user prime generation, as well as an indexing process.
To contrast, I’m favouring an option that requires no permanent memory. I need some extra temporary memory, but not permanent. It is greedier on memory used, but requires no additions to the user database, and I don’t have to be as careful regarding breaking the order.
That said, I do like the idea of assigning every user a random large prime number. User IDs are temporary right now, matched with your WordPress ids. I’m not really that thrilled about having to both write a script that gives everyone a prime, and do it during activations. I’d rather just do it during activation (everbody will be creating new user accounts when we move to the new site anyway).
Generate the prime from the UserId on the fly. No need to store it!
PrimeList[10] = {7841, 7853, 7867, 7873, 7877, 7879, 7883, 7901, 7907, 7919};
ThemeStep = PrimeList[UserId % 10];
That could work, but it’s still best if everyone has their own.
Anyway, somebody made a good suggestion in the bug report: Just move all randomization client side. When packed as a string, the current list of 3300 themes+ids is only 80k as a JSON string, 33k gzipped. Doing that once, keeping it in browser session storage, only talking to the server to give it your votes (and occasionally refresh your data). I’d forgotten that the theme list itself really isn’t a secret. Most data is, but the raw list is something totally shareable. There’s already an undocumented API call for fetching the full list.
If the theme is going to be kittens then whats the point of voting? the votes for this ludum dare are engineered.
Is POV really about to slaughter the kittens?!?!?!
*SLAUGHTERING INTENSIFIES*
I wanted to make my suggestion and I missed it. Again
Argh! Time to slaughter some kittens (among other themes)!
happy to see most themes are formatted in a way that do not infringe any limitations on game mechanics but are actually themes !
i could hardly slaughter any of them as the majority would be valid themes.
I thought the same themes are treated as one, but here is what I got for Proxy:
✕
Proxy
✕
Proxy
✕
Deceptive
✕
Beat
✓
Fragments
✕
Calibration
✕
Zero-sum game
✕
Proxy
✕
Cubism
✓
Disability
Maybe the later Proxy was the proxy of the first Proxy, rather than being the same entity as the first Proxy?
In all seriousness, the slaughtering doesn’t have a mechanism to prevent providing the same theme multiple times. Apparently it’s planned, but won’t get implemented before this Dare.
We do remove duplicates, where a duplicate is a theme that matches alphanumerically (i.e. “ten 10” is the same as “Ten 10” and “TEN (10)”). Unfortunately though, we randomly pick a theme without regard for what you’d picked before.
I hope we can slaughter some of these bad themes
Is there any way we can see how our theme suggestions are doing? I would love to see the votes that my suggestions got.
Internally this is possible, but then it’s a question of what’s too much information. After the fact yes, but during, I’m not sure.
Yeah this would be great even if it’s after the voting is finished.
still need to bring back the flashy logo
can you make algorithm to make sure all suggestion is voted instead of random selection
Yes. I didn’t have the time to do it this time (I wasn’t happy with my current implementation idea), but I think I have an idea now I’d be happy with.
You should make it so that you can see how the themes that you suggested have been voted. It’s probably too late for that, but for next time.