Arcanaville

They could ensure there are no end-arounds in the reward system. The notion that balancing reward systems or combat systems is an impossible, and therefore ludicrous task, is itself ludicrous. It may be difficult, and the tools to do so may not be commonly exercised in typical game design methodology, but the notion that its actually an impossible task is so humorous to me from an engineering perspective that I always look upon it in the same way I look upon the notion that the moon landing was obviously faked.

You can't stop "farming" and "powerleveling" but you can theoretically ensure that the only skills that generate enhanced rewards are efficiency-related ones, not corner-case advantage-leveraging ones. You can make sure the players can exercise tactical options, and not engineer skewed circumstances.

You can try to improve both the speed and the precision of game rebalancing, and there's no question there's tons of room for improvement there. But you don't, as someone else put it, "give up." Giving up on game balancing is giving up on game design, period.

What you want in a closed beta tester is someone capable of finding ways to break or exploit the game, is willing to report such findings to the devs, and has the restraint to avoid using that knowledge for personal gain.

But we'd be in beta by 2013, 2014 at the latest.

Still thinking about those, as I mentioned at the end of the post:

As I said, you can argue what (I agree it goes too far) but not the if (I don't agree they can simply ignore it until they come up with a solution guaranteed to be optimal).

I can't attest to who was or was not in the Shard itself during I9 beta, but I can say with certainty that having been in basically *every* closed beta your portrayal of it is basically fantasy. *I* was testing Pool A drop rates in I9 beta from almost the very beginning. In fact I started a thread with my drop rate results only to discover someone else had beaten me to it, whereupon I dumped my results into their thread and then switched to testing Pool B end of mission drops. And in between the love-fest posts which are the only ones you apparently saw or remember testers were complaining about, and making suggestions regarding things such as common IO recipes, salvage storage, ingredient-recipe inconsistencies, and the like. I also hammered the devs on things like LotG and GotA being unique, and all the tohit buffs in the invention system (which caused them to get changed to accuracy buffs). There was massive testing and critiquing going on in I9 closed beta.

There wasn't as much opportunity to be highly critical for Issue 10, but there was a lot of testing of the RWZ and its missions, and those were pretty broken at times. And of course, while people were fawning over Positron they were also complaining about things like the mole machine.

Issue 11 was back to form. People complained about the way combos worked, they complained about the performance of Willpower, they complained about the stalker version of Willpower. The players also specifically got two changes to Willpower: they got its immobilization weakness removed after repeated complaints that lack of immobilization was potentially worse than lack of knockback protection because critters are designed to be able to perma-immobilize in many cases, and they got quick recovery moved from tier 7 to tier 6 which is a massive difference for scrappers and brutes: it makes the power available at level 20 - when stamina would first become available - rather than 28. The testers also beat the crap out of the Ouroboros system and complained about the temp power attenuation.

There was a lot of back and forth testing and debate over Cimerora and the VEATs in Issue 12, day jobs and the merit system in Issue 13, and even the architect in Issue 14.


For you to characterize the closed betas in the way you do, I have to assume you either weren't actually there, or you were there and were not an active participant, or you have such a loaded perspective that you were incapable of seeing what was going on around you. To say the testers were not rigorous or critical in *any* of the closed beta tests going all the way back to CoV beta - and I was in every single one of them - is so contrary to the facts that its insulting. And its personally insulting to me, because the issues related to this patch are things *I* personally tested in Issue 14 beta and reported on, so if you're saying that these issues are due to the quality of the testers of I14, then you're specifically saying that about me.

There is exactly zero public knowledge available for any MMO that Paragon Studios is working on besides City of Heroes/City of Villains. There is only some speculation by observant players that some of the personnel shuffling that has happened in the past several months may be a reflection of people being moved to areas of responsibility for some other project or to oversee multiple projects. Beyond that, CoH2 could be City of Hydrogen for all we know.

Suppose you don't care about starting fresh. Suppose you can work out all the technical details. Suppose you can make an entire new game such that its possible to seamlessly level from CoH1 into the new game. The question remains why you'd want to make that a totally new game rather than just an extension of this game?

In other words, why would you want to go through all the trouble of solving all of the problems you just mention, and then arbitrarily make it difficult to move from CoH1 to CoH2 when you could just jump on the train and zone into it? It would be like if the devs made Going Rogue a totally separate game, and when you hit level 20 you had to character copy yourself into Paragon City.

Basically, I'm not saying what you are theorizing is impossible, nor even necessarily a bad idea. What I'm saying is that if you're going to do it, you might as well go all the way and make it an end-game expansion for CoH1 with optional autoleveling rather than a CoH2.

Of course, the market for an end-game expansion for CoH1 with autoleveling is probably significantly smaller than the market for a CoH2.

At least one of the issues the pet recharge change was intended to fix was, if I remember correctly, that recharge did some really weird stuff to critter AI. And to be honest, I *still* don't exactly know what the critter AI was doing, and I've studied it probably longer than anyone else. I do know that some improvements were made to critter AI that *might* make those changes reviewable and maybe reversible, but the changes were so relatively recent I'm not even sure they are on the live servers yet.**

I do know that at least the problems I'm familiar with were amazingly bizarre and inexplicable. Sometimes critters would do things so strange I would swear there was a dev controlling them just to screw with me.


** As some of the problems were potentially exploitable and involved under-the-hood things, any fix for them would not have been necessarily announced in patch notes.

This is actually not too far from my current line of thought. Its not a bad starting point for a workable solution although there are still some gotchas in there. The catch is that as stated its still too expansive because it counts things that *have* buffs and debuffs but don't actually buff you or debuff your targets. Furthermore it presumes an ally that possesses attacks can actually use them. There are ways to ensure they don't.

I have an outline for an idea that I was going to eventually put some time into, that involved the problem of how to give support characters credit for kills - say, how to give a rad defender partial credit for helping to defeat a giant monster. It occurs to me that idea has significant application for this situation. But I don't know if its technologically feasible. Working in my favor is that if implemented, it would solve several problems simultaneously. But it might take a significant amount of work in parts of the game engine not often tweaked.

The basic outline is to consider an overall fight to be a case of you dealing damage and you taking damage. "Help" is when something increases your damage or decreases your incoming damage. If the game could calculate damage components in a manner similar to how the tohit code calculates deflection messages, you could theoretically say, for every attack you make, how much of that damage is "yours" and how much is due to someone else buffing you or debuffing the target (this is not as straight forward as I've phrased it to be, given the way buffs and debuffs interact multiplicatively). A rad defender using EF on a giant monster could, in effect, get partial credit for all the attacks that land.

Do that for custom critters, and you could divide up the XP for each and every kill into your part and your buff-bot's part. A more complicated scenario could attempt to proportionately value defensive buffs which reduce your incoming damage.

This is, of course, an extremely tricky and speculative idea. I *think* I can make the math work (the defensive part is an order of magnitude harder to make fair). I don't know if there is enough jelly doughnuts in the world to bribe the devs into attempting it during their I17 crunch time. And even this somewhat complex idea has some corner cases still to consider (the most obvious of which is: what do you do about stacking slows and mezzes).

Unfortunately this is exploitable. The problem is that you can make buff bots that have melee attacks and buffs, set them to buff you with long-duration buffs, flip them back to passive, and use the buffs until they run out. There are other AI-related tricks you can play, but this is the most obvious one.

Its also surprisingly tricky to determine what an "attack" is in an automatic fashion. This is something I've specifically put a lot of thought into.

There's only one reason that can cause that that I'm aware of. The devs have datamined evidence in hand that the problem is being leveraged to increasingly higher degrees, and across an increasingly wider percentage of the player population. At that point, and this is true for every MMO dev team I've ever heard of, action is non-negotiably mandated. You can still argue what but the option to argue if disappears.

You can debate the philosophy if you want, but you'd basically be arguing to repeal gravity.

You can exercise your creative juices supporting the existing game, and retrofitting improvements to it, from a development standpoint. From a publishing standpoint, I believe the point to a fork is for the fork to leave the baggage of the past behind, and launch a game with that new car smell.

I don't think getting a jump start should be considered in the same vein as transferring powerful characters from one game to the other. Both City of Heroes and City of Villains had a couple of days of head start. But you still started from scratch. Allowing people to transfer CoH1 characters into CoH2 would be like allowing people to keep beta characters into launch. I don't know of any MMO that allowed that to happen. The beta wipe is, I think, the ultimate expression of the principle that at launch everyone starts the same, and it appears to be (small pre-order perks aside) an absolute of MMO launch philosophy.

Apple isn't interested in developers making applications that run on the greatest common factor between their platform and everyone elses. They want developers that specifically target their platforms, and make applications that specifically target their platforms' strengths, work around their platforms' weaknesses, and distinguish their platform in as many consumer-attractive ways as possible.

It should come as no secret, since that's been their strategy with iPods and iPhones from the start. They really don't care what anyone else does on any other platform in any other context. They really don't care what anyone else expects either. Their message is that Apple products are different, and that difference makes them better, and if you agree, buy one. If you don't agree, buy something else: they don't care. I think you'll find tons of people who either agree with, or disagree with, that message, but no one should be confused as to whether that *is* the message, or whether or not the message has been commercially successful to date.

The analogy was specifically intended to highlight the fact that while you might think eliminating a couple of powers solves the bulk of the problem, in fact it wouldn't even scratch the surface of the problem. Honestly, fortitude is a more serious offender in buff bots than force fields. In other words, its only a better fix in the sense that it does nothing, whereas the current patch seems to be doing too much.

My hostility, such as it is, is specifically directed towards the notion that complex problems have trivial solutions, when basically none of those trivial solutions ever seems to be either workable, or even actually address the problem. Exploit-related (actual exploits, and general exploitive activity that isn't actionable exploits) issues are usually acted upon when the devs have direct datamined evidence of that activity. My guess is that the devs have dozens, maybe hundreds of examples of this sort of thing going on, and the directive is not just some generic vague "fix buff bots" but rather "fix everything on this list, and everything that isn't on the list but is related to things on this list. Today." Suppressing two powers isn't a "better fix" because its not a fix: it almost certainly doesn't satisfy the mandate.

I'm currently trying to think of a more elegant solution, actually. It isn't quite that simple. For example, an ally with nothing but radiation emission debuffs would not buff the player, but could debuff the critters in a comparable way that made them both easier to kill and offensively ineffective. But if they only debuff and don't do credible amounts of damage, confuse-like code won't account for them either.

The only ideas I have that might work correctly would require code, and that means they would likely take a while to implement, assuming you could get resources allocated to implement them.

If the patch is counting non-supporting critters, its broken and should be fixed or rolled back. That's my opinion on the patch, period.

However, having said that, these sorts of "see how easy it is" posts are pretty worthless. That would address the issue in the same sense as trying to fix a hole in the geometry by putting a sign in the game pointing at the spot that says "hole in the geometry."

For a suggestion that is free, you're charging too much.

Never going to happen. The whole point of making a new game would be to in effect start from scratch. You want to be able to market the game as a totally fresh start. No one has an advantage over any others. Everyone gets to start clean. You have a chance to get in on the ground floor. There's no (or as little as possible) pre-established social or gameplay conventions. This is so important to a new game launch that I think the powerleveling issue is not even on the radar compared to this one.

The cost to do this just in terms of the intangibles makes this simply not worth it. Assuming NCSoft is making a CoH2 I could imagine NCSoft allowing CoH1 players to transfer CoH1 characters in some fashion like four years after CoH2 launches and has established itself. And I can imagine NCSoft allowing CoH1 players to preorder and recreate their characters from scratch during a headstart period. I could even imagine NCSoft making a tool that would convert saved CoH1 costume files into CoH2 costume files. But actually transfering a character in any sense other than as a convenient way to recreate name and costume?

I think it will be tempting, but even if Paragon Studios wanted to do it I believe the publishers would strangle them before allowing them to do that.

I have no knowledge of the devs looking at those powers. But I personally would not specifically design a build on the presumption that any attack that does significant damage would also do a reliable long duration mag 4 hard mez. If the devs asked me to make a list of every power with an oddity or inconsistency that should be reviewed by the powers team, seismic smash would definitely be on the list.

I don't think they are, and never said they were. I think they were exploitive, in the colloquial sense, but not an Exploit, as in something the devs consider bad faith conduct which is actionable. Or to put it in a less loaded but much wordier fashion, I believe buff bots take advantage of a feature that has an imperfect compromise in its design which was intended to provide more latitude than a fool-proof design would allow, but which the devs hoped would not be leveraged to the point where they would have to take compensating action. That's usually what I mean when I say something is "exploitive" but not an "Exploit."

In between "fine and dandy" and "exploit" is "unintended, not generally desirable, but no specific solution that doesn't create other problems or that can be implemented with the resources currently available." The binary distinction is a false dichotomy.

An example would be the Mag 4 stun in total focus. Castle wasn't comfortable with a boss-stunning ultra-high damage attack long before the power was actually changed (I know: I discussed it with him long before it was changed). However, the devs were not going to significantly nerf a power blasters had when their internal datamining showed that blaster performance across the board sucked**. So for a significant period of time Total Focus was not "fine and dandy" but also not "an exploit." It was too powerful, but possessed by things that were too underpowered. Note that first blasters were given a modified Defiance (end of '07), and then after a period of time had passed Total Focus was revised (mid '08).


** It was only after I found out that Defiance was changing, and *why* Defiance was changing, that in retrospect what Castle said about total focus made complete sense: he basically said that total focus' stun was probably too strong, but that was not a high priority problem until "other issues" regarding blasters were looked at first, once resources became available.

Actually the first Ariane 5 test launch blew up not because of a specification error. It was a double-dumb implementation error:

1. The Ariane 5 control software included a subroutine from the Ariane 4 system that converted some floating point flight data into 16 bit integers. In Ariane 4 those values never exceeded the 16 bit space but on Ariane 5 the launch velocities were able to overflow those counters, causing an unhandled software exception. This specific component of the software was not designed that way for Ariane 5 and never tested in ground simulations.

2. The Ariane 5 control software didn't even need those subroutines because it handled those functions in a different way, so those values were just thrown away anyway and not used. That's actually why they were never tested. However, when the overflow occured, the processors threw a trap, the trap had no handler, the system determined there was an unknown software error it couldn't recover from, and self-destructed the rocket.


In any case, the use of buff-bots is not an Exploit with a capital-E, in the sense that it is an actionable violation of the rules of the game. However, it is an exploitive with a lower-e use of the mission design system. I know the devs knew about these types of problems because I was personally involved in the testing of these circumstances (in I14 beta, testing all the different ways critters and custom critters could be used in AE missions was basically *all* I did for literally hundreds of hours), and I know that using buff bots to allow players to get either minimal-risk rewards or highly accelerated rewards was not intended. The existence of the ability to even include them was a compromise, as most features of the AE are, between trying to give the players as much flexibility as possible, and trying to curtail the worst excesses of exploitive (and Exploitive) behavior.


The question often comes up: if the devs won't let everyone use everything for everything they want, why do they include it at all? And the answer is simply that if the devs only included in the game things they were willing to allow to be used in literally every conceivable way without regard to balance, there would be no game at all. There is nothing in this or any other MMO for which that statement is true. If someone believes that the moment a developer places something in an MMO they are giving unqualified permission to use that thing in any and all possible ways, with an additional promise not to change it when unexpected and undesirable uses are either discovered or discovered to be excessively promoted, then that person is obviously not within the target audience of the MMO industry.

One thing you could play around with if you didn't want to commit to making an iPhone CoH app might be to make a mobile skin of paragonwiki. It would be an interesting mental exercise just to try to figure out how to make the most useful possible interface that will fit on a smartphone screen. That thought process would be a necessary first step to making a good iPhone (or other mobile device) app anyway.

One significant limitation on the iPad currently is no universal storage. Every app must maintain its own separate and isolated storage. So the iPad itself doesn't "sync" documents, its actually iPad apps that do. If an iPad app is written to support document synchronization, the app itself shows up in iTunes with a document folder you can stick things in. iTunes will then sync those documents into the working directory of the app itself on your iPad.

Its clunky and a major limitation of the iPad. While I can appreciate the app isolation intrinsic to the design of the product, the ability to share data between different apps on the device in *some* way is something that has to be resolved eventually to fully unlock the potential of the product. Or Apple risks losing control of this issue altogether by being trumped by the cloud computing people, to the detriment of both themselves and most of their (non-cloud dependent) app developers.

There's two different issues here: the actual limits and capabilities of the tablet platform in general, and the specific design decisions (i.e. multitasking) that Apple made in the first generation iPad.

In my opinion, the reason why there is a place for tablet computing is the same reason there is a place for smartphones. There's absolutely nothing my iPhone or anyone else's smartphone does that my laptop can't do - not even make phone calls in theory. So why do smartphones exist?

1. They have a convenient form-factor
2. They are almost instantly available
3. They are specifically streamlined to do certain things, such as actually making phone calls.

The last one is the one most computer people fail to recognize. Computer jockeys are notoriously bad at understanding the requirements of consumer electronics devices in general. More features is automatically better in the general computer world. But not in the consumer electronics world. Computer people laughed at the iPod shuffle. They were dead wrong.

Its too early to know if the iPad and its constellation of apps will make the jump to convenience item, but its certainly within the ballpark. The battery life alone makes the iPad a player in the consumer electronics field that no laptop or notebook can touch: if you need a device that only needs to do a subset of things, but needs to do them untethered all day long, you have three choices: laptop/notebook, smartphone, tablet. Based on my testing, the iPad will be running long past the point where both of the others will be dead (even smartphones burn their batteries up too quickly when doing heavy app running or network transfers).

I know would much rather find an app that would record my meetings than bang away on my laptop (if this app didn't exist, I had already suggested to a few people to write it). Things like this, and not clunky attempts to do the same thing we already do on laptops, are where tablet computing is going to ultimately go, and app evolution like that is what tablet computing needs to carve out a place for itself.


Now, things like document management and multitasking (at least some version of it) are things Apple is going to have to improve on. But those things are not limitations on tablet computing, just the limits on the 1.0 version of the iPad, and perhaps on Apple itself. The 1.0 version of the iPhone wasn't all that great either. But in my opinion, having seen tablets from the GO and the Newton up to the iPad, I think until recently just like smartphones would have been ludicrous to try to create in the 80s, the technology to make a genuinely interesting tablet computer has only existed very recently. History is simply not a good guide for whether tablet computers will ultimately succeed.

In any case, I think the Kindle is the defacto counter-example to the notion that tablet computing is a temporary fad. I think as electronic book readers continue to get better, they will continue to displace print as the means to carry around and read documents and books. The Kindle is the extreme example of the special purpose computing device, and I don't think its going anywhere. Apple is betting that you can succeed selling the couple-dozen use tablet rather than the single use tablet. They might ultimately fail, but I don't think it will be because tablet computing itself is doomed.


In the long run, tablet computing only has to hold its own for another decade or so. The entire game of portable computing in general is going to change because of the twin advances of cloud computing and wireless broadband. And in fact, there are iPad app developers that are just getting their feet wet trying to sidestep all of the limitations of the iPad by moving both storage and computing into the cloud.