Idea: python game code swap

Cosmologicon on 2011/10/10 17:22

Reading some people's PyWeek code, I realized I could give them suggestions on how to improve it, and I'm sure someone reading my code could do the same as well. I'm not talking about "best practices" like scalability, docstrings, and unit tests - these things understandably go out the window during PyWeek. I'm talking about avoiding doing things the hard way. Suggestions that would save time during PyWeek and make your code more usable/reliable/readable/efficient to boot. Things like:
  • a set would be better here than a list
  • you've basically implemented itertools.product from scratch
  • caching these images would speed things up a lot
At the same time, I don't know if looking at PyWeek code would be the best way to get this feedback, because we're obviously under a difficult deadline, so maybe we do some silly things that we know are wrong. I wouldn't want to waste people's time asking for feedback that I already know.

So I'm proposing a "code swap", where we write a small game and send it to each other for feedback on the code itself. I'm thinking something like 500 lines of code, depending on your coding style. You'd get maybe a week to write it, so there's not much pressure, and you'd be expected to put some effort into making your code comprehensible. If you think your PyWeek game is coded well, you could also submit that.

This wouldn't be a contest, just a feedback session, but hopefully we could apply lessons learned to PyWeek. Would anybody be interested?

(log in to comment)

Comments

tnelsond on 2011/10/11 17:36:

Hey I like this. Or maybe we could make a new compo where every day or two you switch code with someone and work on their code. Lol. It would be hillarious!

DR0ID on 2011/10/11 17:52:

I like the idea, but I admit I have barely looked at other peoples code. Maybe I should peek more often into the sources.

tnelsond on 2011/10/11 20:16:

Who's with me? Let's start a new code switching game making compo. People will practice writing readable code and will practice reading (and writing) other people's code. I don't know how something like that would be judged (probably doesn't need to), but it'd be fun and interesting.

gcewing on 2011/10/11 22:26:

Sounds interesting. Maybe instead of multiple games being swapped, there could be just one game that circulates among the participants. It would be a little like the game where you pass a story around and everyone adds a bit to it.

tnelsond on 2011/10/11 23:35:

Or better yet, you start out with one game and it branches off into a 100. For example, person A starts the game, person B and person C both fork it and work on it a little. E and F fork B, and G and H fork C, etc.

tnelsond on 2011/10/12 00:42:

Oh and back to your original question Cosmologicon, yes I'd be interested in a code-swap feedback session.

Hugoagogo on 2011/10/12 21:24:

Yea i would be up for it, mabey with a version of my code though that i have cleaned up a bit after pyweek

Cosmologicon on 2011/10/13 04:16:

Sounds like there's enough interest to at least try it out, and enough concerns that we should treat this as pretty experimental. Here's my first draft of the guidelines. Let me know what you think:


The purpose of this code swap is to give and receive feedback on your python code, to help us become better at writing PyWeek games. This is very informal but hopefully we'll get something useful out of it.
 
Submission guidelines:
  • Submission deadline is Sunday October 30th
  • Your submission must be a game you wrote in python
  • There are no restrictions on using libraries or other people's code and assets, but please make it clear what you actually wrote
  • Package it like you would a PyWeek game
  • Judges should be able to give you feedback within 1-2 hours
  • Make your code readable and comprehensible
  • Explain the purposes of functions and modules
  • Limit the size of your code to something small, say around 500 lines, depending on your coding style
  • If your code is larger than that, or you want feedback on a particular part, you can point out certain functions or modules that you want judges to focus on. Make it so judges can understand these parts without reading the rest of your code (although you should make the whole thing readable)
  • If your code requires certain knowledge to understand (like a specific library, algorithm, or mathematical background), please note that with your submission

"Judging" guidelines:
  • Judging consists of giving feedback for improvement. There are no scores or winners.
  • Format your feedback however you think is most constructive. This might consist of links to articles that would be helpful, or maybe rewriting a small piece of the program.
  • Focus on suggestions having to do with, for instance, algorithms, data structures, formulas, object oriented design, library usage, and optimization
  • Don't focus on things like long-term maintainability, scalability, and reusability
  • Don't focus on production, fun, and innovation. You're judging the code, not the game
  • Judging period is two weeks (ends Sunday November 13th)
  • You can judge even if you didn't submit anything
  • Expect to spend about 1-2 hours on each entry that you judge
  • Commit to judging at least 3 entries (if there were fewer than 3 other entries, judge all of them). This is a time commitment of 3-6 hours during the judging period.
  • You may be randomly assigned 3 entries to make sure everyone's is judged

Game guidelines:
  • You won't be judged on how good the game actually is, but it should be playable
  • Finish the game a few days ahead of time so you have time to make the code readable
  • Feel free to leave out major pieces that games usually have, like sound or menus or saving, unless you want feedback on the coding of these pieces. You'll be judged on what's there, not on what's missing.
  • Optional, but try to implement one "tricky" feature, that's not obvious how you should do it. Hopefully this will generate the most interesting feedback. Some ideas include: changing gravity, the ability to reverse time, the ability to manipulate platforms, background music that changes with game events, controlling multiple objects simultaneously, procedurally-generated levels or graphics