Goblin Squad Member
|
So I was thinking about ways to minimize server lag, and I thought it might be a good idea for the more technical of us to have a thread where we can brainstorm ways in which to make different aspects of the game better from a technical standpoint.
Random number generator - I've been wondering off and on how the random number generation will work with PFO. There are whole dissertations written on how to generate random numbers, and some methods are better than others depending on what you're doing. I doubt Goblinworks will want to have a chunk of something decaying radioactively laying around, and I don't think they'll want to go to the expense of sourcing quantum particle phasing in a vacuum, so obviously there's going to be a purely programming solution to random number generation. I wonder if it's faster to pre-generate the random numbers when the system has free processing ability, or maybe at least the d20 rolls since that's probably a large chunk of the numbers that will be needed. If it's done when the processing cycles would otherwise basically be unused, then the processing is essentially free. At that point, you would just have to compare the storage and retrieval of those numbers with the generation of numbers on the fly and see which action is cheaper in terms of processing (I doubt that hard drive space is an issue, and these can be stored in their own database so db size shouldn't be an issue either). Of course, there would have to be a system to generate numbers on the fly still if there are none stored. Anyway, it's just a thought - I imagine there are definitely ways to generate random numbers that are faster than pulling from a db, like a simple operation using the system clock for example, but it seems like the more processing you spend on random number generation the better the randomness of the outcome will be, in general. It just boils down to how random Goblinworks wants the numbers to be.
If you guys have any other technical ideas, or can improve upon previous ones in the thread, please post!
|
Goblin Squad Member
|
Line of Sight - I checked up on some of the documentation in Unity, and it looks like there's a choice between Linecast and Raycast, the former being much more efficient when comparing known positions. The problem is that it only compares two known positions, for example the middle of characters' foreheads. Since Goblinworks will want LoS calculations to be done server side for security reasons, I'm not sure how useful this info is unless they're running another instance of Unity in the back end for calculations and synchronization. Anyway, if each character has an array of points including forehead, feet, hands, and stomach, then LoS calculations can be done using Linecast with those array points. Each point increases the processing time, of course, so maybe leave off the hands since they're going to be animatedly moving a lot more than the rest of the body and a lot of the time they'll be in front of the stomach point anyway. The feet points could be combined into just one point, halfway between the feet, calculated by subtracting the vertical coordinate from the forehead point - the stomach point can be done in much the same way, so you end up with 3 vertical points. There's probably something in the first person code to easily get the forehead point. With three points, there are 9 linecasts per check, unless all casts are done from the forehead point so there would only be 3, and the linecasts only have to be done when an ability is used, so I think this method would be efficient enough. Of course, if this is done server side and there's no Unity instance there, this is all moot. In addition to security issues, you'd have to make sure the location data is up to date in each client in the area when they use abilities or you'll have characters hit with scorching rays who are clearly behind an object just because someone is lagging. Lag switching would be an issue in this case, for sure.
EDIT: Cover (+AC) and Concealment (miss chance, stealth) checks could be done very easily using this method, but again they should be done server side. You could minimize potential problems by transmitting just those three points and doing all the calculations server side, but you'd also have to take into account terrain so you'd have to source map data as well. The more I think about this, the more it makes sense to run another instance of Unity in the back end just for calculations and synchronization of data, unless there's some sort of resource that already does a lot of this stuff.
|
Goblin Squad Member
|
Would there be some way to distinguish hard cover (relatively static environmental obstructions) from soft cover (a fighter dancing briefly in the way)? It'd be really annoying to have players getting "No line of sight to target" because someone else sprinted across the path for the tenth of a second you hit the button.
|
Goblin Squad Member
|
@Dario: Well, there are two mechanics in Pathfinder that are similar - Line of Sight and Line of Effect. Basically, LoE is no solid object obstructing more than a certain portion of your target while LoS is also blocked by non-solid things like clouds and such. Some abilities rely on LoS while others only need LoE and still others (Clairaudience) don't need either.
In your example, that fighter would block both LoS and LoE because the moment you used your ability he danced in front of you and you no longer had a straight line between you and the target. Goblinworks could mitigate this by using the forehead point as a source for LoS but all points as sources for LoE, but that's not entirely in line with the purpose of LoE in my opinion. I think in your example you would just have to hit the button again once you regain LoS/LoE.
|
Goblin Squad Member
|
Yes, but that also turns ranged combat into a twitchy, latency prone pop-up target game. If, however, the game can distinguish between hard cover and soft cover, and provide a boost to AC (or whatever the hit calculation is derived from), then the ability still fires, but has a lesser chance of hitting, vice the player having to sit there slapping the button over and over again hoping to get lucky enough that they're in line of site for one of the presses while their character stands there watching the battle doing nothing.
|
Goblin Squad Member
|
@Dario: If a character is in melee combat, in Pathfinder that gives a -4 to hit to anyone using ranged attacks, including magic rays. I think this is more like what you're talking about, and there are other ways to calculate this (for example, with a boolean MELEE flag that could be more easily calculated without using line tracing). In terms of preventing ranged attacks from even being able to execute, though, you have a point. Maybe if any of the points are visible then you have LoE at least, which would translate basically to a lower chance to hit (because of cover rules) if your fighter is blocking your shot, but you'd still be able to execute your ability unless it was completely blocked. I think that's pretty realistic and acceptable.
Goblinworks Executive Founder
|
We've moved from a discussion of how to determine LOS cheaply to a discussion of why to determine LOS.
I'm not going to add to either, because I don't know enough to contribute to the former and I think the latter will devolve into appeals to the rules of Pathfinder instead of a discussion of the effect of a proposal on PFO. I just watch all of the threads here, and another train wreck makes that much more painful.
|
Goblin Squad Member
|
| 1 person marked this as a favorite. |
Seamless Zoning
So the topic of seamless zoning has been touched on in a couple places, the most recent of which was during the live broadcast at the end of the Kickstarter. I've been thinking since then of ways to accomplish this, and I don't think WoW's model will work. Seamless zoning is important for immersion, and while EVE has the excuse of needing to use warp travel to go between star systems, PFO doesn't have that luxury. That's why it's especially important for PFO to have seamless zoning.
Since this is going to be a single server, everyone will be in the same world and zones will have to support potentially hundreds of people or even more for some hubs like the NPC towns or some very large settlements. One way to accomplish seamless zoning is to preload every zone that connects to the one the player is in so that when they move to the next zone it will already have loaded it and will just load the next zone(s) before they can get to the other side.
Since PFO is going to use hexes, almost every hex will border 6 other hexes. Loading 7 hexes is going to be hugely taxing on systems to the point where you would basically need to have an SSD for even the most remote hexes and also a great connection to the server cluster for well populated ones.
I wonder if it's possible to overlap hexes somewhat. Draw a band, something like 5% of the width of the hex, around the perimeter of the hex that is loaded when a neighboring hex is loaded. The band will have to be big enough so that draw distance is included. Actually, since it's common for spells to have a range of "long" (400 ft + 40 ft/2 levels) it'll probably have to be 800 ft minimum regardless. If the band is entered, the next hex is completely loaded so that by the time you get into that hex you'll essentially be in a zone that is 2 hexes big. The most this would ever get is 3 hexes if you hover around the vertex of a hex. If low res textures are loaded by default until complete and then they switch to high res if that option is selected, this would most likely be possible with no indication to the player besides noticing low res textures if their system is slow enough. Of course, the band width could be tweaked and tested to find the optimum size.
So here is what would happen in order:
- Uthreth is in a hex, and his system has loaded 800 ft into each of the neighboring 6 hexes
- Uthreth walks toward the edge of his hex, until he gets to 800 ft from the edge
- The next hex is loaded
- Uthreth continues walking, and crosses over to the next hex
- The previous hex remains in memory because he's still within the 800 ft band (of the new hex)
- Uthreth continues walking, and exits the 800 ft band in the new hex. The old hex is removed from memory except for its band, and the band for all 6 of the hexes that border the new hex has been loaded
Everything mentioned until now has to do specifically with textures and the map, and not with dynamic objects such as players and monsters. Likely not all dynamic objects in a hex will ever be loaded at the same time, so these have to be treated differently when moving from hex to hex. For objects within the same hex, the normal dynamic object loading code will occur with no difference and no problems related to zoning. However, when a player is within that band that borders the hex, sometimes dynamic objects within the band of the next hex will have to be loaded. This is where synchronization will have to occur between shards in the cluster, but since we're only concerned with what is in the 800 ft band it shouldn't be too much strain. Problems might happen when there are armies clashing along the border of hexes, but since settlements are in the middle of each hex that should be kept to a minimum, I imagine. Even more so if armies defending a settlement get a bonus while in that settlement that's enough for them to pull back to the settlement instead of meeting on the road. Also, priority can be given to band synchronization over other operations to mitigate the potential problems.
In EVE, when there was a large fleet battle the devs would redistribute the load so that the system where it took place would be able to handle more than usual. It didn't always help enough, but it did help some and this kind of proactive tuning could be done in PFO as well. It would be trivial to set up an alarm to notify the devs when more than X number of people gathered in a hex, presumably an army about to begin the march.
|
Goblin Squad Member
|
There definitely needs to be a "buffer zone" around each hex, so you don't constantly load back and forth as you walk down the line.
Or better yet, load 7 hexes at a time. Then, in the background, drop any loaded hexes that are now 2 hexes away, and load any unloaded hexes that are 1 hex away.
|
Goblinworks Executive Founder
|
There's two aspects to 'zoning'- one is loading the terrain, textures, and other static content into memory from storage. The other is loading the characters, buildings, and dynamic content from the server.
Both types of content only need to be loaded out a little bit further than the draw distance of the rendering device.
|
Goblin Squad Member
|
| 1 person marked this as a favorite. |
Use subhexes. Here's an example: http://i.imgur.com/38QCs.png
Red's the map hex, black's the hex(es) to be loaded. The subhexes can be divided more to reduce load. This can allow dynamic load balancing.
|
Goblin Squad Member
|
It's true that hexes would allow for loading smaller hexes better than squares would allow loading smaller squares because of the way the vertices line up. In this case, each hex would have to be at least 800 ft from side to side (not vertex to vertex) to allow for spell target range. That or maximum draw distance, whichever is greater. Alternatively you could load static objects from 2 hexes away and dynamic from 1 hex away.
|
Goblinworks Executive Founder
|
Both types of content only need to be loaded out a little bit further than the draw distance of the rendering device.If the load process is sufficiently quick.
If the load process takes longer than moving into an area which requires a new load, then things go bad quickly.
If the load process takes longer than moving to the area, there is no seamless solution mathematically possible.
|
Goblin Squad Member
|
That's not exactly true, or at least a little off the mark. If the area that's being loaded is smaller, theoretically you're loading less but more often whereas if you're leading the entire hex's static objects at once the load will be heavy but will only happen when you go between hexes. The static loading is done almost completely from the hard drive, as you wouldn't want things like dungeons and such to count as static for security reasons (someone could sniff packets or have a 3rd party map viewer to find the sites in seconds). So the tradeoff is with loading the entire hex your computer might slow down, which can be mitigated by having an SSD or lots of RAM etc. If we're talking about constantly loading 1-2 layers of hexes around you worth of static objects then the load on your system will be more constant with smaller jumps.
|
Goblinworks Executive Founder
|
The line in the sand was 'it takes more time to lead the static content needed than to walk past it'.
Consider Morrowind's overworld, which can be traversed at normal speed without noticing the seams; when using the alchemy exploit, your speed is basically unlimited, and you can notice the cell boundaries again.
|
Goblin Squad Member
|
A few things come to mind:
a) Pseudo-random isn't that expensive, i ran python script for 1s
and generated 2,754,483 random numbers. And even if you want
pre-generated numbers, just put them into ram. If they are stored
in db or anything like that, well, you could generate the number
just as well, given fetch latency.
As for faster generation, if I remember correctly, Quake 3 used
float overflows. :)
b) Unity isn't very golden server back-end as it is not thread-safe.
Sure, you can run threads but not interact with unity from those.
c) GW2 put everything into a gigantastic one file, for mechanical disks
to have better access to data and they could load faster.
Hmm. Now that I look this over, it looks almost like an attack towards Uthreth. Please don't take it as such :)
|
Goblin Squad Member
|
If the load process takes longer than moving to the area, there is no seamless solution mathematically possible.
Thus my suggestion for "buffering" bordering hexes and loading the hexes you can potentially move to in the background while you're still moving around inside the current hex.
|
Goblin Squad Member
|
If the load process takes longer than moving to the area, there is no seamless solution mathematically possible.Thus my suggestion for "buffering" bordering hexes and loading the hexes you can potentially move to in the background while you're still moving around inside the current hex.
The core idea of the point is still valid tho. Given enough speed, the game would need to buffer almost the whole world in a worst-case scenario.
But, as the speed is limited, buffering is the solution I think.
|
Goblin Squad Member
|
Hmm. Now that I look this over, it looks almost like an attack towards Uthreth. Please don't take it as such :)
This statement came as a surprise to me, since it hadn't even crossed my mind. So don't worry. ;)
@Nihimon I think that what I laid out was basically a way to do just that. That is, buffering bordering hexes or zones so that the movement appears seamless.
|
Goblin Squad Member
|
@Uthreth, yes, the 800 foot buffer is essentially the same idea with different specifics.
If anyone has played Vanguard, you'll understand the frustration of needing to adventure where four chunks (square map areas) converge. It usually takes a few seconds to load, and there's no buffering so if you cross back, there's another handful of seconds. It's maddening.