OP here. Unsubbing If anyone wants to watch me rant about other programming issues, (currently hopping mad about Symfony!) http://www.twitter.com/12dcode (thar be mah twitters)

plump

It is fixable If they ignore marketing And listen to devs

+1 sir

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.

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,

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.

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.

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.

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.

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.

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

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.

<-- creator of thread and +1 for truth

So you are saying that SW:TOR's game loop is event-driven. What evidence do you have that it's event-driven? Burden of proof > axiomatic rules of thumb