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

[JeramieCrowe]

I have provided conclusive evidence that their servers and their clients use blocking operations (just as I suspected) in very critical aspects of the game itself. It's in the second spoiler in the opening post.

 

Those .DAT loads are async, but the HeroScript that issues the file i/o is sync!

 

Be that as it may, you cannot guarantee that it's to blame for any noticeable lag even half the time. Many spikes could be the total client-side propagation of program through processor application, especially if there's any L2 or L3 hang-ups, especially for those with only 2 cores.

Edited April 28, 2012 by JeramieCrowe

[GlowstickSwinger]

Be that as it may, you cannot guarantee that it's to blame for any noticeable lag even half the time. Many spikes could be the total client-side propagation of program through processor application, especially if there's any L2 or L3 hang-ups.

 

If you are firing a script and blocking the entire application from continuing until after that script is finished running its async processes, you have a problem: Whats the point of async disk i/o if the parent process is blocking?

 

The disk reads still have to finish before the HeroScript terminates and unblocks everything else.

 

That's pretty significant when you are encountering dozens of people with any random collection of gear that is not stored into memory preemptively.

 

No amount of CPUs is going to help if the entire application comes to a halt and is waiting on the disk.

Edited April 28, 2012 by GlowstickSwinger

[JeramieCrowe]

If you are firing a script and blocking the entire application from continuing until after that script is finished running its async processes, you have a problem: Whats the point of async disk i/o if the parent process is blocking?

 

The disk reads still have to finish before the HeroScript terminates and unblocks everything else.

 

That's pretty significant when you are encountering dozens of people with any random collection of gear that is not stored into memory preemptively.

 

No amount of CPUs is going to help if the entire application comes to a halt and is waiting on the disk.

 

I quite disagree. Perhaps for some of the average users. In my experience, some "not too electronically savvy" users tend to have quite a messy process tree going on when the OS starts. It seems that the average gamer, however, is more careful about this.

 

If one keeps one's processes clear of any unnecessary processes, which should be normal for any gamer, then the scenario in your post will rarely, if ever, actually fire. But if you insist to clutter your processor space, then yeah, any amount of CPU is going to halt because of YOUR choice.

 

Thus, the I/O pause is actually saving you from a clean lock-up. Again, it's necessary for a game that transmits, utilizes, and displays much more data and objects than any other MMO previous.

 

Again, I'm scrupulous about what my processor crunches, and my machine rarely, if ever, utilizes such blocks. My wife, though, calls me obsessed about it. We had to get her her own PC because of it. I'm more fastidious than even the advanced user.

 

You really have to put yourself into the position of a developer of a data-heavy game. You know the typical end user has a messy process list going on simply starting the computer. Then, you have users who run things in the background along with your data-heavy game. If you don't want constant complaints of lock-ups, you're going to put a dynamic block in place, simple as that.

 

If you, as the end user, don't want any blocks happening, clean your crap up!

Edited April 28, 2012 by JeramieCrowe

[mattgyver]

This thread has degenerated into a comparison of hardware. Was OP talking about having end users buy better equipment? If so, I missed it.

[JeramieCrowe]

This thread has degenerated into a comparison of hardware. Was OP talking about having end users buy better equipment? If so, I missed it.

 

Hardware? Nah, it's a matter of watching your software, really. There's so much crap that you can inadvertently cause your processor to sweat it's not even funny. And make no mistake, we're talking about a processor issue here.

 

However, we cannot fault BW for creating a game that's next-gen, while "cutting the fat" for now to work with what's currently available. I, for one, am glad to see an MMO that is so ready to be expanded upon. And I think OP is misinterpreting his data to mean that it's just processor-heavy with nowhere to go.

[GlowstickSwinger]

I quite disagree. Perhaps for some of the average users. In my experience, some "not too electronically savvy" users tend to have quite a messy process tree going on when the OS starts. It seems that the average gamer, however, is more careful about this.

 

If one keeps one's processes clear of any unnecessary processes, which should be normal for any gamer, then the scenario in your post will rarely, if ever, actually fire. But if you insist to clutter your processor space, then yeah, any amount of CPU is going to halt because of YOUR choice.

 

Thus, the I/O pause is actually saving you from a clean lock-up. Again, it's necessary for a game that transmits, utilizes, and displays much more data and objects than any other MMO previous.

 

Again, I'm scrupulous about what my processor crunches, and my machine rarely, if ever, utilizes such blocks. My wife, though, calls me obsessed about it. We had to get her her own PC because of it. I'm more fastidious than even the advanced user.

 

