Download Arinoid with Sound. Requires Python and Pygame.

The sounds were taken from Flashkit, which I think is a fantastic resource for game developers looking for free sound effects and free sound loops for background music. There are many sound samples to choose from, and they are neatly categorized to make browsing easier. What makes browsing the sound collection fun is the site’s use of preview consoles, which allows the user to play sound samples on the page, with matching visualization. Once you find what you want, you may download the sound sample as an MP3 or as a WAV, which may be used immediately in your game, or edited using an audio editor like the highly-recommended Audacity.

Picking sounds for this project was a very interesting activity – there were so many sounds to choose from! I hope that my choices were okay .

I would really appreciate it, and I’m sure everyone would, if you know of a resource which can help game developers add sound to their games easily, just like Flashkit, and share it with us! Just leave a comment if you have something in mind. I suppose that these types of resources will be particularly useful for those who plan to join PyWeek 3 . Thanks in advance!

At last, video tutorial 4 is here! I would like to apologize for the terrible delay, and thank you so much for your patience!

You may notice some mistakes in the screenshots though – in particular when the code that converts between integers and floating point numbers is displayed. The highlighted code is correct, but the way that it appears in the following slides (without the float and int conversions) is incorrect.

The transcript for this will be available shortly, and the fifth video tutorial is in the works. Thank you so much, especially to all those who have left comments of encouragement! They really keep me going . I hope you find these helpful!

Source Code for Video Tutorial 4

The paddle image is contained in our sprite sheet. However, the image spans two tiles, which means that we cannot just extract the paddle image from the sprite sheet and use it as is. We have to get rid of the boundary at the middle. We can do this by extracting the left and right halfs of the paddle image, and joining them together. We will do these things without resorting to manual image editing. Since we want to be able to use the sprite sheet without manually editing it, we will do all the image manipulations within our program.

The first thing that we have to do is get the numbers needed to extract the left half of the paddle. We will pass these numbers to spritesheet.imgat, which will extract the image for us.

We also have to get the numbers for the right side of the paddle.

Let us write a function that will produce the paddle image. The first step is to define a surface on which we will have the finished product, the paddle. Our surface is 11 pixels in height, corresponding to the height of each of the half-paddles. Since the width in pixels of the left half of the paddle is 27 while the width in pixels of the right half is 28, we just have to add these numbers to get 55, the width of the entire paddle, and use this number as the width of the surface.

Then, we use spritesheet.imgat to extract the image of the left half of the paddle, then we blit the left half to the left side of our new surface.

Then, we do the same thing with the right half of the paddle, blitting the image to the right side of the surface. We do this by placing the left edge of the half-paddle image at x = 27. This ensures that both paddle images are seamlessly connected.

Then, we want to set a colorkey for our image, so that it will blend seamlessly with the background, instead of looking rectangular.

When setting the colorkey, we have to make one of the pixel colors transparent. Since the upper left corner pixel of the sprite surface is not actually part of the actual paddle, but a part of the background, we took its color, and set pixels of this color as transparent. Again, we use the flag RLEACCEL to make using the surface fast.

Finally, we return the paddle image, making it ready for use. And that’s it – we have a paddle graphic that we can use!

In pygame, game elements are usually defined by deriving from the pygame Sprite class. Let us define a Paddle class which we will use later on to make our paddle appear on the screen and make it move using the mouse. The __init__ method that we have defined here will be called every time a new Paddle instance is made.

To attach the paddle image that we have made earlier to our Paddle class, we set the image attribute of our Paddle class to our paddle image.

Also, we have to make our paddle aware of its surroundings, the world it is in. In order for the Paddle class to access the world it is in, which is actually contained in the variable arena, we can define the attribute arena for our Paddle class and set it to our arena variable.

