Your technology needs help... lots of help... lots and LOTS of help. :(

[GlowstickSwinger]

Nono, that was something you noticed and confirmed. I meant anything else.

 

What's your theory on why developers that have developed MMOs since UO chose to make it not event-driven? I'm curious.

 

HeroEngine sells itself as an all-in-one solution complete with hardware options you can rent out. HSL allows real-time updates of code. Overall, the package is designed to reduce the amount of time it takes to get a viable product up on the tech end. HSL also allows you to write game logic abstracted from the underlying C+, which is essential for any modern game development as you can then hire less-than-stellar coders to write game logic wthiout worrying about threads, pointers, or non-concurrent operations/deadlocks.

 

At my last game job, I wrote a scripting language that did just that and, just like HSL, I made it procedural so that any Joe Schmoo can use it. And it, too, had blocking problems.. especially when checking achievements. (Wonder why traditional achievement engines aren't in this game? EH? EEEHHH??)

 

If I could do it again, I'd have a scripting language similar to node.js (but not node.js... you still need object-orientation for many things and while prototypes are great, most people find them confusing) and make the whole thing event-driven. That way I'm abstracted from the torturous C++ while having the option to use non-blocking operations in the game loop itself.

Edited April 29, 2012 by GlowstickSwinger

[JeramieCrowe]

HeroEngine sells itself as an all-in-one solution complete with hardware options you can rent out. HSL allows real-time updates of code. Overall, the package is designed to reduce the amount of time it takes to get a viable product up on the tech end. HSL also allows you to write game logic abstracted from the underlying CC+, which is essential for any modern game development as you can then hire less-than-stellar coders to write game logic wthiout worrying about threads or non-concurrent operations. (At my last game job, I wrote a scripting language that did just that)

 

On paper, it's good for leveraging massive results with little input.

 

But keeping your scripting language simple (procedural) has trade-offs that become apparent as your code base and your asset library grows.

 

I realize that. But what's your theory on why BioWare chose it? The same?

Edited April 29, 2012 by JeramieCrowe

[GlowstickSwinger]

I realize that. But what's your theory on why BioWare chose it? The same?

 

- HeroCloud keeps 30% of your revenue. (Go go Facebook model!)

- Who knows what LucasFilms wants... probably something equally obscene.

 

In the end, you can either pay the pipers and get the game out now (which is all anyone ever cares about really)... or you can build it all from scratch and hope that your massive upfront investment pays off.

 

Someone pitched the idea "Hey! WoW makes mountains of gold. Star Wars makes mountains of gold. OMG lets make Star Wars MMOmgogmogmogmomg"

 

An investor went "Piss yeah, I'll take two!"

 

Then the pitch guy said, "Minimized up front costs! Look at these CHAAAAAAAARTTSSSS OMMMMMGGGgggG Super low cauwsts fo teh bauwse with HeroEngine!"

 

The investor nearly feinted and could barely contain himself to sign the pledge to invest.

Edited April 29, 2012 by GlowstickSwinger

[JeramieCrowe]

- HeroCloud keeps 30% of your revenue. (Go go Facebook model!)

- Who knows what LucasFilms wants... probably something equally obscene.

 

In the end, you can either pay the pipers and get the game out now (which is all anyone ever cares about really)... or you can build it all from scratch and hope that your massive upfront investment pays off.

 

Someone pitched the idea "Hey! WoW makes mountains of gold. Star Wars makes mountains of gold. OMG lets make Star Wars MMOmgogmogmogmomg"

 

An investor went "Piss yeah, I'll take two!"

 

Then the pitch guy said, "Minimized up front costs! Look at these CHAAAAAAAARTTSSSS OMMMMMGGGgggG Super low cauwsts fo teh bauwse with HeroEngine!"

 

The investor nearly feinted and could barely contain himself to sign the pledge to invest.

 

They modified it so much, they may as well have started out from scratch...

[GlowstickSwinger]

They modified it so much, they may as well have started out from scratch...

 

Who knows what they modified. Maybe the graphics engine was the primary focus. All I can say with some certainty is that, based on all of the specs I can read about HeroEngine regarding game logic seem to be completely untouched and do explain much of the network bloat and the disk i/o lockups.

[JeramieCrowe]

Next question for you:

 

Georg Zoeller has stated that the more cores you have, the better the performance. In your opinion, do more cores help or exacerbate the HD I/O issue?

[GlowstickSwinger]

Next question for you:

 

Georg Zoeller has stated that the more cores you have, the better the performance. In your opinion, do more cores help or exacerbate the HD I/O issue?

 

More CPUs can help with the 3D aspect (Say via PhysX and you are piping stuff to from the GPU to the CPU), but not with the game loop. Concurrent HeroScripts can have their async operations be distributed across multiple threads, and that would assist in executing the HeroScript faster per say (especially if the repo spreads out assets across multiple drives which I don't think it does), but the fact remains a script has to finish before the next one can start.

 

Technically, he'd still be right while the problem I'm pointing out would still exist.

Edited April 29, 2012 by GlowstickSwinger

[JeramieCrowe]

More CPUs can help with the 3D aspect (Say via PhysX and you are piping stuff to from the GPU to the CPU), but not with the game loop. Concurrent HeroScripts can have their async operations be distributed across multiple threads, and that would assist in executing the HeroScript faster per say, but the fact remains a script has to finish before the next one can continue.

 

Technically, he'd still be right while the problem I'm pointing out would still exist.

 

Ok, next question:

 

Which engine-type would you say is more expandable in the future as processors grow in number of cores and improved hyperthreading: event-driven or multithreaded?

Edited April 29, 2012 by JeramieCrowe

[GlowstickSwinger]

Ok, next question:

 

Which engine-type would you say is more expandable in the future as processors grow in number of cores and improved hyperthreading: event-driven or multithreaded?

 

uhhh Thread usage still have to be architecturally intelligent. A single paradigm across the board won't work. Regarding a game loop, it should scripted in a 1st class function, OO-esque pattern with minimal syntactic sugar (which HSL does) while executing in sequence (which HSL does) but it needs lexical scope preservation so that async operations can be threaded out and modify GOM/DOMs when they are ready without blocking the game loop.

 

Does this make things confusing? Yes it does.

 

Does it improve game loop performance and create the illusion of real-time seemlessness? Oh hell yeah.

Edited April 29, 2012 by GlowstickSwinger

[JeramieCrowe]

uhhh Thread usage still have to be architecturally intelligent. A single paradigm across the board won't work. Regarding a game loop, it should scripted in a 1st class function, OO-esque pattern with minimal syntactic sugar (which HSL does) while executing in sequence (which HSL does) but it needs lexical scope preservation so that async operations can be threaded out and modify GOM/DOMs when they are ready without blocking the game loop.

 

Does this make things confusing? Yes it does.

 

Does it improve game loop performance and create the illusion of real-time seemlessness? Oh hell yeah.

 

Sooo... which one has more potential for growth and expandability, event-driven or multithreaded?

[vandana_]

In my opinion (as I can see backed by the comments of other players participating in the discussion) the original post isn't a mere suggestion. It's a very well thought through speculation on technical aspects of the game (with added solutions to some problems) and it started a discussion on an important issue to many players. It deserves more attention and recognition (can we know why it was moved to Suggestion Box please?). Edited April 29, 2012 by vandana_

[GlowstickSwinger]

Sooo... which one has more potential for growth and expandability, event-driven or multithreaded?

 

That's not a question that can be answered in an either/or way. Certain operations regarding game development lend themselves to multithreading (non-deterministic FSMs for server AI) while other are best with event-driven operations (client UI)

 

What I'm focusing on is having the flexibility to do both when it is needed.

 

Distributing HeroScripts via threads in the raw results in nearly unmanageable and nearly unpredictable game logic. You're better off writing everything in C++ at that point.

 

Allowing HeroScripts to run concurrently while preserving lexical scope for callbacks will lay the foundation of a much more sane asset loading strategy. (Event driven programming which can be offloaded via threading if you can RPC the scope) That's what I'm suggesting.

 

Forcing HeroScripts to resolve all procedural operations before moving on to the next one will block things and, when compounded over time (code base increase, CPU use increase, asset volume) , you'll get serious problems.

Edited April 29, 2012 by GlowstickSwinger

[JeramieCrowe]

In my opinion (as I can see backed by the comments of other players participating in the discussion) the original post isn't a mere suggestion. It's a very well thought through speculation on technical aspects of the game (with added solutions to some problems) and it started a discussion on an important issue to many players. It deserves more attention and recognition (can we know why it was moved to Suggestion Box please?).

 

Because it was a suggestion.

[JeramieCrowe]

That's not a question that can be answered in an either/or way. Certain operations regarding game development lend themselves to multithreading (non-deterministic FSMs for server AI) while other are best with event-driven operations (client UI)

 

What I'm focusing on is having the flexibility to do both when it is needed.

 

Distributing HeroScripts via threads in the raw results in nearly unmanageable and nearly unpredictable game logic. You're better off writing everything in C++ at that point.

 

Allowing HeroScripts to run concurrently while preserving lexical scope for callbacks will lay the foundation of a much more sane asset loading strategy. (Event driven programming which can be offloaded via threading if you can RPC the scope) That's what I'm suggesting.

 

Forcing HeroScripts to resolve all procedural operations before moving on to the next one will block things and, when compounded over time, you'll get serious problems.

 

It seems to me that since the eventual size of this game is gargantuan (after all, within the year it will effectively double in size with the release of Chapters 4-6 of all 8 storylines alone), more control will be needed than what asynchronous provides, especially given the complexity of all the moving parts of simply doing your storyline.

 

I can definitely agree with your statement of combining both procedures, using asynchronous when it's handy, but as this game grows, asynchronous will become more and more of a liability and bottleneck than a solution.

 

Wouldn't it?

Edited April 29, 2012 by JeramieCrowe

[GlowstickSwinger]

It seems to me that since the eventual size of this game is gargantuan (after all, within the year it will effectively double in size with the release of Chapters 4-6 of all 8 storylines alone), more control will be needed than what asynchronous provides, especially given the complexity of all the moving parts of simply doing your storyline.

 

I can definitely agree with your statement of combining both procedures, using asynchronous when it's handy, but as this game grows, asynchronous will become more and more of a liability and bottleneck than a solution.

 

Wouldn't it?

 

Blocking operations will completely cripple your client over time, period.

 

You have no choice but to go total async when dealing with dynamic asset loading in your game loop. You just can't stop everything and wait for files to load. It's not even an option on the table lol.

Edited April 30, 2012 by GlowstickSwinger

[JeramieCrowe]

Blocking operations will completely cripple your client over time, period.

 

You have no choice but to go total async when dealing with dynamic asset loading in your game loop. You just can't stop everything and wait for files to load. It's not even an option on the table lol.

 

It's black or white, eh? That'd be a first...

[Budahla]

TL;CR Breakdown:

 

Problems

• Technical needs are lowest priority, which causes the following:
  
• Network I/O is abusive Send/read bloat.
  
• Network I/O may have blocking operations. Send/Read bloat.
  
• Client has blocking operations. Read bloat.
  
• Client loading screen isn't always away from the play state. Read bloat.
  
• Client physics engine is authoritative regarding movement. Send bloat.
  
• The more people cluster together, the more packets and the more data they are putting out, the more your bandwidth costs sore and resources dwindle as you expand.
  

 

Solutions

• Don't let marketing run the show... they never have any idea what they are doing. It's Star Wars. It markets itself for God's sake.
  
• Set aside time to fix technical debt.
  
• Prioritize performance issues over all else until things stabilize, primarily, the network I/O and the asset loading strategy.
  
• Reduce your poly count on the client.
  
• Back off any 3D engine features for a bit. You're not going to outshine where Xbox was three years ago and it's an MMO. You can get away with some crappy graphics.
  
• Devs, leads, PMs, and the CTO needs more spinal fortitude to push back against other department priorities instead of being driven to cutting corners and create more technical debt.
  
• Make HeroScript execution preserve lexical scope for async callbacks. (LOL good luck with that!)
  

 

THIS IS WHERE TL;CR ENDS. YOU CAN NOW GO BACK TO YOUR 140 CHARACTER POEMS.

 

To see the packet analysis of the network I/O, click on Show!

 

 

 

So, some breakdown on the numbers of why I think that their synchronous network I/O and syncrhonous asset loading on the client is cause of all lag in SW:TOR. I'm comparing WoW (which creates the illusion of collective areas seemlessly) with SW:TOR (which uses isolated instances, the more traditional MQ room compartmentalization)

 

The tool I'm using is SmartSniff on Windows 7.

 

A few observations:

 

• SW:TOR push down packets according to area of sight. (AOS) Stand near a crowd and you get more, stand away from a crowd, you get less. This active push prioritization would lead to false positives in QA environments simply because they could not properly recreate an environment that would tax the discerning algorithm.
  
• WoW appears to not care about where you are or what you are doing, no matter where you are, no matter how many people exist in your AOS, which is interesting, especially considering the dramatically less amount of traffic you send and get from them. WoW data is also surprisingly uniform.
  
• The physics engine in the SW:TOR client appears to be authoritative regarding movement. This means that if I jump, the client broadcasts data every single video frame until I land on the ground again. They appear to be trying to run an FPS setup that typically uses UDP on a massive scale using TCP. This is proof positive that SW:TOR network i/o strat is not good and was poorly conceived.
  
• They both use TCP.
  
• SW:TOR is pulling down data the entire time during any loading screen. WoW only pulls them down at the 90% of its initial loading screen. In many cases, the loading screens are just overlays, not actual states separate from the play state.
  
• We have a report of a Midwest player accessing a East Coast server and getting -half- of the data sent in the 10 second time span. Lots of factors can go into that and I'm trying to figure out what that means...
  

 

Without further ado, here are the numbers.

 

SW:TOR Data usage:

 

Standing in a populated area (Combat Training area) of a single instance of the Imperial Fleet for 10 seconds with 152 people in the instance:

 

Packets: 110

Data Sent: 426 bytes

Data Received: 4,877 Bytes

 

Standing in a sparse area (Far north of the Supplies area) of a single instance of the Imperial Fleet for 10 seconds with 152 people in the instance:

 

Packets: 36

Data Sent: 244 Bytes

Data Received: 1,783 Bytes

 

Standing in an impossible to populate instance (your ship):

 

Packets: 16

Data Sent: 166 Bytes

Data Received: 857 Bytes

 

Jumping.

 

Packets: 12 packets

Data Sent: 307 Bytes

Data Received: 854 Bytes

 

WoW Data usage:

 

Standing in a populated area (near the AH) of the collective instance of Stormwind for 10 seconds with hundreds of people in the zone:

 

Packets: 36

Data Sent: 42 Bytes

Data Received: 1,536 Bytes

 

Standing in a sparse area (far north @ Wollerton Steed) of a single instance of Stormwind for 10 seconds with hundreds of people in the zone:

 

Packets: 33 packets

Data Sent: 191 Bytes (I jumped.. oops)

Data Received: 1,611 Bytes

 

Standing in an impossible to populate instance (Stockades in my own group with only me in it):

 

Packets: 27

Data Sent: 56 bytes

Data Received: 1,190 bytes

 

Jumping.

 

Packets: 5

Data Sent: 163 bytes

Data Received: 463 bytes

 

 

 

To read the drill-down into the HeroEngine network optimization itself, click on Show!

 

 

 

HeroEngine Wiki regarding Network Optimization

 

• http://hewiki.heroengine.com/wiki/Network_Optimization
  
• http://hewiki.heroengine.com/wiki/System_areas
  
• http://hewiki.heroengine.com/wiki/GOM
  
• http://wiki.heroengine.com/wiki/Asynchronous_considerations
  

 

This confirms everything I believe to be happening:

 

• "Designers still need to architect systems that are asynchronous, parrallelizable, perform caching, lazy evaluation, etc as appropriate (designers think of area server instance as geometry with npcs, shops, quests, etc. As programmers we know an area server instance is a unit of simulation and we have control over spinning up additional processes called areas each of which can be used to run any code we need http://hewiki.heroengine.com/wiki/System_areas.)"
  
• "No engine, no programming language, no technology can make a bad N^2 algorithm anything other than a bad N^2 algorithm."
  
• "I might pump out more data in movement messages than can be pushed through the a physical server's network interface(s) because of everyone being aware of everyone"
  
• "A battle ground area instance where PvP combat events run might only handle a few hundred (though here probably the issue will be more of a client one depending on the topology represented and number of characters a given client simultaneously observes)."
  
• "The frequency of the movement updates is also based on distance, as managed by priority and the bandwidth manager"
  
• "On the client, each time it starts up, it gets the latest DOM definitions from the Repository. Then, when a character enters an Area, their Client loads .DAT files from the repository which generate a subset version of the GOM -- nodes on the Client that correspond to the Area." (NOTE: These file reads are actually async, but the HeroScript parent operation running that disk I/O is not!)
  
• "The HeroMachine (virtual machine in charge of running HeroScript) processes HeroScript synchronously where one instruction must complete its operation before the next one may be started. The synchronous nature of the average HSL script simplifies the learning processes allowing relatively unsophositicated programmers to work comfortably in the environment."
  

 

See that last point? That's what I saw happening in the game and I called it. I was able to deduce all of this just from the lag that occurs when encountering someone new in an open field. Please stop calling me an "armchair dev" you crazy trolls. It hurts my feeling. >:U

 

Your Client GOMS are a significant part of the problem, BioWare. They are an RPCesque solution, which explains why the client physics engine can act as an authority regarding network i/o. That is -exactly- the kind of setup we had when I was building a game and it was a resource monster. That also, sadly, explains the packet bloat and the difficulty of fixing this problem through software-based initiatives alone.

 

3D engines are a solved problems with known or at least expected outcomes, imo. It's the game logic and the RPCs/io where bad practices can take hold and turn all other resources into bottlenecks.

 

 

 

To read the original scathing rant that kick started this whole shebang, click on the SHOW button! Free bunnies!

 

 

 

The Original Post

 

Former game developer here. (No gigs with Lucas, BioWare, or the other companies associated with this... although I did contract for someone who did help with the marketing push lulz) I left the industry because too many non-gamers were entering it. Some thing about the dream of accruing abusive amounts of money from a single title seems to attract the parasites, the wolves, and the incompetent.

 

I like your game. I really do. The focus on the single-player aspect is amazing. The voice acting is from top notch talent (I personally know many of the voice actors in the game, actually) and it is delivered as well as it can be given the -extreme- amount of disconnected copy that had to be read. My kudos to your producers. I'm sure many, many long hours were spent on that aspect of the game alone.

 

Let's move on to the problem. Notice I said “problem” and not “problems”. You only suffer from one problem and all of these ailments stem from it.

 

The Client

 

I've only researched the client packet i/o. I'm assuming you purchased licenses for the 3D engine and that the lead devs on the project had a solid streak of 3D game programming on their resumes.. but only a few of them them had any experience with the engine itself. This shouldn't come as a shock, as there are many, many 3D engines on the market and having one dev knowing them all would price that dev right out of the market entirely. The logic behind my guess is that if the entire dev team was deeply intimate with the engine, then they would have been able to successfully push back against the art and marketing department's insistence on using high poly count models everywhere.

 

Yes, the creativity of these departments are paramount because it's the pretty pixels us consumers froth over. However, if this factor is the foundation of developing a game (It often is the most frequent goto by artists, marketers, and MBAs alike) then it will become obvious in the final product. That being said, your leadership has long crossed over the “golden ratio” between pretty pixels and performance. It is obvious BioWare's entire objective regarding client development is to wage a holy crusade against GPUs everywhere and crush them. It's one thing to write Crysis. It's another to write something that blows up a GPU like Crysis and have absolutely none of the visual effects.

 

I'm sure the politics in your company, the silverback chest-thumping, and the e-peen flopfests all take turns stifling any attempt to rebalance this pixel-vs-performance ratio. (SSDD) When the flaws of your product are broadcasted to the world that the devs are not included in any actual decision making regarding priority or direction, it's time to replace your CTO for being spineless and probably all of his reports.

 

The Servers

 

Your networking infrastructure, however, is not as easily purchasable as an out-of-the-box 3D engine that you just drop in and start hacking away at. It is woefully taxed. I have nothing but pity on your back-end and IT department for one reason: your asset loading strategy is completely untenable in relation to your resource demand.

 

These loading screens between “zones” (See: MQ channels/rooms/subscriptions) are reminiscent to installing an operating system from a pack of floppy drives. You do know that when broadcasting client data to other clients, that shouldn't issue a blocking resource pull from the HD -every- -single- -time-, right?

 

Right?

 

I mean, I like the little pause when on a PvP server because it lets me know that I'm about to be ganked. But I know why that pause is happening. And I know that when you tested it on your local machines that were well-tuned for this sort of testing, and on staging server setups that didn't have even 1% of the load of a live environment, this issue never cropped up.

 

It happens to everyone.

 

Don't fire off blocking calls as a response to time-sensitive events that are pushed down from the server. Your client will fall apart because those events are random. Have a default placeholder asset primed in memory and ready to instantiate until the rest of the local resources (model, textures, etc) are pulled asynchronously.. Spinning plates, man. Spinning plates.

 

This blocking call is only part of the problem. I am almost positive the vast majority of these load screens are caused by the servers trying to poll live information regarding other connections... and that you've made this a blocking call as well. Network I/O is, literally, the most expensive time operation you could perform and you've made a mass polling operation a blocking call. Going from a planet to a warzone to planet is an experience similar to participating in hurdling... except each hurdle is a two hundred foot tall stone wall. This is because you've relied on blocking calls and no one caught it.

 

And no one's going to fix it. It's very easy to undo and yet... it will never be fixed. Why...?

 

...and back to your organizational problems we go.

 

Somewhere, an investor is having ******s (I can say "******s", right? American's aren't still squeamish about that word, are they? Does that put me on a terrorist list or something?) about the revenue and ROI. Yay, capitalism! All is well... except your growth is in jeopardy and both you and I know it. Anyone watching this pure marketing-driven priority of pushing out pointless doodads and trinkets instead of solving fundamental performance problems can spot it a mile away. You have too many non-devs leading the effort.

 

You will not survive your own success because your leadership will not take the ten minutes required to have someone explain to them that people won't play a game where 30% of the time is spent at loading screens due to a failure to prioritize and solve an extremely common problem in an industry-standard fashion. What they will listen to is some non-tech failed actress say that little cute tauntauns will solve these problems. B*tches love little cute tauntauns. (The * is for 'o')

 

Say it with me, BioWare:

 

YOU DO NOT HAVE A CONTENT PROBLEM. YOU HAVE A PERFORMANCE PROBLEM.

YOU DO NOT HAVE A CONTENT PROBLEM. YOU HAVE A PERFORMANCE PROBLEM.

YOU DO NOT HAVE A CONTENT PROBLEM. YOU HAVE A PERFORMANCE PROBLEM.

YOU DO NOT HAVE A CONTENT PROBLEM. YOU HAVE A PERFORMANCE PROBLEM.

YOU DO NOT HAVE A CONTENT PROBLEM. YOU HAVE A PERFORMANCE PROBLEM.

YOU DO NOT HAVE A CONTENT PROBLEM. YOU HAVE A PERFORMANCE PROBLEM.

 

Say that in your next stand-up, loud and proud. E-mail it every fifteen minutes to the CEO. You can fix these problems. It's solvable. You just have to spill some blood and not be afraid of it.

 

 

 

 

*applauds*

 

Excellent post. Im no programmer but even i have noticed my high end pc hates tor but plays crysis2 full board with no hiccups and crysis graphics poop on tor's.

[GlowstickSwinger]

It's black or white, eh? That'd be a first...

 

Again...

 

Burden of proof > Axiomatic rules of thumb

 

You've danced around HSL handing scripts linearly long enough. It's time to start providing even 10% of the research I've provided to back up your assertion.

 

Please, explain to me how exactly large procedural operations that access latency-prone resources is somehow better at smoothing out end-user continuity than a distributed or async operation using the same hardware?

 

I'll even let you use wormholes and time travel,

Edited April 30, 2012 by GlowstickSwinger

[JeramieCrowe]

Again...

 

Burden of proof > Axiomatic rules of thumb

 

You've danced around HSL handing scripts linearly long enough. It's time to start providing even 10% of the research I've provided to back up your assertion.

 

Please, explain to me how exactly large procedural operations that access latency-prone resources is somehow better at smoothing out end-user continuity than a distributed or async operation using the same hardware?

 

I'll even let you use wormholes and time travel,

 

I have yet to make any real "assertions". I'm still gathering data. I find it hard to reconcile that a full team of experience MMO developers, who developed UO, Warhammer, SWG, and a couple other AAA MMOs, can make such a "newb mistake"... as you're portraying it, anyway...

 

There *has* to be something we're not considering...

 

When I've gathered more data, I'll get back with you. Might have more questions, too. Viewpoint ones, really, like I've been asking.

Edited April 30, 2012 by JeramieCrowe

[GlowstickSwinger]

I have yet to make any real "assertions". I'm still gathering data. I find it hard to reconcile that a full team of experience MMO developers, who developed UO, Warhammer, SWG, and a couple other AAA MMOs, can make such a "newb mistake"... as you're portraying it, anyway...

 

There *has* to be something we're not considering...

 

When I've gathered more data, I'll get back with you. Might have more questions, too. Viewpoint ones, really, like I've been asking.

 

And you didn't even use time travel! That was a freebie.

 

Unrealistic and disconnected demands of investors will always trump any flag a developer raises unless that flag it is impossible to deny in the public eye.

Edited April 30, 2012 by GlowstickSwinger

[JeramieCrowe]

And you didn't even use time travel! That was a freebie.

 

Unrealistic and disconnected demands of investors will always trump any flag a developer raises unless that flag it is impossible to deny in the public eye.

 

A little devil's advocate never hurt any scholar before.

[ironix]

Bumping this thread even though it has been moved to the thread graveyard.

[JeramieCrowe]

Bumping this thread even though it has been moved to the thread graveyard.

 

Well, if you're waiting for a dev response, probably won't get one. And it's probably because the devs are wondering why, too.

 

It's not like they're the ones who decided to make their own jobs harder by being practically forced to turn crap into gold, if that's indeed what's going on here. I'm still not convinced we're seeing the whole picture, but that's because my 40 years has taught me that things are almost always NEVER what they appear from the outside...

 

Although, I do have to say that it's a testament to their talent how well it has turned out despite the original engine's fallacies and imperfections.

[GlowstickSwinger]

Bumping this thread even though it has been moved to the thread graveyard.

 

+1 sir

[vandana_]

“Although the Internet loves to pronounce the doom of all things, what we’re seeing is a huge increase in activity with [update] 1.2 as people return to see all of the new content, the community has generally been excited about the direction the game is going as we finish up our last must-have quality of life features (group finder, etc) and can start concentrating full-time on creative things like the world events.” Daniel Erickson for Rock Paper Shotgun, 2nd May 2012 http://www.rockpapershotgun.com/2012/05/02/bioware-force-pushes-back-against-swtor-doubters/

 

Abandon all hope for any decent engine (said the Internet, the Doom Herald).

Edited May 2, 2012 by vandana_