Blob Game Physics Project

This project was built off a previous physics project discussed here. So I already had some of the basics of a physics engine such as a physics object. The goal of this project was to create some sort of game using contacts, rods, cables, bungees, springs and mass aggregates. The first step was to create the contact system. This allows for contact generators to generate contacts and then a contact system to go through and resolve all of the contacts. For this game I went with a simple implementation of resolving the most important contact until all contacts were resolved or the loop went over the initial amount of contacts times two. From here it was time to create actual contact generators. The first one being the ground contact generator. This simply created a contact if the physics object went past a certain y value. With the ground contact it was important that our contact system handled something called a resting contact. We determine this by checking if velocity has changed. Once we determine it is resting we cancel out the velocity effects of the contact preventing the physics object from vibrating. That is pretty much all there is to the basics of contacts.

The next step was implementing the rods, cables, springs and bungees. This was pretty simple because we went over this in detail in class and had code examples in the book and the slides. From here we used rods to setup our mass aggregates. This was interesting because you had to be careful how you connected your rods or the object would not do what you expected. For this project I created a cube, a pyramid, and a tetrahedron.

Now that all of our physics was setup it was time to make the game. The first thing I did was add simple player movement to the player adding force in 4 directions based on WASD. Next I added a bungee cord to the camera and the player. I was able to get a pretty clean effect using a bungee cord over a spring and a significant amount of dampening. Without these tweaks a spring attached camera does not work very well at all. After the camera was working I decided to add collectibles and make them data driven. I made it so when you got into a certain range of a collectible it would attach a cable between you and one of the physics objects that was part of the collectible  shape. When a lot of objects are attached to the player it can be tricky to move around the game but that is just part of it.

Finally I decided to create a simple enemy AI. Once the player gets into a certain range of this AI it starts to follow the player. If it gets close enough it attaches a spring between the player and the AI. It then runs away from the player until it reaches the edge of the map. This makes it harder for the player to collect the objects needed to win the game.

Two Brothers Iteration 6

The first thing I worked on this week was a node graph generator. This creates a node graph with all of the connections that our AI needs to path-find effectively. The first step in this was creating the nodes.

The above image shows my first generation attempt. Here I displayed cubes on the nodes for viability. Basically what I did was given a start point, size, and distance between nodes create nodes in all directions based on that distance until we've reached the size. The next step from here was creating the connections.

The way I created connections this week was to check each possible adjacent position and check if there could be a valid connection. This method works but after doing some testing I think it would be good next week to try to connect to all other nodes rather then just the adjacent ones. In order to determine if a connection was valid I did a ray-cast from node to node to make sure there wasn't any collisions in between the two nodes.  This still wasn't enough to assume all nodes were valid.

I cut down on the nodes and connections even more. On creation I added collision box to the nodes and destroyed them if they collided with anything. And after all the connections were made I took the node closest to the start and checked if every other node could path to it. If the pathing failed I destroyed the node because it was invalid. This ended up creating the picture above of a much more reasonable node graph.

You might be wondering at this point how it would be possible to do all of these calculations during the game. Well you can't; it took up-to 30 minutes to generate some of these graphs. Fortunately after the graph is generated I can just pause the game and save the graph as a prefab. This way we can generate the graph for each level before hand and not have to worry about any creation time processing.

Now that I had my node graph created it was time to write the AI to follow it. I added path following to my AI control and created a wonder AI. The wonder AI just choose a random node and pathed to it. At first this caused lag issues on pathing but I optimized the path finding function a bit and limited the path length because there was no need to wonder to a specific point 100 nodes away. This fixed all of the lag issues. The AI still was running into everything and dying constantly because it did not do anything to avoid the trails or smaller obstacles.

So then as intended I knew I had to create some avoidance AI. I created rays in-front, above, to the left, and right of the player to check where obstacles were. In the event that an obstacle was in-front of me I checked for an open direction. I then avoided in that open direction. Once the opposite of the direction I avoided in was open I went back to what ever I was doing before. After a lot of tweaking of numbers and playing around with I got something I was happy with, for a start.