In screencast number 1, we defined the variable all, which is a pygame RenderUpdates group, whose contents will be displayed on the screen. Since we want to make our paddle appear on the screen, we have to place instances of the Paddle class inside the RenderUpdates group all. We can accomplish this in two steps. First, let us define the attribute containers, which states the group or groups which we want instances of our class to belong to, and make this contain the RenderUpdates group all.

Whenever we derive from the pygame Sprite class, we have to call its __init__ method. We can pass the containers attribute to the __init__ method of the pygame Sprite class to make sprite instances belong to the groups contained in the attribute containers. Since we let the containers attribute of the Paddle class contain the RenderUpdates group all, this command will place instances of the Paddle sprite in the RenderUpdates group all. Since we have already laid down the game loop code in screencast number 1, simply placing instances of sprites in the group all will make them appear on the screen. So our paddle will appear on the screen!

To display pygame Sprite instances on the screen using pygame render groups, our Sprite instances should have two attributes – the image attribute and the rect attribute. The image attribute, which we have already taken care of when we attached the paddle graphic to the Paddle class, is the actual image which our pygame render group will put on the screen. The rect will determine where the image will be on the screen. To make the rect for our paddle, we just have to call the get_rect() method of our paddle surface.

Next, we have to determine where to place the paddle on the screen. Definitely, we want it to be at the bottom area of our playing field. To do this, we can set the y-coordinate of the bottom edge of our paddle to correspond to the top edge of the last row of tiles in the playing field. We do this by taking the y-coordinate of the bottom edge of the playing field, subtracting the length of one tile edge from it, and making the resulting value the y-coordinate of the bottom edge of the paddle image.

At this point, we can define the update method of our sprite. This method is called every time the update function of the group it belongs to is called. In general, this is the rendering group which contains all the sprites, such as the group named all in our code. Since we call the update method of the group all during every iteration of our game loop, we should expect this update function to be called once per frame.

For our paddle, we want it to follow the x-coordinate of the mouse to allow it to move along the bottom area of our playing field. To do this, we may set the x-coordinate of its center to correspond to the x-coordinate of the mouse pointer, which is obtained by taking the first element, which is indexed 0 as shown in the code, of the ordered pair corresponding to the position of the mouse, which is obtained by calling pygame.mouse.get_pos().

We are free to move the mouse pointer anywhere in the entire screen, even outside the playing field or even outside the game window. Of course, we do not want to see the paddle go out of the playing field even when the x-coordinate of the mouse pointer goes out of bounds. To restrict the paddle inside the playing field, we can use the built-in clamping functions of pygame. This particular piece of code restricts the rect of the paddle inside the rect of the playing field, ensuring that the paddle doesn’t go outside the playing field.

Finally, we can go inside our main function again and make an instance of our paddle, which makes it present on the screen and in our game. We store our Paddle instance inside a variable so that we can easily access it later on.

And we are done! Finally, we have put a sprite on the screen, and we actually have something that we can interact with. Adding other game elements, which are usually represented as sprites, should be easier for us later on, since the procedure should be more or less similar to the one we did here.

I would love to hear from you! I really encourage you to leave a comment on the site. For the next screencast, we will be adding the ball to the game, together with some basic physics. Thank you so much and I hope to see you again for the next screencast!

screencast 3 source

