As regular players are too-painfully aware, there are a couple of ways in which the CONE SF system has been “nerfed” (gamer slang for a system that has intentionally been made less-capable in some area).
One disability that the system has had from the beginning is the way the camera will automatically zoom to a fairly zoomed-out position (not the maximum zoomed-out position, but pretty far) if you try to point it in the area of the buildings in the upper lefthand corner of the panorama. As the FAQ explains, that has been done for privacy reasons, and while it’s kind of a pain when you’re trying to get a shot of the Rock Pigeons on the rooftops, I think it’s probably necessary.
The second disability is one that the game acquired on May 7. I talked about it some in System Changes. Basically, since that time, certain operations take a lot longer than they used to. In particular, loading the My Gallery page, and entering an ID on an individual photo page, can sometimes take a very long time.
My assumption has always been that this represents an intentional act of nerfing, rather than an unintended performance problem. (Update: Actually, as of a couple of days after I originally posted this, I no longer think this. I’m now thinking it’s an unintended performance problem. I’ll post more on that when I’ve got more specifics.) I’ve mentioned it a few times in emails to the site’s operators, and although I’ve received some feedback from Professor Ken Goldberg (the project’s co-director) and from Bryce Lee (one of the students who developed the system) to other comments I’ve made, they’ve never said anything specifically about this issue. Which is pretty much what I’d expect. There’s a complex dynamic that controls what information you do and don’t give out when you’re developing an online multiplayer game, and as someone who’s been on both sides of that issue I understand, and sympathize with, the CONE SF creators’ hesitation to share too many details about what they’re doing.
So, given that I don’t really know what the intention behind this was, or the specifics of how it has been implemented, it’s hard for me to be sure of what I’m about to say. But I’ll say it anyway: I think this particular act of nerfing isn’t very effective. It doesn’t appear to me that it’s accomplishing much beyond annoying a lot of us to the point that we’ll probably end up using the system less than we otherwise would.
In preparation for writing this item, I ran some tests to try to get a better idea of how the nerfing actually behaves. I turned off image loading in my browser (to better monitor the connections I was making to the server), loaded the My Gallery page multiple times in new browser tabs by Command-clicking in Firefox, and noted how long it took for the individual requests to complete.
Here’s the first test I ran, in which I submitted five requests in quick succession (spanning two to three seconds, probably, from first to last). For each request (numbered in order), I give the number of seconds until the server’s response completed:
Requests submitted at 08:30:00:
1: 47s
2: 54s
3: 1m 00s
4: 1m 08s
5: 1m 15s
I suspected that that test might have been influenced by the clicking around on the site I’d been doing just prior to that, so I waited several minutes, then tried again, this time only making two requests. The results:
Requests submitted at 08:35:00:
1. 8s
2. 16s
Then I ran a test with three near-simultaneous My Gallery page loads:
Requests submitted at 08:37:00:
1. 8s
2. 15s
3. 22s
Next I did a test with four:
Requests submitted at 08:39:00:
1. 8s
2. 16s
3. 21s
4. 28s
And then with five:
Requests submitted at 08:41:00:
1. 8s
2. 16s
3. 24s
4. 35s
5. 1m 35s
That one was interesting. Between the fourth and fifth request returning I suddenly got a huge jump of an additional minute of time. Two and a half minutes later I ran another test with five requests; here are the results from that:
Requests submitted at 08:45:00:
1. 49s
2. 1m 45s
3. 2m 45s
4. 3m 00s
5. 3m 05s
Again, there’s lots of extra time being injected into several of those responses. And then I tried 10 simultaneous requests:
Requests submitted at 08:49:00:
1. 8s
2. 16s
3. 24s
4. 30s
5. 35s
6. 43s
7. 50s
8. 56s
9. 1m 05s
10. 1m 10s
Now it seems to be back to “normal”, with about 7 or 8 additional seconds being tacked onto each request. And then, just now, after not using the system for an hour or so, I loaded the My Gallery page once, waited two minutes, and then loaded the page 10 times in quick succession. The response times were as follows:
Requests submitted at 10:11:00:
1. 8s
2. 15s
3. 22s
4. 29s
5. 34s
6. 40s
7. 47s
8. 54s
9. 1m 00s
10. 1m 08s
Again, all the responses look “normal”, with about 7 additional seconds (on average) for each additional request.
So, summarizing what I’ve seen, the nerfing system seems to work like this: requests for the My Gallery page are queued up, and responded to with one response every 7 seconds (or so). There’s also something that occasionally injects a large (and variable) amount of extra time, on the order of 45 seconds to a minute. I can think of a couple of explanations for that:
1. It could be that the nerfing is being done on a per-user-account (or per IP address, maybe) basis. In that scenario, the occasional injections of big blocks of additional time could be the result of some kind of longterm effect of my previous testing. Maybe the nerfing algorithm is integrating requests across a longer span of time than the minute or two of inactivity I was leaving between requests?
2. It could be that nerfing is being done on a server-wide basis. In this scenario, the injections of extra time could be the result of other users’ requests slipping into the queue ahead of mine.
I can think of a couple of ways to figure this out. One way would be to create a “sock puppet” account and run two tests simultaneously (from different IP addresses, I guess, to be sure I was isolating the tests from the server’s perspective). But I haven’t used sock puppets to try to figure out the system up until now, and don’t think it’s really kosher, even though I haven’t been able to find any language explicitly forbidding it on the system.
An easier way to test the “one big queue, across all users” theory would be to repeat my tests late at night, when I can be reasonably sure I’m the only person interacting with the system. Maybe I’ll try that.
In the meantime, I hope the good people on the CONE SF development team will get rid of the response-time nerfing. Especially when one is trying to snap a good picture of a rarity, taking lots of photos and then trying to delete the rejects in order to get another one before the bird disappears, the nerfing is very annoying. (That annoyance is multiplied many times over if you only have one or two shots left in your roll for the day.) If it’s true that all the users entering nerfable requests at any given time are competing with each other for a place in the queue, this gets even worse, since when a rarity is on-camera everyone will be trying to delete their rejected shots at the same time. In effect, the system will become cumbersome and unusable at the precise moment that players are most sensitive to its performance.
That’s not fun. And games are supposed to be fun. 🙂
Okay; done ranting for now.