Pong!

This week's main project was to tackle the arcade classic "Pong." Where as you probably know, you play a game of back and forth, trying to score goals, similar to air hockey. A very important discovery that my partner and I made was that you cannot move smoothly using "when key pressed" commands, and that it works better if you use "If key pressed." Not only does it move smoother, it is impossible to move both at once if you use the "when key pressed" blocks. The ball moves back and forth between the two paddles, it starts going at 90 degrees, and then when it comes in contact with a paddle, the direction is multiplied by -1, and by a variable called "Speed." Speed is determined by every 10 steps the paddle moves Rawspeed being multiplied by 2, and then having Rawspeed divided by 5 in order to determine speed. This is to make it so the speed of the paddle has a direct effect on the direction the ball goes. There are a few bugs with this, but the most noticeable one is that the ball tends to get stuck inside the paddle, and scores a goal even though the player shouldnt have had a goal scored on them. The most important thing I learned from this project is the moving function earlier, without that knowledge creating this game and other games in the future would be impossible.


W: Left Paddle Up
S: Left Paddle Down
Up Arrow: Right Paddle Up
Down Arrow: Right Paddle Down

Crazy Conversions!

This task involved creating a system that converts various units. We were only required to go from one to the other, but I made mine go both ways, except for on binary because I did not have time. The First two just used the simple equations for Temperature conversions and Distance conversions, but the Binary was where it got complicated. I was not sure how to make a way that you could type in the whole binary number with one go, and have that be converted, but I was able to get it to work with the enter one digit at a time method. Basically it asks how many digits in total (Up to 6) and it will set the ones up until where you chose to 0 (ie you choose 5, digit 6 becomes 0). Then it asks individually which digit is which, and multiplies those digits by the corresponding power of 2. From this program I learned that the "Brute force method" is not always the best way, and you can find yourself wasting hours doing something that you may all of a sudden realize could have been done in a much easier way, or in my case realize that you did it all wrong.

What an A-MAZE-ING Game!

For my final draft of the maze I kept all the mechanics from the original, and then added more levels. Level 2 is nothing new, other than I had to implement sprite shrinking and a new level. But level 3 adds an aspect that I did not see an anyone else's maze, and that is a key. Level 3 you have to first avoid a shark, which moves back and forth. Once you pass the shark you have to grab a key, which opens up a gate in front of the finish, allowing you to complete the level. If you do not grab the key you will be teleported back to the start of the level. The Key works by using a broadcast once the starfish touches it, which tells a thin yellow line in front of the finish to disappear once that message is recieved. In this maze I learned a lot about broadcasts. I had never used broadcasts before, but once I started they became very useful. I used broadcasts for when the sprite hits the wall in order to go back, as well as completing the level and the Key.


W: Step Foreward
A: Turn Counterclockwise
S: Step Backward
D: Turn Clockwise

SWARM

I had a lot of ideas for the swarm program, but unlike the others, I planned to have a bunch of sprites move randomly, and when they came within a certain distance of eachother one would become the leader, and the other would follow closely behind. This would have been done by having all sprites move to random areas of the stage. Then when 2 came within a certain distance, both would pick a random number, if they picked the same one they would try again until one is the leader. Then the process would repeat for all the random sprites until they are all lined up together. From this project I learned that the touching color option is often much more useful than the touching sprite option, because of a higher accuracy. And I also learned about the functionality of lists. I will not post the program here because currently it only has one sprite picking a random start point.