I am sorry,I want to ask another question:

some people can use some library, that create before the challenge, and some people cann't.

Why they can? why the cannot??

Wow, I'm honored and humbled by the responses to "gather". I had fun and will be back for sure. The pyweek upload system is giving me trouble, so if you want the most recent versions of the game (the post-pyweek release) at my personal site. There really aren't many changes. I fixed the level-end crash bug and added survival mode and a conversion animation so the moment of conversion is a little more obvious.

src : http://static.adambachman.org/games/gather-2008-04-24_src.zip
Windows .exe : http://static.adambachman.org/games/gather-2008-04-24.zip

On with the postmortem...

What I think went right:

• All sound and graphics were from somewhere else. This is not for everyone, but besides some minor tweaking to shrink file sizes (cutting music into smaller loopable chunks and increasing compression), I didn't have to do anything to make the media work. That saved a ton of time for tweaking gameplay.
• Start with big ideas, cut mercilessly. This was originally going to be an RPG/story based game with a sci-fi story running through everything. Didn't happen. There was going to be flocking, heatmaps, procedural content and other complex algorithmic stuff, but I found that I didn't have the chops to bring it together in one week. So I cut everything that wasn't necessary for playing and added back just enough to make it finished. I came very close to ignoring levels, score keeping, and the whole little HUD thing, but managed to slip them in on Friday.
• Standing on the shoulders of giants. From the first moment I opened my editor, pygame and the Splush package meant I could see something happening. I'd never used the pygame Sprite library before this week, but it came easily once I got started. Not having to ever worry about collision algorithms alone was worth the learning curve. Feedback is key to keeping up my motivation, so being able to rely on other people's tools meant almost all my own changes were high level, substantive changes that actually effected the way the game played instead of rewriting a framework.
• Polish. Little changes add together for big effects. Little changes are also easier to get right than big changes. Most of Friday and Saturday were spent polishing. With only one week to design and develop, I'm including bugfixes in the category of polish.

What needs improvement:

• Barking up the wrong tree. Wednesday was a total day off, no game code touched, because I almost burned myself out Tuesday trying to lever a trigonometry based flocking algorithm into an 8-way movement system. On top of the fact that I've never written boids code, I tried to retrofit it into what I already had. This resulted in pretty much a day and a half wasted. I could've been more merciless in feature cutting on that one.
• No practice or preparation. I promised myself I would try writing a game in the weeks leading up to pyweek. FAIL. This didn't kill me in the week of the comp, but it meant I had to learn as I went. Related to this, I would've liked to figure out in advance what I could rip out of Splush to avoid mental clutter. In general, I wish my tool use abilities had been a little more honed getting into the week of coding.

All in all, I enjoyed it making and playing the game, and I'm glad some other folks did too. I hope to do a small set of tutorials while pulling the game apart and re-writing most of it. At this point I can't imagine adding features without coming at it fresh. I think there's potential here, but I don't envision turning this into a power-up heavy 2D action shooter. I like the design constraints of a five-minute casual shooter, so I think whatever changes, it'll still be pretty much the same game.

Huge thanks to Richard and everyone else involved for keeping pyweek rolling, I look forward to 7!

Looking at the ratings for all of zK's Pyweek entries, I'd conclude that our games become more innovative while production goes up and down. And with each Pyweek we make less fun games! ;)

(Ok, you shouldn't compare ratings from different Pyweeks, but it's fun to speculate about the quality of our (hypothetical) next game.. Less fun, more innovation and better production?))

I guess logo-like games arent't for everyone (especially after one week of programming? ^^), so I'd say we did fine this time. Now, to summarise Pyweek 6 for us:

Good:

• I learned a lot (again). C.A.T.:B.O.T. has the most complex interface I ever made (and the worst and buggiest too - I'll use my lack of experience and patience as an excuse), so I found it hard not to learn anything new.
• Zahme improved his pixel art (esp. for UI elements).
• The game feels complete (although it needs some fine-tuning and fixes).

Bad:

• I think we were a bit slothful during the first days
• A lot of bugs creeped in during the last days as I hastily squeezed new (vital!) features into the game.
• Some bugs remained in our final submission - probably new bugs were added during last-minute bug fixing.
• I suspect the game doesn't run on Pygame 1.8 because of something pygsear does and I still didn't have time to fix this (yet).
• The click-on-empty-macroline crashbug is just embarrasing and sorry for all the flickering stuff.

A new version of C.A.T.:B.O.T. (with less bugs) and a Windows .exe will be uploaded soon..... All in all, we had a lot of fun and we really enjoyed playtesting the other games, too. Mostly. ^^

I could list all the stuff we want to do/learn until next Pyweek, but that would be exactly the same as last time. Maybe we'll get around to it this time.. The only addition would be that we shouldn't do another puzzle-game next Pyweek. We already have three - it's about time to try something new. Anything.

So, thanks and hope to see you next time!
-Serval

PS: Btw, our game was indeed inspired by a mini-game in The Lost Mind of Dr.Brain.

Oh, and C.A.T.B.O.T. says to Zahmekoses: "Thank you for making me myself!" :)