Let us define a Spritesheet class, and the first thing that we want it to do is load the sprite sheet file.
Since the file we want to load is in the data subdirectory, we can use os.path.join to describe the location of the file in a platform-independent way. This means that the code will work regardless of the operating system that we use – Windows, Mac OS X, or Linux.
Let’s not forget to convert the image to the correct pixel format so that using it will be fast.
Let us define the method imgat, which will allow us to extract subimages from the sprite sheet. This method takes two arguments – a rect which describes the region we want to extract, and the colorkey, which will allow us to make the background transparent. Making the background transparent is very useful in games, because we want our graphics to blend in seamlessly with the background, instead of retaining their solid background, which makes them look rectangular.
Note that we converted the rect argument into a Rect object. This will allow us to pass 4-tuples, representing the upper-left corner and the size of the subregion, instead of actual Rect objects, to the imgat method because converting the 4-tuple into a Rect object is already done for us.
Then, let us make an empty pygame Surface, and convert it to the correct pixel format. This is where we will place the image that we want.
Then, let us transfer the subregion which we want from the sprite sheet into our blank image.
By default, we will not make the image transparent. Passing the parameter -1 will make the color of the upper-left pixel of the image transparent. This is often the case. Otherwise, we can specify the color which we want to make transparent.
Finally, let us apply the colorkey. We used the flag RLEACCEL to make using the resulting image fast. And we’re done!
It can also be useful for us to extract many images from the sprite sheet at the same time, and store all the resulting images in a list. Let us define the imgsat method to do this. First, let us make an empty list which we will use to store our images.
Then, we simply use imgat for each given rect, use the same colorkey for each image, and store the resulting images in the list. And we’re done!

By the way, we should import the os module as well, so that we can use os.path.join when we initialize the Spritesheet class.
The Spritesheet class is a general-purpose class which we may paste into our barebones pygame application. We will definitely use this class again in our future projects.

Let us define the Arena class, which will represent our playing field. The constant tileside, which contains the value 31, represents the width and height of the tiles in our sprite sheet. You can obtain this value by opening the sprite sheet file using your favorite image editor.
The numxtiles and numytiles correspond to the width and height of the playing field in tiles. This means that our playing field will be 12 tiles in width and 14 tiles in height.
Finally, it is useful to define a rect object which will correspond to the actual playing field. The upperleft corner of the playing field is one tile away from the corner of the screen because we can use the resulting space to draw a border around the playing field. The actual size of the playing field is then computed by multiplying the number of tiles to the size in pixels of each tile.
Note that having a tileside of 31 is a bit strange, because the dimensions of the screen, 640 by 480, are not divisible by 31. If we try to fill the screen with 31 by 31 tiles, using only whole tiles, you will see that there will be extra space left, corresponding to the remainder when you divide 640 by 31 and 480 by 31. So it would be good if we could make some adjustments to center the image on the screen, which we can do by evenly distributing the extra space around the screen as a border.
To do this, we must first determine the number of tiles that will fit in our screen. We do this by dividing the width of the screen by the tile size and the height of the screen by the tile size. Since both values are integers, the divisions will result in integers as well, leaving out the fractional part. Performing these divisions will give us the exact number of tiles that will fit crosswise and lengthwise.
Then, let us multiply both by tileside, so that we will get the width and height of the region if an exact number of tiles were used. This may surprise you initially, because it may seem that you just cancelled the effect of multiplying tileside. However, remember that the fractional part was discarded during the previous division, so you should end up with a number that is less than or equal to the original width or height.
Then, let us subtract the value that we currently have to the original width and height. This will give us the remainder, or the amount of extra space, when you divide the width or height by tileside.
Finally, since we want the border to be evenly distributed around the screen, which effectively centers the image, we divide the remainder by 2. This ensures that the amount of space at the top is equal to the amount of space at the bottom. The same goes for the extra spaces at the left and at the right.
To apply the border, we add topx and topy to the coordinates of the upper-left corner of the playing field, which moves the playing field by the computed amount, centering the screen. That does it for centering the screen!
Let us now draw the background. Let us define a pygame Surface as large as the screen.

The background elements will come from the sprite sheet. Let us make a Spritesheet instance using the Arinoid graphics sprite sheet.

The background graphics are contained in this part of the sprite sheet.

To extract one of the tileable backgrounds, we need to know two things about it: the coordinates of its upper-left corner and its dimensions. You can use your favorite image editor to do this. In my case, I used The GIMP, a free image editor, and used the Crop and Resize Tool to determine the information that I need. Here, we see that the upper-right corner of this purple tile is at (129, 321), and its dimensions are 31 by 31.
All we have to do is take these numbers and use imgsat. As you can see, I used the numbers corresponding to the coordinates of the upper-left corner of the tile and the dimensions.
Then, we just do the same for the other background tiles.

