10

Problem: Objects in Box2D were registering collisions, even when they were not even close to touching. Specifically, particles of water were supposed to delete themselves on contact to anything, but thought that they were colliding with the nearby player as soon as they were created and instantly deleted themselves.

Impact: The player could not shoot, keeping them from playing the game.

Solution: We had created a custom collision listener to see when the water should be deleted, but forgot one important line of code: if(contact.isColliding){. Without calling this to see if the objects were actually, physically touching the collision listener would be called even if the objects were only near each other. Adding that line fixed the problem.  

9

Problem: Box2D was horribly limiting the maximum speed of objects, and colliding objects together was displaying odd behavior. The fire hose we were trying to create could launch water out at a trickle at best, and it was impossible to knock the block we had created with this water anyways. This was the case no matter how high we set the water’s initial velocity; it went the same speed at a velocity of 5 as it did at a velocity of 5000. Objects would also fall incredibly slowly. 

Impact:  Knocking over a house was impossible with this in place, and since the player’s running speed was just as fast as the water of his hose the game looked bizarre and stupid.

Solution: We were drawing the game to be exactly the same size as the object in box2D, unaware of the scale Box2d actually used. As far as the physics engine was concerned, all our objects were the size of a small continent and reaching terminal velocity long before reaching the improbably huge velocities we were assigning them. By scaling down every number given to the physics engine by 100 and scaling it back up before drawing it to the screen, the problem was fixed and all objects behaved normally.

8

Problem: A game made in the Box2D physics engine was displaying odd behavior. The player would hover above the ground at the start of the game, and occasionally blocks would fly off the screen for no apparent reason.

Impact: Since the game was still in the early stages of development, this error did not majorly affect game play, but it was clearly something wrong that needed fixing before the final version.

Solution: Through experimentation, we discovered the problem was some invisible boxes we had created at some point in the code. The player would start standing on it, causing the hovering. Actual drawn blocks would fly off at random if the layer accidently kicked the invisible block into them. By searching through the source code and deleting every unused body and fixture definition, the problem went away.

7

Problem: For a lab, we had to write a client to use a server given to us by the teacher. This server assumed that any messages received would follow a certain protocol (http protocol, followed by either n= or c= depending on what kind of message was being received, then the actual message). The client did not account for this and sent all messages protocol-less.

Impact: The server would attempt to determine the type of message from protocol that was not there, be unable to do so and would return garbage output as a result.  

Solution: The client had to be edited to include the needed protocols, and then the server and client could work together properly.

6

Problem: When working on a Windows 7 Phone game, many variables were uninitialized in some of the game object’s constructors, but because these variables were rarely used outside of the constructors, and in the constructors the variables passed in were used as is instead of being assigned to a global variable like they were supposed to be, this error was not found for a while.

Impact: The program would attempt to access these uninitialized variables and crash.

Solution: The constructors had to be edited to include the forgotten code.