PyWeek - Postmortem

I have written blog post and I am riposting it here:

-------------------------------------------------------------------------------------------------------

So, PyWeek #12 (http://www.pyweek.org) has ended and this is going to be some standard lessons learned kind of blog post.

First of all I am sorry for my poor English.

This was my second pyweek entry. First one was kind of weak. But this time I have made better one. It managed to get second place at solos. Oh, and now it even has a clone. How cool is that?

So, link to my entry:

http://www.pyweek.org/12/ratings/

And lessons learned:

RTBR (Read the bloody recommendations)

I really should have read the recommendations. But wait. I have read it. Twice... But. But I paid almost none atention to it. That is bad thing. I think this blog post would have been shorter if not my ignorance.

Include dependencies Yourself

It is one from recommendations. But I have managed to miss it. I could have included pyglet and cocos2d libs into my game. Ok, there is some small pyglet's c dependency (AvBin), but cocos2d has no C code and should have been included into game's source. I think this mistake of mine haved caused some errors for peaple who have tried to run (without positive results) my game.

Communicate with others

I spend around half an hour in IRC communicating with other entrants and that is it. If I would have spent more time chating with others they could have save my game from problems running it by pointing such simple things as: "Your game do not work on my machine because Your have left THAT mistake". And more people than would have played (and hopefully liked) my game.

Proofreading is Your friend

"Squares citry". Mhuhahahahahaha. Citry. I managed to leave spelling mistake in my game's main screen. There is like 10 words in my game and I still managed to leave one spelling mistake... In the main screen. One proof reading pass (10 words -- it should not take long). One bloody reading pass.



And the goodies part:

Try to reach playable state as soon as possible

You probably have nice idea (half borrowed). Your imagination is really powerfull. You can play Your game with it and Your game rules. You definitely are going to win. There is one "but" of course. You have not written one line of code...

My point is that You should reach state of Your first prototype where You can actually see Your gameplay. And it is going to suck donkey balls. But situation will not be as bad as it sounds now, because from there You will make it good or at least not as annoying. But You will need time.

So, You should be fast. I mean really fast. It is game competition and it has very restrictive time limit (one week). Use anything You can think of to reach that limit. Screw good practice. Copy and pasting programming? Good! No unit or other kind of auto tests? Good! Strange class structure? Good! I mean as strange as Dali's paintings? Still good! All anti-patterns You can think and find at http://c2.com/cgi/wiki?AntiPatternsCatalog? Good!

Use anything to have main portion of gameplay ready within shortest amount of time possible.

Do not get me wrong. Do not write bad code just to write bad code. But if writting bad code helps You -- than go for it. During these kind of competitions You need to produce as many features as You can and bad practices are really good for that. Seariuosly.

Than tweak Your gameplay as much as You can

Now You can sort off play Your game. As I said it sucks. But that good -- You have enough time to fix it. But You code sucks. So what? You still need to remove half off it (Your gameplay sucks. Remmerber?).

Spend a lot of time tweaking various aspects of Your gameplay. Refactor some of Your code as You go along. Just do not try to refactoring all of it -- just parts that stops You from easy way of changing small bits of Your gameplay.

Know Your limitations

At start I was thinking of some complex stuff I am going to do. Some complex art I am going to produce. But than I have understood -- I am alone into this one. I can draw all week or I can code all week. I just can not do both. So simple graphics to go.

Some peaple like to say: try to make imposible -- this is the only way to make something decent. I do not think so. You have one week. One week. One week! Forget Your utopia. Just try to make something with start, with end and something that You can call "It is game". First rule: You need to finish within one week. Second rule... Wait... To make playable game within one week is very hard so no more rules. Just make something with start and with end. With too ends (win and lose) if You can.

Have fun

Have fun. Have fun. Have fun. Have fun. Have fun. Have fun. Life is short. Have fun. There is no way I could finish my entry without thinking that I am world class hacker while making some stupid rectangles to collide. So, have fun.

petraszd on 2011/05/02 23:11 of Petras Zdanavińćius


Comments: (log in to comment)

Excellent writeup, thanks!
It was awesome to get to actually play your entry in my browser, since it didn't work in python. Fun game! I noticed you used the game_over sound I made :-).

As Richard said, excellent writeup. I do have to disagree with you on the part about using AntiPatterns. I think you are spot on in having the goal of reaching a playable state as soon as possible. But I don't think you have to compromise (mostly) clean code to get there. When implementing a feature (or the very first code), I like to Do The Simplest Thing That Could Possibly Work. At this point I am be able to see if my idea/code works or not. And then if I'm breaking the single most important divinely inspired programming rule, I'll refactor. It is almost always worth it to obey this rule no matter the short-term coding cost.
Indeed nice write up. I didn't notice the typo until you pointed it out :D

I actually found your code to be pretty readable! (I'm the one who did the JavaScript clone) Which doesn't happen often. And it showed my some nice cocos patterns ;)
 
@superjoe yeah I used your game_over sound... I think - hope - I give you credit in the README :D
superjoe: Yeah... Maybe Your are right. And maybe I am right too (probably not). In my day work I am tend to work with projects that stays in production for long time. And I am tend to think about that guy (future me) who is going to maintain all that code. I think that kind of thinking is bad for one week competition.

So, when I was coding for this pyweek I was trying to have one goal at the time. At first I have chosen to make playable prototype as fast as I can. If I have chosen to write prototype as fast as I can while maintaining clean code base, well then it is two goals: fast prototype and clean code. I have chosen first one because clean code does not help to see if my gameplay works or not.

Oh, by the way. HTML5 game is not 1 to 1 copy. It has slightly different gameplay feeling, different art and different sounds. Mine does not have any of game over sound FX. Just nitpicking a little bit...