Finally I played around with actually being able to get the flag. The way this worked was I would path find to the flag until I was within a certain distance. Once I was within this distance I would just go strait for the flag. Once I got the flag I would just wonder. This worked well enough for getting the flag once but the AI was not able to pickup the flag again because his trail was in the same spot that he was aiming for making it impossible to avoid. This is something to workout in the future but overall I was happy with this weeks progress.

Solar System Simulation

My first game physics project was to create a solar system. This is a simulation of our solar system including the sun, 8 planets and the earths moon. Here is a video of the finished product.

In order to create this the first step was to create a physics system. The first part of this is just a basic physics object. I used euler physics for moving objects to make the calculations simpler. This works but it does leave inaccuracy that can affect the simulation. After adding the physics object it was important to add forces. The way I did this was have force generators, in this case a gravity force generator, that would be registered with each object pair. In this system each planet is registered with all the other planets. This allows gravity to affect everything the way we would expect. Once this system was done I needed to figure out the actual values I would use to setup my planets.

I used the precise orbital speed equation to figure out the planets initial velocity at the perihelion. I also looked up the values for each of the planets perihelion and placed the planets at those distances in AU. These calculations worked reasonably well for the sun and 8 planets but unfortunately this was not the case for the moon.

At first I thought that looking up the initial velocity of the moon would work. Later I figured out that it would need to be the combination of the velocity of the moon and the earth because the value I had looked up was relative to the earth and not the sun. Even this value did not work as expected, the moon would constantly get further away from the earth. This could be due to various inconsistencies within the system that were not easy to fix. Because of this I just played with the numbers until I got a moon that orbited reasonably around the earth. The values I have now allow it to orbit around the earth for a good amount of time but eventually it will still leave orbit.

Another challenge was choosing the sizes for all of the planets. What I ended up doing was having the sun be way smaller then it would be and have all of the other planets be relative to an arbitrary size for the earth. This was the only way the planets could be viewed in relative sizes and still us AU for distance. This allowed me to setup my camera to view all of the planets while still keeping some relativity. There is an issues with the moon, however, because it is so close to the earth it appears to be inside the earth because of the scale I used. This scale was not a perfect solution but I think it was ideal in showing off what I wanted to show off.

Two Brothers Iteration 5

This week I got the start of the AI working. I got a ship simply able to move to a point. I do this by finding the direction between the ship and the desired point and rotation towards it. I make sure to take the ship mobility into account so that it moves within the same constraints as a real player. I also started writing my A* path finding algorithm which will allow me to navigate the node graph.

Two Brothers Iteration 4

This week I spent primary on researching the AI. What I am thinking right now is using a node graph to allow the ships to navigate the map. This way they will intelligently move around big structures and obstacles before even getting close to them. On top of this I want to add a avoidance algorithm that allows the ship to avoid things that are right in front of him. The combination of these will hopefully leave to a ship that is able to navigate the map without instantly dying.

Two Brothers Iteration 3

Last week I spent a good amount of time working on the networking systems for the game. I integrated networking into the split screen selection system. This way players could join and see each other choose different colors and y-axis inverted over the network. I also spent some time working on the network initialization of players, sending inputs over and working on the movement of the player ships. I was getting close to a point to start showing the basic networking aspects but during yesterdays class we decided networking would not be worth it given our resources. As much as I enjoy networking I agreed with the reasons not to do it. Instead I will start to look into creating AI for the ships in the upcoming weeks.

Two Brothers Iteration 2

This week I started working on the networking aspects. At first I had some trouble just testing the build because I do not have a controller and there are no keyboard controls. Paul said that he was going to work on adding them this week. Because of that I spent the first week getting a feel for the code base and creating the background systems for networking such as the lobby system. Given this start it seams reasonable that I will have prototype networking up and ready two weeks from now.

Two Brothers Iteration 1

This is the first week I will be working with my new team, Two Brothers. Here is a video of what they had at the end of last semester.

The first thing my team asked me to do was look into weather or not networking is reasonable. There are some definite challenges given the nature of this game. Such as important twitch movement and having trails work over the network. I'll talk with lawson and keep these things in mind to see if it is reasonable.