I was thinking about what is the logical sequence in which the "standard" games should be tackled to learn properly. By standard I mean

• pong
• pacman
• other such game

I think I saw a list somewhere but couldn't find it now, By logical sequence I just mean trying out small things so I don't take a huge pile of things that are totally unknown to me at once. Small steps you can say..

Also any suggestions about how to wade through the game programming articles. There are a huge amount of articles. Is there like a post categorizing the articles?

This? http://www.gamedev.net/page/resources/_/technical/game-programming/your-first-step-to-game-development-starts-here-r2976

That is exactly what I was looking for. Thanks.

The article talks about getting game reviewed. Do people on gamedev do code reviews or should I look elsewhere?

I think you just have to post your code in this forum (the Beginners forum) and ask for a code review.

Yes, someone on the forum is usually willing to take a look and offer pointers.

Bonus points if you have your code hosted somewhere like GitHub (plus, you'll learn about version control into the bargain).

Python 3 - Pygame

So how about taking a look at the file game test.py at my github? While this isn't a complete game there are a few basics that I made after looking up this tutorial's lesson 1 and 2. I changed a few things.

• Any newbie silly things that I am doing?
• Also I didn't understand what the get_image function is actually doing other than making the path os independent.

Anyone interested in having a look?

Edit:

Any newbie silly things that I am doing?

The function get_color() is one of the scariest things I have ever seen. Not because it does anything dangerous, per se, but because it relies on intimate knowledge of external state (i.e. what value you initialised the variable color to), and the name of the function gives no indication of this.

Since we are in python, I'd probably implement it more like this:

color, alternate = (255, 100, 0), (0, 128, 255) # assign both values by tuple unpacking
# ...
if (event.type == pygame.KEYDOWN and event.key == pygame.K_SPACE):
    color, alternate = alternate, color # swap values using tuple unpacking

Also I didn't understand what the get_image function is actually doing other than making the path os independent.

The get_image() function is mostly there to prevent you loading the same image twice. It caches every image you load in a dictionary (key'd with the file name), and if you try to load the same image file again, it will hand you the one it already loaded earlier.

The get_image() function is mostly there to prevent you loading the same image twice. It caches every image you load in a dictionary (key'd with the file name), and if you try to load the same image file again, it will hand you the one it already loaded earlier.

I get that now but isn't it a little flawed? I mean shouldn't the canonical path be calculated before the first assignment to image variable. If it is done after that then actually there is no problem as the dictionary is updated with the same value but the image is loaded again.

I mean wouldn't something like this be better.

_image_library = {}
def get_image(path):
    global _image_library

    path = path.replace('/', os.sep).replace('\\', os.sep)
    image = _image_library.get(path)
    if image == None:
        _image_library[path] = pygame.image.load(path)
        image = _image_library.get(path)
    return image

I get that now but isn't it a little flawed? I mean shouldn't the canonical path be calculated before the first assignment to image variable. If it is done after that then actually there is no problem as the dictionary is updated with the same value but the image is loaded again.

If you look at it carefully, you'll note that even after deriving the canonical path, they still use the original (unchanged) path as the dictionary key.

It's a fair point that it might be better to use the canonical path as the key - at the very least, it would catch cases where the user passes in both the unix-style and windows-style paths at different times. That said, calculating the canonical path isn't free, so you might prefer to keep the current version, which is very fast in the already-loaded case.