DESMA 157B

Before beginning work on actually setting up this game, I wanted to learn more about the physics solution I want to use with it.  In probing around Farseer’s documentation, it became clear that it uses many of the same techniques as Box2D, and references heavily Erin Catto’s work with Box2D and other physics engines.  I don’t plan to do any real modification to the engine, but reading the powerpoint presentations was a great starting point for a trek through wikipedia that was way over my head.  The general understanding of the contact points and attempts to resolve them using constraints, however, I believe will be useful when trying to debug physics glitches over the course of the project.

When reading about Delegation in particular, a design pattern that I was totally unfamiliar with, I came across a thread that others using Farseer, especially non-technical people, may find useful.  The code in that thread is slightly incorrect.  The name has been updated to “.Collision” not “.CollisionHandler”.  But the concept is probably new to people coming from Processing.

.Collision isn’t a value, or an object.  .Collision is actually a reference to a function.  And you can make that reference point to your own function if you want.  Every Geometry object in Farseer has this .Collision delegate, and you can assign any function that takes the same parameters to it.   Then whenever the code would call .Collision, it calls that function instead.  This function can live anywhere, such as in the class for some sort of Game Object, and have access to all of that class’ variables, even though the Geometry has no knowledge of them.  The main purpose of this, is the ability to set a variable local to a game object when physics objects collide, allowing you to detect collisions in game logic.  This pattern strikes me as a great way to give people access to deeper levels of a large system without breaking encapsulation, and I want to integrate this into my Particle System.