Finishing Up With "Invent Your Own Computer Games with Python" and Starting My First Game!

Andrei Marks · September 8, 2011

Okay, I’m on the final chapter of Invent Your Own Computer Games with Python. As soon as I finish that up, I’m going to start splitting my time between working on a specific game and doing general tutorials or lessons on programming. I’m also going to be better at keeping track of my time, so I have a better idea of how long my project development cycles are and how long it takes me to work on things. I’ll start keeping a spreadsheet.

I’m simply going to follow the advice on this page and start with these games (tetris, breakout, pacman), and add a twist to them to make them a little more than just copies. One highly rated comment at StackExchange (by user Bob Montgomery) does mention that you should start with the type of game that you actually want to write:

I'd strongly recommend that novice programmers should start with the simplest game that they actually want to write. As mentioned by Matt Rix, a huge part of writing a game vs. a demo is pushing the damn thing through to completion - credits, menus, play testing, high scores, pausing, play testing, difficulty levels, clean game state transitions, play testing, etc. That stuff takes at least half the time you're going to put in and it just isn't fun. It isn't. So unless you love the concept and are really motivated, you will give up and move on before the game is a game. If you want to write an RPG, figure out the simplest, most manageable RPG concept you can come up with that you want to do and do it. Same if you want to do a sci-fi shooter, or a horror-themed platformer, or whatever. Pick something you will finish, that you will still want to finish after everything fun is done but you're still looking at dozens of hours of work before you're really done. The best game to "earn your wings" with? The one you completed. I don't care how many half-done PONG/Breakout/Galaga/Tetris demos you've written, you aren't a game developer until you've released an actual completed game. Plus, no one wants to play yet another version of those 40-year-old games, and at least some of the point of writing games is for people to play, right?

However, I think that developing these other games will also be beneficial when it comes to learning how to implement design ideas that you might not initially expect to use in the games you really want to make. I’d think that anything that helps you expand your code repertoire is a pretty good thing. And besides, adding a personal twist to the games also makes them games that I’d like to complete anyway.

Things I learned yesterday:

pygame.init() function, pygame.display.set_mode() function, pygame.display.set_caption() function, pygame uses RGB values for colors, pygame.font.SysFont(), render() method, anti-aliasing, pygame.Rect() function, attributes, constructor functions, type() function, fill() function, pygame.draw.polygon() function, pygame.draw.line() function, function, pygame.draw.ellipse() function, pygame.draw.rect() function, pygame.PixelArray data type, locking objects, blit() method (from "block image transfer"), pygame.display.update(), game loop, pygame.event.get(), collision detection, pygame.time.Clock object, tick() method, list[:], events: quit; KEYDOWN; KEYUP; MOUSEMOTION (pos attributes, rel attributes, button attributes); MOUSEBUTTONDOWN (pos attribute, button attribute); MOUSEBUTTONUP; keyboard key events, (event.pos[0], event.pos[1]), .colliderect() method, sprites, pygame's supported file formats, pygame.image.load() function, pygame.transform.scale() function, pygame.mixer module, module, pygame.mixer.Sound() constructor function,,,, toggling boolean values

Twitter, Facebook