Are we already seeing 'graphical improvements'?

HA!

What would it take for that to happen? I don't mean in terms of hours, marketing, but in coding? What would have to be changed?

Hundreds of new animations if the types were used in any extensive way. That's after rewriting the systems.

I think the point you are making is that hindsight makes other ways clearer, but the way you said it is hard for me to not reply to. There are always alternate ways of doing things, even if there is an industry standard. They didn't predict that people would want power customization, but I don't think it's right to suggest that nobody could have conceived of it before customer requests came along.

Hmm... Let marketing handle it...


FOR IMMEDIATE RELEASE

Paragon Studios is pleased to announce that Christopher "Back Alley Brawler" Bruce has accepted a position as Lead Indentured Servant. Under the terms of his new contract Bruce will be working twenty hours a day on a new customized powers system for the City of Heroes / City of Villains game engine.

"We believe this represents a significant innovation in the development of MMOs" said Brian Clayton, general manager of Paragon Studios and executive producer for the City of Heroes franchise. "As pioneers in both the comic book-inspired MMO genre and the fifteen man MMO development team, we believe this move furthers our mission to continually strive for innovation, solidify the strength of our brand, and wring productivity out of our development teams as blood from a stone."

Bruce, formerly the lead animation artist for Paragon Studios, has been a long-time proponent of increasing the amount of resources available to enhance the visual elements of the "City of" games. "We felt the time was right to demonstrate our continued dedication to the quality of our product," said Matt Miller, lead designer of Paragon Studios, "and I could think of no better person to lead this effort than Chris."

The advantages of the Indentured Servant concept are significant. MMO developers are provided adequate accommodations and food, and no longer have the need or right to leave the premises. This allows them to dedicate an average of 82% more time to game development while reducing external distractions from sources such as hobbies or spouses by 93%.

"We believe this innovation in game implementation represents only a small fraction of the potential of this program," said Miller. "For example, I understand pohsyb has been complaining that he needs a faster compiler."


About Paragon Studios
Paragon Studios is a wholly owned development studio of NCsoft West, and is dedicated to the growth of the City of Heroes franchise. Located in Mountain View, California, the team at Paragon Studios brings the world of comic books alive in a massively multiplayer 3D online universe, by any means necessary.

That's my primary concern with ATI as well. My old ATI card that I purchased 3-4 years ago worked great with CoH. Unfortunately, when its fan decided to start running at top speed constantly last December, I upgraded. Since that card was so nice, I got another ATI. Little did I know that it would work less well with CoH than the older model. So now I have to type in /fsaa 2 whenever I spot water so that I don't see my character's gigantic reflection upside-down spread across the river/sewer/slow-field-in-the-base (because whatever set of settings I have, I do manage to have watery-appearance on the slow-field AND decent water, but HAVE to manually re-set the fsaa to 2 every time I start the game because it won't save the setting.

yes / no / not really.

I hadn't read after this, and was biting my tongue on Bill's "use D3D" comment. Fact is, DirectX is a billion-dollar mistake by many game developers. I understand why a lot of game developers went to DX though since OpenGL was more stagnant than CoH with Jack at the helm.

Now though, as non-Windows computing devices are becoming more popular... Cell Phones... Netbooks... Portal Gaming devices... and the rising tide of gamers running Linux boxes or Mac boxes in addition to Windows boxes... It's becoming more important from a sales point to be able to hit all available markets possible. Using any technology that limits targets platforms is just bad business. Yes, programming today's hottest computer games using the DX api's might save a few quid on programmer paychecks.. .but what happens if somebody wants to exploit that program / application at a later date?

The empirical case in point is QuakeLive. Yes, Quake 3 is an aging PC game... but the only reason it works as a browser game today is because of it's OpenGL roots. Had it been a DirectX title the porting and updating costs would have been prohibitive.

Now, I'm not saying every single hardcore FPS of yester-year is the browser mini-game of the future. I am saying that using open standards increase the developers and publishers abilities to develop or redevelop properties and retain value in those properties. Using DirectX as a development API... especially now... simply limits a products potential market.

***

In the specific case of whether or not OpenGL made the Mac port possible... sort of overlooks something about the port. It's not actually a port.

The Mac Port simply uses Transgaming's Cedega / Cider engine to run the Windows Client. Yes, one of the reasons why support is almost seamless and just as fast is that CoH does use OpenGL... which makes the task of rendering on various graphics cards a lot easier.

That does not mean that having used DirectX would have prevented CoH from running atop Cedega / Cider. Transgaming's technology also supports re-routing DirectX calls. As CCP, the developers behind Eve Online, found out though, supporting DirectX is extremely difficult. The official Eve Online Linux client never ran as smoothly as the Windows client because they used the DirectX API.

There is also the cost prohibitive option of having simply gotten a developer to port the engine over to OpenGL from DirectX. The cost isn't as prohibitive as you might think. Large publishers behind cross platform games for the Xbox 360 and Playstation 3 do the same. The PS3 utilizes OpenGL 2.0 ES... the Xbox 360 utilizes DirectX 9. This is also why many developers find that the Xbox 360 is easier to develop for first... but have problems porting content developed for the PS3 back to the Xbox 360. Tales of Vesperia stands as a perfect example.

Anyways. Having used DirectX wouldn't have made a port impossible. It would have just required either actually porting the game, or made the Cedega / Cider pass-through a little bit more difficult.

The water topic came up while I was talking with somebody involved on the Cider side of testing.