You really have to put yourself into the position of a developer of a data-heavy game. You know the typical end user has a messy process list going on simply starting the computer. Then, you have users who run things in the background along with your data-heavy game. If you don't want constant complaints of lock-ups, you're going to put a dynamic block in place, simple as that.

 

If you, as the end user, don't want any blocks happening, clean your crap up!

 

The OS handles processes. Processes handle threads. I don't think SW:TOR runs the risk of accidentally calling a thread that Chrome may or many not be using? o___O

 

Now, those threads might be pulling and writing data to and from the same shared resource... like a hard drive, in which scheduling and priority takes over.

 

So let's take your scenario.

 

What happens when you have two browser, an mp3 player, and SW:TOR running? A whole lot of reads from the hard drive is what's going on.

 

So SW:TOR goes to access some .DAT files. As it turns out, some other dude is all up on your hard drives, stinking up the joint. So now SW:TOR has to wait until Mr. Hard Drive Hog is finished. Yes, this call for the .DAT file is asynchronous, but the parent HeroScript is not. So until that those disk i/o requests gets resolved, all subsequent HeroScript requests are going to come to a dead halt until that resource request is resolved.

 

That's why the game hiccups when you dismount or encounter someone new. It's pulling new models from the hard drive all the time and it is blocking all future HeroScripts in the process. (HeroScripts contain most of the game logic)

 

The problem is very far removed from something as fundamental as fork() or epoll(). The engine itself simply won't execute multiple HeroScripts in parallel.

 

And that's not a misinterpretation. That is the expected and intended use case of the engine:

 

http://wiki.heroengine.com/wiki/Asynchronous_considerations#Background

 

"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. "

Edited April 28, 2012 by GlowstickSwinger

[ironix]

And I think OP is misinterpreting his data to mean that it's just processor-heavy with nowhere to go.

 

Actually, he's not saying that. What he's saying is that the software is very poorly optimized and if it were optimized correctly, this game would run much, much faster.

 

EDIT: http://www.heroengine.com/2011/11/heroengine-meets-starwars/ only serves to confirm that the code is poorly optimized.

 

EDIT #2: Forgot a word. >.>

Edited April 28, 2012 by ironix

[JeramieCrowe]

The OS handles processes. Processes handle threads. I don't think SW:TOR runs the risk of accidentally calling a thread that Chrome may or many not be using? o___O

 

That was left-field. What? You don't think there's any processes from TOR that doesn't go through your processor? There are? Then this statement makes zero sense. Of course TOR only calls its own threads... *smh*

 

Now, those threads might be pulling and writing data to and from the same shared resource... like a hard drive, in which scheduling and priority takes over.

 

So let's take your scenario.

 

What happens when you have two browser, an mp3 player, and SW:TOR running? A whole lot of reads from the hard drive is what's going on.

 

So SW:TOR goes to access some .DAT files. As it turns out, some other dudes are in line to get them as well. So now SW:TOR has to wait. Oh, and by the way, this call for the .DAT file? It's asynchronous, but the parent HeroScript is not. So until that HeroScript gets resolved, all subsequent HeroScript requests are going to come to a dead halt until that resource request is resolved.

 

That's why the game hiccups when you dismount or encounter someone new. It's pulling new models from the hard drive all the time and it is blocking all future HeroScripts in the process. (HeroScripts contain most of the game logic)

 

The problem is very far removed from something as fundamental as fork() or epoll(). The engine itself simply won't execute multiple HeroScripts in parallel.

 

You're clouding the issue with unnecessary drivel. The fact is, when you have TOR, Chrome (which I use), and Vent going, along with a clear start-up process queue, no blocks happen. Period.

 

And that's not a misinterpretation. That is the expected and intended use case of the engine:

 

http://wiki.heroengine.com/wiki/Asynchronous_considerations#Background

 

"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 implementation of that factor is situational. A failsafe. Don't present the situation (which is all too easy to prevent), and it won't present itself.

Edited April 28, 2012 by JeramieCrowe

[GlowstickSwinger]

Actually, he's not saying that. What he's saying is that the software is very poorly optimized and if it were optimized correctly, this game would much, much faster.

 

Understandably, I see why the HeroScript is blocking. It's a scripting language that is made procedural for ease of organizing and understanding game logic. But it's also the reason why things are slowed to all hell.

 

IMO... game logic should be purely event-driven, not procedural.

[JeramieCrowe]

Understandably, I see why the HeroScript is blocking. It's a scripting language that is made procedural for ease of organizing and understanding game logic. But it's also the reason why things are slowed to all hell.

 

IMO... game logic should be purely event-driven, not procedural.

 

The problem I have with your description is that it should be global if that's actually the case.

 