Here it is, our first post-pyweek release. There've been a lot of cosmetic changes and I don't know what they are anymore but I'll mention some key differences here:

• Item names are more interesting than they used to be.
• The inventory menu is new and improved.
• Targeting enemies is easier now.
• Balance has been tweaked.
• We added a new weapon. :-)
• A million little things.

Basically, it works better now. Feel free to post feedback to this diary. Our next release (a couple of months away I would estimate) will be a massive content upgrade.

Get it!

Well, I really feel that I accomplished the goal I had set at the beginning - a working game at the end. Next pyweek I intend to be a bit more ambitious, but since it was a first crack at python for my teammates I feel we did really well.

Having said that, the scores were not quite as high as I was expecting, but after I read the comments I felt better. Disregaurding the several 1,1,1 - apparently did not work but they didn't check the DNW box - type ratings might put the numbers right where I would expect them.

Most of the issues people encountered we were already aware of, just ran out of time to do any gameplay balancing at the end. I'll have to make sure and save a day for that next time

So now for the standard-ish response to specific feedback:


I'm impressed. A complete game that follows the theme and works without fiddling!

Thanks!

it is hard.

Actually, it's far too easy. I had a hard time too at first (level 2 was too tough), but once you get the hang of it there's unfortunately very little challenge.

Very nice job on the game! It was quite a bit of fun, and though I had to read the README to learn how to play, it was a real blast once I got the hang of it! I got to level 7 before I even started to get a little bored, and I continued on to level 9 just to see if there was any more of the storyline to be revealed. All told, very well done! :) I liked the premise -- it was cute. The graphics and music were very good, and I *really* liked how smoothly the gripper-hand moved -- timing the placement of the hand is a pretty good strategy element, and so it's fun to optimize. You guys did a good job of balancing the game and not making it too hard or too easy -- well done!

Yes, next time I'm going to aim to have a tutorial so it's not necesarry to read the readme to figure out how to play. We weren't really happy with the lack of intuitiveness of what to do when the robot is complete either, but we will be fixing that in a post pyweek version. (there were just a few things that we really just can't let stand in whatevr final version it comes to)

It didn't work: IOError: [Errno 2] No such file or directory: 'data/story01.png'

Ok, then please rate it DNW instead of the 1,1,1 you gave it :P (if you'd checked my bug diary entry or the wiki you'd have found this was trivial to fix)

Hey, guys: you should make clear which version of pyglet you're using :) I forgot to set up the path with pyglet1.0 and it worked quite bad.

Sorry. I didn't bother including that because pyglet 1.1 is supposed to be backward compatible! That'll teach me to just assume it works as documented :)

I couldn't select an option @ menu. Linux user.

That's odd. You did try using the mouse didn't you? (there's no keyboard support in menu besides the esc key).

this type of game just isnt fun at all for me.

Fair enough, me neither :D. I believe the main demographic for this game type is middle aged women.

The game don´t work, but i don´t know why! I am a graphic artist.

Surely there was a stack trace? I hear python provides those even for graphic artists.

Creative and pretty fun!

Good, we were hoping it'd be fun :)

Well done. I played through to level 12. Things should speed up as you go along!

Agreed. We didn't have time to balance gameplay. Ideally it should eventually get impossibly hard - either that or at some point you "win".

Odd: The game seems to get easier with each level you reach. But I bet younger ones will have fun with this game.

Yep. Post pyweek release will get harder w/ each level. . . somehow.

Decent game but not my style, not nearly enough challenge

Actually, I expected more of this sort of reaction; didn't figure there'd be a lot of overlap between the people that liked this sort of game and the types who think writing a game is fun.

Good game, well designed , decent gameplay

:)

