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.

Noise for Games

This post is inspired by something I recently read on Notch's blog about Minecraft. It turns out that much of the random terrain generation that happens in Minecraft is from noise-based textures. Initially he used a 2d noise as a height map. He has sense modified the technique to use a 3d procedural texture with some secrets to allow for overhangs to be generated. It occurs to me that there might be some room for noise-based textures to be used in random map generation even in pygauntlet.

Conveniently I have a little bit of experience with procedural textures using Perlin and other types of noise so I feel well prepared to eventually implement some noise stuff when the more important functional features are finished.

Test-Driven Development

I just read about this technique, and while it probably will not be added to pygauntlet, I think I will use it in any of my future game projects. The idea is to write a test, run it to see it fail, write the smallest amount of code to make it pass, then continue with development (refactoring, etc.). The good things that come from this process are primarily a set of tests that you can run on your code to be sure any changes have not broken anything, That means every time something is changed, you can check the test to see if the change was successful or wrong. In a small number of cases, one might find that the test is no longer accurate and needs to be modified to match the new correct assumptions.

A big thanks to Noel for the paper he presented at the 2006 Game Developers Conference and his blog post: Games from Within | Backwards Is Forward: Making Better Games with Test-Driven Development

Documenting a Dream

There we go. I made a horrible title for the first post. I must be amazing. Anyway, the point of this blog is to let people know information about progress on the open source project Pygauntlet. So far we have 2 people "actively" working on the project. I'm working on the programming, and we have an artist working on new images for the game that might also post updates on here from time to time. Maybe at some point the game will be ready for packaging and distributing.

Also, if anyone who happens to read this has any questions, feel free to post them and I'll do my best to respond to them.