Physics Rods, Cables, and Springs

Currently I have completed a simulation for Rods, Cables, Springs, and contact generators at the particles level. I noticed during the quick implementation of OpenGL and the graphics system built on top caused some frame-rate issues. I needed to go back and re-factor the way the images got processed and streamlined it into a class, which is more efficient for numerous reasons. In these pictures the player being the ball is following around a cube, put together of Rods, so that it doesn't lose its shape.

Above you see a diamond like shape that has fallen because it has 3 sides in the middle not 4. In a perfect simulation a 4 sided diamond would stand perfectly on a particle because all forces would hit equilibrium once it landed on the ground. As you look at the pictures the camera is slightly off of where the ball is and it's because currently the camera is based off of a physics object attached to the players. So sudden moves and stopping causes a little elastic motion for the player.  In the bottom you can see the wall which all physics object bounce off of including the camera. This iteration I also took the time to set it up by game objects which render, and physics objects which just update collide etc. This also increased performance, and allowed the camera to have physics without having to fake render anything. Current shapes that can be rapidly created by my physics implementation are cubes, triangular pyramids, and triangular diamonds. These can be quickly created by the level, just by creating and setting a center point and the width of the total object. It will figure the rest out and easily set-up cables, rods, or springs depending on what you would have wanted.

Physics Solar System

In our physics Engine class the past couple weeks we had to create a Planetary Simulation. This project also allowed me to get into OpenGL, and is the first time I have used it. In order to create everything I use a Force Generator which which takes scaled numbers to calculate the gravity equation G * (m1* m2) / r^2 r being the distance between them. In order to produce it on a screen 1 distance in openGl is the same as the distance from the Sun to the earth. As for Mass 1 is a solar mass so the mass of the sun. As well all planets are scaled properly except for the earth moon and sun. The Sun would eat Mercury and Venus if proper, as well the Earth is too large and you would be unable to see the moon. The initial distance is also the heliocentric position which is when it is closest to the sun. This location has a given velocity which is a percentage of the earths initial velocity which is given. If you failed to give an initial velocity in the y or z, it would just be all eaten by the sun. The velocities and accelerations on bottom are scaled by 10 ^ 9 so they can be seen on the GLUI. For this project I use GLUI for the UI and I use SOIL in order to load images into a graphics section of the planets and simple skybox.

The video software states that its running at one FPS, but that text is just an error with the video. It would be a lot worse at one FPS, because I have a DPF which is days per second because I have a game timer in my simulation. This way a loss in frame rate doesn't slow the simulation down itself. So when my when an update occurs it runs through the physics system, that many times between 0 and 150 which are the min and max. This way it does the math day by day instead of just doing it one large jump which would cause a lot of errors, both floating points and getting correct velocity and acceleration for each section. Since I am using euler physics there are errors overtime, some calculations were done before putting it into the system so it would round less and I could use doubles for maths, but save as floats. However there is some rounding and just using the general gravity does not produce a perfect simulation. If I was going to take this farther I would use Keplers' laws of planetary motion to create a better simulation, but it would have required a lot more time than I had.

Abyssi Production 2 Project

This is my groups production two final project. It is a horror based game with the player being reliant on his flashlight for everything. In order to play you use wasd to move, as well as shift to sprint, control to crouch, e to interact with objects like extra batteries generators and anything that can be opened. As we developed this game we gave the users shaders on all interaction objects, but the web format will not keep the shaders as of now and if you full screen doors may not fully open, our group is working on that as we speak.
I personally was in charge of the AI and a lot of game testing. I enjoyed and feel that how they two enemies came out went very well. One who is attracted to light if you shine it on him and one who is afraid of the light. Using A* node pathfinding I allowed designers to have the enemies only roam area's they wanted them to do as well as go to different spots every play through. The could place nodes around the whole map and dictate node maps that held whichever nodes they wanted. From this they would just give that node to an AI member and he only knew about that region.

Sights and Sound