The next thing we have to do is draw the background of our playing field using the tiles we have extracted from the sprite sheet. For this, let us define the drawtile method, which will draw an individual tile at the given place. For this, we just use blit, blitting the given tile image to the coordinates shown in the code. By multiplying tileside by x, we will get an exact multiple of tileside, which allows us to blit tiles which are situated exactly beside one another and do not overlap or have any gaps. By adding topx, we are making sure that the border that we constructed awhile ago to center the screen is followed. The same goes for y.
To make the background, all we have to do is use drawtile to lay down each tile individually in the proper place. We do this by using 2 for loops. Take note that we added 1 to both x and y, so that we will have space left for the border, just like when we constructed the rect for the playing field.
makebg takes the argument tilenum, corresponding to the tile color which we want to use. Recall that we placed 5 tile images with different designs in the list tiles. All we have to do is index this list, using the index of the tile image which we want to use. We made note of these indices as comments, as you can see at the bottom right of the screen. 0 corresponds to purple, 1 to dark blue, and so on.

Next, we have to make some changes to our original background code. We have to replace the highlighted code, which drew our blue background in the barebones pygame program, with code that will draw our playing field background.
Since all the background code is in the Arena class, all we have to do is make an Arena instance, then use its makebg method. Here, we used 0 as an argument to draw a purple background.
Then, we just have to change background to arena.background, since the arena instance stores the background image in its own background variable.

We have to make the same change in the clear part of our game loop.
And we are done! Although it may seem that we had to do quite a bit of work to do something as simple as this, we have actually written some code, in particular the sprite sheet code, which we will have to use later when we add the other game elements. At the same time, we have also tackled some of the principles behind drawing tile maps, which will come in handy if we decide to make tile and map-based games later on.
I’d love to hear from you! I highly encourage you to leave a comment on the site if you have any questions, comments, suggestions, or anything at all. In the next screencast, we will add the paddle to our game, and look into simple mouse handling. Thank you and I hope to see you again for the next screencast!

If you want to follow along the screencast, you will need an image editor that will allow you to select subregions of images and get the size and location of the selected subregion. To do this, I use The GIMP, a free and full-featured image editor. Of course, you can use any image editor that you’re comfortable with. In fact, I would love to know about your image editor suggestions !

By the way, once you view the screencast, you may notice that I select regions using The GIMP’s Crop and Resize Tool. Although it does the job, I still think that there’s a tool that’s more appropriate for the job. Can you help me out on this ?

I know I haven’t posted the transcript for the first screencast yet , but I plan to do so soon, and the same goes for this screencast .

screencast 2 source

First, let us import the pygame module, to make the features of pygame available to us.
Then, let us place the most-commonly used pygame constants into our global namespace, so that they can be easily accessed.
Then, let us define our main function.
We have to initialize pygame before using it.

Then we have to make our window appear. Let us define the variable SCREENRECT, and it will just contain a Rect object defining a rectangle whose upper-left corner is at (0, 0), and whose dimensions are 640 by 480. Having a Rect object to represent the screen will help us later on when we actually have to put things on the screen.

Then, let’s call pygame.display.set_mode, passing to it the size attribute of SCREENRECT, to initialize a 640 by 480 window.
By now, we’ve already done what we want – display an empty screen. However, it would be better if we already prepare the stage for our game by adding a basic game loop, so that sprites may be easily added later on.
We need to accomplish 4 things:

1. We have to make a background, keep a copy of it, and display it on the screen.
2. We have to define a sprite group which will contain the elements of our game, such as the enemies, the player, etc.
3. We have to make sure that the game’s speed is just right by keeping track of time using a pygame Clock object. And finally,
4. we need to have a game loop, where all the action in our game will take place.

Step 4 can actually be subdivided into 5 more steps.

