Today, my day at the GDC2011 here in San Francisco started with the GDC2011 Dutch Business Breakfast. I met a few people from the Dutch game industry and also a few students who also got a scholarship from the Level-Up project to go to the GDC. What I found really cool and also kinda awkward were the one minute business pitches. In such a pitch someone can speak to everyone there and tell them what they need. Then later, people with the resource can talk to them to see what they can do for them. I found this really weird since these pitchers are not afraid to ask for half a million dollars.

The rest of the day I attended the Physics for Game Programmers tutorials. I did expect much of it because, well I will probably never build my own physics engine because its way to complicated with all the math involved. I have always just used existing physics engines because they always suited my needs. I did create a very simple physics engine for Mia and Momo but that was not very complicated compared to what I had seen today.

Of all the talks I attended today there were two that I found really interesting. The first was about how to network physics and the second was about fluid simulations. Especially the second got me thinking because I am thinking about a new effect involving fluid dynamics.

Networking physics

I didn’t really learn anything new here. I have looked at how to network physics before. Simply put the problem is how to sync the entire physics simulation over all the client computers in a game. This is a non-trivial problem because different games require different focuses. For instance in a first person shooter you generally want zero-lag meaning that when a player performs an action you immediately want to see the result of this action in the game. This becomes extremely hard when sending input to a server because then the client first has to wait for the the response of the server before it is able to continue with the physics simulation. This creates some lag between the input and when the input is processed which is very annoying in a first person shooter. In an RTS game however this might not be a problem.

This lag in the so called client-server model can be partially removed by also running a physics simulation on the client computer. This means the client is predicting what the server will send back as the new state. The problem with this is that the client does not have all the information required to run the simulation because it is missing information from other clients. This is solved by rewinding and replaying the simulation with the correct state that is received from the server. This however introduces a lot of overhead because replaying a few simulation frames can be very expensive. This technique is called client side prediction.

Another proposed method is by using a deterministic physics simulation. With this method the server (or a client) waits until it has received all information from the other clients and than updates the simulation using a deterministic simulation. This implies that the state will be the same at every client. The advantage of this method is that it is very cheap and takes up almost no bandwidth. The disadvantage is that there can be quite a lot of lag and that creating a deterministic simulation is a real pain in the ass.

Last but not least the speaker talked about authority schemes. This removes the need of an explicit server. A client simulates and distributes the state of some of the objects in the world. A client has for instance authority over its player and over all the objects it interacts with. The state of this (sub-)simulation is than distributed to the rest of the client using either a peer-to-peer model or a server. The nasty thing about this approach is that a player is now able cheat because the simulation runs on his own computer instead of on a trustworthy server. Also problems occur when multiple players interact with the same object.

So all and all it really boils down to what kind of game you are trying to network. For first person shooters where a few milliseconds of lag is a problem and where dynamic rigid bodies are scares, client side prediction is good solution. For RTS games a deterministic solution could work very well. There is no out of the box solution here, which is probably also the reason why physics engines don’t provide it.

Fluid simulations

The last session of the day was about fluids simulations. There was actually quite some math involved which I can’t reproduce right here. The reason why I found it interesting is because it is possible to run a fluid simulation completely and quite efficiently on the GPU using either CUDA or Compute shaders. The way it works is using particles that represent a small piece of the fluid’s body. These particles are then simulated on their own and during rendering they form a solid body again. This session gave me some insight in how it works but didn’t really thought me anything new. I had already seen most of the presented work in presentations like this one.

Well thats it for today again. Tomorrow I will be attending a broader variety of sessions. Also check our Marries’ and Emiel’s blog!