Because they have " a larger, better funded, more experienced development team".
So are you are saying that SV are small, poorly funded, inexperienced and clearly unable to deal with the complexity of the UE engine in an MMO setting? Then why do you blame UE? Oh and finally you seem to agree with most of the posters here.
You responded to the sentence that used that phrase so I'm not sure why you say " too long, did't read"
That was for people not wanting to read my post, not yours.
P.S. Did you find the word "incorrect" in that blog post? Or find some way in which mismanagement and bad design are cotradictory?
I have already told you to stop doing this. Stop misquoting and misrepresenting what other people post, even after they correct you. You are deliberately doing it to bolster your non-existant case and to goad other posters. Keep doing it and I will report you as I have no time for that kind of game.
Nowhere did I say it was a direct quote and I corrected you last time. Your statement was that RTW failed due to the UE engine's problems. An employee of RTW says that is not the case. You then state that you have no real idea if it was anything to do with UE at all. QED you are incorrect. That is not a quote, just a fact.
P.P.S. I guess you've got me on speedtree, how about flash intefration and seamless world streaming?
Scaleform GFx 3.0 in early 2009, maybe earlier iterations.
MO does not have a seamless world. Nodes remember? Those things that kill pets and crash your client when you cross them with your inventory open. However games such as L2 had large expansive zones too.
Now stop fishing in the vain hope of finding a problem with UE that is the cause of SV's problems. All 3 of your claims were demolished in 5 seconds of Google. Just face it, the problem is with SV and not UE.
So are you are saying that SV are small, poorly funded, inexperienced and clearly unable to deal with the complexity of the UE engine in an MMO setting? Then why do you blame UE? Oh and finally you seem to agree with most of the posters here.
Well, I would say less experienced. "Every aspect of Unreal Engine 3 has been designed with ease of content creation and programming in mind, with the goal of putting as much power as possible in the hands of artists and designers to develop assets in a visual environment with minimal programmer assistance, " http://www.unrealengine.com/features If SV (and the examples I gave and you discounted as tiny) run into problems with UE3, what does that say abou the "ease of content creation" and "minimal programmer assistance"
Originally posted by Betel
P.S. Did you find the word "incorrect" in that blog post? Or find some way in which mismanagement and bad design are cotradictory?
I have already told you to stop doing this. Stop misquoting and misrepresenting what other people post, even after they correct you. You are deliberately doing it to bolster your non-existant case and to goad other posters. Keep doing it and I will report you as I have no time for that kind of game.
Nowhere did I say it was a direct quote and I corrected you last time. Your statement was that RTW failed due to the UE engine's problems. An employee of RTW says that is not the case. You then state that you have no real idea if it was anything to do with UE at all. QED you are incorrect. That is not a quote, just a fact.
The blogpost says that mismanagement was the "core" reason for the failure of APB, it does not say that it was the only reason. Poor management can lead to bad design choices. The CEO gives an example of how a problem that was known for 476 days under the old management was addressed in 30 minutes with the new team. http://apbreloaded.blogspot.com/2011/02/end-of-week-15-update-closed-beta.html Mismanagement lay at the root of their inability to address design flaws, plan finances appropriately, etc. It may be lazy to say that RTW failed because they ran out of money, but it is not incorrect. Same thing goes for design choices and bugs.
APB had a fairly significant number of bugs. If UE3 is the underpinning for the entire game, at least some of those bugs will relate to how they used UE3 "Fixed collision issues on trees that allowed players to sit ‘inside’ them."
I may be focusing on the wording "incorrect" to much. Could you point out where Luke Halliwell said it would be wrong to say that flaws/bugs contributed to the failure of RTW? (not just lazy)
Originally posted by Betel
Scaleform GFx 3.0 in early 2009, maybe earlier iterations.
To be noted SV is only company to take on Atlas that provingly is merely experimental system thats main job is to torture the Unreal3 engine to do things that it wasnt created to.
Iunno. I'm still passively annoyed at Epic for what they did before in regards to developing MMO infrastructure with the UE3 engine when Sony offered a partnership for it.
If they had done that, Epic would all ready have had a solid networking layer and server architecture a few years prior to their announcement of developing Atlas.
It's been quite a while and difficult for Epic to create their own network solution along with the changes and addition in tools to support it. Have a friend who was hired onto Epic last year to specifically work on the network code as a result.
Like I said elsewhere, it's as much a fault of the developers for being incapable of developing their own solutions as it would be due to Epic themselves. Perhaps more so, due to the frequency of titles to rewrite large segments of the code in engines any ways.
Even Lineage 2 modified the networking layer of the 2.5 engine when they used it.
Vanguard followed suit by modifying the UE2 engine for graphics, performance, and the networking layer.
Spellborn once again used their own solutions and modifications to the game engine and networking layer, as per their own comment 'Over the course of development we made many changes and additions to the engine to add effects that were missing or insufficient in the 2.5 engine.' as well as their replacement of combat function with target and reticule based detection to avoid lag and glitches.
Huxley, Blade&Soul, Global Agenda, Crimecraft, Fury, APB, and Tera all did their own modifications to the UE3 engine, but you also notice all of those games also work on a smalley player count and heavier use of instancing in order to function as they never fully replaced the networking layer like Sony did for MAG.
Then in the case of The Agency and DCUO, both are again made by Sony and uses Sony's own solutions to the engine and it's problems. In the case of DCUO it's actually based directly on the solution they developed for MAG, and the Agency does a similar tactic to other titles by limiting player count and interactivity options across game world instances.
MO is the only real foray into the use of Epic's solution so far, and there's been plenty of quirks, bugs, and roadblocks because of it. Like that memory leak in the servers, that was actually part of a bug with the engine and Atlas and needed to be patched as part of Epic's work.
However, I still say that it's very much so on the developer as well to be capable of designing and implementing their own solutions to such problems, if not write a new system themselves.
"The knowledge of the theory of logic has no tendency whatever to make men good reasoners." - Thomas B. Macaulay
"The greatest enemy of knowledge is not ignorance, it is the illusion of knowledge." - Daniel J. Boorstin
Iunno. I'm still passively annoyed at Epic for what they did before in regards to developing MMO infrastructure with the UE3 engine when Sony offered a partnership for it.
If they had done that, Epic would all ready have had a solid networking layer and server architecture a few years prior to their announcement of developing Atlas.
It's been quite a while and difficult for Epic to create their own network solution along with the changes and addition in tools to support it. Have a friend who was hired onto Epic last year to specifically work on the network code as a result.
Like I said elsewhere, it's as much a fault of the developers for being incapable of developing their own solutions as it would be due to Epic themselves. Perhaps more so, due to the frequency of titles to rewrite large segments of the code in engines any ways.
Even Lineage 2 modified the networking layer of the 2.5 engine when they used it.
Vanguard followed suit by modifying the UE2 engine for graphics, performance, and the networking layer.
Spellborn once again used their own solutions and modifications to the game engine and networking layer, as per their own comment 'Over the course of development we made many changes and additions to the engine to add effects that were missing or insufficient in the 2.5 engine.' as well as their replacement of combat function with target and reticule based detection to avoid lag and glitches.
Huxley, Blade&Soul, Global Agenda, Crimecraft, Fury, APB, and Tera all did their own modifications to the UE3 engine, but you also notice all of those games also work on a smalley player count and heavier use of instancing in order to function as they never fully replaced the networking layer like Sony did for MAG.
Then in the case of The Agency and DCUO, both are again made by Sony and uses Sony's own solutions to the engine and it's problems. In the case of DCUO it's actually based directly on the solution they developed for MAG, and the Agency does a similar tactic to other titles by limiting player count and interactivity options across game world instances.
MO is the only real foray into the use of Epic's solution so far, and there's been plenty of quirks, bugs, and roadblocks because of it. Like that memory leak in the servers, that was actually part of a bug with the engine and Atlas and needed to be patched as part of Epic's work.
However, I still say that it's very much so on the developer as well to be capable of designing and implementing their own solutions to such problems, if not write a new system themselves.
they tried to fix the ploblem themselves if i recall but really I am kinda giving sv thumbs up because the game is improving slowly and the only real ploblem is the network solution from EPIC which even held them back 10 months but the game is still going strong and the teleporting/rubberbanding is pretty much gone in normal fights, from what i can tell theres just a little "delay" on actions these days but when theres lots of people in one area, performance, network wise drops, also because of that memory leak, server been bad, but its improved, that it able to stay up most of the time again, but the other day server went into offline mode, but it wasn't just random, something caused it to go into offline mode due to a certain gathering of people doing something.
Fair enough Ange. But that still tells me that their programmer base in house isn't particularly strong on the engine or more specifically networking side.
While Epic is supposed to be operating as their support and doing the work on Atlas to make sure the newtork and engine backend is running right, it's still important to have some gurus in-house that can and do specifically work on such things. Whoever thay have on it now apparently isn't quite the 'guru' they need to be.
Thois wouldn't actually be an issue to me when Epic is there working on their own solutions if it weren't for the fact that the dev status of the title has all ready pushed it's way past internal development a long time ago, where much of these bugs that it's still or are now having should have been solved by either them or Epic. They don't need a fully stable server that can house thousands indefinitely or what have you, but there's a difference between the stability they have now and what's seen when doing stress tests.
Here's to hoping they get better though before they flounder out of existence. The game itself I actually kinda liked tinkering with.
"The knowledge of the theory of logic has no tendency whatever to make men good reasoners." - Thomas B. Macaulay
"The greatest enemy of knowledge is not ignorance, it is the illusion of knowledge." - Daniel J. Boorstin
"Every aspect of Unreal Engine 3 has been designed with ease of content creation and programming in mind, with the goal of putting as much power as possible in the hands of artists and designers to develop assets in a visual environment with minimal programmer assistance, " http://www.unrealengine.com/features
Yeah, that looks like the big joke.
Presumably SV took Epic at their word and bought into Epic's hype. You could say that's unskillful of SV, but hey, Epic are big and ought to be relatively trustworthy, right?
Can anyone deny that Epic were simply jumping on the MMO bandwagon, with the lessening of popularity of PC FPS games, and simply bodged their FPS engine to be a MMO engine?
And, further, that this mess has been the ruin of several indie developers?
Sure, SV are not overly competent; but consider what might have been the case had the UE3 engine worked as advertised.
It amazes me that some people here are attacking indie developers simply because they're indie, because they're small and have fewer resources; and by extension exonerating Epic, who bear a large part of the fault of several recent fiascos.
IOW, isn't the whole point of offering for licence something like UE3 to make the job of indie developers easier?
In reality, the engine seems to need a score of programmers to strip out the networking layer and put their own in, to make it a proper MMORPG engine.
Fine for big teams like Sony.
Not working as advertised, for smaller developers comprised mainly of "artists and designers" (e.g. SV).
"Every aspect of Unreal Engine 3 has been designed with ease of content creation and programming in mind, with the goal of putting as much power as possible in the hands of artists and designers to develop assets in a visual environment with minimal programmer assistance, " http://www.unrealengine.com/features
Yeah, that looks like the big joke.
Presumably SV took Epic at their word and bought into Epic's hype. You could say that's unskillful of SV, but hey, Epic are big and ought to be relatively trustworthy, right?
Can anyone deny that Epic were simply jumping on the MMO bandwagon, with the lessening of popularity of PC FPS games, and simply bodged their FPS engine to be a MMO engine?
And, further, that this mess has been the ruin of several indie developers?
Sure, SV are not overly competent; but consider what might have been the case had the UE3 engine worked as advertised.
It amazes me that some people here are attacking indie developers simply because they're indie, because they're small and have fewer resources; and by extension exonerating Epic, who bear a large part of the fault of several recent fiascos.
IOW, isn't the whole point of offering for licence something like UE3 to make the job of indie developers easier?
In reality, the engine seems to need a score of programmers to strip out the networking layer and put their own in, to make it a proper MMORPG engine.
Fine for big teams like Sony.
Not working as advertised, for smaller developers comprised mainly of "artists and designers" (e.g. SV).
No, Epic doesn't sell Unreal Engine as an MMO engine. They sell it as a game engine. They sell Atlas technology to be the MMO solution. That said, every developer out there who has built a successful game using Epic's tools has had to do significant work on the engine to get their game to the point where they want it to be. The problem is, that SV has no programmers, but only a modder as their lead programmer. This is why they can't modify the game engine to do what they need, because they have no skill to do so.
The UE3 engine works exactly as advertised. If you stay within the guidelines of what it can do and what it allows for, then you can build a game that works fine. The problem is, that no game that releases nowadays stays within the strict guidelines of what a game engine can do. It has to be enhanced. The whole point of offering a license for UE3 and other engines is because it takes significant effort to build an engine that does the base things that it does, shadowing, lighting, vector graphics, menus, etc. If SV didn't have that base to start with, the game wouldn't even be OUT right now. It took Darkfall 7 years to build their game because their engine was from scratch. And they are what you can call an "indy" developer as well.
So ultimately, UE3 works *exactly* as advertised. Nobody in Epic sells the engine as a whole solution to building a game, it's simply a big tool in a developer's arsenal to avoid work that has been done thousands of times over. Epic isn't to blame here, it's SV entirely. That's why their patcher is made by a volunteer, because they have no skill to do it themselves.
No, Epic doesn't sell Unreal Engine as an MMO engine. They sell it as a game engine. They sell Atlas technology to be the MMO solution. That would be why the thread is titled UE3 + Atlas. It's just harder to discuss Atlas since MO is the only game that we know uses Atlas. That said, every developer out there who has built a successful game using Epic's tools has had to do significant work on the engine to get their game to the point where they want it to be. The problem is, that SV has no programmers, but only a modder as their lead programmer. This is why they can't modify the game engine to do what they need, because they have no skill to do so.
The UE3 engine works exactly as advertised. If you stay within the guidelines of what it can do and what it allows for, then you can build a game that works fine. The problem is, that no game that releases nowadays stays within the strict guidelines of what a game engine can do. It has to be enhanced. The whole point of offering a license for UE3 and other engines is because it takes significant effort to build an engine that does the base things that it does, shadowing, lighting, vector graphics, menus, etc. If SV didn't have that base to start with, the game wouldn't even be OUT right now. It took Darkfall 7 years to build their game because their engine was from scratch. And they are what you can call an "indy" developer as well. Could you explain what they try to do that is "outside the guidelines"?
No, Epic doesn't sell Unreal Engine as an MMO engine. They sell it as a game engine. They sell Atlas technology to be the MMO solution. That would be why the thread is titled UE3 + Atlas. It's just harder to discuss Atlas since MO is the only game that we know uses Atlas. That said, every developer out there who has built a successful game using Epic's tools has had to do significant work on the engine to get their game to the point where they want it to be. The problem is, that SV has no programmers, but only a modder as their lead programmer. This is why they can't modify the game engine to do what they need, because they have no skill to do so.
The UE3 engine works exactly as advertised. If you stay within the guidelines of what it can do and what it allows for, then you can build a game that works fine. The problem is, that no game that releases nowadays stays within the strict guidelines of what a game engine can do. It has to be enhanced. The whole point of offering a license for UE3 and other engines is because it takes significant effort to build an engine that does the base things that it does, shadowing, lighting, vector graphics, menus, etc. If SV didn't have that base to start with, the game wouldn't even be OUT right now. It took Darkfall 7 years to build their game because their engine was from scratch. And they are what you can call an "indy" developer as well. Could you explain what they try to do that is "outside the guidelines"?
You'd have to ask Epic there. As EPIC has stated, and other developers agree with, the Engine alone doesn't make it a launch title, it takes a lot of time and effort, and EXPERIENCE to make a game work properly using an existing engine. The problem with SV is that they have no experience in their team in any capacity. None of them have shipped any software, ever, not to mention the fact that their lead programmer has done nothing more than mod the unreal engine using unrealscript. When a core component (the patcher) isn't written by you but a "fan" whom you later hire, it shows the talent pool is extremely thin at the company. The engine has nothing to do with the fact that they can't make the game run right. It's a matter of learning the intricicies of the tools, and being one of the first to license Atlas, they made a bad move because they don't have the experience to figure out the issues on their own.
No, Epic doesn't sell Unreal Engine as an MMO engine. They sell it as a game engine. They sell Atlas technology to be the MMO solution. That would be why the thread is titled UE3 + Atlas. It's just harder to discuss Atlas since MO is the only game that we know uses Atlas. That said, every developer out there who has built a successful game using Epic's tools has had to do significant work on the engine to get their game to the point where they want it to be. The problem is, that SV has no programmers, but only a modder as their lead programmer. This is why they can't modify the game engine to do what they need, because they have no skill to do so.
The UE3 engine works exactly as advertised. If you stay within the guidelines of what it can do and what it allows for, then you can build a game that works fine. The problem is, that no game that releases nowadays stays within the strict guidelines of what a game engine can do. It has to be enhanced. The whole point of offering a license for UE3 and other engines is because it takes significant effort to build an engine that does the base things that it does, shadowing, lighting, vector graphics, menus, etc. If SV didn't have that base to start with, the game wouldn't even be OUT right now. It took Darkfall 7 years to build their game because their engine was from scratch. And they are what you can call an "indy" developer as well. Could you explain what they try to do that is "outside the guidelines"?
You'd have to ask Epic there. As EPIC has stated, and other developers agree with, the Engine alone doesn't make it a launch title, it takes a lot of time and effort, and EXPERIENCE to make a game work properly using an existing engine. The problem with SV is that they have no experience in their team in any capacity. None of them have shipped any software, ever, not to mention the fact that their lead programmer has done nothing more than mod the unreal engine using unrealscript. When a core component (the patcher) isn't written by you but a "fan" whom you later hire, it shows the talent pool is extremely thin at the company. The engine has nothing to do with the fact that they can't make the game run right. It's a matter of learning the intricicies of the tools, and being one of the first to license Atlas, they made a bad move because they don't have the experience to figure out the issues on their own.
Yeah, putting aside the UE situation (I still think there's something fishy about it), I think you've hit the nail on the head re. the SV situation.
But, in the spirit of MMORPG.COM's overall hankering towards sandbox games, and with a view to seeing how the game could be helped along to improve and work well as a brave example of a rare genre, what would be a positive step SV could take in their situation? Supposing either: 1) they don't have a decent amount of money, or 2) they have, or could get access to decent amounts of money?
No, Epic doesn't sell Unreal Engine as an MMO engine. They sell it as a game engine. They sell Atlas technology to be the MMO solution. That would be why the thread is titled UE3 + Atlas. It's just harder to discuss Atlas since MO is the only game that we know uses Atlas. That said, every developer out there who has built a successful game using Epic's tools has had to do significant work on the engine to get their game to the point where they want it to be. The problem is, that SV has no programmers, but only a modder as their lead programmer. This is why they can't modify the game engine to do what they need, because they have no skill to do so.
The UE3 engine works exactly as advertised. If you stay within the guidelines of what it can do and what it allows for, then you can build a game that works fine. The problem is, that no game that releases nowadays stays within the strict guidelines of what a game engine can do. It has to be enhanced. The whole point of offering a license for UE3 and other engines is because it takes significant effort to build an engine that does the base things that it does, shadowing, lighting, vector graphics, menus, etc. If SV didn't have that base to start with, the game wouldn't even be OUT right now. It took Darkfall 7 years to build their game because their engine was from scratch. And they are what you can call an "indy" developer as well. Could you explain what they try to do that is "outside the guidelines"?
You'd have to ask Epic there. As EPIC has stated, and other developers agree with, the Engine alone doesn't make it a launch title, it takes a lot of time and effort, and EXPERIENCE to make a game work properly using an existing engine. The problem with SV is that they have no experience in their team in any capacity. None of them have shipped any software, ever, not to mention the fact that their lead programmer has done nothing more than mod the unreal engine using unrealscript. When a core component (the patcher) isn't written by you but a "fan" whom you later hire, it shows the talent pool is extremely thin at the company. The engine has nothing to do with the fact that they can't make the game run right. It's a matter of learning the intricicies of the tools, and being one of the first to license Atlas, they made a bad move because they don't have the experience to figure out the issues on their own.
Yeah, putting aside the UE situation (I still think there's something fishy about it), I think you've hit the nail on the head re. the SV situation.
But, in the spirit of MMORPG.COM's overall hankering towards sandbox games, and with a view to seeing how the game could be helped along to improve and work well as a brave example of a rare genre, what would be a positive step SV could take in their situation? Supposing either: 1) they don't have a decent amount of money, or 2) they have, or could get access to decent amounts of money?
Money isn't going to fix this game at this point. I can insert a little bit here from experience; I am an enterprise architect and the design and flow of software (hardware and other things) is part of my job.
Programming is like art. You start with a foundation, your canvas -- a backdrop. You paint your trees, your grass, your sky. Then you start bringing it to life, adding birds, and more detail. Then you add foreground stuff like people walking around, cars driving, whatever. You have painted your scene.
The problem with SV's painting is that they have already painted the foreground, and realized now that they have done so, that almost everything in their painting is screwed up. The backdrop (network solution, game engine optimization, server sync, account code) is subpar or poorly written. Additionally with the fact that the lead programmer isn't a programmer by training, most of the code is probably not written in an optimized, object oriented format. So for example, if you wanted to use "programming" to "call" the foreground elements, they have to call that specific element. In proper object oriented code, say there was a "bird on the tree" (to use my painting analogy), but your work really needed to have the tree 5 feet lower than you made it. In proper OO code, you make the tree 5 feet lower, and the bird will adjust downward because it's anchored to the "object". But the way people that are not taught code, the tree will move five feet lower and the bird will be in midair, because it's not linked to the object of the "tree". Hope you can follow that
Using that example, apply it to what SV has done. Their game is broken, but every time they "fix" one thing, they break several more. That's the bird, sitting on a non-existent tree. Now the only way to really fix this problem is to repaint the entire canvas; and that means almost a total re-code of the game. And that sadly, is something only a HUGE amount of time will buy them. The money will be necessary too; you'd need to hire proper architects (somebody like me, but familiar with gaming as I am not), build a proper roadmap, figure out the milestones, and have an ER diagram for basically the whole game in an "object" state. It's called an Object model, and it's something that I am very positive SV has no idea about. The amount of time alone makes it unfeasible, but the money would be significant because in an industry like this, you attach your reputation to the work you take part in. This is why after MO falls apart, Sebastian, Henrik, Mats, and the rest of the gang will have a *very* hard time getting their foot in the door with anything even related to gaming.
Until then, you will continue to see them try to fix the height of the tree, and every patch will bring you more birds floating in the air.
On a related note... I was doing a little reading about game development... and it seems that gaming companies that license engines build additional tools so that they can import their work into their world without code. It's pretty smart. Think of Starcraft, or Warcraft, and the "map editor" they have. This is a tool that is made perfectly according to their object model so that they present you a GUI and you can do all the work.
Gaming companies often take the time to build a tool like this up front (even though it's heavy development in pure code) just so that they can push out the rest of the game at a faster rate. SV thus far seems to have opted to code everything by hand, and it is why you have continual problems with almost every patch.
On a related note... I was doing a little reading about game development... and it seems that gaming companies that license engines build additional tools so that they can import their work into their world without code. It's pretty smart. Think of Starcraft, or Warcraft, and the "map editor" they have. This is a tool that is made perfectly according to their object model so that they present you a GUI and you can do all the work.
Gaming companies often take the time to build a tool like this up front (even though it's heavy development in pure code) just so that they can push out the rest of the game at a faster rate. SV thus far seems to have opted to code everything by hand, and it is why you have continual problems with almost every patch.
This is very common in software development. Developing tools that develop products.
Say you have a product that has features x, y, and z. A customer comes to you and wants a new feature, a, but doesn't want feature z. Do we go in and recode the entire product? No, we develop a tool that generates the code according to what features are needed in the spec.
This means we can sell any combination of features in the product family, and never have to lift a finger.
Like you said, Blizzard had this process already with warcraft 3, and they use it for WoW as well.
Just wanted to interject and say this is the most interesting thread I have ever come across in the MO forums. Some very well though-out arguments and it has stayed relatively civil. Kudos to all involved and I hope it continues.
A man is his own easiest dupe, for what he wishes to be true he generally believes to be true...
Just wanted to interject and say this is the most interesting thread I have ever come across in the MO forums. Some very well though-out arguments and it has stayed relatively civil. Kudos to all involved and I hope it continues.
It is easy to have a civil debate when people want to agree on the facts. It's when the "facts" are up for contention that the debate falls apart.
The nice thing is, that facts are true whether or not the other side believes them. That's the nice thing about facts
Interesting fact -- all proper programmers program in *english*. And another fact -- Mortal Online early on threw error codes in Swedish. You can make the logical leap from here.
DCUO does, in fact, suffer from some issues that are pretty common for UE games.
Claymen, an inability to properly load assets in a timely fashion. Ok, well, that's really the only thing I can think of that I've seen in other UE MMO's.
DCUO had a memory leak issue that was recently fixed.
Crashing? Can't really say this is an UE problem, every MMO I've played has crashed at some point or another.
MO is the only seamless world using UE3. However, an older MMO that used an older version of an UE was seamless; that would be Lineage 2. NCsoft added in instances later, but it's still a seamless WORLD.
I know we have some apparent experts on these boards that know more then everyone else. Instancing is not the same thing as server nodes, at least not really. MO is no dif. then any other MMO that has a seamless or non-seamless world; not even dif. then WoW. Darkfall is seemless, with the world broken into nodes; just like MO and WoW. To put it simply, Duskwood is on one set of servers, while Silverpine forest is on another. You just don't notice you crossed from one server to another, today. When WoW first released Blizzard had the same issues with pets crossing nodes that MO has, they wouldn't. It took Blizzard a couple of months to get pets fixed so they wouldn't vanish when you crossed from one area to another.
MO streams all of the information for a node to you when you enter that node. Other MMO's have started adopting this, in fact blizzard now uses streaming as well as SoE.
Saying a node line is the same as an instance is wrong. An instance implies that there can be multiple instances of a particular area. City of heroes is fully instanced. Every area of that game can have multiple instances of a zone, not just a dungeon, but an area of the world itself. WoW is not instanced, but uses instancing for dungeons; at the same time it's not a seamless world. MO is not instanced, not even the dungeons, and it's also seamless.
I was a block A MO player. I was in the beta from day one of block A until release, and played for over six months. SV is a really small company, with really big dreams, and light on talent. MO is also Unreals test pilot for the atlas technology. MO is the first seamless world MMO using UE AND Atlas. As much as SV may not be happy, or as disgruntled as the players may get, I dobt that Epic is any happier. MO was supposed to showcase the power of the UE AND Atlas. MO was supposed to HELP Epic sell the Atlas technology for other studios looking to create seamless, non-instanced worlds, and things aren't going very well for them.
The truth always lies somewhere in the middle.
You can't blame Epic or SV alone. You gotta blame them both.
PS: DCUO is an effing awesome game.
PPS: Epic also had a suit filed against them from a studio. The studio was claiming that Epic didn't provide them with the tools they needed to develop their game, and that Epic withheld stuff to delay the company so that Epic could release gears of war first. Things like patches to resolve issues with the engine.
So yes, there is in fact a presidence for what Henrik keeps saying. They're waiting on Epic.
MO streams all of the information for a node to you when you enter that node. Other MMO's have started adopting this, in fact blizzard now uses streaming as well as SoE.
You can't blame Epic or SV alone. You gotta blame them both.
PPS: Epic also had a suit filed against them from a studio. The studio was claiming that Epic didn't provide them with the tools they needed to develop their game, and that Epic withheld stuff to delay the company so that Epic could release gears of war first. Things like patches to resolve issues with the engine.
Both MO and WoW always worked in similar way: when player is walking through particular node, all adjancent nodes are loaded in background.
The only difference between new "streaming" WoW client and older one is that new one can stream zone data directly from Blizzard servers, not only from local hard disk. So you can start playing very quickly after creating trial account.
The main difference between MO and WoW is that WoW is designed around engine limitations:
When two nearby nodes contain too much data to be loaded in seamless way, designers put in some very light node between them, like train between Stormwind and Ironforge, or ship to Kalimdor. If particular area requires low latency for gameplay reasons - it's moved to separate instance. All crowded areas are divided by high walls, canals, etc - so you won't be able to interact with all players at once. Quests are designed in such way, that players with different levels are more or less evenly distributed through the world.
It doesn't really matter if engine is internally developed, or licensed. To have properly working MMO you just need 2 more years of internal development AFTER engine, gameplay systems and most art assets are finished. And redesign, improve or cut 90% of content, knowing what engine can and what can't do.
Just wanted to interject and say this is the most interesting thread I have ever come across in the MO forums. Some very well though-out arguments and it has stayed relatively civil. Kudos to all involved and I hope it continues. Does that include the exchange between me and Betel? I guess it stayed civil, but at times didn't feel terribly civil.
It is easy to have a civil debate when people want to agree on the facts. It's when the "facts" are up for contention that the debate falls apart.
The nice thing is, that facts are true whether or not the other side believes them. That's the nice thing about facts Because of the macro-picture nature ot this debate relative to MO the things that can be argued as fact are fairly well established, (i.e. SV employees have relatively little professional programming experience, the track record of Epic game) When it gets more concrete the "facts" become more anecdotal (there was no one in Fabernum when I logged in vs. there were at least a dozen when I logged in) and much of the debate ends up being about discrediting the other sides anecdotal "facts". In this discussion any thing proposed as a fact has to be couched in terms that indicate how well established it is (i.e.most of the code is probably not written in an optimized, object oriented format)
Interesting fact -- all proper programmers program in *english*. And another fact -- Mortal Online early on threw error codes in Swedish. You can make the logical leap from here.
English is preferred as a best practice in C++, but may be less practical if the entire programming team is fluent in Swedish and has varying proficiency in English.
English is preferred as a best practice in C++, but may be less practical if the entire programming team is fluent in Swedish and has varying proficiency in English.
Except that some errors were in Swedish and some were in English. There was absolutely no consistency, and that goes beyond just "convention". It's an industry standard.
On a related note, all the lore for the game is supposedly only written in Swedish and "just needs to be translated" according to Henrik. Why would they do this? The game is in English for god sakes.
It's just one laughable decision after another with these guys.
DCUO does, in fact, suffer from some issues that are pretty common for UE games.
Claymen, an inability to properly load assets in a timely fashion. Ok, well, that's really the only thing I can think of that I've seen in other UE MMO's.
Long load times have as much to do with the engine as they do with the assets they are loading.
DCUO had a memory leak issue that was recently fixed.
A memory leak can come from anywhere. That's what badly written code tends to lead towards.
Crashing? Can't really say this is an UE problem, every MMO I've played has crashed at some point or another.
I guess you answered your own point there.
MO is the only seamless world using UE3. However, an older MMO that used an older version of an UE was seamless; that would be Lineage 2. NCsoft added in instances later, but it's still a seamless WORLD.
I know we have some apparent experts on these boards that know more then everyone else. Instancing is not the same thing as server nodes, at least not really. MO is no dif. then any other MMO that has a seamless or non-seamless world; not even dif. then WoW. Darkfall is seemless, with the world broken into nodes; just like MO and WoW. To put it simply, Duskwood is on one set of servers, while Silverpine forest is on another. You just don't notice you crossed from one server to another, today. When WoW first released Blizzard had the same issues with pets crossing nodes that MO has, they wouldn't. It took Blizzard a couple of months to get pets fixed so they wouldn't vanish when you crossed from one area to another.
MO streams all of the information for a node to you when you enter that node. Other MMO's have started adopting this, in fact blizzard now uses streaming as well as SoE.
Saying a node line is the same as an instance is wrong. An instance implies that there can be multiple instances of a particular area. City of heroes is fully instanced. Every area of that game can have multiple instances of a zone, not just a dungeon, but an area of the world itself. WoW is not instanced, but uses instancing for dungeons; at the same time it's not a seamless world. MO is not instanced, not even the dungeons, and it's also seamless.
No, a node is the same exact thing as an instance. An instance or a node basically means you're transferring into a different cluster of servers, or at least, a different hardware area of the same server that is cut and diced for performance purposes. Whether it loads the same area again (instanced) or another area is just a matter of semantics to the code. The reason instances are used is because in things like a dungeon, there are confined spaces and you can't have it be seamless, especially in games like WOW with really high player counts. In MO it's easy, because there are what, maybe 100 people online at a time, scattered around the world? When MO hits the player count like WOW does, and tries to stuff them all into the same dungeon, you will find that instancing is a logical decision for things like that. It makes the game different, but like UO there was never so many players that crowded a single area because the player count was never that high. And Everquest? Instanced, and with much higher player count than UO had at the time.
I was a block A MO player. I was in the beta from day one of block A until release, and played for over six months. SV is a really small company, with really big dreams, and light on talent. MO is also Unreals test pilot for the atlas technology. MO is the first seamless world MMO using UE AND Atlas. As much as SV may not be happy, or as disgruntled as the players may get, I dobt that Epic is any happier. MO was supposed to showcase the power of the UE AND Atlas. MO was supposed to HELP Epic sell the Atlas technology for other studios looking to create seamless, non-instanced worlds, and things aren't going very well for them.
The truth always lies somewhere in the middle.
You can't blame Epic or SV alone. You gotta blame them both.
No, I don't have to blame them both. Epic is an organization of professional game engine developers, with combined years of experience that are unrivalled in the industry. SV is a company with employees who have *never* shipped a product as simple as Notepad, nevermind a full blown game.
In enterprises and development, most organizations make the risk assessment of what using a 1.0 product is going to do for them. For example, in our organization we were approached many years ago to use MS Sharepoint in its infancy. We at the time used something called Vignette for content management. Looking at what Sharepoint offered, the risk was too high for the benefit and we passed. Currently we are migrating to Sharepoint 2010 after a few versions of revision. Similarly, SV decided to use a 1.0 product for a new project. They didn't have the experience to build the network solution on their own, so they had *no other choice*. Atlas is, and will be an evolving technology and while I think it probably works, I also think it's probably *very* hard to implement. Usually in a 1.0 version of any product, the core of the product works but the tools are simply not there to accomodate easy development around it. That's what the case was with Sharepoint for us, and why after three versions we jumped at the chance to switch. And that's why I won't blame Epic, because they are releasing a 1.0 product, and anybody that has ANY experience or common sense will know that the difficulty in implementing a 1.0 product successfully is going to be very hard. SV made that choice, and now they find they can't cope because they simply don't have the expertise required to finesse the engine to do what they need. It's really no surprise.
PS: DCUO is an effing awesome game.
I wouldn't know.
PPS: Epic also had a suit filed against them from a studio. The studio was claiming that Epic didn't provide them with the tools they needed to develop their game, and that Epic withheld stuff to delay the company so that Epic could release gears of war first. Things like patches to resolve issues with the engine.
So yes, there is in fact a presidence for what Henrik keeps saying. They're waiting on Epic.
There is always going to be precedence for people who are unqualified to complain about something not working. It's true of any product. Buy a car and you don't know what the buttons do? The car's radio doesn't work right! Buy a computer and don't know how to use it? The computer doesn't work right! Buy a chainsaw and don't know how to use it? The chainsaw is a piece of crap! And similarly the suit you are talking about (Silicon Knights), was in almost the same place SV is now. They developed the game and showed it off at E3, and the gaming LAUGHED IN THE CEO's FACE because the game sucked. Days later (after E3), the CEO goes out and said it sucked because of technical issues and problems with the engine. They then began the process of heavily modifying the UE3 engine for their needs, and didn't bother to pay Epic a dime; they sued Epic for inadequate support and documentation, despite the fact they used their game engine as a BASE for their own engine. That's why Epic countersued them, for not paying for the engine use. Of course, they wouldn't be able to finish the development if they had to pay Epic, so they sued first and didn't pay, and finished the game. If they had to pay Epic AND do the development, the game would never have made it to see the light of day.
Your statement that "a node is the same exact thing as an instance" just doesn't square with my understanding of what an instance is. http://www.mmorpg.com/discussion2.cfm/thread/309342/Static-loading-vs-Dynamic-loading-instances.html I'd appreciate if you could answer in that thread, to keep that topic focused. I understand that instances and nodes serve the same purpose (dividing the game world into more managable chunks of data). I suppose an argument could be made that they are exactly the same thing and that the boundaries between them are the difference (opaque, heavily gated boundaries for instances; transparent, permeable boundaries for nodes) However, that seems like fairly heavy parsing of the semantics.
If Epic games is to be held harmless for any problems with Atlas because it is version 1.0, why does that standard not apply to Starvault? The greater amount of experience at Epic doesn't render them or their products faultless. It just means that if there is a fault they are more likely to be able to fix that fault sooner or later. At this point Atlas is 2 years old http://www.epicgameschina.com/tech/tech_press_ct_htm.htm?id=198. Whether that is sooner or later, I'll leave to you to decide.
While it is true that you can almost always find a precedent for complaining about any given product, the precedents in this case hardly come from unqualified people. Silicon Knights developed Blood Omen:legacy of Kain and codeveloped Metal Gear solid. If you look at the other companies that have had complaints about Epic delaying releases, you also have Digital extremes and Midway. Arguably, Midways bankruptcy has stripped them of much of their talent, but Digital extremes codeveloped Unreal, Unreal tournament, Unreal Tournament 2003, Unreal Tournament 2004, Bioshock and Bioshock 2. http://www.gamesradar.com/ps3/stranglehold/news/unreal-engine-3-delaying-games/a-2007082016332832027/g-20060301165611510047
Just wanted to interject and say this is the most interesting thread I have ever come across in the MO forums. Some very well though-out arguments and it has stayed relatively civil. Kudos to all involved and I hope it continues. Does that include the exchange between me and Betel? I guess it stayed civil, but at times didn't feel terribly civil.
Interesting fact -- all proper programmers program in *english*. And another fact -- Mortal Online early on threw error codes in Swedish. You can make the logical leap from here.
English is preferred as a best practice in C++, but may be less practical if the entire programming team is fluent in Swedish and has varying proficiency in English.
I am a SW developer from Sweden and have been for the last 6 years. There is no excuse at all for a Swedish development team not to code in english as it is practically the second language in Sweden.
If I would see a code written in Swedish, have not so far, I would see that as a clear sign of unproffesionality. Ofcourse code are written in English, even discussing it is something that just does not happen. So it is not a "preference", it is an industry standard. Even in Sweden.
Comments
Well, I would say less experienced. "Every aspect of Unreal Engine 3 has been designed with ease of content creation and programming in mind, with the goal of putting as much power as possible in the hands of artists and designers to develop assets in a visual environment with minimal programmer assistance, " http://www.unrealengine.com/features If SV (and the examples I gave and you discounted as tiny) run into problems with UE3, what does that say abou the "ease of content creation" and "minimal programmer assistance"
The blogpost says that mismanagement was the "core" reason for the failure of APB, it does not say that it was the only reason. Poor management can lead to bad design choices. The CEO gives an example of how a problem that was known for 476 days under the old management was addressed in 30 minutes with the new team. http://apbreloaded.blogspot.com/2011/02/end-of-week-15-update-closed-beta.html Mismanagement lay at the root of their inability to address design flaws, plan finances appropriately, etc. It may be lazy to say that RTW failed because they ran out of money, but it is not incorrect. Same thing goes for design choices and bugs.
APB had a fairly significant number of bugs. If UE3 is the underpinning for the entire game, at least some of those bugs will relate to how they used UE3 "Fixed collision issues on trees that allowed players to sit ‘inside’ them."
I may be focusing on the wording "incorrect" to much. Could you point out where Luke Halliwell said it would be wrong to say that flaws/bugs contributed to the failure of RTW? (not just lazy)
Scaleform has only been supported for MO since October http://www.mortalonline.com/forums/54092-patch-notes-v-1-3-0-0-new-build-release.html and while it may have been available since early 2009 the integration/pipelining is still a work in progress(at least as of August ) http://www.udk.com/news-beta-aug2010
To be noted SV is only company to take on Atlas that provingly is merely experimental system thats main job is to torture the Unreal3 engine to do things that it wasnt created to.
Iunno. I'm still passively annoyed at Epic for what they did before in regards to developing MMO infrastructure with the UE3 engine when Sony offered a partnership for it.
If they had done that, Epic would all ready have had a solid networking layer and server architecture a few years prior to their announcement of developing Atlas.
It's been quite a while and difficult for Epic to create their own network solution along with the changes and addition in tools to support it. Have a friend who was hired onto Epic last year to specifically work on the network code as a result.
Like I said elsewhere, it's as much a fault of the developers for being incapable of developing their own solutions as it would be due to Epic themselves. Perhaps more so, due to the frequency of titles to rewrite large segments of the code in engines any ways.
Even Lineage 2 modified the networking layer of the 2.5 engine when they used it.
Vanguard followed suit by modifying the UE2 engine for graphics, performance, and the networking layer.
Spellborn once again used their own solutions and modifications to the game engine and networking layer, as per their own comment 'Over the course of development we made many changes and additions to the engine to add effects that were missing or insufficient in the 2.5 engine.' as well as their replacement of combat function with target and reticule based detection to avoid lag and glitches.
Huxley, Blade&Soul, Global Agenda, Crimecraft, Fury, APB, and Tera all did their own modifications to the UE3 engine, but you also notice all of those games also work on a smalley player count and heavier use of instancing in order to function as they never fully replaced the networking layer like Sony did for MAG.
Then in the case of The Agency and DCUO, both are again made by Sony and uses Sony's own solutions to the engine and it's problems. In the case of DCUO it's actually based directly on the solution they developed for MAG, and the Agency does a similar tactic to other titles by limiting player count and interactivity options across game world instances.
MO is the only real foray into the use of Epic's solution so far, and there's been plenty of quirks, bugs, and roadblocks because of it. Like that memory leak in the servers, that was actually part of a bug with the engine and Atlas and needed to be patched as part of Epic's work.
However, I still say that it's very much so on the developer as well to be capable of designing and implementing their own solutions to such problems, if not write a new system themselves.
"The knowledge of the theory of logic has no tendency whatever to make men good reasoners." - Thomas B. Macaulay
"The greatest enemy of knowledge is not ignorance, it is the illusion of knowledge." - Daniel J. Boorstin
they tried to fix the ploblem themselves if i recall but really I am kinda giving sv thumbs up because the game is improving slowly and the only real ploblem is the network solution from EPIC which even held them back 10 months but the game is still going strong and the teleporting/rubberbanding is pretty much gone in normal fights, from what i can tell theres just a little "delay" on actions these days but when theres lots of people in one area, performance, network wise drops, also because of that memory leak, server been bad, but its improved, that it able to stay up most of the time again, but the other day server went into offline mode, but it wasn't just random, something caused it to go into offline mode due to a certain gathering of people doing something.
Are those people stillgathering or something. It is a new day and the server is still in the pooper.
http://www.mortalonline.com/forums/47651-server-status-82.html
Fair enough Ange. But that still tells me that their programmer base in house isn't particularly strong on the engine or more specifically networking side.
While Epic is supposed to be operating as their support and doing the work on Atlas to make sure the newtork and engine backend is running right, it's still important to have some gurus in-house that can and do specifically work on such things. Whoever thay have on it now apparently isn't quite the 'guru' they need to be.
Thois wouldn't actually be an issue to me when Epic is there working on their own solutions if it weren't for the fact that the dev status of the title has all ready pushed it's way past internal development a long time ago, where much of these bugs that it's still or are now having should have been solved by either them or Epic. They don't need a fully stable server that can house thousands indefinitely or what have you, but there's a difference between the stability they have now and what's seen when doing stress tests.
Here's to hoping they get better though before they flounder out of existence. The game itself I actually kinda liked tinkering with.
"The knowledge of the theory of logic has no tendency whatever to make men good reasoners." - Thomas B. Macaulay
"The greatest enemy of knowledge is not ignorance, it is the illusion of knowledge." - Daniel J. Boorstin
Yeah, that looks like the big joke.
Presumably SV took Epic at their word and bought into Epic's hype. You could say that's unskillful of SV, but hey, Epic are big and ought to be relatively trustworthy, right?
Can anyone deny that Epic were simply jumping on the MMO bandwagon, with the lessening of popularity of PC FPS games, and simply bodged their FPS engine to be a MMO engine?
And, further, that this mess has been the ruin of several indie developers?
Sure, SV are not overly competent; but consider what might have been the case had the UE3 engine worked as advertised.
It amazes me that some people here are attacking indie developers simply because they're indie, because they're small and have fewer resources; and by extension exonerating Epic, who bear a large part of the fault of several recent fiascos.
IOW, isn't the whole point of offering for licence something like UE3 to make the job of indie developers easier?
In reality, the engine seems to need a score of programmers to strip out the networking layer and put their own in, to make it a proper MMORPG engine.
Fine for big teams like Sony.
Not working as advertised, for smaller developers comprised mainly of "artists and designers" (e.g. SV).
No, Epic doesn't sell Unreal Engine as an MMO engine. They sell it as a game engine. They sell Atlas technology to be the MMO solution. That said, every developer out there who has built a successful game using Epic's tools has had to do significant work on the engine to get their game to the point where they want it to be. The problem is, that SV has no programmers, but only a modder as their lead programmer. This is why they can't modify the game engine to do what they need, because they have no skill to do so.
The UE3 engine works exactly as advertised. If you stay within the guidelines of what it can do and what it allows for, then you can build a game that works fine. The problem is, that no game that releases nowadays stays within the strict guidelines of what a game engine can do. It has to be enhanced. The whole point of offering a license for UE3 and other engines is because it takes significant effort to build an engine that does the base things that it does, shadowing, lighting, vector graphics, menus, etc. If SV didn't have that base to start with, the game wouldn't even be OUT right now. It took Darkfall 7 years to build their game because their engine was from scratch. And they are what you can call an "indy" developer as well.
So ultimately, UE3 works *exactly* as advertised. Nobody in Epic sells the engine as a whole solution to building a game, it's simply a big tool in a developer's arsenal to avoid work that has been done thousands of times over. Epic isn't to blame here, it's SV entirely. That's why their patcher is made by a volunteer, because they have no skill to do it themselves.
whit all stuff maxed out MO put my 5850 to ~90% load on starting city but i wont get over 45 FPS i play at 1920x1080
BestSigEver :P
You'd have to ask Epic there. As EPIC has stated, and other developers agree with, the Engine alone doesn't make it a launch title, it takes a lot of time and effort, and EXPERIENCE to make a game work properly using an existing engine. The problem with SV is that they have no experience in their team in any capacity. None of them have shipped any software, ever, not to mention the fact that their lead programmer has done nothing more than mod the unreal engine using unrealscript. When a core component (the patcher) isn't written by you but a "fan" whom you later hire, it shows the talent pool is extremely thin at the company. The engine has nothing to do with the fact that they can't make the game run right. It's a matter of learning the intricicies of the tools, and being one of the first to license Atlas, they made a bad move because they don't have the experience to figure out the issues on their own.
Yeah, putting aside the UE situation (I still think there's something fishy about it), I think you've hit the nail on the head re. the SV situation.
But, in the spirit of MMORPG.COM's overall hankering towards sandbox games, and with a view to seeing how the game could be helped along to improve and work well as a brave example of a rare genre, what would be a positive step SV could take in their situation? Supposing either: 1) they don't have a decent amount of money, or 2) they have, or could get access to decent amounts of money?
Money isn't going to fix this game at this point. I can insert a little bit here from experience; I am an enterprise architect and the design and flow of software (hardware and other things) is part of my job.
Programming is like art. You start with a foundation, your canvas -- a backdrop. You paint your trees, your grass, your sky. Then you start bringing it to life, adding birds, and more detail. Then you add foreground stuff like people walking around, cars driving, whatever. You have painted your scene.
The problem with SV's painting is that they have already painted the foreground, and realized now that they have done so, that almost everything in their painting is screwed up. The backdrop (network solution, game engine optimization, server sync, account code) is subpar or poorly written. Additionally with the fact that the lead programmer isn't a programmer by training, most of the code is probably not written in an optimized, object oriented format. So for example, if you wanted to use "programming" to "call" the foreground elements, they have to call that specific element. In proper object oriented code, say there was a "bird on the tree" (to use my painting analogy), but your work really needed to have the tree 5 feet lower than you made it. In proper OO code, you make the tree 5 feet lower, and the bird will adjust downward because it's anchored to the "object". But the way people that are not taught code, the tree will move five feet lower and the bird will be in midair, because it's not linked to the object of the "tree". Hope you can follow that
Using that example, apply it to what SV has done. Their game is broken, but every time they "fix" one thing, they break several more. That's the bird, sitting on a non-existent tree. Now the only way to really fix this problem is to repaint the entire canvas; and that means almost a total re-code of the game. And that sadly, is something only a HUGE amount of time will buy them. The money will be necessary too; you'd need to hire proper architects (somebody like me, but familiar with gaming as I am not), build a proper roadmap, figure out the milestones, and have an ER diagram for basically the whole game in an "object" state. It's called an Object model, and it's something that I am very positive SV has no idea about. The amount of time alone makes it unfeasible, but the money would be significant because in an industry like this, you attach your reputation to the work you take part in. This is why after MO falls apart, Sebastian, Henrik, Mats, and the rest of the gang will have a *very* hard time getting their foot in the door with anything even related to gaming.
Until then, you will continue to see them try to fix the height of the tree, and every patch will bring you more birds floating in the air.
On a related note... I was doing a little reading about game development... and it seems that gaming companies that license engines build additional tools so that they can import their work into their world without code. It's pretty smart. Think of Starcraft, or Warcraft, and the "map editor" they have. This is a tool that is made perfectly according to their object model so that they present you a GUI and you can do all the work.
Gaming companies often take the time to build a tool like this up front (even though it's heavy development in pure code) just so that they can push out the rest of the game at a faster rate. SV thus far seems to have opted to code everything by hand, and it is why you have continual problems with almost every patch.
This is very common in software development. Developing tools that develop products.
Say you have a product that has features x, y, and z. A customer comes to you and wants a new feature, a, but doesn't want feature z. Do we go in and recode the entire product? No, we develop a tool that generates the code according to what features are needed in the spec.
This means we can sell any combination of features in the product family, and never have to lift a finger.
Like you said, Blizzard had this process already with warcraft 3, and they use it for WoW as well.
Just wanted to interject and say this is the most interesting thread I have ever come across in the MO forums. Some very well though-out arguments and it has stayed relatively civil. Kudos to all involved and I hope it continues.
A man is his own easiest dupe, for what he wishes to be true he generally believes to be true...
It is easy to have a civil debate when people want to agree on the facts. It's when the "facts" are up for contention that the debate falls apart.
The nice thing is, that facts are true whether or not the other side believes them. That's the nice thing about facts
Interesting fact -- all proper programmers program in *english*. And another fact -- Mortal Online early on threw error codes in Swedish. You can make the logical leap from here.
DCUO does, in fact, suffer from some issues that are pretty common for UE games.
Claymen, an inability to properly load assets in a timely fashion. Ok, well, that's really the only thing I can think of that I've seen in other UE MMO's.
DCUO had a memory leak issue that was recently fixed.
Crashing? Can't really say this is an UE problem, every MMO I've played has crashed at some point or another.
MO is the only seamless world using UE3. However, an older MMO that used an older version of an UE was seamless; that would be Lineage 2. NCsoft added in instances later, but it's still a seamless WORLD.
I know we have some apparent experts on these boards that know more then everyone else. Instancing is not the same thing as server nodes, at least not really. MO is no dif. then any other MMO that has a seamless or non-seamless world; not even dif. then WoW. Darkfall is seemless, with the world broken into nodes; just like MO and WoW. To put it simply, Duskwood is on one set of servers, while Silverpine forest is on another. You just don't notice you crossed from one server to another, today. When WoW first released Blizzard had the same issues with pets crossing nodes that MO has, they wouldn't. It took Blizzard a couple of months to get pets fixed so they wouldn't vanish when you crossed from one area to another.
MO streams all of the information for a node to you when you enter that node. Other MMO's have started adopting this, in fact blizzard now uses streaming as well as SoE.
Saying a node line is the same as an instance is wrong. An instance implies that there can be multiple instances of a particular area. City of heroes is fully instanced. Every area of that game can have multiple instances of a zone, not just a dungeon, but an area of the world itself. WoW is not instanced, but uses instancing for dungeons; at the same time it's not a seamless world. MO is not instanced, not even the dungeons, and it's also seamless.
I was a block A MO player. I was in the beta from day one of block A until release, and played for over six months. SV is a really small company, with really big dreams, and light on talent. MO is also Unreals test pilot for the atlas technology. MO is the first seamless world MMO using UE AND Atlas. As much as SV may not be happy, or as disgruntled as the players may get, I dobt that Epic is any happier. MO was supposed to showcase the power of the UE AND Atlas. MO was supposed to HELP Epic sell the Atlas technology for other studios looking to create seamless, non-instanced worlds, and things aren't going very well for them.
The truth always lies somewhere in the middle.
You can't blame Epic or SV alone. You gotta blame them both.
PS: DCUO is an effing awesome game.
PPS: Epic also had a suit filed against them from a studio. The studio was claiming that Epic didn't provide them with the tools they needed to develop their game, and that Epic withheld stuff to delay the company so that Epic could release gears of war first. Things like patches to resolve issues with the engine.
So yes, there is in fact a presidence for what Henrik keeps saying. They're waiting on Epic.
Both MO and WoW always worked in similar way: when player is walking through particular node, all adjancent nodes are loaded in background.
The only difference between new "streaming" WoW client and older one is that new one can stream zone data directly from Blizzard servers, not only from local hard disk. So you can start playing very quickly after creating trial account.
The main difference between MO and WoW is that WoW is designed around engine limitations:
When two nearby nodes contain too much data to be loaded in seamless way, designers put in some very light node between them, like train between Stormwind and Ironforge, or ship to Kalimdor. If particular area requires low latency for gameplay reasons - it's moved to separate instance. All crowded areas are divided by high walls, canals, etc - so you won't be able to interact with all players at once. Quests are designed in such way, that players with different levels are more or less evenly distributed through the world.
It doesn't really matter if engine is internally developed, or licensed. To have properly working MMO you just need 2 more years of internal development AFTER engine, gameplay systems and most art assets are finished. And redesign, improve or cut 90% of content, knowing what engine can and what can't do.
Except that some errors were in Swedish and some were in English. There was absolutely no consistency, and that goes beyond just "convention". It's an industry standard.
On a related note, all the lore for the game is supposedly only written in Swedish and "just needs to be translated" according to Henrik. Why would they do this? The game is in English for god sakes.
It's just one laughable decision after another with these guys.
@ HerculesSAS:
Your statement that "a node is the same exact thing as an instance" just doesn't square with my understanding of what an instance is. http://www.mmorpg.com/discussion2.cfm/thread/309342/Static-loading-vs-Dynamic-loading-instances.html I'd appreciate if you could answer in that thread, to keep that topic focused. I understand that instances and nodes serve the same purpose (dividing the game world into more managable chunks of data). I suppose an argument could be made that they are exactly the same thing and that the boundaries between them are the difference (opaque, heavily gated boundaries for instances; transparent, permeable boundaries for nodes) However, that seems like fairly heavy parsing of the semantics.
If Epic games is to be held harmless for any problems with Atlas because it is version 1.0, why does that standard not apply to Starvault? The greater amount of experience at Epic doesn't render them or their products faultless. It just means that if there is a fault they are more likely to be able to fix that fault sooner or later. At this point Atlas is 2 years old http://www.epicgameschina.com/tech/tech_press_ct_htm.htm?id=198. Whether that is sooner or later, I'll leave to you to decide.
While it is true that you can almost always find a precedent for complaining about any given product, the precedents in this case hardly come from unqualified people. Silicon Knights developed Blood Omen:legacy of Kain and codeveloped Metal Gear solid. If you look at the other companies that have had complaints about Epic delaying releases, you also have Digital extremes and Midway. Arguably, Midways bankruptcy has stripped them of much of their talent, but Digital extremes codeveloped Unreal, Unreal tournament, Unreal Tournament 2003, Unreal Tournament 2004, Bioshock and Bioshock 2. http://www.gamesradar.com/ps3/stranglehold/news/unreal-engine-3-delaying-games/a-2007082016332832027/g-20060301165611510047
Tried to find out the verdict on the lawsuit, but apparently it's still going.http://dockets.justia.com/docket/north-carolina/ncedce/5:2007cv00275/89570/
I am a SW developer from Sweden and have been for the last 6 years. There is no excuse at all for a Swedish development team not to code in english as it is practically the second language in Sweden.
If I would see a code written in Swedish, have not so far, I would see that as a clear sign of unproffesionality. Ofcourse code are written in English, even discussing it is something that just does not happen. So it is not a "preference", it is an industry standard. Even in Sweden.
My gaming blog