adrwen on 2011/08/08 21:06:

Yes:

Stenographer's advise:

Emphasize the sleep deprivation section.

Stenographer's lecture:

Writing speed sits almost entirely in the mind if you use a fast input device (your keyboard should do just fine for programming in python). Since being tired makes you think much slower, and not sleeping keeps you tired for prolonged periods of time, night-time programming leads to prolonged periods of low productivity, thus potentially leading to a net loss of productivity during the week as a whole.

Of course, this is only true under the assumption that a computer keyboard is an efficient tool for producing source code.

Also, there is one more thing:

Caffine is your friend! This is because caffine seems to make us think faster (provided we have slept our eight hours!).

superjoe on 2011/08/22 23:15:

I like the feedback - I'll incorporate it eventually.

In the meantime, if you have a Hacker News account, upvote this article on there! If it makes front page it will drive traffic and get a bunch more people to enter the competition. Don't worry, it's a good community - PyWeek would do well to have members from that community join this one.

Cosmologicon on 2011/08/29 18:22:

Overall I think it's a great article. I'll respond to what I disagree with, or have a different perspective on, but overall I think it's great!

If you are new to version control, and you honestly would spend more time struggling with the version control software than developing your game, you should use version control anyways, because that skill should take priority over game development, and this is a great opportunity to learn.

I disagree. VC, like pretty much all tools, should not be learned during pyweek (the week before would be fine, though). Once you get used to it, it's not an issue, but when I was learning it, I ran into time-wasting issues by accidentally creating branches that I couldn't figure out how to merge.

Maybe this is just me, but VC doesn't save me any time on my solo projects. I've used it on a few games so far, and I don't think I've ever reverted anything once. It could just be my development style, in that I always add features in a way that makes them easy to disable if I don't like them. I also can't say I recall ever "forgetting what I was working on".

Examples of things you may want to practice: 

• Deploying on Windows, Mac, and Linux

I'd point out that if you run low on time, you can leave this step until after the competition, since you only need to submit a source version by the deadline. The other things on the list you should be ready for (assuming you're going to use them).



Once the theme is decided, you can often pick your best idea, regardless of what theme you thought of it for, and adapt it to fit the real theme.

I'm sorry, I hate when people do this. I want to discourage it as much as possible. I think games should always follow from the theme. I think that Lemming worked out okay, but I strongly disagree that you can "often" get away with this. Do you think there were other successful entries that did this? 

As a general rule, do not try to write a level editor during PyWeek.

This depends completely on what kind of level you're editing. If you're doing anything at all unorthodox, Tiled may not suit your needs. Many people find that the level editor is only slightly more work than the level renderer. But I would definitely agree if you wrote it, "Don't try to rewrite Tiled during PyWeek".

Think about game theory.


Okay, I love game theory, and I'm actually pretty familiar with it. I feel like you may be abusing the concept somewhat. Game theory is not just whatever makes games interesting.

If you're designing an AI for a board game, you absolutely need game theory. But I would be hard pressed to use the formulas I know to calculate something like whether my tutorial is too long. For anything where the state space is extremely large (like a platformer), you really have to rely on general "feel" (hopefully with feedback from others) and experience more than theory.

Sketch your levels on paper before coding anything.

I think this goes against your previous advice of getting the game playable early, which I agree with. I generally save level design for the end, once I think my mechanics are rock solid. If you design a level on paper assuming you'll be able to wall-jump, and then find that the wall-jump mechanic is not fun, or too hard to code, you've wasted a bunch of time.

You get what you give. Write a diary entry after each day of work. 

I definitely agree that it would be great if people did this. However, I don't know if it contributes to success. The winners of pyweek (those with the highest ratings) tend to be fairly taciturn. Maybe that's not what you mean by "successful at pyweek", though, in which case that's fine. ;)


Generally I find it really hard to participate in the community during the week, I get into my own game so intensely. That's unfortunate, but maybe not too surprising. Of course I try to participate as much as possible before and after the coding week.

Make stupidly easy levels come first, and then slowly introduce your more complex gameplay elements as the player progresses and gains confidence.

I say make the whole game stupidly easy, or more precisely, expect that half of your judges will quit once they get to the first non-stupidly-easy part, so your game should be judgable based on that much alone. The real reason for this is that you tend to underestimate your own game's difficulty. So in order to trick yourself into making a medium-difficulty game, you have to aim for stupidly easy. True for me, anyway.

Defaulting to WASD is acceptable, but the player should be able to remap the keys.

As another Dvorak user, I would say, why not let the arrow keys work as well? If Z and X do something, why not also Ctrl and Alt or 1 and 2?


