@ IceBrain:

Full of Ö’s pretty weird

@ Matthew Weathers:
Another nice platform is LÖVE, for Lua. The framework comes with all the modules necessary for 2D games (graphics, audio, event handling, input, etc) and Lua is really nice as a language.
It’s also licensed under zlib, so you can use it to make (as they say) “evil, closed-source commercial” games.

http://love2d.org/

@ dawn:

Yep, that’s what I was thinking to. I designed it backwards concentrating on the blocks and pieces when I should have been working with a boolean grid with pieces being just 4 sets of grid coordinates and a color.

Pretty much this will require a complete rewrite – precious little of the code can be salvaged without major alterations. Still it should go much faster now that I know what I’m doing a bit better. :)

I agree completely with “Make it playable as soon as you can.” I used to teach an intro to CS class six or seven years ago, and I would have first-semester students writing little C++ games within 12 or 13 weeks. Many of them got really excited about the games they were making because the framework we used allowed you to see things on the screen right away.

When I first started playing with computers, you could write two lines of BASIC on a Commodore 64, type RUN, and it would work. That kind of immediate gratification is important to get people excited about programming if they’ve never done it before. And unfortunately, you can’t turn on a brand new computer and start writing code as easily these days.

If I were to teach an intro CS class now, I’d consider using PyGame. Or maybe Randy Pausch’s Alice language.

PS – If you want to see the games some of my students made, they’re still on an ancient (2005) web site here: http://csci.biola.edu/csci105/ – the only problem is they’re downloadable executables, and I don’t expect anyone to trust me that they’re virus free. But if you had some virtual machine, you could try them out.

I was thinking about writing a tetris clone myself and wrote down some design ideas. So I have a solution to:

# TODO: optimize the shit out of this

This would change a few things in your program, but why don’t you make the board a boolean array. This way, collision detection is a matter of checking whether there is a 1/true in grid[xi][yi] where xi, yi are the coordinates of square i in the current piece.

@ icebrain:

Wow… I was not aware of codepad. Thanks.

Also, thanks for the tip. I shall see if I can apply it to my code.

Nice work! I’m a big fan of this type of development (for hobby coding of course).

It certainly helps to keep the momentum going if you quickly get something that does something.

Storing them as an unsorted array of x/y coordinates makes it a bit hairy to perform the whole drop-down-after-line-removal operation.

Really? I’d think it would be easy, if you have an array like block[row][column], thanks to the wonderful slice list assignment:
NUMBER_OF_ROWS = 3
NUMBER_OF_COLUMNS = 3
block = [[True, False, False],
[True, False, True],
[True, True, True]]
for row in reversed(range(NUMBER_OF_ROWS)):
columns = block[row]
if all(columns): #if every column in that row has a block
block[:row+1] = [[False] * NUMBER_OF_COLUMNS] + block[:row]
print block
#result:
# [[False, False, False],
# [True, False, False],
# [True, False, True]]

As you see, it removed the filled line and “dropped” the other, adding a blank (all False) to the top.

Warning: poorly tested, on codepad: http://codepad.org/JC64rSu6 (great tool, btw)