I was recently reminded of the fact that in many ways, the CoH Devs didn't actually know how their product did certain things (like aggro) or how well or poorly certain parts of the game were doing (we had to practically assault the place for Blasters to be fixed). Now maybe I have a different perspective due to my background but isn't it a common use for a computer to TRACK things?
I'm curious as to what kind of tools will be built into the system to check on various parts of the game to see how things are doing. Some ideas that leap immediately to mind:
1) A way to track how many players have created a particular AT
2) How often they play said AT
3) What powers they've chosen for their ATs
4)Win/loss ratio
5) Time spent active, time spent defeated and time spent Mezzed
6) Where the toon is standing when it is idle for more than say 5 minutes
I'm sure there will be many more. If I were a Dev I'd want to be able to say 'Hey Tom, there's been a mot of chatter on the Forums lately about the new story arc being too hard. Call up all the instances for that arc so we can take a look.' Then you can compare the 'normal' parts of the game and win/loss with a particular mission or enemy. If you see that, yeah, some types of ATs have a tougher time of it, you might want to tweak things. Of course all of this should come out in testing.
Another thread reminded me how horrid the Ninjas were for MMs and another poster said that the Devs were shocked when they heard the news. Shocked? Really? They didn't have people occasionally checking the numbers for outliers? They had no way of knowing that Ninjas were essentially defenseless without Force Field?
Please tell me this will not be the case with CoT.
I remember when Star Wars was cool...a long, long time ago...
Good Games have Good Tools.
Bad Games lack Good Tools.
A game lives or dies by the quality of its Tools.
A game that stops making or improving the quality of its Tools is a game on its way towards oblivion, not success.
The only things an engineer needs in order to build ANYTHING are ... Time, Tools and Tech Manuals.
[center][img=44x100]https://i.imgur.com/sMUQ928.gif[/img]
[i]Verbogeny is one of many pleasurettes afforded a creatific thinkerizer.[/i][/center]
Good post, Comicsluvr.
I recall the time where a drop rate got indirectly and inadvertently changed--that is, reduced significantly. Can't remember the root cause, but I think it affected common recipes only (???).
Essentially, it took 5-10 days of data collection and crunching by a couple dozen marketeers to convince the Devs that something was broken.
I'm pretty sure that the market didn't get too crazy as a result, but such a basic capture of fundamental game data could be reported internally daily, and corrections made quicker.
Other examples of possible helpful info...
Internally, the Devs really love the ABC event in neighborhood X. They think the players will love it, but do they really? And is it challenging?
Examine: [I]Number of teams formed in event neighborhood during ABC event. Number of defeats of ABC event's Giant Monster per hour during peak server time[/I]
Devs just buffed the ePunks. Are people still doing ePunk missions?
Examine: [I]Time spent in each mission (sortable by faction, level range, arc, location, etc.). Team size on ePunks missions. XP/per hour vs. ePunks.[/I]
Is base building fun, simple, are there enough "decorative" options?
Examine: [I]Time spent base building, Time spent in base [/i] ...in addition to player surveys, of course
Of course, drop rate exploits, mission exploits, and faction exploits might also be discovered (if the queries are solid), even if they don't hit the MARTy threshold.
[img]https://i.imgur.com/26pBVBG.png[/img]
([i]Currently developing the Sapphire 7 Initiative[/i])
The big drop-rate bug that I recall was from i16, but the cause actually went back to i9 (it was an uninitialized variable). And yes, this is a perfect example of how... lacking... some of their tools were. Especially when they kept saying that nothing had changed, the system was working the same way it always had, etc. Of course, being an uninitialized variable meant that the code re-compile for i16 moved a memory address somewhere and, poof... drop rates got completely buggered for some people/characters, but not everyone.
I had an IM discussion going with Synapse on that issue, including showing him how to use the dropstats scripting that someone had written so he could go in on their test box, hit the "kill all" button and track what actually dropped. The fact that they needed to use a player-written script/tool to figure out that it had been broken for 7 issues speaks volumes as to their lack of knowledge of what was going on, and their lack of tools to diagnose it.
Interestingly, I started getting closed Beta invites around i17....
Wait, why do you want to monitor the Devs?
Former Online Community Manager & Forum Moderator
[img]http://missingworldsmedia.com/images/favicon.ico[/img]
To be able to plan ahead for whatever trick they're going to throw at us next, of course.
And to get to know their thought processes so we can better make arguments to swing them to our side of a discussion about planned fixes/contents/updates/etc
I bet the NSA already is...
And we can't let [i]them[/i] have all the fun...
[i]Has anyone seen my mind? It was right here...[/i]
If we don't monitor them, how will we know what kinds of cookies they like?
I really like this guy... :9
EDIT: white chocolate with macadamia nuts please. Just to be clear.
___
"What you say is rather profound, and probably erroneous." - Joseph Conrad
“The universe is made up of stories, not of atoms” - Muriel Rukeyser
[color=#ff0000]Composition Team[/color]
[img]http://missingworldsmedia.com/images/favicon.ico[/img]
My biggest memories were Aggro and Bases, personally. I read somewhere that the Devs liked how aggro was working and then they had someone deconstruct the code. They found out it wasn't behaving how they thought it was, decided the way it WAS working was better than their idea and they left it. How many man-hours were wasted on that boondoggle?
For Bases, Castle once said players weren't using Bases as the Devs had intended. I wrote him a nasty-gram asking what THEIR vision for Bases was and oh, by the way why didn't they share it during the Beta? As I mentioned before, Blasters were broken for YEARS before they were finally fixed. Defenders came next and again, it took years to convince the Devs that something even needed to be done.
My background is in Quality Assurance. I like the idea that the Devs will build in code that will enable them to detect and solve problems quickly rather than waste time. I also hate to think that the whole 'yes it's broken but we don't dare touch it or it'll crash completely' situation that we had with Bases might come up.
I remember when Star Wars was cool...a long, long time ago...
Apparently a LOT of the City of Heroes codebase was just ... unsupportable. Things like (if I'm remembering this correctly) their User Interface stuff being written in PEARL ... so as to make *sure* that pretty much any pretense of Code Control would be lost in 3-6 months, especially if people "moved on" and left the company, leaving their incomprehensible code behind. That's essentially what happened with Bases ... it was an orphaned set of Code written by someone who was long gone that "worked" (barely) but was highly unstable and therefore Not To Be Disturbed. The comment made by multiple Devs with respect to the SG Base programming code was "playing Jenga when the blocks were [b]ON FIRE!!![/b]"
Entire huge swaths of the City of Heroes game engine and codebase were like that. Antiquated, obsolete and orphaned ... but still used and "functional" as long as you didn't try to change anything about them. The game used like 3 (or was it 4?) different programming languages, not all of which were Developer Friendly (see aforementioned PEARL) which meant that all kinds of things that a Player would look at and just assume "fix this part" could potentially be way more problematic than anyone outside the people working with the codebase could ever imagine. There were "sunk costs" just about EVERYWHERE in the City of Heroes codebase, and the SG Bases were just merely ONE of the more glaringly obvious examples of that.
Noble Savage (David Nakajima) once said to me, in a miserable sigh, "It's ALL spaghetti code now" ... and that was at the FIRST Player Summit, not the second (I went to both).
[center][img=44x100]https://i.imgur.com/sMUQ928.gif[/img]
[i]Verbogeny is one of many pleasurettes afforded a creatific thinkerizer.[/i][/center]
For the record, a similar thing happened in Robotron 2084.
[i]Has anyone seen my mind? It was right here...[/i]
*makes a note* Luckily, here in Hawaii we have the *best* macadamia nuts.
Proposal: All dev monitoring tools should be named after cookies.
[i]Has anyone seen my mind? It was right here...[/i]
Written in Perl? Yeep. Often when you need to make a change in perl, particularly a big on, it's easier to rewrite the entire thing than it is to decipher what does what in the original code.
Hence why whenever a change to the game UI was needed, the Devs did everything in their power to avoid needing to dive into the Perl codebase. Just talking to them (at the Player Summits) very quickly convinced you that anything having to do with the game UI fell into the category of "back away from the keyboard [b]SLOWLY[/b]..." followed by posting "Warning! Dev Sanity Cannot Be Verified!" signs everywhere around their workspaces.
[center][img=44x100]https://i.imgur.com/sMUQ928.gif[/img]
[i]Verbogeny is one of many pleasurettes afforded a creatific thinkerizer.[/i][/center]
Oops, wrong thread.
Beware languages that require the command [code]bless[/code] to create objects. (If you read the docs, remember that when it says "might" and "consider" and "make sure", those are places where bugs or other unintended behavior can creep in, and have done so often enough to merit mention.)
On the plus side, Perl is great for code golf. Speaking of code golf, over on StackOverflow there's a code golf wiki for finding the prime factors of a number. The shortest Perl version is only 70 characters:
[code]
perl -nE'sub f{($a)=@_;$a%$_||return$_,f($a/$_)for 2..$a}$,=x;say f$_'
[/code]
Here's the Python version, 7 characters longer:
[code]
d,s,n=2,'',input()
while n>1:
if n%d:d+=1
else:s+='%dx'%d;n/=d
print s[:-1]
[/code]
I know which one I'd rather debug. But then again, I'm biased.
[i]Has anyone seen my mind? It was right here...[/i]