Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 11 Sep 2007
Offline Last Active Sep 06 2013 11:07 AM

#4990278 Voxel based world, best practice for sending information

Posted by on 15 October 2012 - 12:25 AM

I generally break my chunks/objects down into 3 basic categories:

1. Chunks that the client and server can generate identically with little to no shared information. (static chunks).
2. Chunks that are dynamic but don't tend to change much or at all once they are created at runtime. For instance, a terrain block that is created and never moves or changes state.
3. Chunks that are dynamic and change a lot (state info updates, position updates, etc). Player objects as an example. They change state a lot and move around a lot.

Then I build a system that can tackle these three major areas.

#4990277 Not sure if I can get into the game industry without a degree...

Posted by on 15 October 2012 - 12:20 AM

As a hiring manager, I can say that having a degree is not necessarily required, however you will have the burden of proof of showing your passion and capability for me to take a chance on you. I have hired and worked with some spectacularly talented individuals who did not have a college degree, but, they are few and far between and in all cases they exhibited exceptional and proven passion and capability whether it was in Art, Design, Production or Engineering.

#4990276 Fullsail Job market

Posted by on 15 October 2012 - 12:15 AM

From a hiring manager's perspective, I have hired and been pleased with graduates from both Full Sail and Digipen.

#4990272 Voxel based world, best practice for sending information

Posted by on 14 October 2012 - 11:56 PM

If the world generation is deterministic, the first optimization is to have the server share the generation seed with the client and have client and server generate the base map identically.

From that point, think about how often a "chunk" or "object changes.

If you have a world where objects/chunks rarely change once generated, then you can leverage a hybrid update range system where the player has an update range established in which change objects will be sent and then "remembered" on the server so they don't ever need resent BUT can be updated to the player in the event that object or chunk happens to change (so when the player comes wandering back they see the updated chunk even if they were miles away when the chunk changed.). This means chunks have to know who knows about them in order to update all players accordingly. This optimizes the initial loading of dynamic chunks that changed from the base generation since players are only sent info about chunks as they first come across them. Assuming these chunks don't change often, then, you never have to send the info for that chunk again once it's sent the first time.

If you have objects or chunks that change frequently, then you want to go with a standard update radius approach where dynamic objects are sent to the client when the player comes in range and then "forgotten" about when the player leaves range and resent when they come back in range. This strategy works well for objects that change a lot (like other players running around for instance) on large maps.