Watermelons was a pygame game made in about 8 hours one evening on the #ludumdare channel. Since then I’ve ported it to flash using haxe. This past weekend I integrated it into the facebook API. You can check the app out here. My server-side high score system was written with PHP.

The integration was somewhat challenging, since I was using a language not supported by facebook (haxe) and my integration involved using flash, which has some restrictions when used within FMBL. To work around these things, I had to embed my flash object within an iframe and then pass high scores back through my main web script in the browser window (instead of as a background request) in order to be able to use all the facebook notification features.

So far (after about 5 days) the app has about 160 users, which isn’t very many. But I suppose it’s not bad for my first shot at writing a facebook app.

I just spent the last few hours working on an update to pygame.org . The most exciting feature is the tagging which I’ve added. Now you can look up all pyweek entries by going to www.pygame.org/tags/pyweek for example (at least, once people start filling in their tags!)

I haven’t had lots of time lately to work on the pygame site, but I’m glad I was able to round up a few hours today, I think this is a nice feature and I hope it encourages people who use other python game frameworks to post their games there as well, now that they can tag their games as “soya” or “pyopengl”.

Although I’m generally an Open Source enthusiast, sometimes you just need something better …

Prince XML – if you need to create lots of PDFs, you probably need this. It converts HTML to PDFs really fast and accurately. They’ve even used it to publish a book. There is an open source alternatives which may suite you: tufat html2pdf – but it isn’t as powerful, is really slow, and takes up a lot of memory. Good for small scale projects. I’ve actually used it quite a bit, but eventually the requirements of my projects grew beyond what could be done with it. (I talked with the devs about sponsoring the changes I needed, but they felt it would be impossible meet my requirements and recommended that I get Prince XML instead.) Prince XML comes as a command line binary, so it’s easy to integrate it with any language. “prince in.html out.pdf” is all it takes.

Chart Director – makes building graphical charts for your website both fun and beautiful. I haven’t really come across any open source alternatives that I cared for. The API is quite nice and includes just about everything I need. It comes with bindings for all common languages.

I’m a big fan of rapid development. I’m also a big fan of the programming languages that I use … but every now and then I come across a use case where my language of choice just isn’t cutting it. And what’s the only obvious solution? Design my own language in 48 hours!

I like the 48 hour restriction because that means I won’t waste more than one weekend of my life trying this. I honestly believe that the people in charge of the languages I use are doing a great job. It’s just that now and again I have the desire to try and make one myself. And if it turns out to be a waste of time, at least it was only 48 hours 🙂

I’ll likely be trying to make some language similar to python and lua – with a special focus on making it easy to integrate into C.

A day in advance I’ve completed my pyweek entry! And, to be honest, my pyweek entry was more the completion of the pug.gui than the “game” I made. Some final stats on pug:

• gui.py is 31360 bytes
• theme.py is 7428 bytes
• 16 widgets included in the core

The theme is easily extensible – while maintaining separation from the Widget core. Themes can respond to events (play Sound effects), have per-frame loops (shrink/grow/change colors), and be styled using the CSS Box model. Here’s a couple fun screenshots:

The default theme:

The “game” with even more custom theme and Widgets:

I decided not to actually enter my entry into the pyweek judging mainly because it wasn’t a game, but also my “non-game” was utilizing pug, which wasn’t released a month ago (per pyweek rules for personal library usage.)

On a more “game design” topic, I’m a lot more comfortable creating arcade games, as that’s more my style. Games that involve your typical “gui widgets” just don’t excite me very much. The rational behind creating pug is that games do need good menus and options screens for the times when you aren’t playing the actual game. Many of my “core” widget choices are based on the primary use case I have for pug.

Since pug still isn’t up to the 32k limit, I’m likely to add in joystick support as well as add more information into the docstrings. There are a number of widgets I could include, but I don’t feel that the primary use case allows for those. (Users will be free to create “contrib” widgets to be placed into the “contrib” folder and will not be supported by me. I might even add in some “contrib” widgets – a secondary use case is quick game dev / level making tools. You need file pickers and dialogs for those – both of which I’ve developed for pug already.)

If you want to give pug a whirl: svn://www.imitationpickles.org/pug/trunk

-Phil

I’ve been working on a re-write of my pygame based gui PGU. I found, that as PGU grew larger I was less inclined to maintain it. It became harder to add new features and harder to maintain existing ones. At present, PGU is pretty stable, but it’s also pretty large and likely not going to change.

While working on Galcon, I added the ability for users to add their own python mods to the game. I wanted to give the users the ability to add their own option screens using a simple gui system, which, just for giggles, I decided to make sure it was less than 32k of code. After I had written this system “gui.py” it occurred to me that not only was the API simpler than PGU it also had most of the features PGU had! (As well as quite a few PGU didn’t have.) My simple 32k gui.py was rivaling my 250k pgu.gui!

I came up with a theory of sorts: “Any useful library can be written in 64k or less.” Of course, I wouldn’t swear by that, but I figured I’d give it a try. I’m working on getting more functionality than PGU had into my new PUG library. So far so well, I’m keeping the gui.py <= 32k and the theme.py <= 8k. So far I have a cleaner API with more features than the original PGU. However, keeping it smaller than 32k requires me to make quite a few trade-offs. I can't have all the features I included in PGU. The real challenge now is deciding “is this feature important for almost all games, or is it a bit frivolous” … I’m sort of cheating by putting those frivolous widgets into a contrib/ folder. At the same time, it’s helping me keep the core small and maintainable. Anything found in the contrib/ folder may very well be quite useful, but I can also claim it is unsupported and not have to worry about it.

My arbitrary rules for PUG development:

• the code in pug/ must be <= 64k
• gui.py <= 32k
• theme.py <= 8k
• code must be readable
• names must be readable
• use 4 spaces for tabs
• must include complete docstrings

A number of those rules are in place to keep me from “cheating” to get the file smaller. I hope to wrap up a useable version today .. and then begin working on my pyweek entry!

If anyone is brave and wants to try the alpha: svn://www.imitationpickles.org/pug/trunk

-Phil