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