I don't expect CoT to have as much total content on Day One as CoH did by November 2012. But given that this new game is being developed with tools and technology that's at least ten years ahead of what CoH started with I would expect it'll be easier for them to come up with things like animations and artwork than it was back in 2004. With that in mind I'd guessimate CoT will start close to being as "big" and detailed as CoH was at its start even after taking the more "grassroots" development paradigm into account.

Truth be told, some of the stuff they talked about in the Kickstarter updates made me drool. Yeah, we know we won't have everything at launch but we all have to sound off about what we believe is important. I'd be thrilled with a game that worked with a lot of the tedious stuff (defeat X missions and no way to call the Contact) fixed or omitted.

I'm confident the Devs, many of whom were players, will get it right.

Cinnder wrote:

Having said that, if MWM can come up with ways to achieve this by some other means while still avoiding the common traps, I'll be all for it.

MMO innovation is great but frankly I'd be happy to just have a game that at least starts with all the "lessons learned" that CoH had by the end.

Clearly CoH evolved quite a bit over its 8.5 years and had corrected many of the problems it started out with as time went on. Hopefully CoT will benefit from that experience and be a better game on its first day without being entangled in outdated game mechanics and ideas that CoH could never (try as it might) completely divorce itself from.

With the management of expectations, I've quite often made in my posts representing MMW...

1. "available at launch" - a lot of what we would like to do can't be all done at once. Only a basic set of 'archetypes' and content levels and power sets and features will 'ship at launch.' So, stuff that we'd like to do may have to wait for updates that come soon or way after launch.

2. "no promises" - a lot of what we would like to do needs to be prioritized, coded, and play-tested. Each step along the way my pose a roadblock. So, anything we talk about comes with the proviso, "no promises," in case something doesn't go as planned.

3. "the engine might..." - The old Cryptic engine was a known quantity as to what it could and couldn't do. In the last few years of CoH, the engineers did wonders hacking the code of CoH to make it do things it originally couldn't. Some were successful (four legged rigs), some weren't (fixing base raiding). Our engineers are still seeing what our engine can do. There are many knowns about this engine, but there are also a lot of stuff players expect from a CoH game that this engine isn't known for, and we need to see if we can get it to cooperate.

So... look for the quibble words and phrases when we hype what we would *like* to do. Telling you what we would like to do is to let you all know the direction we're heading. But we're also aware and alerting you that there may be bumps along the way.

Personally, Fire Away, I would prefer that we take the time to educate the community rather than encourage the devs to watch their words. Several overzealous community members were far more damaging at propogating false expectations or reinterpreting dev statements than the actual dev issues themselves.

The devs had some very visible examples of the kind of things that never make it- anyone here remember the SSOCS that even got to the point of having its own game mag article before it was scrapped as "un fun" early in testing. Yes, they called it a super-secret-out-of-combat system (I think that was the abbreviation) but they alluded to much of it and then they "didn't deliver" and explained why. I'd rather commend the devs for being willing to cut several months' worth of effort rather than "lower the bar" and not hold it over their heads as broken promises.

Some devs, trying to maintain dialogue and get early input from the community, tried to stress in their posts that "planned" is a long way from "delivered." They knew that getting player feedback very early on can be very helpful in fleshing out different paths, setting priorities, and even scrapping ideas where user expectations for a feature would signifcantly exceed their own. They tried to set those expectations. It didn't matter-- posts were held as "promises" and the devs were criticized for not delivering. Heck, even when they moved to closed, targeted market surveys- cutting the open community out of the process- these were often leaked and then used by players as a "what's coming" marketing list, disappointed when things didn't pan out.

Things change. Often for good reason. I recall a post around the time that Kheldians came out where Emmert commented on several other lore-based but unscheduled "Epic" possibilities... one of them with a name that implied a winged race (avilian). The game didn't have "wings" back then, and this was a vision of how to add wings and incorporate it into the lore. Over the time, it was realized that the personalization benefits of "wings" were far better than tying them down to a single archetype of a single origin, so wings were just added as a costume part. With wings already in the game, the unique value of that epic AT was significantly reduced, and it thus never went into development. Yet, some players lamented the 'broken promise." In my eyes, we got something better by having wings for everyone, of any archetype, for any origin we imagine.

It starts with a simple understanding that anything "in concept" is going to be months before its ready for "in production" and "in testing" and each of these can substantially change the nature of the original concept based on what's encountered there.