Interesting concept. I'd like to see more balance to the gameplay though -- waiting for parts just doesn't pay off very well. A suggestion: the ability to pick up a piece and put it back down without having to build it on something. Would add a 'conveyor management' element of gameplay so you keep the parts around you want to work with, allowing faster conveyor belt speed and more action for the user.

Actually, you can put the piece back down on the conveyor, or drop it in the recycle. The tough part is you have to find enough space on the conveyor because you can't overlap pieces. Turning up the conveyor speed would actually have the side effect of having more empty space for putting pieces down on, so I'll try that and see how it feels. The other option is generating random parts slower.

Kinda tough to control. Took a while to figure out that I could place the stuff back on the conveyor because sometimes it wouldn't let me.

Yea, I chose to not let pieces overlap on the conveyor - I think mostly because it looked better. Maybe the gameplay suffers for that, I'm not sure.

File "C:\Users\saluk\Downloads\pyweek6games\BotBuilder2000-1.1\lib\credits.py", line 20, in __init__ self.textList.append(pygletfont.Text(self.font, line, x = 800 / 2, y = sy, halign = pygletfont.Text.CENTER)) ... File "build/bdist.linux-x86_64/egg/pyglet/text/layout.py", line 854, in _get_left TypeError: unsupported operand type(s) for //: 'NoneType' and 'int'

We seem to have quite a few crashes related to the fonts on the credit screen, but all the stack traces are different (I deleted the other two because they were lengthy). And I haven't seen it on any of our machines, so it's going to be hard to fix. I wonder though if it has to do with the pyglet version. . .

Got the game to work by deleting the halaign argument. The game ran really slow, and clicking on parts didn't seem to work very well (sometimes it worked, sometimes it didn't.)

We didn't get to spend any time optimizing - I know it doesn't run very well on slow hardware.

Nice idea and story, but the game is not very challenging after all. Especially as you can get a negative bank balance, you could just build all robots by yourself by buying all parts - this could also be done fast enough to earn a lot of money in the end (especially as you get $5 per completed robot, while it only costs you $3 to construct one)...

yea, the $1 per part and $5 for sale was just what we started with and never did have a chance to find the right values. you're right though, there's little incentive to use the random parts when it's so cheap to just buy them.

A neat idea. Way to slow to play (hand moves like molasses) and it's rather boring. Great use of the theme, and nice story intro.

I'd kind of like to have a more integrated story next time, but thanks.

Fun: I played the first 4 levels with joy but after level 5 there wasn't enough challenge to keep me playing. Maybe you could made the time limit a little bit tougher or introduce a point limit the player has to reach. But so every level was as the one before but with more robots to build, which was initialy fun. Innovation: Nice idea to make a puzzle game where you have to construct robots out of different parts. Production: You have nice graphics and sound effects that does not become annoying. They fit very well. Also i encountered no bugs and the help in the README.txt did a good job. Overall: Nice game which was fun for the first levels.

Thank you. You've summed it up quite well I think

Foreword

Well first off all let me express our appreciation to Richard for organizing this great challange from time to time. We've enjoyed working on this project even if we were very tired at the end.

Ratings

• Yes, you're right: we came up with this idea for the Formation theme but we felt that it would fit the Robot theme more-or-less. Unfortunately we didn't have time for new ideas. In fact we didn't even have time for coding till wednesday.
• There were speculations that we created the game before the competition. That's not the case. We simply felt that the idea fit both themes. We were wrong, sorry for that. :)
• There were complaints about the game speed. Well that's really a strange issue. If the game runs slowly in fullscreen try to run in windowed mode (-w command line switch). We'll investigate in that matter.
• Some of you found controlling a little hard. We admit: it's not easy. But if you knew we planned 5 by 5 formations... ;)
• "Impossible to play with french keyboard": you're absolutely right. Unfortunately we couldn't figure out how to access the scancode of a keypress. That's why we planned to implement a keyboard calibration feature but we dropped it because lack of time. Nevertheless it's an important issue which we'll fix in the next release.

I ported our game to OLPC[1], it can be download from http://humitos.homelinux.net/~humitos/robotfactory-1.xo

Instalation: unzip this file into ~/Activities directory

[1] http://laptop.org/

Uhh, now that I am sufficiently burned out of programming for the rest of my life, what with pyweek, and then ludum dare 11 (which i am fairly positive I spent more hours on than I did pyweek) I suppose I may as well see what I can learn from the experience. Those of us in the industry may call this brain dump a "post mortem". I call it blarfing.

