How to make an icon

Today I spent a short time creating an icon for use in another project, but what I learned will probably also be applied to future pygauntlet icons. The first thing I did was find an image that I wanted to use as a basis for the icon from the web. I opened the image in the GIMP to scale and crop the image down to a square size (ideal for icons). Then I opened the square image in Inkscape to begin tracing it. I traced the lines in the original image that I wanted to use in my icon, then I copied those to a fresh Inkscape file to not have to deal with the original image. Once that is done, you can fill in the lines with colors, and save the file as a .svg, which is the default file type for saving from Inkscape. The final step uses a magic website called iConvert. Just upload the svg and then click the download buttons for the ico, icns and png files for windows, mac and linux icons.

Pyglet Recommendation

So today for a completely different project I decided to try out pyglet to see how much better or worse it would be for creating a .app or .exe package. Since I do my development on a mac, I'm mostly interested in the .app (although I will make a .exe when possible too). It turns out that the pyglet project is way easier to create a bundle with than the combination of pygame and pyopengl that I've been using on pygauntlet. If I had the time available to me to do a full or partial rewrite to pyglet I would, but pygauntlet depends so much on pygame that I don't see that being feasible. However, if anyone else is looking for a good library to use for rapid prototyping I am in full support of pyglet even after a single day. They even provide examples with setup.py scripts that do both py2app and py2exe.

Slow Going Packaging

So I spent a lot of time this evening trying to coerce py2app into packaging up pygauntlet into something I could distribute to people. It kept refusing for one problem or another so I'm calling it for now. It seems to be an issue with PyOpenGL at the moment, although it could just as easily be a problem with pygame. I believe the next step is going to be to try a fresh install of python by fully uninstalling all versions other than the one that came with my OS. If I do that I'll be sure to document which steps I take on the google code wiki so that at the very least, a set of instructions will exist that will allow people to run the game from the source even if it is a little more work than just double-clicking.

Score Display

As can be seen in this picture, the score display is now present in the game again, even when the OpenGL rendering is turned on. Also new to this picture are the walls and floors. Way better than what we used to have.

Animation! (sort of)

So I finally made some modifications to the code. I made it so that the potions animate (up and down as if they're floating) now. This makes me want to add a generic shadow sprite to draw below them just for better looks. As it is, the current sprites from Rime has shadows built in that move with the potion up and down, so it looks like they're sliding across the floor. Still, i think it's a step in the right direction. And with new images being potentially added soon it gives me fresh motivation to work on these things.

New Default Theme

As a taste of what will eventually be available, this is a screenshot of the current character selection screen with the new sprites for 3 of the classes.

Source Code Management

Pygauntlet currently uses, and has always used Subversion for managing the source code. The reason we started in svn is because that's the tool that UCR made available to us for the software engineering course. Since I knew how to use svn, when I made the effort to make the project open source and move to google code for hosting, I chose svn for source code management. I have had a tiny bit of experience in using CVS and even RCS as well as the occasional check out of other projects using Mercurial (hg) and git. Unless I have a very strong argument presented to me, I will probably not move pygauntlet to any other source code management tool.

However, Richard Fine just made a blog post about explaining his reasons for moving to git for his SCM. He makes some good points about why svn is not always useful, but I believe it to be plenty good for what we're doing with pygauntlet. There still isn't any better way to manage source code and art/music assets with one tool. However, it is good to know that there are other options out there and that those options are improving. I may try using git for my next project, but if that fails, I'll probably just fall back on svn, because I know how it works and I know that there is lots of help out there on getting it to work.