(Now, if its something like Age of Conan's "barfights" that never were delivered but existed on the original product's PACKAGING... well, that's another beast.)

------------------------------------------------------------------------------------------------------------------------
I do agree with the OP's concerns to a degree. I see discussions on HOW core mechanics should work as very valid, as these are things that are fleshed out, but I also see posts wher people are essentially adding feature requests to things that CoH had, which assumes that a whole lot is already available in the game. This is a dev team with a very unconventional development team structure and a budget that, so far, is well below even CoH's original budget. There are a LOT of open variables here. While it is great to encourage ideas, it would be beneficial to temper expectations with the realization that we're participating at a VERY early stage and that many things will change or NOT be part of the initial release.

Fire Away wrote:

I actually think CoH did "too good" of a job educating the community if there is such a thing. At different points in CoH's history I heard about fifteen people (right down to a scorecard by individual of who stayed and who left), "spaghetti code", and about a dozen reasons why base raids (and other things) failed. So, I was educated... and it all boiled down to it was either "too hard" or "not worth the time and effort" to fix an on the box feature. I just didn't like this explanation or how this feature made it into production in the first place.

At the 2012 Player Summit, I basically [b]monopolized[/b] Arbiter Hawk for a goodly part of the day, throwing [b]WALLS OF TEXT[/b] at him in person, and one of the subjects that came up was the SG Base Editor (of course).

You know how when simply MENTIONING something to someone causes a look of [b]NAKED FEAR[/b] to sweep across their features and cloud their eyes? Yeah ... I saw *that* happen to Arbiter Hawk when I mentioned the SG Base Editor. The phrase that got used by him (and not just for me personally, but also publicly during panels) was "imagine playing [url=http://en.wikipedia.org/wiki/Jenga]Jenga[/url] when the stack of wood is [b][i]*ON FIRE*[/i][/b]!!"

The SG Base Editor, and by extension Base Raiding (and the PvP Rules needed to make that activity "fun" to do) were functionally Orphaned Code and Abandonware. They were evolutionary dead ends with sunk costs too high to just throw them overboard and do them again from scratch (although Base Raiding did get disabled because it was too embarrassing to allow it to continue to exist).

As Players, we had no idea of what a truly unholy mess the codebase was for the game itself. All we knew was that it worked and didn't crash (all that often), so naturally we started with the assumption that the coding was much more robust and disciplined than it actually was. Apparently, under the hood, it was an unholy horror that made the need to ritually sacrifice barnyard animals in order to terminate [url=http://en.wikipedia.org/wiki/Scsi]SCSI chains[/url] seem sane, rational and based on clear, obvious [i]and repeatedly demonstrated[/i] principles of Cause and Effect, rather than on superstitious nonsense, magical thinking and the fact that the [b][url=http://en.wikipedia.org/wiki/Bastard_Operator_From_Hell]BOFH[/url][/b] coders needed to drink warm blood in order to keep [i]sanity at bay[/i] long enough to dive into the code without breaking themselves (or the code).

Redlynne wrote:

The phrase that got used by him (and not just for me personally, but also publicly during panels) was "imagine playing Jenga when the stack of wood is *ON FIRE*!!"

I interpreted that line a little differently. IMHO it's a description of the conceptual nightmare that is editing the base while it is live.

It's one thing to have an offline tool, or more specifically a tool that edits bases while they were not in use and nobody was in them. In that case you pretty much have a 3D modeling program with added stuff.

But when you're editing a live, working base that could have players in it, there's a huge number of other things that need to be done and checked for, so that it isn't used for (accidental or intentional) griefing. Not to mention crazy things like accidentally losing pieces, so that an object is "in the base" but not in any room (and thus inaccessible and cannot be removed except by deleting the base).

So the code you put in has to deal with all this, and prevent the editor from doing something Wrong, even if that Wrong is only temporary. For example, if you had two large items in your base and needed to swap them, you need a space big enough to hold them somewhere else to act as a temporary location. Whereas if "objects won't clip" weren't required (or worse, "objects won't block pathing"), you could just have them overlap for a bit.

Which is where the metaphor seems apt: it's Jenga because:
[list]
[*]you're moving blocks around,
[*]that could affect other blocks,
[*]there's no pause (effects happen immediately),
[*]there are a lot of dependencies, and
[*]it can all fall over at any minute.
[/list]

and it's on fire because:
[list][*]the objects are live (e.g. that gun turret is an actual, functioning pet and can be shooting things while you're trying to edit),
[*]other players are present, doing various things (remember that putting things in storage bins worked as a form of "base editing" in the engine; what happens when one player puts an enhancement in a table another player moves to a different room? Not all code is written with the mindset that "fixed" objects could spontaneously move), and
[*]there could be pets running around, too.
[/list]

All these issues have [i]absolutely nothing to do[/i] with code quality. Bad code quality only makes this [i]worse.[/i]

IMHO, the CoT devs can save themselves a lot of SAN points by making base editing an "offline" activity, like costume editing, and by adding the requirement that the base be vacated when changes are applied. The most important benefit here is that base editing code does not have to interact with the entire rest of the live game.

But that opens another can of worms, which developers will recognize as the "merging" problem (and which the "edit bases while they're live" strategy avoids). One small example: Say two players, both with edit privileges, start editing the base. One player finishes first and applies their changes. So far so good. However, when the second player attempts to apply their changes, we're left with a list of bad choices:
[list]
[*]second player's changed version is applied verbatim, effectively discarding the first player's work.
[*]second player's changes are discarded because they no longer make sense.
[*]huge complex algorithm attempts to merge the changes, with no guaranteed level of success.
[*]second player has to go through the first player's version, copying over whatever changes will be kept and discarding the rest.
[/list]
One alternative is to allow only one editor at a time, effectively "locking" the base against changes until they're done. Great until the editor decides to just not log in again and nobody can change anything because that guy has the lock.

This general problem is one that every version control system has had to deal with, so the fact that they've mostly settled on the last option above (second committer merges earlier committers' work before pushing in their own changes) is instructive. However, they're dealing with text files, which are far easier to show differences between than with graphical data.

I'd love to hear what the devs have thought about these issues, but I get the feeling that they're simply not to the point where this matters yet.

WRT Base Raiding: Yeah, we all know it didn't work. But did you know the Paragon Devs sunk months into developing a BRAND NEW BASE SYSTEM? They were re-writing the base coding from scratch. And it didn't turn out to be anything better than the broken system they already had. And so, they tossed aside all that work that never even made it to Beta. It was at that point they pretty much left the current base system raid-disabled, pathing-disabled, and dead-ended development-wise. That's tens of thousands of dollars of employee cost down the drain.

A cautionary tale to be sure.

Comicsluvr wrote:

Zombie Man wrote:
WRT Base Raiding: Yeah, we all know it didn't work. But did you know the Paragon Devs sunk months into developing a BRAND NEW BASE SYSTEM? They were re-writing the base coding from scratch. And it didn't turn out to be anything better than the broken system they already had. And so, they tossed aside all that work that never even made it to Beta. It was at that point they pretty much left the current base system raid-disabled, pathing-disabled, and dead-ended development-wise. That's tens of thousands of dollars of employee cost down the drain.
A cautionary tale to be sure.

If you don't mind my asking, why would a new system built from scratch be as bad as the mess that was left from before? Was it that the old bases (many thousands of them to be sure) had to be transposed into the new system?
Sorry but I'm not a tech guy so the idea that something newly-built had that many problems boggles me.

Software engineering on the scale we're talking about here is far more like trying to write a great classical symphony or building a cathedral than it is like assembling a car in a factory.

With a car you have mass produced parts that all go together in a precise way that's repeatable over and over. Something like a SG base raiding system for a MMO is more of a one-of-a-kind creation that requires good design but also individual skill to account for hundreds of unique variables and sub-functions that all have to fit together into something that will be playable. If software like that were easy to make we'd have new MMOs or updates to existing MMOs every day instead of having to wait years for most titles.

When you consider history has only produced a handful of great symphonies or cathedrals then you might have a better appreciation for why it's actually relatively easy for huge software systems like this to fail, or at the very least turn out to be less than what was originally intended.

I've been putting a lot of thought into thigns that would be cool in a base building system, but when it comes to raiding, I keep getting stopped at the very first question:

[i]What is the point?[/i]

Everything raid-related proceeds from that. Everything else is just a customizable-housing CAD system.

As I understand it, it's not dead - what happened was the court said 'Yes, you could do it, FCC, but you can't do it under _the specific authority you claimed_. Fixable.

summer-heat wrote:

I've seen code _like this_ first-hand and I can attest it is absolutely bone-chilling terrifying. Once I actually had to take a week off AFTER I dove into code like this, which everyone agreed was needed when my basic english sentence structure started jumbling up from my experience in it. Code like that changes a man.. and the PTSD-like dreams of code on mushrooms are enough to send a man crawling back to momma.

My current job requires me to maintain, improve (and whenever possible migrate to a sane codebase) code like that. Triple indirect pointers (with pointer arithmetic!) Hard-coded variables! GOTOs!!