In production 1 of early times I worked on another project that went extremely well and the group I feel worked flawlessly with each other. Again I worked with a another programmer. This time my other Programmer was Alex Beauchesne, my designer was Devon Case, and Artists were Kristin Darling and Caitlin Coon  For this project when something was needed or necessary our group never had a problem meeting or talking at all times of the day, which really helped this game which had just a few weeks get extremely far and work very well. We were told to make an educational game so what we went was, teaching children how to solve puzzles using another character which you switch between and eventually would be two player and each would help and control one of them. Each had abilities which the other didn't and these were strengths the other lacked. For this game we had a character who had earmuffs stuck to his air so he was technically deaf and the other had a bandanna over her eyes, so she was technically blind and they used the other member sense the lacked to make it through the course. The game progressively moves the player forward and has introductions and teaches the player how to use each player through the first few levels then requires the player to use the past until you get to a real level with no new activities and you are put to the test.

Bounce - Production 1

During Production 1 in school the final project we were given a lot more selection as what we wanted to do compared to previous assignments as well as a longer time period to go alongside it. So this put us more into a field of a small group of Programmers, Artists and Designers like we would when working in a company. The programmers were Jacob Ellenberg and I, Designers were Devon Case and Eric Teall, and the Artists were Noah Drayton and Stephen Baptiste With these added opportunities and freedoms compared to being told what to make it had its own pros and cons. My team was the only double programmer group for the class. My programming partner was Jacob Ellenberg. We worked very well with each other and worked together most of the time, but tended to work on what the other wasn't in order to avoid conflicts of the tree which made testing and updating much easier. As well this project was the first were we chose to use an outside library in order to do something for us. We used Box2D in order to do all the physics which allowed us to put more time into the game and features over creating a physics engine that worked specifically with all shapes that we wanted as well as adding proper physics. Our project was Bounce, which is a physics puzzle in which you need to collect a percentage of lights in order to move onto a new level and depending on how you hit a piece depends on how far you go, what angle, which means that the project would have heavily relied on graphics.

                     
          Also this was our first project that we have down on a sole touch device, we have made computer games and programmed for the Xbox 360 using XNA, but we have never done anything with touch. This added a bit of confusing topics and problems that would not occur if we were to do this on a computer. As well we tested on a computer emulator more then we did on the device we chose which was a nexus. The problem with this, is the computer can do a lot more than a smaller device could. For example an issue we ran into was it ran on the computer, but not the device at one point. The cause of this was we were reading in too many text files for the levels which caused the nexus to crash the app and we should have opened and used the files only when the player picked on them. We tried doing this at the beginning which works fine for the computer, but not for any device even if we switched to a phone. Overall this was an amazing learning experience and a great first opportunity to fully work with a team who had different ideas then your own. This was good one we had so much freedom that the drawing board was large and limitless and as a group between all roles we had to sit down everyday and talk about what we want to get down today, this week, and overall if we realize certain scopes were large or small. This also caused a bit of arguments, but nothing our team didn't overcome with ease. In the end we were extremely satisfied with our program and got a lot farther then expected in week one.

EGP 405 - 5 - Spacewar Clone Wars

This past Friday the 27th of September in my networking class we were introduced to our first full class game jam. Our job was to recreate the old Spacewar game for online. The first thing we had to do was split into teams of 2. My partner was Alexander Beauchesne. We decided to work with his past projects, which he has done a lot of background work already which he enjoys. This framework he has been working on has made our lives for this jam a lot easier than if we went with what we were given at the beginning of the semester. The hardest portion that we worked on was getting our explosions to collide both correctly and accurately. The way we were always having 4 shield taken away when we first started playing with this. We kinda knew why it was so, but we didn't know how to exactly fix it. First we threw in a joke that we could have a shield health of 160 and show that divided by 4. This technically fixed the issue, but we wanted to go back and actually look at it properly. When we changed the amount of collisions possible after explosion to 1. This caused the players to never lose any amount of health. If it was 2 it would take away 2. So we still needed to clean it up so it would work at 1. We worked with different ways to send packets in a hope that this would reduce the problem. At first we were sending all packets in a way that took up to much time and they weren't necessary every time we sent. Then we realized the collisions was being done in a scene of the explosions where it affects a player, but the player doesn't check. When it came down to it we realized we had a chance to fix it normally, but it would update a lot which meant we had to re work a lot of the project. We decided to go with shield is 80 / 2 because it loses 2 every time it gets hit. This "Hack" or "Feature" does not affect efficiency or any play-ability of our game. Although as programmers it hurts us, we decided for the well being of our health to move forward and produce the rest of the game. The easier parts of the game were getting the game play to work. We would spend more time making sure everything would work efficiently as well as focus on being ready for the bullet fix ahead of time and make sure we know that.

Alex's Blog
Pile's Blog