In the part on packaging tips, I would make some mention of the fact that the majority of pyweek games are structured the same way (run_game.py and README in the base directory, no other .py files) and if you follow suit, many judges will appreciate it. I would mention you should look at the skellington for reference, even if you don't plan to use it.

superjoe on 2011/08/29 19:55:

Great feedback Cosmologicon. If you don't mind, I'm going to merge your feedback into the article and cite your name in the credits at the bottom.

Also good point by Martin on defining "success."

saluk on 2011/08/30 01:45:

Rebinding keys: this would be nice, but it's a pretty complex feature to add during the week for what it really offers.

Coming up with potential ideas before the final idea is chosen is a pretty good practice. Of my two favorite games, I did this once, but the other one was an idea that took a long time coming afterward. DON'T just take any random old game idea and try and wedge the theme into it. I hate when people do this! I have done this of course :) If you work hard enough at adapting the idea and its not obvious, thats ok.

I strongly disagree with the level editor. My two favorite games had editors, and some decent levels. Mechanics are important, but I almost think that level design that works for the mechanics is more important. Great levels can hide poor mechanics, great mechanics have a harder time distracting you from poor levels. We had to cut 2 or three rooms from our adventure game because hard coding the interactions and object positions took twice as long as it should have. Having a level editor early also helps to test the mechanics against different situations much faster, which can help you make the mechanics better. I don't think it's something that every game needs - having some structure to easily define the game environment in a text file or whatever can accomplish the same goal. And if your game is mostly random or only one room it might not be a time saver. But, if tiled works for your game, of course use tiled :)

I like your ideas about game theory. I think better ideas happen when you think of your game as an abstraction of some non-game related idea, rather than as something existing in a set genre and using mostly inspiration of other games. A lot of our existing genres came about because of designers trying to convey something, rather than trying to make a copy of space invaders. For instance, the first text based multiplayer rpg game, mud, had 'levels' because the designers were irritated with the british class system, and wanted to create an environment where everyone had the same chance to get to the top.

Cosmologicon on 2011/09/01 21:43:

Sure, that's quite simple once you've gotten used to it. But a beginner doesn't know what's useful and what's not. Go take a look at any tutorial on version control, and you'll see how many features get introduced that aren't part of your usage pattern. How is a beginner supposed to figure that pattern out without spending a significant amount of time at it?

Maybe a document explaining those few steps for beginners would be appropriate. Just an idea. :)

mauve on 2011/09/02 19:50:

There must be articles on version control for beginners, but here's a stab:

I recommend Mercurial for beginners if only because I find it slightly more friendly than Git. If you just wanted to take snapshots of your working directory throughout development, with a command prompt open in your working directory, type

hg init

which sets up a repository for you to store your snapshots. Having done that, type

hg addremove && hg commit

to commit a snapshot. The snapshots you've stored can be seen by typing hg log. If you ever need to go back to a previous snapshot, then look up the documentation for "hg update".

If you aren't working with a team, that's all you need. Stop reading. If you're working with a team you need to be able to exchange snapshots, or more accurately the changes you've made between snapshots. This is sometimes called a changeset. Mercurial can exchange and combine changesets so that everyone stays in sync. The way to do this is to set your repository up with a service like Bitbucket or Google Code. After you've created a project, you can start pushing your changesets to it, and pulling other people's changesets from it. First, make sure you've committed before you do pushing or pulling. This will save pain!

hg commit
hg pull -u <url>

retrieves changes from the remote server (substitute the actual URL they give you) and brings your working copy up to date. If it says

added 1 changesets with 1 changes to 1 files (+1 heads)
(run 'hg heads' to see heads, 'hg merge' to merge)

or

abort: crosses branches (merge branches or use --check to force update)

it's not all gone wrong! It's just that you've received new changesets from the server. Check out the docs for hg merge. Typically the solution is just

hg merge -r tip
hg commit

Merging may occasionally need manual intervention, which is why this process isn't all automatic* but it's not difficult. Right, let's continue.

hg push <url>

puts your changes onto a remove server. If there are newer changesets on the server it won't let you push! It will say

abort: push creates new remote heads on branch 'default'!
(you should pull and merge or use push -f to force)

so just follow the steps for pulling, as above!:

hg pull <url>
hg merge -r tip
hg commit
hg push <url>

Python Jedi on 2011/09/05 02:53:

As a first timer, this is great, I'll put this in my bookmarks bar.  I might play with mecurial, looks simple enough.  Thanks everyone!  (I will likely be posting demos often, since I'll need tons of feedback)