Server Talk
From Trinity Reign Wiki
(content thanks to HexiDave, HTT-Bird, amogorkon, Underthemoon, and Tucos)
Contents |
Server requirements.
Keep track of players and send messages to players keeping track of players
Depending on how much you want to have the player interact with, you need to know what the server is going to handle. The server is interested in: player position, player angle, player attempting to interact. When the player tries to do something, the server goes "beep" and tries to test against the physical realm that it knows. If the check fails, the client gets jack.
If you're using physics to handle terrain/world interaction, then you need to figure out HOW much physics it's going to do. Is it just going to detect collisions and ray-casting, or is it going to handle a physics simulation? Bounding box collisions or more advanced ones? Bounding box around the entire body sounds good enough for whole bodies bashing each other. Bounding Box collision types, you're just testing the bottom-middle point of the box, for the most part.We want 'real' physics motion. Object tends to stay in motion type thing. No instant stopping and turning on a dime. You can do basic physic on the server (track and flying body) and specific physics on the client (turn that flying body into a ragdoll.
Animation will be handled client-side. The easiest way to see the server-side simulation is a rectangular prism with a pyramid rotating around the middle and tilting up and down (for the camera's vision for interactions) and the prism slides around on the floor. That's it. The prism slides around using physical impulses. The player's animation on the client does its best to handle the "look" of slowing down and stopping and such. The server will likely track which direction the body is facing independently from the head and send that info to other clients. So you can see others 'look' around to some extent. That will add a key element to the 'there' feeling of the game.
<HexiDave> Well, before building the server, I'd build some simple unit tests - stuff like having the server know where the client is correctly, no matter what the client sends. Then make sure the server understands physics and visualizes it on the client-side (i.e. all-server physics sim test)
Climbing is just ray-casting against terrain. You'd probably trigger that as an event to "attach" to a wall face. Everyone loves 'glitching' up walls and stuff, so we might as well make it a feature. The server just would detect the slope and say "Slow down" and maybe tell the client that the steep angle is for climbing as a hint, but the client should know anyways. Then the client would just have low speed and a climbing animation.
As long as the player is in the correct spot in-game and on-server, the client can solve the other things (slope, spacing, angle, etc). They don't have to be 100% exact all the time between the server and client if position does not play a huge role like in FPS games.
There'll be epsilon values to determine whether or not to re-assert position for the player. So, the client would snap to the correct position or take another step in whatever direction if the server says they are not in the right place. The more common solution that scares players less is to just pop them into position and warn them of latency. With other players, it's sometimes better to try to interpolate the position over a few frames - having them run to the correct position is more correct. If the latency is terrible, they're going to see popping anyways. Don't worry about it. Focus more on stability and keeping the server running as smoothly as possible.
We have inertia physics with bounding box collision. Clientside correction for lag issues ('popping' or taking a step for other characters).
Partitioning the world.
As well as prioritizing operation speed for different partitions.
Basically, NPCs will be doing stuff all over the world all the time, but you don't need to keep an eye on that critter on the other side of the world from the players to see if it's bumping into trees at 60 updates a second.
The partitioning and speed part is tough sometimes. You need to have the biggest load on the server where people are looking or action is happening.
If you're planning a small server operation, it's not so bad.
If you statically chop the world up into even parts, you're going to have a lot of boundary hopping issues.
Static partitioning verses dynamic partitioning.
Which method is preferred?
HexiDave's suggestion: Server checks >distance from point. Points are dynamic. I'd clearly recommend against any simple partitioning - don't just slice the world up into a bunch of square chunks.
You populate the world with circles (or spheres) that determine where boundaries lies. You just dump these circles, overlapping if you'd like, to determine when a boundary is crossed. If you have a funky shape for a town, you can spread the circles out to cover where the zone actually is. The player is designated to the circle that it crosses - when it leaves that boundary, it'll do a boundary check again. If it goes into another one, it'll pass into that circle. If it's not in a boundary, it'll fall into an world boundary.
Now, in the wild, if more than one player are in a sizable area (radius check again), you can designate that a hot-spot. Just track that until it breaks. Reform again when needed. If the hot-spot gets too big (too many players chaining up or grouping) you can tell the server to push more power to that section. So, using density checks on these boundaries, you can pretty easily set up an algorithm to assign extra cycles to that area. The more action happening in that hot-spot zone, the more power it gets (up until a certain point, though - don't want to stop the rest of the world) This metric works, too, if players are attacking a city (or having a large party)
That way, you are designing the world the way you like - very specifically, too - and the server will pay attention to client interactions in the wild. You can stick these radii of interactivity onto NPCs, too. That way, if some player sets up a combat area for an attack or something, he can come back and it'll still be processing
Underthemoon's little addition: The rest of the world where players are not can revert to a predictive system. Say you have a bunny hopping around with no players within 100 miles. The server could just file that bunny away, predict where it could be in a certain set times, and randomly stick it somewhere around there when a player comes near enough to see it.
Hexidave on that: You could even just have its AI package update much fewer times - maybe once every few seconds. Make it move a yard every few seconds, rather than an inch every milisecond. Don't even bother with physics much, just make sure it's not falling off the world or going into the ocean or under a house. Very, very simple collision checks is all it needs. You could simply have the AI package handle that, too. Just check against object radii to make sure they don't enter that area.
Pretty flexible - you can easily play with the scaling metrics on the hot-spot radii. The nice thing about this method, too, is that it's thread-safe. You could easily separate these hot-spots/zones across a few servers, if you ever cluster up. The processing servers that would handle these would hide behind a firewall/router and would get sent through to clients.
Separation of World (movement), Message (chat), and AI servers.
A modular server is best if you don't have the money for a dedicated datacenter. A lot of games have just moved chat to IRC servers. Then just run the game separately and just have the client deal with IRC. If the chat server dies, you're still game-capable. If the game server dies, you're still able to bitch about it. If one of the AI NPC servers die, people can both play the game and bitch about it, and move to an area where the NPCs are still working.
AI
What does the AI need to know?
It needs to know how to get from point A to B in simple movement. It needs to know how to navigate buildings and such while attacking/fleeing others in the most complex movement situation. It needs to have flocking ability, as well as teamwork with other NPCs. NPCs wil have to find resources on thier own, assess risks.
AI processing will mostly likely have a multi-stage effect - basically, for long-distance pathfinding -> Short distance path finding -> Player interactions/behavior.
Hexidave has offered his A* implementation that functions over a quad-tree for navigation. http://www.filefront.com/15351113/AStar.avi source: http://www.filefront.com/15351227/AStar.7z
<Underthemoon> What about different terrain types, like water or swamp?
<HexiDave> You'd just calculate those for cost - A* algorithm (A-Star) works on how much it costs to move to different spots - the lowest score wins.
<HexiDave> So, swamp might add a lot where as a little bit of water wouldn't add much (you'd probably add score based on depth)
<HexiDave> Yes, exactly. Faced with not moving at all or moving slowly, the NPC will take the slow path (unless, of course, you tell it not to do that)
<HexiDave> The storage costs are pretty low for all this: If you use my setup in that demo, you have 8 possible directions (which can be smoothed out using curves) of integer scores.
<HexiDave> You only store the node tree as is visible.
amogorkon has suggested a hexgrid projected on top of all the world, simplifying pathfinding; calculate length of distance of "real path", not just ray. an often-used path would degrade from grass to mud, etc. http://www.azarentia.de/mediawiki-1.15.1/index.php?title=Environment#Hexgrid
<HexiDave> Hexagons aren't very programatically simple - seems like it'd be just as easy to make them radii (circles)
<amogorkon_> it could be generally applied for your approach of dynamically splitting up the world
<HexiDave> Ah, I just used squares and used corners in the calculation as well. Lemme get a vid, one sec.
<amogorkon_> i also was thinking of triggers attached to any field
<amogorkon_> to get proximity-triggers of sorts, without calculating the proximity really, just by an observer-pattern
<amogorkon_> also it could be used to keep track of movements/paths, for reactive landscape or self-improving NPC paths
<HexiDave> Yea, stuff like that is part of the AI package, to me.
<HexiDave> Stuff only the AI is going to be seeing and dealing with.
<amogorkon_> well, interactive landscape is a terrain-thing too
<HexiDave> As in, editing the terrain?
<amogorkon_> i was thinking of modifying the tiles, not the geometry, but yes
<amogorkon_> i would send out NPCs to test out random paths by simple rules, like ants
<amogorkon_> just keep track of paths walked by NPCs and players and drop them after a while if not used anymore.
Other Options:
- path-meshes
- Steering
AI integrated into the core server, in an NPC server, in group NPC servers, or each NPC as a seperate service?
- Single server
- Part of the core server parted out just as if it were another process with multithreading. If the NPCs crash, the entire server goes down.
- Single NPC Server
- Like PlaneShift. If the NPC server goes down, the main game stays up, but all NPCs turn into statues.
- Group NPC servers
- NPCs are placed in groups, which are each set to their own servers. If one group goes out, only those NPCs stop owrking, or another server can take over.
- Single NPC services
- Each NPC is its own service in a completely modular server architecture. NPCs can then be moved around on physical servers as load shifts. Basic, low cost NPC actions could be in one server (even built into the core) and more complex behavior on other services (threads or physical servers).
<Underthemoon> Would that be each as its own 'program' and possible thread on the server machine (or another physical server completely)?
<amogorkon_> like push an NPC-AI to another server if it's busy
<amogorkon_> MSI i think was the word
<HTT-Bird> basically, a SOA approach to NPCs
<HTT-Bird> which has the benefit of high scalability and flexibility in "what goes on what box"
<HTT-Bird> because the server itself shouldn't need much in terms of resources
<HexiDave> Partition the intelligence as best you can - have more advanced AI for combat, have something for path-finding, have something for long-distance path finding, have something for indoor (3D) pathfinding, then you should keep them as far away from each other as possible.
<amogorkon_> again, if you want to implement an ant, you won't need many rules or knowledge to produce "reasonable" behaviour
<HTT-Bird> combat AI differs from simple pathfinding AI differs from conversational AI
<HTT-Bird> yeah, a good pathfinding system is the heart and soul of an AI
Scripting
Scripting is pretty much up to whomever decides they wanna script. Choices are LUA or Stackless at the moment, based on an observer system. Tucos: i think telaviv had some stuff on this ..
