Monday, May 16, 2016

://BEGIN: Pong-esque

For my first game I have decided to create a simple paddle game. Mainly because the first issue of the amazing Pico-8 Zine gives you the code of a single player variant of pong to type-in. It was a great read for someone like me, because it explains what every snippet of code does. I was not just blindly typing some arcane formulas (as it was the case with 80s magazine type-in programs), but actually learning what each part of the code does.

Around an hour later I had a functional game! Sure, it was a super simple and nobody would look at it twice, but it was mine. I made that thing. For someone whose only previous programming achievements were a calculator and a hangman type game, both text mode only, this was a great feeling.

The code from the magazine covered just the basic gameplay. Press button to start, bounce the ball to get score. If you lose a ball, it just reappears and you play until you run out of lives. Once this happens, the game just stops. Done. If you are just starting your programming journey, I think things like this zine's tutorial are a great way to do it. Not only it slowly teaches you the basics, but it gives you something that you can actually play in short amount of time. Sure it gives you a really barebone product, but I think it was a brilliant tactic, because you will want to expand it on your own. After playing for a while I wanted to implement things like "Game Over screen" or ability to serve the ball from the paddle. I have willingly stepped into an uncharted territory, trying to code things on my own. To my surprise, I was able to implement few extra features the same afternoon.


First thing that bothered me was that the ball would just start flying on its own after you lost a life. Instead, I wanted to be able to hit a button to serve a ball after losing a life. That was pretty easy on its own: just add a variable (newball) that stops the ball from moving  after you lose a life. But having a ball just hanging in the middle of the screen wasn't fun either. Instead when you lose a life, I have put the ball in the middle of the paddle (ballx = padx+padw/2) and made it move with it (using the same formula for ballx that I use for padx when left or right cursor is held) until you hit a button to let it go. This would be very handy if I wanted to turn this game into a Breakout/Arkanoid clone (spoiler alert - I do).


The constant speed of the ball turned out to be very boring. Like "I would quit the game before I even lost a life" level of boring. So I decided to spice it up a bit. The speed of the ball in this game is basically how many pixels the ball travels each frame (4 vertical and 3 horizontal in the Pico-8 Zine version, kept in the ballydir and ballxdir variables). Knowing that, I just added 0.1 to both those variables each time the ball bounces off the paddle. Simple solution that made the gameplay a little bit better.


Another anointing thing was not being able to restart the game after you lose all your lives. I added a simple IF function that prints a game over message after the player loses all lives (lives<0). When the player hits Z (as directed by game over message) everything restarts: score goes down to 0, lives go up to 3, speed goes down to original values (that's something that I changed later to restart after losing a life instead, it made for a better game). The program changes the newball state back to the value that allows serving.  There was a bit of trial and error here (that still left a bit of iffy code behind that needs fixing), but I am glad I solved it.


To my surprise, bug fixing was actually really fun. It is probably because the code for this game is pretty short and simple, and, let's face it, this project is not really that important. I can see if I would have thousands lines of code for something else than a side project, bugs could be a real pain in the ass. Fortunately I have only run into few bugs so far. One when the ball would bounce multiple times while overlapping the paddle, the other would make the ball stuck on either left or right wall if you hit the ball "just right." Solving them was a bit of a process. I had to ask myself questions "why" this particular thing is happening and once I had the answer, I had to come up with some code to solve it. So far I think that debugging was the most rewarding thing when it comes to learning how to program. Knowing the syntax, even figuring out how to introduce new gameplay elements is great, but getting down to a root of a problem, and tweaking the code to prevent the program from doing it again will really put you in a programming mindset.

No comments:

Post a Comment