YOU are the only person consistently claiming that MO is instanced.
Not at all, other posters here agree.
Could you name one poster that has consistently stated that MO is instanced ? I only found one other person arguing that in this thread, and frankly I don't find them credible on this matter.
Others who have used the Atlas technology, and Unreal technology, have opted for instance based games.
I would not call MO for instance based. Notebased is entirely different, in my opinion. And to be honest, it would not matter for me anyway, as long as there are no loading screens the world is seamless to me, disregarding whatever system they use to achieve it.
However, I really don't get what one slipup with xbox360 have to do with the debate, to prove that people make mistakes? Well, all do, but I refuse to believe all the blame Henrik is trying to put on Epic just because of that one slipup. He was blaming them for pretty much everything lately, and I do have more trust in Epics programming then SVs.
YOU are the only person consistently claiming that MO is instanced.
Not at all, other posters here agree.
Could you name one poster that has consistently stated that MO is instanced ? I only found one other person arguing that in this thread, and frankly I don't find them credible on this matter.
Others who have used the Atlas technology, and Unreal technology, have opted for instance based games.
It is a matter of semantics. Instancing in the colloquial use is as you say; taking the same space and spinning it up again for more users to pack into it, as WOW and countless other games do it. Nodes are transitional pieces from area to area.
The thing is though, that it's the SAME THING. Instancing tells a software "hey, here's this place in memory, here's this CPU, here's this disk, send all the users HERE for this instance." In a node, you go from one to the other and the when you cross, the server says, "hey, here's this place in memory, here's this CPU, here's htis disk, send all the users HERE for this NODE."
Using Unreal and Atlas and deciding whether to use a NODE or an Instance is in software and hardware, THE SAME THING. There is no difference. The only benefit that instancing buys you is that an infinite number of people can occupy the same space, barring only hardware limitations. Using nodes, a finite number of people can occupy the node; though this isn't an issue for SV, since they have less than 300 people online at a given time, and that's being generous.
Now given that I've explained it, and that you understand what I'm saying (because it's not that complicated, or maybe I worded it poorly), please tell us why it makes *any* difference to the problems that MO has currently? SV decided to implement "instances" in the form of nodes. It gives them a different layout to work with, and they have to balance hardware resources based on the popularity of an area, rather than being able to give the same hardware resources to every "instance" as something like WOW would do. This is purely a design decision, as they wanted the "seamless" world ideal, but here's a little tip; did you ever play Ultima Online? When there are a zillion people in Britain, ALL OF BRITAIN LAGS. Oddly enough, Vesper and Minoc don't lag at all, because they are on separate hardware.
When you have a game with huge population and you want to offer people the ability to be able to play, part of your design decision has to be whether to include instancing or not in order to accomodate the demand for specific game areas. If nobody's playing your game, it's kind of a moot point. But it's not any different in the software, it's a simple design choice.
How does your explanation contradict my post a couple pages back? As I understand it, the difference is that players (and AI) in seperate nodes are supposed to be able to see and act on one another if they are close enough within the game world. The same is not true for instances.
Originally posted by osmunda
@ 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 an instance and a node are exactly the same thing, what did you think the server architecture was going to be when you posted the following?
Originally posted by HerculesSAS
Lobby-Session Game Type Support – Atlas provides full support for persistent lobby session based games.
What does that mean? It means that Atlas technology was designed to support (and you can figure this out if you read the EpicGames.com forums) INSTANCED GAMES.
Now ask yourself? Is it Epic's fault if SV decided to take their technology and use it in a manner that it was not meant for? Look at the games using it -- ALL INSTANCED. APB, Global Agenda, Blade and Soul..
and
Originally posted by HerculesSAS
Unfortunately for SV, this is a case of "damned if we do, damned if we don't".
I have maintained all along about SV, that they were not really capable of producing a title of this magntitude. Others who have used the Atlas technology, and Unreal technology, have opted for instance based games. And these are developers who have some previous experience too.
The benefit of instanced based games (vs node based) is that you can offer good content to people at a theoretical unlimited amount. MO's game world is very bland and boring, and it would have benefitted them greatly to look at having richer areas that are instanced.
That said, I now have the luxury of time to look over what I've said and I can say I've learned a lot about game development in the past year. The post you referenced was from a year ago, when I'd done little digging into how game engines worked and the processes used in game development. It's not a hard jump from what I do now; financial software has different tools to develop, however the process is still mostly the same. I can say my own understanding a year ago (from when you posted) of instancing vs nodes was basically the same as yours. However after looking at the implementation of what a game engine does, and network stacks do, in software and hardware it's basically the same thing. You're simply calling an API to load some resource; in the case of an instance, you're loading the SAME resource, in the case of a node, you are loading a different resource.
At the time I posted what I did, I had the assumption that SV just did it the wrong way and were working against the tools. It's more clear now that they used the engine correctly, it's rather obvious instead that their design and layout is entirely broken and doesn't mesh with what they wanted to do. Having no ability to code properly doesn't help them either.
Comments
Could you name one poster that has consistently stated that MO is instanced ? I only found one other person arguing that in this thread, and frankly I don't find them credible on this matter.
Others who have used the Atlas technology, and Unreal technology, have opted for instance based games.
I would not call MO for instance based. Notebased is entirely different, in my opinion. And to be honest, it would not matter for me anyway, as long as there are no loading screens the world is seamless to me, disregarding whatever system they use to achieve it.
However, I really don't get what one slipup with xbox360 have to do with the debate, to prove that people make mistakes? Well, all do, but I refuse to believe all the blame Henrik is trying to put on Epic just because of that one slipup. He was blaming them for pretty much everything lately, and I do have more trust in Epics programming then SVs.
It is a matter of semantics. Instancing in the colloquial use is as you say; taking the same space and spinning it up again for more users to pack into it, as WOW and countless other games do it. Nodes are transitional pieces from area to area.
The thing is though, that it's the SAME THING. Instancing tells a software "hey, here's this place in memory, here's this CPU, here's this disk, send all the users HERE for this instance." In a node, you go from one to the other and the when you cross, the server says, "hey, here's this place in memory, here's this CPU, here's htis disk, send all the users HERE for this NODE."
Using Unreal and Atlas and deciding whether to use a NODE or an Instance is in software and hardware, THE SAME THING. There is no difference. The only benefit that instancing buys you is that an infinite number of people can occupy the same space, barring only hardware limitations. Using nodes, a finite number of people can occupy the node; though this isn't an issue for SV, since they have less than 300 people online at a given time, and that's being generous.
Now given that I've explained it, and that you understand what I'm saying (because it's not that complicated, or maybe I worded it poorly), please tell us why it makes *any* difference to the problems that MO has currently? SV decided to implement "instances" in the form of nodes. It gives them a different layout to work with, and they have to balance hardware resources based on the popularity of an area, rather than being able to give the same hardware resources to every "instance" as something like WOW would do. This is purely a design decision, as they wanted the "seamless" world ideal, but here's a little tip; did you ever play Ultima Online? When there are a zillion people in Britain, ALL OF BRITAIN LAGS. Oddly enough, Vesper and Minoc don't lag at all, because they are on separate hardware.
When you have a game with huge population and you want to offer people the ability to be able to play, part of your design decision has to be whether to include instancing or not in order to accomodate the demand for specific game areas. If nobody's playing your game, it's kind of a moot point. But it's not any different in the software, it's a simple design choice.
@ hercules:
Just a couple questions....
How does your explanation contradict my post a couple pages back? As I understand it, the difference is that players (and AI) in seperate nodes are supposed to be able to see and act on one another if they are close enough within the game world. The same is not true for instances.
If an instance and a node are exactly the same thing, what did you think the server architecture was going to be when you posted the following?
and
The benefit of instanced based games (vs node based) is that you can offer good content to people at a theoretical unlimited amount. MO's game world is very bland and boring, and it would have benefitted them greatly to look at having richer areas that are instanced.
That said, I now have the luxury of time to look over what I've said and I can say I've learned a lot about game development in the past year. The post you referenced was from a year ago, when I'd done little digging into how game engines worked and the processes used in game development. It's not a hard jump from what I do now; financial software has different tools to develop, however the process is still mostly the same. I can say my own understanding a year ago (from when you posted) of instancing vs nodes was basically the same as yours. However after looking at the implementation of what a game engine does, and network stacks do, in software and hardware it's basically the same thing. You're simply calling an API to load some resource; in the case of an instance, you're loading the SAME resource, in the case of a node, you are loading a different resource.
At the time I posted what I did, I had the assumption that SV just did it the wrong way and were working against the tools. It's more clear now that they used the engine correctly, it's rather obvious instead that their design and layout is entirely broken and doesn't mesh with what they wanted to do. Having no ability to code properly doesn't help them either.
I believe there is a saying about workers who blame their tools for their failures.