Reportedly this is related to how the developers initially developed water early in the game, with the suggestion being made that some components of the game using vendor specific hardware calls. Also reportedly, a fix has been developed, but the tester I was talking to didn't know why it had not been propagated to the game.

A red-name developer (*pokes Ghost Falcon and Positron) would have to answer for certain but my likely answer is that there still are a couple of vendor-specific calls being made for some effects, such as water.

If the playerbase was large enough, growing and there were a bunch of features a new engine could bring even more players to it, redeveloping the engine could be a priority.

That's a lot of "if". Going Rogue will have a graphical enhancement aspect to it, but unless the CoH/V player base is doing a lot better than I think it is I don't think the resource rational exists for a complete re-write of the engine, which would have huge potential downsides (e.g. breaking things that work now) in return for little short-term upsides (sure, in the long-term it might allow more flexibility, but in the short-term all the work would be on making sure things that worked right under the old engine work right under the new engine i.e. a backend change that the majority wouldn't even see if it was done right).

My guess is that a total rewrite of either the game client or the server-side systems is highly unlikely, but I will say that I believe it is unsafe to make any extrapolations as to the amount of resources NCSoft/Paragon Studios is willing to invest in the development of the game. I would not currently hazard a guess as to what level of resources they are currently committing to the development of CoX. I only know that from the moment of the NCSoft buyout, my best educated guess has always been lower than what it has later turned out to be likely to be, and my best educated guess has consistently been revised upward.

How long it will be sustained is an open question, but I believe NCSoft is committing more resources to developing the product than any player is likely to be guessing. That bodes well for us (the playerbase) in at least the medium term.

That problem would probably go away for you if you set up your rig as outlined in the ATI sticky thread in the tech forum. I believe the only other option to be disabled ingame not listed in the OP of that thread is Desaturation FX.

Except for performance issues directly related to the "artistic" choices.

Head to Port Oakes by ferry. Once zoned in, check your FPS. Turn slowly to the right until the abandoned laboratory comes into your field of view. Watch your FPS plummet. Head to the east side of the zone. Turn back toward the abandoned lab, watch FPS drop again.

There are a LOT of these performance dips caused by how the "world" has been created using this engine.

Now I know exactly fark all about rendering engines. What I do know about is tracking performance. If the kind of horrific open zone performance described above gets fixed by the devs with GR, then I call a win.

However, if they do nothing but throw more crap into the world as haphazardly as it SEEMS they've done so far, it's gonna be sad day for a lot of people.

Sometimes it's easier to write your own code to do the things you want than it is to modify someone else's code to make it do what you want.

Three or four years ago? At this point the code probably looks like something the A-Team rolled out of a barn after a musical montage.

Yeah, your post there was, of course, the first thing I tried when I got the card and had the problems, Bill. Now, I may have not followed the instructions correctly, but when I did all that, my slow-field in my base was invisible instead of looking wavy and slightly watery. So I fiddled more and got what I have, which is perfect except for having to, as I said, type /fsaa 2 every time I start up the game.

Doing a re-write is seldom as wise or as easy a move as people think. For a code-base as mature as CoX, there is a MASSIVE amount of *debugged* and *working* code. Yes it has a few limitations and quirks, but 95% of it is perfectly good and usable. Additionally, in the case of CoX, I have no doubt that the content is tightly coupled to the code. Not only would a rewrite involve throwing out all the code, it would (in all probability) involve throwing out all the content and re-writing it to match the new system. Throwing years of labor and valid code should only be done when the benefit outweighs the cost, and that doesn't happen very often.

The Windows team discovered this when trying to write what became Vista. They started with a fresh code base, and in the end had to throw it out (after ~3 years) and seed off of Server 2003 because they had too many issues trying to get it to work (where it took an additional ~3 years to complete Vista).

Look at Champions - for all intents and purposes it IS a rewrite of CoX. It took several years to achieve, and still it is buggy and has all new quirks — something CoX went through years ago. I for one would not want to reset to a new release/opening weekend/pre-I1 state only to watch the developers patch and update for a solid year or more just to bring CoX v1 feature parity

Although I might reconsider if it means getting my own Batmobile-eqsue conveyance... :P

Sure, but their stuff always works, so that's not so bad.

Actually, Vista started off as a fork of the XP codebase, and was reset to be a fork of the 2k3 codebase. It's problems stem from classic feature-creep making the design target a complete mess. It's actually Windows 7 that is mostly based on a clean base, and it's more focused design ended up generating a much better product overall.

Starting from scratch is not intrinsically problematic. The problem comes when you're unclear about what the old code did or have insufficient direction over what the new code is supposed to do or both.

I knew I should have checked my facts before posting. I even told myself that someone would contradict me with actual facts. Did I check it? Noooo.....

Still, all the same, Vista isn't a re-write, it's the same old codebase we all know and love (sic), heavily patched. As far as I know, 7 is not a clean code base (at least I can't find any references to support that statement), it was, as you said, just developed with a clear set of priorities, mostly aimed at fixing the flaws (perceived or otherwise) of Vista.


For anyone interested, see this story (editorial?) for a real life example of how things went bad during a rewrite

This is an excellent object lesson in the old saw, "If it ain't broke, don't fix it." There wasn't any actual reason for them to make Windows Vista; they could've just kept updating XP, like Apple's done with OSX all these years. But no, the marketing department said, "It's time for a new version! It's time to boldly reinvent the wheel!" You'd think they'd have learned and just made the next rev Windows XP Service Pack 4: We're Really Sorry About Vista.

Well, yes, clearly that would be part of the apology.