The point of this post is to make you aware that there are more projects tackling with trophies than just the OMG! trophies and I’m asking to give it a little more time before you think about integrating your app.
Not there yet, obviously – it’s missing bling, polish and refinement. We’ve already asked for trophy icons from the design team and Lapo Calamandrei (the icon machine) stepped up, so that’s in progress.
The gnome-achievements project has a single goal and that is to enable users to discover application features. Fun is a side effect of that.
For example in hamster – it is hard to expose some specific features in the UI – like entering negative minutes to start activity in past, or the fact that you can override the default report. It is documented in help and linked as contextually as possible (in the delta times case you see the help icon in the input box now) – but often one won’t even realize that there is a better way to do things.
And so enter trophies. If you know negative deltas, then after doing it a number of times you will get a trophy. Maybe you will say “hey – what was that about” and go into trophies and stumble upon more interesting ones. Or maybe, if you don’t know negative deltas – you will stumble upon them via some other trophy or by deliberately opening the trophy browser.
We have come up with 67 trophy ideas for hamster so far, out of which 34 seem to be viable right now.
The current progress is that the service is there, there is a rudimentary browser and now i’m working on putting the trophies in hamster. The plan is to gain insight while doing that and write a first draft of guidelines. There are many questions to be answered and the whole system, being so different from video games, has to be rethought. Do ranks make sense on desktop? Should hidden trophies be included in the interface if there is such a large proportion of them. And so on.
After that the plan would be to approach developers of some other project and with them try bring trophies into their app and see what bits are missing.
And after a few more trials then we go public. It shouldn’t take too long – a month or two perhaps.
Apart from coming up with guidelines, which i think are crucial to be relevant, the trophy system itself will try and offload as much of trophy related state-tracking, as possible.
Anyway, it’s not a release yet, and there are things coming and going, so this is not the point where you plugin in yet. There will be a proper announcement when we are there.
Finally, we do plan to get into GNOME eventually. And there is such intent because i firmly believe that this makes sense.
If interested, head on to the wiki to find more details and check out the code.
|
|
Project Hamster 
This is nice and quite thought-out, though does your post need to be condescending towards Seif’s work? He’s obviously gone for a much more game-ish feel to his project and therefore is different to your work. There is no reason why both cannot exist at once to try out ideas.
Also, I’m sure no one cares if he wrote 20 LOC or more, there is obviously an audience for his work and therefore he can/should continue with it.
Anyway, I look forward to seeing what plugs into this and how you choose to deal with the UI and feedback to the users about gaining achievements.
We were seriously disappointed to see Seif post about a project that was mere lines into implementation. While we’re working to bring something that is both thought-out, documented (including guidelines on how to design trophies) and field-tested, Seif organizes a third total rewrite of his project (Python → C# → Vala). This just wastes people’s attention. If we waited a month more before announcing gnome-achievements (and the plan was to wait until it was ready for consumption for GNOME app maintainers), people would just say “oh, so now they’re back to Python, umm, okay I guess”.
although i don’t think i condesce on the omg! trophies, i take your point. Also, slightly mildened the blog entry replacing “zeitgeist plug” with “omg! trophies”.
what i was and still am worried about, is the split of attention and that the whole achievement idea will be reduced to absurd so that it would become hard if not impossible to convince application developers to even consider the idea.
I completely understand your point, and it is unfortunate that there are two competing systems. However I guess that (being someone who tries to keep a close eye on PH development), I woke up today not being amazed by the cool, though-out, trophy system, but being slightly saddened by the attitude towards a competing project. I guess I would have just had a “What about OMG!Trophies?” section at the bottom of the post explaining the issues and noting that I hoped they could be solved in the long-run by some good-will from the other party.
Anyway, this is way too serious for something that’s pretty cool. Once again, congrats on the work and what looks to be a very good architecture, I look forward to seeing where you take it!
i’ve revised this blog entry once more – i think now it’s less whine and more happy
Hey guys,
Awesome job on your work. However I am a bit surprised about how you condescend my work.
1) I did not know until you commented on my blog
2) It is my choice to choose which language i want to swtich from to
3) I did link to your stuff on our Wiki
4) I was open for collaboration
5) I am having fun
If you decide to work behind close doors until you have something stable this is you way of doing things. My way is to hype the idea and gather developers. When you say focus… well Zeitgeist team has a plan ahead until GNOME 3. I want something fun on the side so hey OMG! 😛
I am still willing to discuss a standard if you want to
Please, no offense 🙂
We too were not aware of your work until you posted about it which happened to occur in the not-exactly-the-best point in time.
As for standards, I’d like you to consider using XML to define trophies up-front. It’s much easier to inject new trophies into the system (just drop a file into the correct directory, no application startup required) and it would make it possible to try and agree on a common (subset of a) DBus interface.
I would say we should allow 2 ways of defining trophies.
Currently we register trophies over DBus. I do get your point of XML but I think we need to make it as developer friendly as possible.
We changed out architecture quite a bit. So trophies are injected into the daemon by other processes (our current on is a process that uses zeitgeist to hand out wards)
Also we need to discuss trophy standards… While you are giving out point to trophies, I purposely did not want to do so…
I say we should meet up on IRC tonight or so.
What do you think?
registering trophies via dbus is not developer friendly at all as the application can not be certain that the service is there (it’s just impractical to think so) and that drills down to trying to see if the trophy is there every time before doing anything with the trophies.
apart from that, it is breaking the exploration idea as you don’t see what you get and in order to reproduce the same via DBUS you would have to run all the applications on the desktop.
additionally, when new trophies are added to the app, it has to sync them up to your service. now, how would you do that? just run registration on every startup when the service is there?
regards the second point – it does not really matter if the trophy has a rank or not, at least not now.
i don’t also think that it is something that can be decided now – it requires insights gained by trying to implement and test the trophies, not something you can just pull out of blue air.
now, there are two possibilities – you go without rank and after a while realize that the trophies differ in difficulty and perhaps it would be fair to weight them accordingly.
from the other angle, i might be going with the ranks and the more i implement, the more i see that the rank is really arbitrary and can’t be put right and decide to drop it.
in any case – adding or dropping a field and even re-running through all the trophies and setting that field, should be a matter of minutes.
is there anything else you would like to discuss on the IRC?
An application can try to register the trophy everytime but only the first time counts. So I don’t care about checks.
How does it break the exploration idea… I dont get it. An app has to run once to put up its trophies. and register it. Even another service could do it for them…
I think both options yours as well as mine should be doable…
These are the issues I want on discuss on IRC
I think our approaches differ in a way so tell me when you have time for IRC
You don’t care about the checks, but app will have to attempt to register all the trophies on every startup.
That results in everything i described in the previous comment – try looking from the applications perspective. Also – what’s the point of yet another system if there is the trophy system that should take care of it?
And what will happen when the locale is switched?
hint: http://bazaar.launchpad.net/~omg/omg/mono/annotate/head:/OMG/TrophyHall.cs#L229
Yeah so… its not like the apps will mess up on startup… but it is debatable
We are fixing the id part as we speak but I don’t see you solving it with your xml format besides giving a static id 🙂
We planned to solve i18n by only passing the trophy ID around and using regular gettext to translate the XML files (one additional intltool line in Makefile.am).
ah, gee, it’s not about messing up – it’s about whenever i start up any application that wants trophies, as simple as it might be and as few as there could be trophies and as rare as they are given out, the app still will have to run through the whole list and call the dbus service so to be sure that they are there. that not only adds overhead to every startup, but also is needless because trophies won’t change that often – now, will they?
I am building a set of trophies for you guys, as a sign of cooperation. However I would like you to meet me half way with some Trophy properties as well as some API additions…
Can we start from there?
i guess those trophies are not yet in the repository, cause i could not find them there.
if you have any ideas please feel free to file them in the issue tracker!
http://github.com/tbaugis/gnome-achievements/issues
nope they are not up yet… they work with our daemon only 🙂
Still working off the registration of those trophies for your code…
I don’t want to have my efforts damaged nor yours TBH. I would like you to publish what your doing to the world on planet.gnome.org or planet.ubuntu.com
It is the only way for us to cooperate and making non of our work redundant.
your offer to give out the shout is very kind and i’ll gladly accept it when we have something more stable – a proper 0.1 release. at that point we’ll also migrate to gnome infrastructure. there are bits missing right now, but i think i’ll finish within a month. i hope you are not in a rush.
i think we are trying to walk around the subject, but there are certain difference in our approaches, and being behind the service means that you establish and determine what will and what will not happen.
so i wonder if you would be willing to surrender your service and leave that part in our loving hands. i could promise considering your requests carefully and in case of disagreement, go the whole seven yards and explain my position in detail.
if not, then we can settle on a format eventually. i think that it is too early for that now though. I would not be worried if we diverge too much at this point because we will come back with different lessons learned then and the reason behind having one or the other thing will be backed up by experience, not just gut feeling.
If you wouldn’t mind giving up your service though, i’d like to suggest you focusing on the pan-desktop observational trophies that zeitgeist should be capable of doing. i mean some really cool stuff, not just how many times i’ve launched calculator – something that makes sense of the usage patterns – like interchangeably using 3 players at all times marks that there are bits missing in each one of them and the user is making use of it.
or how a file is being intensely edited for a good while, then orphaned and then picked up after 6 month or so – you know, massive stuff.
although being in the field for so long i believe you can come up with way better and interesting ideas.
well anyway, it does not have to be all disney land – it’s either one sees the superiority of the system of the other, or both go ahead, try out ideas and then see if they really work. like – really really work.
Awesome… I will talk it through with my other developers.
However some of them are already contributing to the engine while I am the only one working on trophy sets and a UI. So if you could consider including them in your development process it would speed and ease things. Then I would gladly surrender the engine development.
Your take?
i added a quick overview of the code here:
http://wiki.github.com/tbaugis/gnome-achievements/code-structure
and populated the issue list with some to-dos to get anybody willing to contribute started:
http://github.com/tbaugis/gnome-achievements/issues
Is there a way to have sub-categories? I would like to integrate this with anki, but it would need Trophies like this: Anki -> Deck -> Trophy and Anki -> Trophy.
So, can trophies be tagged or categorized and then viewed grouped by application and then by category / tag in the interface?
there are no plans to have categories
Do either of these solutions consider security? It sounds like any app can register a trophy (via a dbus call or xml) even a counterfeit trophy for another app.
A rewards system isn’t likely to be effective if user interest only lasts as long as it takes to download the ‘master awards unlocker’ cheat.
there won’t be any grand prize for getting all the trophies or anything.
the trophies are meant to be means for the user to explore the applications and notice functionality that can’t be really exposed otherwise – like operating habits and stuff like that.
It’s like the app could tell you are doing well when you are. a pat on a shoulder perhaps, or an interesting observation.
It’s not like you can really protect any application from the user… on their own machine. Whatever means you use it’s just a matter of either running sudo or copying/pasting parts of the program to a fresh file and running that. The more you obfuscate and user strong cipher mechanisms, the more people will find it worthwile to crack it open.