Wrapping Things Up



Mmmm… Shepherd’s Pie!! I know, you probably don’t want to hear about what I’m chewing as I write this blog but damn. I LOVE me some Shepherd’s Pie! Anyway, back to our game. Last time we left off with a list of bugs that needed to be fixed and some features to add/change. That list looked like this:

 

 

1. Fix crappy controls

2. Add angular control to the ball

3. Fix crappy collision

4. Add a pause function

 

Before I forget, the current source code for our game is here.

     …Here’s where I learn an unfortunate lesson. Now that I’ve gone back to look at
the source code to blog about the changes I made I just realized I don’t know exactly what was changed since the last time. I made very poor decisions in the organization of my code. Before I go on anyfurther let’s just go over some of the changes that I did make.

First of all I fixed everything on our list. On top of that though, I also added mouse control to the paddle, so if you play the game you’ll have no idea if I fixed the crappy controls unless you comment out the section of code that is
responsible for mouse control. There were also a few glitches that were almost game breaking. sometimes the ball would get stuck in the top or bottom wall. Because of how the AI is handled, this ment you had to let the ball score on your side to get it out. This could meen losing if the
AI paddle’s score was 4. So that also is fixed.

If you go to this link , it will take you to the game and you will see that it is actually a pretty functional game. Definitely a lot better then it was when we last left off. However functional code is not always good code, and my code is terrible. This is my first app using processing.js and It’s also my first app written to be uploaded to the internet. I didn’t know how to properly organize my code in processing before starting this project. That’s why all of our classes are jumbled up in one big file. I also used poor practices by not commenting the code properly, and since I went a few days without looking at it, the code has become cluttered and hard to read.

The final and biggest mistake I think I made while doing this blog though is not saving multiple instances of my code as I progressed. I should have had files relevant to each blog post so I didn’t have to sort out what changes I made since the last post. If I did this, I would have easily been able to look at the relevant changes to the code for today’s post, and then update the more resent changes after.

This blogging / tutorial thing is going to require me to be a more careful programmer. I think it’s also required of me to keep the distance between posts much shorter, so that next time I don’t have too many changes to the code by the time I post again.

Sorry for anyone who actually stumbled across the blog hoping to see this through to the end. I will keep the source code up for the game so that you can still learn from my algorithms and use them when creating your own projects. Just note that there are better ways of keeping code clean and maintainable. Having maintainable code is a must when developing anything even if it’s just a small project like pong. Learn to comment effectively and document major changes to your code so you can always go back to previous builds.

If your interested in learning good programming practices I strongly recommend watching Stanford’s CS106a on YouTube. It’s all about programming methodologies, and you will learn java along the way if don’t know it already. The playlist on YouTube is here.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Show Buttons
Hide Buttons
%d bloggers like this: