In late ‘04 and early ‘05, I did a fair bit of work with Python. The language is quite nice. I would like the ability to use static typing sometimes, but it’s not that big a problem. The fact that the language is dynamic and interpreted leads to some of the coolest stuff that one can do. You can dynamically load modules, call functions by searching for their name at runtime, and all sorts of other stuff. Python’s performance is quite good too. And the hit of having an interpreted language isn’t that bad, plus it seems to be the way the world wants to move anyway (both Java and .NET are interpreted). It’s syntax is very close to C and C++ which makes it easy to use, but at the same time it is cleaner because it uses indentation to figure out where the blocks of code are. This means you don’t have to type all the ‘{’s and ‘}’s, and makes the code look better because you are forced to indent (which many people don’t seem to do for some odd reason).
The ease of Python plus the fact that it can interface so easily with C, C++, Objective C, and so many other things makes it a great language to work in. Lately I’ve been experimenting with OpenGL and it’s easy to do in Python thanks to pygame and PyOpenGL. The programs that I made are below.
Blocks
I haven’t worked on this particular program since January 18th, and I’m not sure that I’ll work on it much more, at least not for a while. This program came out of my want to learn OpenGL. After a few tests I wanted to make a real program and so the idea of this little puzzle game seemed perfect. The first piece of development for this (as opposed to simple OpenGL tests) came on October 7th, 2004. So while I worked on the program for 3 or 4 months, the fact is I would only work on it in spurts. I only worked on it on 17 individual days which ranged from as little as fixing a small bug to doing massive improvements.
As a learning project went, it worked quite well. I got familiar with large parts of OpenGL and how the lighting worked. It was also the first real program that I did in Python so I learned quite a bit there too. This was also the first project I did that used PyGame, although I didn’t use too much of that (as OpenGL handled the graphics which were the largest part). Also, this was the first program I made that used sound. I guess I learned quite a lot.
So what does the program feature? Well if you are unfamiliar with the concept, there is a grid on which you play (15×14 in my version, IIRC). You are given pieces made of blocks (not unlike Tetris, but there are more shapes). Your job is to set them on the board. When the pieces form a square or rectangle of 3×3 or bigger, it disappears. You continue doing this until you can’t place a piece anywhere. This sounds simple, but as you play little bits of pieces get left on the board as junk making it hard or impossible to move the current piece around. It can get quite tricky!
There are various features of this program above the simple description. It should be relatively independent of the graphics engine, so it shouldn’t be too hard to swap it out and do a sprite based version (something that would be interesting to do some day). It features sounds for when you place pieces and other such things. There is a highscore that is kept so you can see if you beat your top score. Last but not least is a bit of a special effect that I put in the program. When a square is made, it doesn’t disappear off the board immediately, it sinks into the board slowly, but at the same speed no matter how fast the framerate it.
I don’t think I will release the source (maybe one day). I’ve posted a screenshot at the bottom of the page. You can see the result of a quick game (not any real attempt to do good). On the right you can see the score issue mentioned below.
Are there bugs in the program? There is one bug and one “feature” that I know of right now. The bug is that under OS X the score and such don’t show up right. The “feature” is that the program just quits when you game-over (that was a debugging feature). The program isn’t complete so what do you expect.
IttyBittyCity
IttyBittyCity is designed to be a little city simulator and god-”game”. It’s not exactly designed to be “fun”, but I think it may turn out that way. In many ways this is a programming learning project and should end up one of the (if not the) most complex thing I’ve ever made.
The idea is to see a little functioning city on the screen (well, more of a neighborhood). You’d see little stores, people, cars, and other such things. The people go about realistic business reacting to things and finding their way around. Some people like certain things (like being near other people) while others avoid certain things (again, like other people). You would be able to do things like designate a spot as “good” so that people would want to go there without knowing why, or do the opposite and make people avoid somewhere for no good reason. You could be obstacles in their path and watch them navigate their way around them. The cars would drive around realistically. People would decide to jaywalk or not. All sorts of interesting stuff would be possible.
Now obviously this is not a simple program, but that’s what I’d like to build to. I may switch to another project some day. But the idea is as a learning experience in things like getting a little world to run, objects interacting and such, path finding, AI experimentation, and other such things. Even as it failed, I learned interesting stuff.
As of February 22nd, 2004, the little car and the road are drawn correctly (hooray!) I spent the last two days or so working on generating a path for the little car to follow so that I can implement A* pathfinding. It was a lot of work but I made a little Python file that, given a map, spits out all that stuff for me. Hooray! So after a bunch of testing and bug (and bugs and bugs and bugs) I got it working. Below is a screenshot of the path for my little map being displayed.
As of February 27th, 2005, after a TON of works things have improved quite a bit. In fact, they have improved to the point that I am going to work on a different project for a while before I come back to this one (I need a break). As of the 24th I had successfully implemented the A* algorithm and the ideal path between any two nodes on the map was easy to calculate. After that it was relatively simple to make the little car drive around which is where I am now. As it stands the car starts on one spot on the map (near the top left). A random spot is selected on the map and the best path to that location is chosen. As the little car drives there, a pink line is drawn showing the path the car will take. You can see it (pretty well actually) in the little 550KB QuickTime movie. It is about 1:20 long, and is 320×240 (50% of the real size). Check it out and tell me what you think. IttyBittyCity Test Movie.
SiteMaker
SiteMaker is the little Python script that runs this site. Updating my site has always been a bit tedious and I’ve looked for various solutions to that including writing Perl scripts to generate EVERYTHING on the fly based on content out of a database. Nothing ever came from those kind of things as they were too ambitious and I was shooting for the moon. SiteMaker came about because I had a simple idea how to make managing my site easier. I had decided I needed to update my site with my recent programming work and with my tale of switching to Mac. Well I didn’t want to hand code ever page that I would need as I had also done in the past. While there is nothing too bad about writing HTML in hand, having to copy and update things like the navigation bar on every page is a pain. So SiteMaker was born.
SiteMaker was originally just two Python files that total 290 lines, which could be reduced a little bit. I wrote most of it in about 3 hours and it was VERY easy to do which I chalk up to using Python. While Perl’s natural string handling would have been nice to have, the ease and syntax of Python outweighed the power of Perl for this. I’ve used Perl for the past, and is can still be a little bit like voodoo to me. Python had just about everything I needed anyway. I’m glad I learned Python.
Now, thanks to a rewrite, things are a bit more complex. SiteMaker is now made up of about 6 files doing various things. The plus to all this (I don’t know how many LOC it is now) is that it is MUCH easier to update and expand than it was before. I’m still not releasing it to the public yet, but I’ve gotten closer to something I’d be willing to release.
So anyway, the theory of operation is this: SiteMaker runs recursively through each directory in the site. It learns what style of page that directory contains by reading a text file. This is stuff like whether it is blog-like (like Adventures in Mac Land) or just “normal” like page (I intend to add other types too). Given that it reads text files in that directory that describe the pages (the files might contain a keyword or some special information, plus the page’s content in HTML that I wrote by hand). From that it generates each HTML file based on what it finds and information that it already knows (like what goes in the navigation bar). It works quite well.
Once it’s done running through things, all I have to do is upload all the files to my website. This is one of the improvements that I’d like to make. I want to make it so I can only update the part of the site that needs it. I also want to make it so I can write “plug-ins” to handle new types of pages instead of having to write them into the original script by hand. It’s not a “well designed program” in that adding to it is not easy, but it wasn’t designed to be, it was designed to be something that I could write quick and use until I had the time to improve it to work better.
I had intended to improve things. I wanted to make the code more modular and improve it in some other ways. In the end, I switched off it because I didn’t have enough free time to implement some of the features that I wanted.
