| Phil Hassey - game dev blog |  |
 |
"What kind of
arrogant jerk has a website like this?" |
It’s time for the 10th Ludum Dare compo!
Dec. 7-14th – Registration and Theme Voting
Dec. 14 at 7pm PST and runs until the 16th at 7pm PST
Join the fun in irc.afternet.org #ludumdare
With luck, the compo will be held on www.ludumdare.com ..
Be sure to join the irc channel for the most up-to-date information.
– Phil
Marshie Attacks: Halloween Interactive Driveway Activity
Some really cool game dev going on there. They used python, pygame, pysight, lasers, bedsheets and potato canons to create an interactive Halloween game!
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”.
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:
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:
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