It's not global. I'm proof of that. So, there must be other factors. If you've done any real-world troubleshooting, you'll know that the obvious answer...is the wrong answer. (In cases like this, hehe. With end users, yes, it's usually that the cord came unplugged. )

Edited April 28, 2012 by JeramieCrowe

[GlowstickSwinger]

That was left-field. What? You don't think there's any processes from TOR that doesn't go through your processor? There are? Then this statement makes zero sense. Of course TOR only calls its own threads... *smh*

 

Just feeling you out.

 

You're clouding the issue with unnecessary drivel. The fact is, when you have TOR, Chrome (which I use), and Vent going, along with a clear start-up process queue, no blocks happen. Period.

 

Why are you obsessing over process queuing? I'm speaking, exclusively, about disk i/o and network i/o, the two slowest resources on the average computer. The processor suffers from potential starvation when adding disk and network wait times, which I never said was the issue.

 

I'm not sure where you thought I did say that.

 

The implementation of that factor is situational. A failsafe. Don't present the situation (which is all too easy to do), and it won't present itself.

 

It's not situational. The -entire- game loop -stops- when reading from disk.

 

Reading from disk is not an FTL operation yet. It takes time to find and assemble that data. And the entire game loop comes to a -dead halt- when that data is being read from a call in HeroScript.

 

It has nothing to do with process queues or CPUs or threads or anything. It is strictly how the application was structured to "simplify" maintaining game logic.

[ironix]

The problem I have with your description is that it should be global if that's actually the case.

 

It's not global. I'm proof of that. So, there must be other factors. If you've done any real-world troubleshooting, you'll know that the obvious answer...is the wrong answer. (In cases like this, hehe. With end users, yes, it's usually that the cord came unplugged. )

 

Wait a sec here... You're an iOS developer using Objective-C and Cocoa and you're NOT writing event-driven applications?

[GlowstickSwinger]

The problem I have with your description is that it should be global if that's actually the case.

 

It's not global. I'm proof of that. So, there must be other factors. If you've done any real-world troubleshooting, you'll know that the obvious answer...is the wrong answer. (In cases like this, hehe. With end users, yes, it's usually that the cord came unplugged. )

 

User system configurations can be all over the place. Different gear, operating systems, configurations... not every machine is going to be the same. This real world fact lends itself to my explanation because I can explain why even people with beefy graphics cards still experience loading time hell. The hard drive activity is to blame.

 

And if you have a boss SSD? The network activity is to blame.

 

And if you have fiber optics? The overall network i/o strategy is to blame.

 

What do the disk, the network, and the network i/o strat have in common?

 

Blocking HeroScripts and synchronous GOMs. The engine itself is imposing needless wait times that compound because their game logic isn't event-driven.

Edited April 28, 2012 by GlowstickSwinger

[VoXPCS]

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.
  

 

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.
  

 

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 fire 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.

 

 

 

The horse is on the ground dude, why do you and others with more talent and skill keep kicking it. Help a game with a pulse, one that wants to live.

 

EA has made what they're going to make. They're praying for 6 more months of sustainability before it STARTS costing them money to operate this piece.

 

You're obviously extremely skilled in the area programming. Don't waste your breathe on the Hero Engine. Unreal and Crysis engines will always reign superior and there isn't a single BW employee with your depth of knowledge otherwise, this thing wouldn't have released as bad as it did, as STILL is after the -

 

"Largest patch in MMO history"

 

3 other major games make fun BW's statement openly in chat, it's comical. If wal-mart were an engineering company, the Hero Engine would be it's flagship. Period.

[GlowstickSwinger]

The horse is on the ground dude, why do you and others with more talent and skill keep kicking it. Help a game with a pulse, one that wants to live.

 

I read everything else, but I think this settles it.

 

You're right.

 

I'm going to bed lol

[ironix]

The horse is on the ground dude, why do you and others with more talent and skill keep kicking it. Help a game with a pulse, one that wants to live.

 

EA has made what they're going to make. They're praying for 6 more months of sustainability before it STARTS costing them money to operate this piece.

 

You're obviously extremely skilled in the area programming. Don't waste your breathe on the Hero Engine. Unreal and Crysis engines will always reign superior and there isn't a single BW employee with your depth of knowledge otherwise, this thing wouldn't have released as bad as it did, as STILL is after the -

 

"Largest patch in MMO history"

 

3 other major games make fun BW's statement openly in chat, it's comical. If wal-mart were an engineering company, the Hero Engine would be it's flagship. Period.

 

Some people continue to kick said horse because they have the smallest hope that maybe, just maybe, the problems will be fixed and the game will flourish.

[JeramieCrowe]

Just feeling you out.

 

Okay....

 

Why are you obsessing over process queuing? I'm speaking, exclusively, about disk i/o and network i/o, the two slowest resources on the average computer. The processor suffers from potential starvation when adding disk and network wait times, which I never said was the issue.

 

I'm not sure where you thought I did say that.

 

You didn't say that. That's why I bring it up. The Hero Engine doesn't just automatically stop when it needs to read from the disk. It stops only if there is a latency with reading from the disk. Which many factors now come into play.... Let me qualify that. It only stops *noticeably* if there is latency with the I/O.

 

It's not situational. The -entire- game loop -stops- when reading from disk.

 

Reading from disk is not an FTL operation yet. It takes time to find and assemble that data. And the entire game loop comes to a -dead halt- when that data is being read from a call in HeroScript.

 

It has nothing to do with process queues or CPUs or threads or anything. It is strictly how the application was structured to "simplify" maintaining game logic.

 

It does, though. There is no such thing as a process that does not have to do with all of that. It has to do with I/O latency, processor queue, AND random access priority queue. You cannot objectively quantify the issue without observing all.

[JeramieCrowe]

Some people continue to kick said horse because they have the smallest hope that maybe, just maybe, the problems will be fixed and the game will flourish.

 

And then there are those of us who see through pessimistic crap and realize the game is already flourishing.

[ironix]

And then there are those of us who see through pessimistic crap and realize the game is already flourishing.

 

Okay... I understand now. Enough said.

[JeramieCrowe]

Okay... I understand now. Enough said.

 

I realize that realism is not as cool as pessimism, but I get by.

[GlowstickSwinger]

The Hero Engine doesn't just automatically stop when it needs to read from the disk. It stops only if there is a latency with reading from the disk.

 

....

 

Again:

 

"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 request for the resource not only waits until it can access the resource, but the time it takes to find and gather those resources? Yeah, it's waiting there, too. -Every- call to a disk has latency. While it's pulling data, the game loop will not move on to the next HeroScript. When reading the data, the game loop is still in the same HeroScript. When processing any of the data from those files, the game loop is still in the same HeroScript.

 

I hope HeroScripts has some Snickers, cuz they aren't going anywhere for a while when you get a disk involved.

Edited April 28, 2012 by GlowstickSwinger

[JeramieCrowe]

....

 

Again:

 

"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 request for the resource not only waits until it can access the resource, but the time it takes to find and gather those resources? Yeah, it's waiting there, too. -Every- call to a disk has latency. While it's pulling data, the game loop stops.

 

Which I said, in the part you cut out from my quote, that it only stops *noticeably* if there is latency with the I/O. Usually only if more than a few threads are accessing the data. And if that's the case, you need to stop.

 

Again, you're acting as if this processor hungry MMO is the end. It's not, it's actually been culled to work with what's available, a "bare-bones" engine. That's good news!! It means that it's more expandable as more powerful hardware becomes available.

 

It seems like it's doing some unnecessary crunching. But that's because it's a culled version of the whole. And if you've ever worked with a culled version of the whole, it's a beast to work with, let me tell ya.

Edited April 28, 2012 by JeramieCrowe

[Rikeryo]

Hardware? Nah, it's a matter of watching your software, really. There's so much crap that you can inadvertently cause your processor to sweat it's not even funny. And make no mistake, we're talking about a processor issue here.

 

However, we cannot fault BW for creating a game that's next-gen, while "cutting the fat" for now to work with what's currently available. I, for one, am glad to see an MMO that is so ready to be expanded upon. And I think OP is misinterpreting his data to mean that it's just processor-heavy with nowhere to go.

 

please explain to me how this modified, cheap, bad performing, ugly looking engine is any kind of next-gen. thank you. additionally, be so kind and explain your silly motivation to defend this game blindly at all cost. is that you, renegadeimp aka bw employee?

Edited April 28, 2012 by Rikeryo

[JeramieCrowe]

please explain to me how this modified, cheap, bad performing, ugly looking engine is any kind of next-gen. thank you.

 

The very fact that it's culled and wonky makes it appear "cheap, bad performing, ugly-looking". I haven't met a program yet that works at optimum when it's culled to work on low-tech.

 

I'm not employed, no. Just a realist who calls 'em like I see 'em.

Edited April 28, 2012 by JeramieCrowe

[Rikeryo]

The very fact that it's culled and wonky makes it appear "cheap, bad performing, ugly-looking". I haven't met a program yet that works at optimum when it's culled to work on low-tech.

 

I'm not employed, no. Just a realist who calls 'em like I see 'em.

 

so your excuse for bad performance on mid - high end systems is the fact that the devs developed this engine to run on a wide variety of systems, even low end? or are you denying that this game runs subpar on countless systems while other games run just fine?

Edited April 28, 2012 by Rikeryo