They mentioned zones, and there will be loading screens between zones. However, they said the zones are huge and the dungeons inside zones are large and persistent. So you wont zone into dungeons and other people outside your grp can be there. (same way EQ was).
Not a huge fan of zones, but as long as they are large enough and open enough I am ok with it.
I also hate when zones bottleneck you into the next one, like Aion. Had to follow the path to zone etc.
Loading screens, or a hitch or hesitation doesn't really bother me if it helps the overall performance of the game. I just don't like being bottle-necked into and out of zones, that completely kills the immersion for me. Vanguard was large and open and I loved it.... I didn't mind the hesitation when you crossed over into a new 'chuck'
I strongly doubt Vanguard was ever meant to have preload. As I explained, assuming square chunks, that strategy would require 16 chunks in memory at all times. The chunks of Vanguard have been massive, thus a preload strategy wasnt feasible.
I am very amused that there are people out there who think waiting a friggin half a minute during a chunk change would be tolerable at all. That would be perfectly enough to cause me to /ragequit. A chunk change isnt a change between areas, its crossing a more or less invisible line in the game world. It can happen multiple times in short sequence. Waiting a friggin half minute every time would be completely intolerable.
Chunk changes in Vanguard took about five seconds and that was by far long enough already. Its five friggin seconds every single time you cross that damn border, after all.
You do not lose any features by having invisible chunk loading. Yes the programming of some features might get a bit more complicated with this. But none get impossible.
I never waited half a minute to chunk in Vanguard, never. It got to the stage over the seven years I played and updating my PC that it was near enough instant.
I guess playing EQ puts it in perspective, anyone remember how long it took to zone in that game would have no problem with Vanguards time.
The problem is you're saying "but 1+1 = 2" and I'm saying "no in this case its 1+1 = 10" and you're saying "thats wrong" and I'm saying "well, dude, its binary, there is no 2, after 0 and 1 comes 10" and you're saying "you are stupid" and I'm saying "sigh".
boojiboy said: Loading screens, or a hitch or hesitation doesn't really bother me if it
helps the overall performance of the game.
But thats the point, it doesnt help ? The overall performance is better
if zones are kept completely invisible to the player. Because no loading
screens = more performance.
I strongly doubt Vanguard was ever meant to have preload. As I
explained, assuming square chunks, that strategy would require 16 chunks
in memory at all times.
No, it would have required 9 chunks in memory. The one you are in and
the 8 chunks surrounding it. Not sure how you got 16. I dont think
your explanation really made sense. xxx xxx xxx
And why I
believe it was intended to be preload is that they stated that there
would be no pause as you cross chunk lines. I think that implies it,
since you cant have instant loading of chunk without preload. But we
know that there was chunkline pause, so clearly that didnt work out.
Err ... just because you dont understand something doesnt mean its wrong.
Its very easy to explain why you need 16 chunks. I explained it above, but let me try again.
As you already figured out, if you have square chunks, any chunk has 8 adjacent chunks.
The critical situation in this scenario is when you're at the border of four chunks. With square chunks, this is easily possible; you are simply at one of the edges of a chunk and can then quickly switch to any of the three other chunks that are directly bordering.
So you can very quickly switch between these four chunks.
With your suggestion of keeping only 9 chunks in memory, every time you switch chunks, the game has to load 5 new chunks now adjacent to the new chunk but not adjacent to the old chunk. This would cause massive load lag very quickly if you repeat that all the time.
And since, in our system, the player isnt supposed to experience the chunk borders at all, this situation would be very common. The player would, as a result, see massive lag in some situations and none in others, for no good reason at all.
Thus, to avoid that, the last 16 chunks have to be kept in memory. You can still switch between four chunks very quickly, but all adjacent chunks of all four chunks will be already in memory, avoiding any load lag aside from the initial, unavoidable one.
One could also have all kinds of other position logic, be sensitive to where the player in the chunk is currently positioned, instead. But thats another debate.
When you cross into a new chunk you still have to load new chunks into memory whether its the 9 chunk system or the 16 chunk system. However they are loaded in background so it doesnt affect play.
Lets say these are the chunks. Player is in chunk M. ABCDE FGH I J KLMNO PQRST UVWXY
If player crosses from chunk M to chunk I the game already has chunk I in memory so the player can still play without pause. If he is headed to chunk D, E, or J, the game has plenty of time to load those zones while he crosses chunk I. This is done in the background. There is no need to pause.
I cant even imagine how you would pick which 16 of the 25 chunks to pick. Naturally the middle 9 are loaded. But which 7 of the outer ring of 16 were you thinking would be chosen? The number you chose (16 chunks loaded), aside from being overkill, doesnt make sense in a square chunk system.
I strongly doubt Vanguard was ever meant to have preload. As I
explained, assuming square chunks, that strategy would require 16 chunks
in memory at all times.
No, it would have required 9 chunks in memory. The one you are in and
the 8 chunks surrounding it. Not sure how you got 16. I dont think
your explanation really made sense. xxx xxx xxx
And why I
believe it was intended to be preload is that they stated that there
would be no pause as you cross chunk lines. I think that implies it,
since you cant have instant loading of chunk without preload. But we
know that there was chunkline pause, so clearly that didnt work out.
Err ... just because you dont understand something doesnt mean its wrong.
Its very easy to explain why you need 16 chunks. I explained it above, but let me try again.
As you already figured out, if you have square chunks, any chunk has 8 adjacent chunks.
The critical situation in this scenario is when you're at the border of four chunks. With square chunks, this is easily possible; you are simply at one of the edges of a chunk and can then quickly switch to any of the three other chunks that are directly bordering.
So you can very quickly switch between these four chunks.
With your suggestion of keeping only 9 chunks in memory, every time you switch chunks, the game has to load 5 new chunks now adjacent to the new chunk but not adjacent to the old chunk. This would cause massive load lag very quickly if you repeat that all the time.
And since, in our system, the player isnt supposed to experience the chunk borders at all, this situation would be very common. The player would, as a result, see massive lag in some situations and none in others, for no good reason at all.
Thus, to avoid that, the last 16 chunks have to be kept in memory. You can still switch between four chunks very quickly, but all adjacent chunks of all four chunks will be already in memory, avoiding any load lag aside from the initial, unavoidable one.
One could also have all kinds of other position logic, be sensitive to where the player in the chunk is currently positioned, instead. But thats another debate.
When you cross into a new chunk you still have to load new chunks into memory whether its the 9 chunk system or the 16 chunk system. However they are loaded in background so it doesnt affect play.
Lets say these are the chunks. Player is in chunk M. ABCDE FGH I J KLMNO PQRST UVWXY
If player crosses from chunk M to chunk I the game already has chunk I in memory so the player can still play without pause. If he is headed to chunk D, E, or J, the game has plenty of time to load those zones while he crosses chunk I. This is done in the background. There is no need to pause.
I cant even imagine how you would pick which 16 of the 25 chunks to pick. Naturally the middle 9 are loaded. But which 7 of the outer ring of 16 were you thinking would be chosen? The number you chose (16 chunks loaded), aside from being overkill, doesnt make sense in a square chunk system.
You have to be in the matrix to understand this logic.
The problem is you're saying "but 1+1 = 2" and I'm saying "no in this case its 1+1 = 10" and you're saying "thats wrong" and I'm saying "well, dude, its binary, there is no 2, after 0 and 1 comes 10" and you're saying "you are stupid" and I'm saying "sigh".
boojiboy said: Loading screens, or a hitch or hesitation doesn't really bother me if it
helps the overall performance of the game.
But thats the point, it doesnt help ? The overall performance is better
if zones are kept completely invisible to the player. Because no loading
screens = more performance.
Its just easier to program.
Isn't it true though that line of sight is what really matters as that's what governs what is being rendered? That's how it works on engines like gamebryo anyway. Hence you can use invisible boxes that indicate line of sight, as well as use objects to block line of sight to optimize the performance by limiting what is being rendered.
For every minute you are angry , you lose 60 seconds of happiness."-Emerson
Interesting discussion about chunks. @Adamantine has it almost right. The problem is the presentation on these forums. Using letters to represent a space is wrong. @Adamantine's case is when the absolute location of the character is in the center X, but at the extreme SE corner. Rather than using an X, the problem is better represented with 4 dots, one at each corner of X. As the absolute location approaches one of the 4 corners, the more likely it will be necessary to load a maximum of 5 new chunks. Proportional spaced fonts work against an accurate presentation, causing of the confusion. (In @svann's A-Y model, if the location is in M, but close to the M-N-R-S intersection, with the likelihood of moving to S, the computer might need to load chunks O-T-W-X-Y in order to maintain 9 chunks in memory).
Beyond the issue with chunks is the absolute constraints of the hardware. Loading a block of memory from disk is the second slowest operation a computer takes. Loading 1 chunk that is 10,000 units x 10,000 units takes the about the same amount of time as loading 100 chunks of 1,000 units by 1,000 units -- the data transfer time from the disk remains the same (not accounting for seek and latency times). The amount of work done in both cases is transferring 100,000,000 blocks of information.
Logic, my dear, merely enables one to be wrong with great authority.
Interesting discussion about chunks. @Adamantine has it almost right. The problem is the presentation on these forums. Using letters to represent a space is wrong. @Adamantine's case is when the absolute location of the character is in the center X, but at the extreme SE corner. Rather than using an X, the problem is better represented with 4 dots, one at each corner of X. As the absolute location approaches one of the 4 corners, the more likely it will be necessary to load a maximum of 5 new chunks. Proportional spaced fonts work against an accurate presentation, causing of the confusion. (In @svann's A-Y model, if the location is in M, but close to the M-N-R-S intersection, with the likelihood of moving to S, the computer might need to load chunks O-T-W-X-Y in order to maintain 9 chunks in memory).
Beyond the issue with chunks is the absolute constraints of the hardware. Loading a block of memory from disk is the second slowest operation a computer takes. Loading 1 chunk that is 10,000 units x 10,000 units takes the about the same amount of time as loading 100 chunks of 1,000 units by 1,000 units -- the data transfer time from the disk remains the same (not accounting for seek and latency times). The amount of work done in both cases is transferring 100,000,000 blocks of information.
You're either in an area, or you're not. Loading additional zones while crossing the border serves no practical purpose unless zones are so small you can traverse them in a matter of seconds.
Mendel, even as slow as loading from disk is it can still load those 5 new chunks 100000x faster (in the background) than you can run across a new chunk to reach them. Even if you are in the corner of a chunk you still only need the closest chunks pre-loaded. There is no reason to preload another layer of chunks beyond that.
Not unless you are considering making chunks really tiny and then you run into the problem that npcs cant cross chunk lines. They are a part of the chunk they are born in.
This is all rather moot. As Distopia eluded to, you wouldn't want to waste resources loading something you couldn't possible see or zones you couldn't enter based on your current location.
When moving from M to S, the 3x3 space goes from G-H-I-L-M-N-Q-R-S to M-N-O-R-S-T-W-X-Y, requiring 5 new chunks to be loaded (O-T-W-X-Y). It also requires 5 chunks to be unloaded, G-H-I-L-Q, which can be a significant time depending on memory allocation schemes.
Normally, moving from M to S then to Y might take a considerable amount of time (relative to loading/unloading), moving from M to S back to M can cause a worst case performance. Also, special movement effects, such as teleporting or super speed, can cause excessive loading / unloading once the movement speed exceeds the chunk dimensions.
Logic, my dear, merely enables one to be wrong with great authority.
With large zones, anything you can see you can run to and explore. Zoning unlike in 1999 takes seconds. Im not sure where the problem lies. Also VR said that as tech change they maybe able to make their game seamless. So it may even happen one day. For now its what we got and its quality.
When moving from M to S, the 3x3 space goes from G-H-I-L-M-N-Q-R-S to M-N-O-R-S-T-W-X-Y, requiring 5 new chunks to be loaded (O-T-W-X-Y). It also requires 5 chunks to be unloaded, G-H-I-L-Q, which can be a significant time depending on memory allocation schemes.
Which only makes the case for loading 9 chunks instead of 16. If you go with the 9 chunk system you only need 5 new chunks loaded as you said. If you go with a 16 chunk system it is more than that.
I've come up with a better, much shorter explanation of what I wanted to state.
Now everybody understands that in a square chunk scenario, any square chunk has eight neighboring square chunks.
Thus its probably very obvious that this could be optimized even further if we had a backlog of some more than just nine chunks in total, in order to reuse chunks that have been recently loaded before.
There is also the special case that people can switch chunks very quickly, and its not exotic in any way. The simpler of these scenarios is that somebody keeps moving forward and backward. Every time they do so, the program would have to keep loading three new squares that havent been adjacent to the previous square but are now adjacent to the current square. Between each load event, there is no lower limit of how much time it takes. Thus it would be very beneficial to have the game cache the extra three chunks, for a total of 12 chunks, to handle this case without introducing constant harddisk traffic and thus lag (also noise if you dont have SSDs. Also disk aging, even if you have SSDs).
There is an even worse case in which a player moves in a circle around the crossing of five square chunks, forcing the game to constantly load the all the adjacent square chunks, for a total of 16 chunks in memory. Again the switching from one chunk to the next has no lower limit and can thus happen extremely fast. Thus again to avoid constant harddisk traffic we would want to increase the total cache of chunks to 16.
I would like to add that a player going backwards and forwards isnt rare. Also players going in circles isnt rare. It occurs during the very popular strategy of kiting.
I hope thats an easier to understand explanation why, with square chunks, we would want to keep at least 16 chunks in memory.
Every time someone leaves a chunk, the out of scope adjacent zones would be dropped. No matter how many times you go back and forth or where you are located, there is no reason to load anything more than adjacent zones.
Adamantine if you load chunks farther out then when you cross a chunk line more have to be loaded not less. When recrossing a chunkline as you say, the 3 dont have to be reloaded, but the ones further out that you have added to the list do. You are increasing HD activity, not lessening it.
You also did not respond to my question posed to you earlier. In a grid of 25 chunks with you in the center chunk (doesnt matter where in that chunk), which 16 of the 25 would you load in your scenario? If you cant define that then you havent really thought about it enough. Just think about that and you will see whats wrong. Define your strategy first, then defend it.
Every time someone leaves a chunk, the out of scope adjacent zones would be dropped. No matter how many times you go back and forth or where you are located, there is no reason to load anything more than adjacent zones.
Adamantine if you load chunks farther out then when you cross a chunk line more have to be loaded not less. When recrossing a chunkline as you say, the 3 dont have to be reloaded, but the ones further out that you have added to the list do. You are increasing HD activity, not lessening it.
You also did not respond to my question posed to you earlier. In a grid of 25 chunks with you in the center chunk (doesnt matter where in that chunk), which 16 of the 25 would you load in your scenario? If you cant define that then you havent really thought about it enough. Just think about that and you will see whats wrong. Define your strategy first, then defend it.
I can't speak for @Adamantine, but I think he's trying to say that holding more than a 3x3 square is beneficial to minimize loading and unloading. More than a circle, a simple serpentine run along the M-N border could easily cause a thrashing condition. To help prevent that, there is usually a buffer area, where the edge of the chunk and the 'trigger line' aren't the same. In a chunk that contains pixels numbered from 1 to 100, there may be a (non-graphical) trigger line at 10 and 90 that actually triggers the load/unload process. This gives the load/unload processes a bit of time to act before the character moves from M(50,100) to N(50,1).
I've not seen an example where there is a need for a 4x4 matrix, since the allocated space for chunks isn't guaranteed to be contiguous in memory. All that are absolutely needed are a maximum of 14 memory chunks allocated at a time, at least in any code that I've ever seen. Maybe @Adamantine has seen more than I have, that's entirely likely, but the mathematics needed should only require 14 blocks. Maybe the intent of the 4x4 is to include 16 allocated blocks of memory to contain chunks, but that seems slightly odd. I'd probably attempt to only allocate a fixed number of 14 blocks plus some multiple of 5 extra blocks (to deal with load / unload operations) and deal with the garbage collection / memory reuse issues myself (stock garbage collection routines triggered with memory management functions can be hideous for performance).
Logic, my dear, merely enables one to be wrong with great authority.
Even WoW has no zones that need a loading screen, they've had it since launch over a decade ago.... Unless you are talking about instances, then they even have a use, creating a ' private' zone for you and your group where you can't be bothered by ' outside' players. Loading screens for zones? Please, is Blizzard using voodoo to get this stuff done?
/Cheers, Lahnmir
'the only way he could nail it any better is if he used a cross.'
Kyleran on yours sincerely
'But there are many. You can play them entirely solo, and even offline. Also, you are wrong by default.'
Ikcin in response to yours sincerely debating whether or not single-player offline MMOs exist...
'This does not apply just to ED but SC or any other game. What they will get is Rebirth/X4, likely prettier but equally underwhelming and pointless.
It is incredibly difficult to design some meaningfull leg content that would fit a space ship game - simply because it is not a leg game.
It is just huge resource waste....'
Gdemami absolutely not being an armchair developer
On a side note, with how mobs dont forget you, zoning is the only way to get away from a pack of aggro mobs. Just think of some Bard training the contents of an open world dungeon across the world.
On a side note, with how mobs dont forget you, zoning is the only way to get away from a pack of aggro mobs. Just think of some Bard training the contents of an open world dungeon across the world.
What, you don't remember how people dealt with newbs like that if GMs didn't? Let's just say they stayed LFG for life
On a side note, with how mobs dont forget you, zoning is the only way to get away from a pack of aggro mobs. Just think of some Bard training the contents of an open world dungeon across the world.
Or like when the rogues rebelled/boycotted and made their own guild. Tried to ruin things for people but what ended up happening is every guild banded together and screwed the rogue guild out of every encounter so they couldn't progress or raid.
I can't speak for @Adamantine, but I think he's trying to say that holding more than a 3x3 square is beneficial to minimize loading and unloading.
The point is that you want an upper limit to how many chunks are loaded during any given timeframe, thus making the whole segmentation of the gameworld completely transparent to the player, since he never experiences lag by moving around.
But if you have the cases I described, you can switch the current chunk extremely quickly, again and again.
Lets say you really only keep 9 chunks in memory and the player is at the border of two chunks and maybe he's even standing still, but the inprecision of floating numbers (which are typically used to describe the position of objects in a 3D graphic environment) causes him to oscillate between those two chunks at every single redraw of the scene. So assuming the game runs at 60 Hz, you would have to load 180 chunks every second. In that case you would have created *extreme* hard disk traffic and thus lag.
Thats why its more efficient to keep the chunks smaller, so you can keep 16 chunks in memory at any time.
On a side note, with how mobs dont forget you, zoning is the only
way to get away from a pack of aggro mobs. Just think of some Bard
training the contents of an open world dungeon across the world.
You can solve the same problem with a timer though, or a distance from the origin.
On a side note, with how mobs dont forget you, zoning is the only way to get away from a pack of aggro mobs. Just think of some Bard training the contents of an open world dungeon across the world.
What, you don't remember how people dealt with newbs like that if GMs didn't? Let's just say they stayed LFG for life
No they just found other a-holes to play with...
For every minute you are angry , you lose 60 seconds of happiness."-Emerson
Thats why its more efficient to keep the chunks smaller, so you can keep 16 chunks in memory at any time.
1. If you make chunks small you have to figure out how to make mobs able to cross chunk lines. Not insurmountable but not trivial either. 2. You still havent answered the question of which 16 chunks out of the 25 chunk grid.
I don't get it,i see all the time people asking for seamless.
So people are worried about loading but are ok with linear questing,giant yellow ? and ! over npc heads,name plates etc etc?
If loading was the ONLY non immersive thing in a game,i would give devs a 9.9999/10.
We are miles form seeing a quality immersive game,instead i am seeing a complete opposite direction.I see phone apps and mobile and mini games ,auto movement,auto fishing,stuff appearing out of thin air,creatures that seem to never eat,no eco systems,players that never eat/sleep or build nor even have homes in most games.Then i see stuff like point systems,put points into x y or z,all non immersive ideas.
Point is i wish i could quit seeing this nonsense about loading,what do people think happens when you start a game?...login screen...loading lmao.Since i started playing rpg's 30 years ago,i been waiting for ONE GAME to bring me an immersive platform to have fun with other gamer's online.
Never forget 3 mile Island and never trust a government official or company spokesman.
Comments
I never waited half a minute to chunk in Vanguard, never. It got to the stage over the seven years I played and updating my PC that it was near enough instant.
I guess playing EQ puts it in perspective, anyone remember how long it took to zone in that game would have no problem with Vanguards time.
Nope.
The problem is you're saying "but 1+1 = 2" and I'm saying "no in this case its 1+1 = 10" and you're saying "thats wrong" and I'm saying "well, dude, its binary, there is no 2, after 0 and 1 comes 10" and you're saying "you are stupid" and I'm saying "sigh".
But thats the point, it doesnt help ? The overall performance is better if zones are kept completely invisible to the player. Because no loading screens = more performance.
Its just easier to program.
Lets say these are the chunks. Player is in chunk M.
ABCDE
FGH I J
KLMNO
PQRST
UVWXY
If player crosses from chunk M to chunk I the game already has chunk I in memory so the player can still play without pause. If he is headed to chunk D, E, or J, the game has plenty of time to load those zones while he crosses chunk I. This is done in the background. There is no need to pause.
I cant even imagine how you would pick which 16 of the 25 chunks to pick. Naturally the middle 9 are loaded. But which 7 of the outer ring of 16 were you thinking would be chosen? The number you chose (16 chunks loaded), aside from being overkill, doesnt make sense in a square chunk system.
For every minute you are angry , you lose 60 seconds of happiness."-Emerson
Beyond the issue with chunks is the absolute constraints of the hardware. Loading a block of memory from disk is the second slowest operation a computer takes. Loading 1 chunk that is 10,000 units x 10,000 units takes the about the same amount of time as loading 100 chunks of 1,000 units by 1,000 units -- the data transfer time from the disk remains the same (not accounting for seek and latency times). The amount of work done in both cases is transferring 100,000,000 blocks of information.
Logic, my dear, merely enables one to be wrong with great authority.
Not unless you are considering making chunks really tiny and then you run into the problem that npcs cant cross chunk lines. They are a part of the chunk they are born in.
Normally, moving from M to S then to Y might take a considerable amount of time (relative to loading/unloading), moving from M to S back to M can cause a worst case performance. Also, special movement effects, such as teleporting or super speed, can cause excessive loading / unloading once the movement speed exceeds the chunk dimensions.
Logic, my dear, merely enables one to be wrong with great authority.
Now everybody understands that in a square chunk scenario, any square chunk has eight neighboring square chunks.
Thus its probably very obvious that this could be optimized even further if we had a backlog of some more than just nine chunks in total, in order to reuse chunks that have been recently loaded before.
There is also the special case that people can switch chunks very quickly, and its not exotic in any way. The simpler of these scenarios is that somebody keeps moving forward and backward. Every time they do so, the program would have to keep loading three new squares that havent been adjacent to the previous square but are now adjacent to the current square. Between each load event, there is no lower limit of how much time it takes. Thus it would be very beneficial to have the game cache the extra three chunks, for a total of 12 chunks, to handle this case without introducing constant harddisk traffic and thus lag (also noise if you dont have SSDs. Also disk aging, even if you have SSDs).
There is an even worse case in which a player moves in a circle around the crossing of five square chunks, forcing the game to constantly load the all the adjacent square chunks, for a total of 16 chunks in memory. Again the switching from one chunk to the next has no lower limit and can thus happen extremely fast. Thus again to avoid constant harddisk traffic we would want to increase the total cache of chunks to 16.
I would like to add that a player going backwards and forwards isnt rare. Also players going in circles isnt rare. It occurs during the very popular strategy of kiting.
I hope thats an easier to understand explanation why, with square chunks, we would want to keep at least 16 chunks in memory.
You also did not respond to my question posed to you earlier. In a grid of 25 chunks with you in the center chunk (doesnt matter where in that chunk), which 16 of the 25 would you load in your scenario? If you cant define that then you havent really thought about it enough. Just think about that and you will see whats wrong. Define your strategy first, then defend it.
I've not seen an example where there is a need for a 4x4 matrix, since the allocated space for chunks isn't guaranteed to be contiguous in memory. All that are absolutely needed are a maximum of 14 memory chunks allocated at a time, at least in any code that I've ever seen. Maybe @Adamantine has seen more than I have, that's entirely likely, but the mathematics needed should only require 14 blocks. Maybe the intent of the 4x4 is to include 16 allocated blocks of memory to contain chunks, but that seems slightly odd. I'd probably attempt to only allocate a fixed number of 14 blocks plus some multiple of 5 extra blocks (to deal with load / unload operations) and deal with the garbage collection / memory reuse issues myself (stock garbage collection routines triggered with memory management functions can be hideous for performance).
Logic, my dear, merely enables one to be wrong with great authority.
/Cheers,
Lahnmir
Kyleran on yours sincerely
'But there are many. You can play them entirely solo, and even offline. Also, you are wrong by default.'
Ikcin in response to yours sincerely debating whether or not single-player offline MMOs exist...
'This does not apply just to ED but SC or any other game. What they will get is Rebirth/X4, likely prettier but equally underwhelming and pointless.
It is incredibly difficult to design some meaningfull leg content that would fit a space ship game - simply because it is not a leg game.
It is just huge resource waste....'
Gdemami absolutely not being an armchair developer
But if you have the cases I described, you can switch the current chunk extremely quickly, again and again.
Lets say you really only keep 9 chunks in memory and the player is at the border of two chunks and maybe he's even standing still, but the inprecision of floating numbers (which are typically used to describe the position of objects in a 3D graphic environment) causes him to oscillate between those two chunks at every single redraw of the scene. So assuming the game runs at 60 Hz, you would have to load 180 chunks every second. In that case you would have created *extreme* hard disk traffic and thus lag.
Thats why its more efficient to keep the chunks smaller, so you can keep 16 chunks in memory at any time.
You can solve the same problem with a timer though, or a distance from the origin.
For every minute you are angry , you lose 60 seconds of happiness."-Emerson
2. You still havent answered the question of which 16 chunks out of the 25 chunk grid.
So people are worried about loading but are ok with linear questing,giant yellow ? and ! over npc heads,name plates etc etc?
If loading was the ONLY non immersive thing in a game,i would give devs a 9.9999/10.
We are miles form seeing a quality immersive game,instead i am seeing a complete opposite direction.I see phone apps and mobile and mini games ,auto movement,auto fishing,stuff appearing out of thin air,creatures that seem to never eat,no eco systems,players that never eat/sleep or build nor even have homes in most games.Then i see stuff like point systems,put points into x y or z,all non immersive ideas.
Point is i wish i could quit seeing this nonsense about loading,what do people think happens when you start a game?...login screen...loading lmao.Since i started playing rpg's 30 years ago,i been waiting for ONE GAME to bring me an immersive platform to have fun with other gamer's online.
Never forget 3 mile Island and never trust a government official or company spokesman.