I would say that I basically failed pyweek. I'm partially talking about the scores, but I think I would be more upset about the scores if I didn't agree with many of them. I made several large mistakes, and I'm sorry to say, most of them I have made before. I am going to print these out and post them in 100pt font on my wall.

• Unclear vision - I took an idea that has been inside me for a game for years and tried to force it into the theme. This was a mistake for several reasons. First, the idea itself has never been clear. Something that takes years to form is probably not a good candidate for a time limit. Secondly, the idea never had anything to do with robots. Trying to force it into a robot game just looked bad. As a result, my game lacked spirit, and development was slow
• Technology above means - Halfway through the week, I should have scrapped the code I had been working on and re-scoped the project. The skeletal animation system was a good idea, however it took the entire week to get right. In the future, I plan on having a timeline for anything I do, and a plan B if I can't get something working right. I attempted this for ludumdare, and while my process can still be improved, it worked MUCH better. To not at least attempt some new technology in a compo would be to miss an opportunity, but to sacrifice the game to a tech is just as bad. Attempt the impossible, but know when to move on!
• Too ambitious - related to the above, but not the same. All in all, I am always too ambitious. I never try to make something simple, I always want to make the complete package. Whether working alone or with my friend, there just isn't a lot of manpower to realize what I can dream up. I think I could do much better if I could dream a bit smaller. Instead, I always manage to express in my games a small slice of what I meant to say, and the result is no one understands what I am going for.

Not to be too hard on myself or anything :) I am just tired of continually making the same mistakes. I think I would find the experience more rewarding and fun if I were less ambitious and not so technology focused.

Now to respond to a few comments!

• "Seems like it could have used a bit more graphics and gameplay, but I liked the rock'em sock'em feel of it." - Glad someone liked it!
• "incomplete." - True!
• "Too hard!" - I get this response often. I usually balance for myself, which may make the games lean a little harder than they should (since I will have the most practice). Still, this feeling isn't unanimous:
• "This was really well tuned in terms of difficulty - it was exceptionally fun to play and win. Sadly no replay value, but a very worthwhile endeavor." - so I guess it was well balanced for one other player.
• "bad game ?" - you'll really have to give me more to go on here.
• "Interesting grpahics style (still there is something missing to be great). Nice idea of making a fight game, but it is a bit too repetitive and movements are too slow to allow the player dodge properly (i.e., you get hit a lot even if you have fast reflexes)" - Graphics were mostly temporary from the beginning that I meant to update. Didn't have the time unfortunately. To dodge you have to hold the duck button down. I can win without getting hit if I am lucky, so there may be a timing issue on your computer
• "I'm afraid I could not beat it even once :( But I like the way the robots move." - I think it's safe to say the animation worked, too bad it's all I've got.
• "The robot looks neat but it doesn't really fit in with the rest of the scene." - Well they are meant to be giant robots that meet on the battlefield. I agree the art was not that good. No comments on the rest of the game?
• "EXTREME" - TO THE MAX
• "the skeletal animation was an interesting touch, but this entry didnt have much else going for it. i eventually beat it by tapping nothing but the space bar." - Yep, I didn't realize the game would be so hard for some other people because to me it seems crazy easy.
• "jajajajajajaja...." - the rogue judge strikes again
• "hahahaha" - the rogue judge's sidekick
• "never had it for street-fighter games, and i had to take extra innovation points for not really using the theme." - I'd argue it is innovative in other areas. How does it not use the theme exactly?
• "Not everyone uses qwerty keyboards, or like to use our left hands for movement, so supporting arrow keys would be nice. Also, being able to hit escape to quit is a good feature." - Noted. Multiple input options are a good thing!
• "Fun for a while, but got bored fast." - At which point the game was SUPPOSED to hit you with the next cool thing. Oh well.
• "WASD on my dvorak keyboard (,aoe) kept switching it to a red screen with the robot parts and weird behavior. If you're a dvorak user, switch it to qwerty to get the real gameplay." - Yeah, I hear you. In my ludum dare game I support wasd and arrows. Thanks for pointing this out.
• "What's going on?" - Not really fair to rate 1/1/1 for not understanding a game. Next time please either ask for help or don't rate. This goes for playing other games as well, not just for me :)
• "Good attempt, pretty amusing. Love the wacky robot hobble." - Lol. The hobble was the temp animation that was going to be replaced. At least someone enjoyed it.
• "didnt like it" - I didn't much either.
• "I liked the animations. The game was too hard, though." - Another too hard? Game balance is a beast.
• "Well.. music and sound is nice but the game is rather unifnished. ;)" - I should have used the time I spent finding the sounds to rewrite the game.
• "Nice game, although it is a bit too short - and nicer graphics would also have been.. um.. nice? ^^" - Well, I can't do much nicer graphics than these even if I try, but I could have made a better game, for sure. But I wasted time on silly things like graphics and animation.
• "Ehhh .... too hard. Graphics need some work as well. The key bindings are also very awkward for this type of game - it's not an FPS. Try arrow keys and space bar in the future." - Alright already, control config is a must. This is the last bad rating I get for poor default controls!
• "Cool skeletal animation, but the robots look like cardboard cutouts? Also the oversized FPS counter in the counter can be distracting. Is it possible to win? I keep getting hit with fireballs (I try to duck but it doesn't happen in time) " - It is possible to win actually, you have to hold the duck key to duck. It may be that there is a timing issue but I'm not sure. One thing you might not be doing is moving left - if you move left it gives you more time to duck or at least see the shots coming at you
• "Fun: After several tries to defeat the boss i had to hacked myself 100 extra health and so i could kill him :) Playing was a nice 5 minute lasting fun. Innovation: Besides the skeletal animation thing there is no innovation. Production: The skeletal animation looks really good and is a nice feature in your game. Besides that the graphics are stylish programmers art. The only thing to do when defeating the boss or get killed is to start again (using [p]). That made me wonder a little. Overall: A funny shorty." - Glad you liked this experiment. Stylish programmer art is a compliment for me!

