Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

119 Neutral

About BrickedKeyboard

  • Rank
  1. I've read that article.  By "to the millimeter" I'm implicitly referring to precision issues.   My plan is that the only client side physics is between player models/small objects and the environment.  All large vehicles would be server side physics.  Instead of simulating in lockstep, only the server does the heavy lifting, and it informs the clients of (1) end position (start being implicit) (2) net forces at start and endpoint (3) intermediate collisions By making the server the arbiter, bugs like false collisions don't happen.  Any collision a client renders is real.  Errors in client interpolation would lead to clipping, however.  This also means I don't have to reduce performance with the kinds of tweaks needed to make floating point math work the same on a variety of CPUs - only the server does the calculations.  It means that clients do not need to be aware of all the same information the server is aware of.  It means that the resynchronizing is easier - the minimum information a client needs to be aware of are essentially the fine environmental details near the client and any "local" forces.  (if a client is onboard a spinning space station, it only needs to know there is a velocity dependent acceleration vector (coriolis force) and a constant acceleration vector (centrifugal force)) It frees up CPU and memory on the client, making it easier to port to consoles.
  2. What?  What does network IO rate have to do with rendering frame rate?  You are supposed to decouple those.  A certain number of times a second your network code gives you the state of everything, then you are supposed to interpolate between states for each rendering frame.  The network IO rate can be anything, it's completely separate from frame rate.
  3. Game Environment : Large, traversable vehicles similar to Space Engineers. Networking Solution :     For Vehicles : Vehicles are under direct on-server computer control.  Players can adjust settings on the vehicle but ultimately fine control is from the computer.  Players can update vehicle state controls.  On their client, instantly when a button is pressed, the state controls update to indicate the new state.  A small window of time exists where a player can "undo" a command and the command will "undo" if the message reaches the server in time.  As commands reach the server, the server incorporates these new command states into it's simulation of vehicle dynamics.  Then, the server sends back new update messages - basically a big message using TCP/IP that contains all of the new states for the game world in the future.  Server always runs about 0.5 seconds in the future.   Clients are always interpolating the game world knowing what the future state will be.  It's interpolation from a known past state, to a known future state.  The idea is to make all movements always correct, down to the millimeter - the client does physics integration per frame, while the server uses a different timestep period, and the client applies a correction factor per frame so that the end result always ends up in the given future state.     For direct client movement, P2P and PeertoServer UDP frames.  Every time a client performs a movement or use or tool switch command, etc, it sends via UDP to both all peers who are close enough to see the client and to the server any actions taken.  Clients then use future state prediction for player models and player shovable small objects only.  (future state prediction being inaccurate) .  (like many other games, every time the player performs an action, their client UDP spams both other clients and the game server with a UDP message every 20ms or so.  The message spam continues until an ACK for that particular UDP message arrives.  The server then UDP spams all clients who need to be "relayed" this message - so at all times the UDP link is being used between between both clients and between client and server so that there is the least possible latency between 1 client performing an action and another client knowing about it.  If a client has other clients blocked via firewall, the 100% packet loss in the link eventually causes a client to stop wasting bandwidth sending to clients who are not receiving.  Similarly, since firewalls can block UDP from the server, the TCP update frames also contain the same embedded data so that the data gets there eventually)    A consequence of this is that the player's model cannot ever block a moving object in game.  If a player is caught between, say, an elevator descending and the floor, the player must be crushed even if they are wearing indestructible armor.  All world objects are unstoppable as far as the player's model is concerned. To use TCP and UDP simultaneously like this I'll need a more clever throttling mechanism so TCP send rate is governed by UDP packet loss.     For larger environments and for handling of clients with limited bandwidth, there will also need to be a subscription system, where clients can subscribe to network events, limiting their subscriptions to stay within their network bandwidth availability, but that isn't needed to get a basic version of the game working.
  4. Ok, so as I understand it, Voxel farm basically does what I'm talking about.  And it's only like $300 a month for an Indie license.     But I'm trying to grasp the concept of what it does.   So you define "everything" in the world as equations.  The simplest being that a flat cube is defined as existing inside the bounds of the cube and not existing anywhere else.   Then you subdivide the world into cubes around the client doing the rendering.  These equations are "spatially partitioned" : you have the world divided into cubes or octrees, and in each cell of the cube or octree, you ask which equations apply in that space.   You then sample the points of the cubes (you sample at each of the corners and sometimes more) you subdivided the world into.   So you now have this 3d grid around you of "something exists here" and "this doesn't have anything here".     Places where there is a transition from "nothing" to "something" or from "transparent something<->solid something" are where the surfaces are.  There's then a couple of different algorithms for producing polygons that roughly follow these surfaces - the most famous being marching cubes.   You then just shove the big mess of polygons into UE4 or Unity and job's done.  A close friend did the last step, starting with an open source voxel library and shoveling it into UE4.     So, ok, suppose you want to add and subtract from this world.   You want to add a flat plate.  Smooth this world out.  So this is a new equation, defined to exist at the plate, and the coordinates of where the plate is in the world determine which of the "cubes" contain a reference to this equation.   You want to subtract a cone-shaped crater.  Similar, but now you take any points that fall inside the cone and if they are currently inside something, you change them to being inside void.     As I understand it, there's a way to sample a whole buncha times in a surface and to replace a series of unions and diffs with many additions and subtractions with a simple one.  Called like "hermite data" or something.  Or have a rule that only a finite number of changes are permitted in volume and you merge the 2 equations with the smallest volumes.  
  5. Game environment : a vehicle control game, where the player constructs large voxel contraptions and drives them around in multiplayer.   I'd like for players to be able to leave their seats and run around in the vehicles while they are moving.  I'd like the vehicles to be able to reach realistic speeds - hundreds of kilometers/second in the worst case - without any chance of players ever glitching through the floor or outside, etc, even if another player is at the helm.  I'd like for 2 player controlled vehicles, both "moving" at ludicrous speeds, to be able to dock in space.  I don't want there to be any visual glitches whatsoever - no warping, rubber banding, juddering, or the sky moving funny if one player is looking out the window while another player is on the helm.     I see one way to do this, but it has a cost and I'm unclear if this is the only option.   It's real simple.  Player updates a GUI that controls a vehicle.  It's indirect control - a player might click the mouse on the 'navball' to choose a new orientation, or choose a new setting on the throttle.   GUI updates instantly with a color indicating that the action hasn't actually started yet.   These GUI actions get sent via the usual UDP spam mechanism to the server.  (50 times a second you send a new set of UDP packets containing any unacknowledged actions).     Server updates it's internal state/sim model from the GUI changes.  Server now starts uploading to all clients a TCP message containing the new state of the game world, specific to the events each player has "subscribed" to.  (player client has mandatory things it must subscribe to, things within a certain radius of the player model itself, and other stuff is by request by the player client.)   The new state is set in the "future".  Clients now generate intermediate game states that are then used for rendering of the world, with the intermediate state series adjusted so it will always end up precisely aligned with the new state.   So the cost : input lag.  About 500-1000 ms.  Press a button to open a door?  500-1000 ms will pass, then the door starts opening.  Summon a lift?  Send the lift to a floor?  Adjust course on a spaceship?  All have a delay.   The benefit is that all players with pings below about 500 ms never see any glitches from the environment.  Everything is always exactly where it really is, synchronized with the server, and everything should move smoothly.  There would be no problems with doors or lifts when multiple players are using them, because every player shares the same game world in sync with everyone else.   Player models and things that can be affected by the player model in real time can't be done this way.  If you see another player in multiplayer, you are not seeing where they are now, just where your client is guessing they are (future state prediction).  So you would have to have the authoritative server pass through immediately in a separate thread any UDP state updates from other players.  P2P would be even better.   This makes small bouncing objects the players can shove around extremely problematic : I cannot think of a perfect solution for them.  Either they warp and rubber band and jitter to where the authoritative server says they are, or they have async and local which also creates edge case bugs.    
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!