1. We need to read the keyboard and the mouse for input, and act accordingly. Animation takes place in steps 2, 3, and 4.
2. We have to clear the sprites. Then,
3. we have to update the sprites. This is the part where we make things move, execute enemy AI, etc. Then,
4. we redraw the sprites on the background. Over these three steps, movement is achieved. Finally,
5. we have to time each loop iteration by using the Clock object we defined earlier to make sure that our game runs at the right speed. For this project, let’s make sure that our program runs at 30 frames per second, just like TV.

At the end of our code, let’s just add this line which will ensure that our program will actually run by calling the main() function.

Let’s take a step back and fill in the comments with code.
For our background, let us make a pygame Surface object as big as the screen. Then let’s call convert to ensure that’s in the correct pixel format so that things will run fast.
Then, let’s fill the background with the color blue. We can do this by using the fill command, passing it a triple representing red, green, and blue values from 0 to 255. Let’s set the last coordinate, corresponding to blue, to 255, while leaving the other two coordinates at 0.
Then, let us blit the background to the screen. We want the upper left corner of the background to correspond to the upper left corner of the screen, to ensure that the two will completely overlap.
Finally, let’s update the display. This has to be called everytime we want to make the changes that we make to the screen visible to the user. Having this is a good thing because this will prevent the user from seeing the screen while it’s being updated. This is similar to how a stage play works – in most cases, the director wouldn’t want you to see the mess that happens onstage when changing props.
That does it for the background.

Next, let us declare the variable all, which will contain a pygame group, in particular, a RenderUpdates group. The variable all will serve as a list which will allow us to keep track of all our sprites. RenderUpdates groups have special properties, which will be discussed further later on, that, in some cases, may allow us to make our game faster.

Then, let us define a pygame Clock object, which will allow us to manage our program’s frame rate during the game loop later on.

It’s time for us to make our game loop. By using while 1, we have made an infinite loop which we can get out of by using the return statement. So we have to make sure that we’ll be able to get out of this loop.

To get input, we will look at the pygame event queue by calling pygame.event.get(). This will return a list which we can go over using a for loop.
We are mainly interested in events related to getting out of the main loop – meaning, quit events. We want the user to be able to quit by clicking on the X button on the upper right hand side of the window, so we want look for a QUIT type of event.
Also, we want the user to be able to quit by pressing the Escape key. So we have to look for a KEYDOWN event, and if such an event is found, we want to see if the Escape key was pressed.
If any of these events take place, we return, bringing us out of the infinite loop, and ending the program.
It’s time for animation. Going back to RenderUpdates, this type of group makes animation very easy by providing methods which correspond to the three things which we want to accomplish – clear, update, and redraw.

To clear the screen of sprites, we just have to use the clear method. We have to pass it the screen, so that it will know where it has to clear, and the background, so that it will know what to paint over the sprites to clear the screen.

Next, we want to update all the sprites. Since all the sprites are listed in the variable all, we just have to call the update method for all. This method conveniently updates each sprite in the group all.

Finally, we have to redraw the screen. We do this using two lines of code. First, we call the draw method to redraw the sprites contained in the group all on the screen. Since this is a RenderUpdates group, calling draw returns a list of regions which changed on screen since the last update. To save on time, it would be helpful if we just redrew these regions instead of redrawing the entire screen.
So we store this list in the variable dirty, since this variable contains “dirty rectangles” or the regions which have to be redrawn.
Finally, just like when we made the background, we have to call update to make the changes visible to the user, but this time we pass to it the dirty rectangles so that it will update only the regions which have changed, and leave the parts of the screen which were not changed untouched.

Then, we use the tick method of our Clock object so that one loop iteration takes a 30th of a second, which makes our program run at 30 frames per second.
And we’re done! It may be difficult to appreciate the work that we have put into this program, because we haven’t put anything on the screen yet. However, by making provisions for sprites this early, adding sprites to our barebones program should be much easier for us later on.
If you have any questions, comments, or suggestions, or anything at all, please leave a comment on the site. Thank you and I hope to see you again for the next screencast.