Finally, I think the final comment I received really sums up my game and how I feel about it very nicely:
"This game has real potential. With different selectable characters using the skelatal system differently you could really pull off an interesting robot battle game here. (I imagine making the skeletal weapons like punching the main tool of damage with powerups like lasers and airstrikes and stuff.) Unfortunately it seems like the engine for this took much of your time and limited what you were able to do. I think what you probably have in your head is awesome."
What I have in my head is quite possibly the most amazing thing that could ever exist. My hope is that in the next pyweek this will be more obvious :)

Ciao!

Thank you to everyone who played and voted! I really appreciated the feedback given by most of the voters. Lots of compliments for the art-style, so extra kudos go to our lean-mean-art-producing-machine Zach.

I have uploaded a re-release with a few post-pyweek improvements. I do plan to continue development on this game. Suggestions for increasing the dept of gameplay would be greatly appreciated.

Also, a few of you had problems with "pygame parachute" crashes on Windows. We haven't been able reproduce these crashes ourselves, but we would greatly appreciate it if anyone who can would let us know, so hopefully we can figure out why it happens.

Here are the new features in the post-pyweek re-release:

• Doesn't crash if pygame.mixer.init() fails (actually, I wonder if that is what caused the pygame parachute errors?)
• Tweaked the difficulty (caller impatience speed)
• Play completion sound effects when you reach a caller
• Display count of fatalities
• Generate random customer names (many of which are awesome)
• Fix block editor
• make the README file not suck
• Tested and working Windows installer and Mac app bundle

Oh, yes, and in response to your questions, no, it does not matter whether or not you smash buildings. The important part is EXCELLENT CUSTOMER SERVICE!

When you follow a link to a diary entry from the main page, it's not clear which team/game the diary entry relates to. You can find out by following the author link of the first comment, but it would be better to have the team and game name displayed prominently at the top somewhere.

More generally, everywhere a team or team member is mentioned, it would be useful to have the game name displayed beside it as well. It can be hard to remember which people and teams go with which games.

Also, I have a general feeling that the whole site layout is somewhat confusing and hard to find one's way around, although I'm not sure exactly what needs to be done about it.

I'm thinking the diary entries list is the wrong thing to have for the main page. The main page should have a definite look of "main-ness" about it, with large prominent links to all the other areas and a small amount of descriptive text letting you know about each one.

As it is, the site doesn't really seem to have a "main" page at all, which makes me feel a bit lost and wondering whether there are parts of the site that exist but I haven't stumbled upon yet.

Another thing that would be useful is a page that lists all the entries for a particular challenge, but without the full size screen shots, just small thumbnails of them. This would be faster to load and make it much easier to browse through the whole list.