Warmup game complete

You can temporarily download it here.

I decided to focus on my weaknesses for this game, so it kind of sucks. During the competition, I'll focus on my strengths. The style's all inconsistent, and there's no innovation at all. Still, I accomplished my goals, which were:

  1. Refamiliarize myself with python/pygame. Check.
  2. Practice some pixel art. Still needs work.
  3. Try out my new Wacom tablet. I drew the fish with it, so check.
  4. Find online and use at least one free image, sound effect, song, and font. Check with some reservations. aenigmafonts.com seems to be great for novelty fonts, but I mostly want a good selection of normal fonts. And I couldn't find a sound effect anywhere of a game show buzzer (for a wrong answer).
  5. Add in-game documentation. This seriously hurt my PyWeek 6 entry. Ideally the Readme will be completely superfluous.
  6. Modularize my code. Better than last time, but still needs improvement. I'm still not sure what's the best way to handle the game data that needs to be accessed by several different modules. Should it be global? Stick it all in a huge struct that gets passed around? Also the cutscene dialogue, even though there's very little in this game, always takes up way more code than it seems like it should. I put it into a separate file rather than dropping it in the main loop. That's something, anyway.
  7. Try out pygame's Sprite and Group classes instead of rolling my own. I'm glad I did: it took a little getting used to, but the Sprite.kill() method alone makes it worthwhile.
  8. Use the Skellington and the creation script. Check.
  9. Pay attention to what takes the most and least time. No huge surprises, but I realized that there's a point - about 2/3 of the way through this time - when everything comes together. The code goes from being a bunch of tests into being an actual game. When I hit this point, I get so enthralled with what I've done that I spend a lot of time just playing around.

The one goal I didn't accomplish was including the pygame library with my distribution. Still working on how to do that.

Well, let me know if you've got any feedback, especially DNWs!

(log in to comment)

Comments

Um, please don't try including pygame - IIRC you have to include and compile each of the modules on each OS and include the SDL binaries for each OS, so you'll end up with a massive download. People in a Python game competition should have pygame installed :)

I found the game surprisingly fun. I liked how you gradually start getting new and more challenging enemies as you progress. I think the comets could've been slightly animated, though. In its update() method, you could add something like:
if not random.randrange(5):
    self.image = pygame.transform.flip(self.image, 0, 1)
to flip it randomly, making it look more flame-y :)
working right in win XP, pygame 1.8.1, python 2.4.3

Hide the mouse cursor for better polishement.

The 'take the pandora box for increased dificulty' is a good idea. I missed the explanation at first, wich i think is common for hints displayed at the gamescreen bottom. Maybe a 'pause the game, blink the message' is worth , or a text sprite atached to the pandora box. This only for the one or two first apareances of pandora.

Dont waste time including pygame for the compo, it is a well know, well behaved library.
It is a matter of tastes, but IMHO the pixel art style substracts from the game value.
I found the vector drawing app Inkscape (www.inkscape.org) good and fast for game graphics, albeit it has no special support for animations.

Thanks for trying it, and for the feedback! Okay, I won't include PyGame.

As for the (unanimated) pixel art not doing it for you, I couldn't agree more. I think pixel art is great when it's appropriate (and, of course, well done), and here it's not.

Thanks especially for the feedback on the in-game instructions. It's probably not necessary to say what the dollar signs do more than once, but sure, the boxes are a less common device, so that instruction can be repeated. Maybe even just "Okay, you're asking for it. Here comes another wave!" every time you get one. What do you think of having the instructions read like dialogue? The nickname thing didn't turn out as well as I imagined it, but other than that? Do you prefer less chatty, more straightforward instructions?

quote: "What do you think of having the instructions read like dialogue?"
You meant audio? Not really, you will need a good sounding voice, and even having that I bet a good chunk of non-english natives will not understand the spell (surelly I will not).

quote: "Do you prefer less chatty, more straightforward instructions?"
The less they are, the better. The small window showing posible buys is a good example of 'make unnecesary aditional help', it is self-explanatory. Same for the '$'.
The only problem here is that while playing, the player is focused in his player pawn and surronding area. So, you must move the hint near the attention area, or make something to move the attention to the hint area ( hence my previuos suggestions. )
If your game will need more help to understand the gameplay, then for pyweek probably the most feasible solution would be a 'help screen' and or 'help popup'; show it before start the level play, mention it can be recalled with keys 'h' and or 'f1'. ( the easyness of implementation deppends on the libraries you use. with pgu + pygame or cocos + pyglet it would be trivial )

When I say that the help is like dialogue, I mean that it's like someone, a character in the game, talking to you. This is opposed to things like the box that says "Controls: space to fire". It seems more natural to me, but I understand what you're saying: it's hard to divide attention while the game is going.

Anyway, I've never made a game with documentation that I was completely happy with. But I've started playing enough games lately, only to give up in 20 seconds if I haven't figured it out yet. I'll be more forgiving of pyweek games, of course, but I won't underestimate how important clear controls are for making a game fun!