With this in mind, I’ve prepared a video tutorial explaining how to make a basic Pygame application from scratch. It’s only 2.3 MB, and according to Martindale’s Download Time Calculator, should only take 5 minutes and 29 seconds to completely download over a 56K modem connection. The video itself is about 7 minutes and 13 seconds long. The video was made using the freeware app DebugMode Wink.

This code and probably all the code that I’m ever going to write in Pygame is based heavily on the Aliens example included in the Pygame source distribution and Line By Line Chimp Example. I encourage you to grab a copy of the source distribution – you can learn a lot just by reading the code.

I will post a transcript of the video soon for those who cannot view the video or for those who prefer to read.

Screencast #1 Source Code

The prototype contains only one level, and I’m pretty sure that a lot of people out there can do a much better job with level design and color coordination . The game is very much playable, although I think there are better ways of implementing the ball/brick “physics”.

So this is how it’s going to work (this will be the general routine for most of the games): this first post will include a general overview of the project, and a zip file containing the prototype. The next posts shall discuss how the game was put together. Along the way, I hope to gather comments, suggestions, and help from everyone, and these will all be factored into the next iteration of the project. This process will just repeat itself until we come up with something that most, if not all of us, will be happy about .

This game was written in Python, using the Pygame library. For me, Python is great to work with, and I would recommend it as a good first programming language. As most of you already know, Python code is very readable, and this is very important for an undertaking like this. I would just like to stress that this project could have been implemented in any other language – the choice of language is mainly due to personal preference.

To understand what’s about to happen, I would consider a working knowledge of Python as a prerequisite. For those of you who already know how to program, I assure you that you can easily pick up Python. With some basic knowledge of C and familiarity with programming, I was able to learn Python by reading the Python Tutorial that comes with the Python package. I think that a weekend is more than enough to go through this tutorial.

For those who haven’t programmed before, the Python website has a Getting Started page, which includes resources for non-programmers. If you’re a non-programmer, I encourage you to give it a shot! I was a non-programmer myself before, and I think that the effort was worth it.

To run the code, you will need to have Python and Pygame installed. Here is the zip file which contains the Arinoid source code and graphics (this should work for Windows, Mac OS X, and Linux).

arinoid source

I learned about subpixel rendering only very recently after playing the amazing physics-based game BreakQuest, which utilizes the technique to allow great-looking particle effects to be implemented through software rendering. BreakQuest’s author Fèlix Casablancas explains the concept of subpixel rendering very well in a forum thread on his website, and I think it’s a good read for anyone who wants a clear explanation of the concept of subpixel rendering.

Will has other Pygame stuff on his website, and I’m sure there’s a lot more on the way – he’s the author of an upcoming Pygame book from Apress . I’m excited already!

The next challenge is PyWeek 4, which will run in the first week of April.

Register NOW!

The PyWeek challenge:

1. Invites entrants to write a game in one week from scratch either as an individual or in a team,
2. Is intended to be challenging and fun,
3. Will hopefully increase the public body of game tools, code and expertise,
4. Will let a lot of people actually finish a game, and
5. May inspire new projects (with ready made teams!)

Entries must be developed in Python during the challenge, and must incorporate some theme decided at the start of the challenge. See the challenge rules for more information.

I haven’t tried participating in one of these yet (I got as far as signing in and writing a very enthusiastic plan of action, but no code ), but I think I should give this a shot this April, and you should, too! I’m amazed at the output that this has generated so far – in a span of just one week, plenty of very good games have been written. The physics-based Nelly’s Rooftop Garden and the well-polished Trip on the Funny Boat are personal favorites – try downloading these games and see what can be done in just a week.

Making good art has always been my weakness – that’s why I rely so much on SpriteLib. Maybe I should consider using simple geometric objects and pygame.draw…