I would have thought that at least the official app could support twitter web intents (https://dev.twitter.com/docs/intents) which would be very useful for integration. Unfortunately it only sortof supports these intents by (I think) trying to open a list with the name of “intent” — so breaks them instead of implementing them.

Thanks

Regarding:

3.1 – the pricing for submission vs. amount of judging required is geared such that the game shouldn’t run out of pics. Any pricing change needs to ensure that every player will effectively replace the pics that they kill through judging. This is the basis for many of the annoy aspects in the scoring.

3.2 – I’ve noticed the same pic coming up many times also (excluding lame dupes like “Link”). Others, like yourself, have also noted it. I dug into the code a while back to check that there was no significant bias in the pseudo-random numbers used to generate battles – as far as I can tell they are truly random, it’s just a psychological effect of recognizing familiar pics if they come up again by chance. I’ve been thinking of implementing a check to ensure that the same judge doesn’t seem the same pic too frequently .. it’s on the TODO list somewhere (along with prioritizing battles for pics of users who have recently played).

4.1 – The rate limit on tokens (and hence effective limitation on submission credits earned per day) is so that people take care to submit good pics, rather than just submit spammy pics in order to level up. That said, for those wanting to submit a steady stream of high quality pics like yourself, I can see how this rate limiting is annoying. The original design was geared so that players could spend 5-10 mins per day judging, in two sessions (eg morning and afternoon) and get enough credits to submit two pics (again, one in the morning, one in the afternoon). It is a deliberate decision to prevent players from being able to play too much in one day … basically since I don’t have time to play much more than that, and I needed to level the playing field against kids with too much time on their hands . The new scoring scheme breaks this a little – I guess it would take at least 12 – 15 min of judging, across two sessions, in order to submit only one pic per day. On re-examination, this is a little onerous and unfun. Maybe raising the judging token cap to 40 (or 60 ?) would help somewhat ? This way judging to earn enough credits for one submission could be done in a single session. One way to speed this up would also be to make the judging inteface (“Arena”) faster .. more about that later.

4.2 – It would be good if battles were more evenly distributed between pics .. but how exactly to do this, and do it right, isn’t as easy as it first seems. If I were to give battle priority to pics with fewer battles to try and even it up, new pics would tend to get lots of action, neglecting older successful pics. It’s always interesting how ‘completely fair’ distribution of battles ends up looking unfair though – maybe if I did prioritize battles for pics with zero wins+loses, things would *appear* more balanced (even though they wouldn’t be). An alternative way I think is to simply give priority to battles for pics of users who have recently played – this won’t even up the battles, but it will mean active players get their pics judged more quickly, which should be more satisfying.

4.3 – There is a “previous page” and “next page” link on the fight history page that work, but the Android “Back” button will back out of the inbuilt browser entirely. I know this breaks Android conventions, and I should fix it … the idea was to make the inbuilt browser not so browser-ish so that people didn’t expect it to behave that way … but obviously that plan hasn’t worked out.

And that brings me to the interface.

I agree that the interface could do with a lot of work. As long as there isn’t need to dramatically overhaul the scoring system again (given the few extra tweaks discussed above), I can focus on UI improvements and new features again (eg, the often requested local save/load feature). The original idea of using an embedded web interface was that I could easily port GMP to multiple platforms .. namely Facebook and iPhone. The amount of time it’s taken getting the game to where it is, I think those ports are a long way off. Also, while the iPhone App Store has become more transparent in recent months, I’m not a huge fan of the way Apple manages their platform, and I’m not sure if I want to risk wasting time on an iPhone version only to have it rejected because some Apple drone spotted some ‘offensive’ user generated content. I’d rather let the players decide what they like, not Apple. So, the upshot of this is that either the web interface needs to be dramatically improved (tough, but possible), or I start building a native Android interface that has the same sort of functionality (my preferred option). A native interface should be really snappy particularly if lots of caching of pics is used. It will be sad to throw away all the work I’ve done on the web interface, but the more I think about it, the more I’m convinced it’s the best way forward.

The other idea I’ve been toying with, but have avoided mentioning lest people start demanding it faster than I can do it, is to open source the whole kit-n-kaboole. This would allow others to help fix bugs, add features and even start their own servers with different rules etc (I’d add a global server list to the client). In reality, for project like this, I doubt many developers would contribute much, and there aren’t really enough players to warrant multiple servers at this time. The main thing holding me back is that the code really needs a cleanup to remove embarrassing bits before it is seen by anyone with a skerrick of programming experience.

Greetz!