Gumm's recipes for success!

Post 1 of 4.

Fellow contestants, please consider the following for future Pyweeks. The intent of this is to provide feedback to the community at large, in the hope that Pyweek judging may proceed more smoothly. In no way is this a list of requirements or expectations. I would consider all of these "niceties" which could reduce the time spent debugging games during the week of judging. And chances are, if your game is buggy, that by observing the following things more people will be able to play your game, and give you an angst-free vote and feedback. Nothing robs Fun points like a snarl of frustration. :)

gummbum on 2018/05/12 18:33
edited on 2018/05/12 18:41


Comments: (log in to comment)

Post 2 of 4.

GAME JUDGES

There are various methods to try and get attention on an issue you're having with someone's game. Check for an email address or instructions for contact in the README. Fall back on IRC freenode.net (#pyweek, #pygame, etc.) to look for the person. Sometimes people in #pyweek have solved the issue. Be aware that people in IRC appear logged in but are mostly away doing life, so ask your questions and be patient. Post your question to the mailing-list for the game library (pygame, pyglet, kivy, cocos2d, etc.); ask for him/her by Pyweek nickname. Look to see if it's solved on the project page; if not, leave a reply to the project's diary. Look to see if it's solved on the Pyweek message board; if not, leave a message.

Post 2 of 4.

GAME JUDGES

There are various methods to try and get attention on an issue you're having with someone's game. Check for an email address or instructions for contact in the README. Fall back on IRC freenode.net (#pyweek, #pygame, etc.) to look for the person. Sometimes people in #pyweek have solved the issue. Be aware that people in IRC appear logged in but are mostly away doing life, so ask your questions and be patient. Post your question to the mailing-list for the game library (pygame, pyglet, kivy, cocos2d, etc.); ask for him/her by Pyweek nickname. Look to see if it's solved on the project page; if not, leave a reply to the project's diary. Look to see if it's solved on the Pyweek message board; if not, leave a message.

1. If you're tired, or crabby, distracted or in a hurry: PLEASE DO NOT RATE MY GAME. Wait until you're in a frame of mind to be fair, if not generous. Waiting is biblical wisdom, if you care about such things; if not, it's still perfectly true.

2. If you can't get an entry to run, report your system and the versions of python and libs you tried.

Post 3 of 4.

GAME CREATORS

1. In the README include some info about the systems you have tested and which python and libs version you used. This will help judges in getting the right environment if there's trouble.

2. If you plan to make a super hard game, please create a configuration for easy mode also. Any convenience is appreciated. Some ideas, with varying ease of implementation: cheats, a supported easy mode; document hacks, hints, spoilers, tactics and strategies in a cheat document or the last section of the README. Whatever you use to test it should be made available. If you wish to encourage folks not to cheat, a master switch is easy to make. Help getting over learning hurdles may provide enough assist to get somebody moving. Why? So Gumm can see all of your game without spending excessive time on it. I lost count of how many games I couldn't finish, and I could not judge them fairly and completely.

3. Implement a logger that captures enough info for debugging. It is not a lot of work to do so, and actually helps your development and testing. It just makes good all-around sense. Logging to a file is acceptable. Add some debugging switches in your settings or on the commandline for debugging levels or features. Why? So folks can work around bugs that would normally kill a game's progress; and it saves these folks time, they really appreciate it.

4. Before the final period closes, grab somebody in IRC and ask them to test your game. Best is someone who uses a different platform than you do. They will likely catch a bug or two, and may make other suggestions to improve the helpfulness of your README. Why? Cause, bugs are bad, mmmkay? And if you're going to be out of reach during judging week, at least make this last effort to find and fix some bugs.

5. Be available in IRC freenode.net #pyweek through the week of judging, so that you can support your game. People will be glad of your presence, especially if your help is needed. :) Remember to document your IRC nick in the README if it differs from your Pyweek nick. This will also give you the opportunity to start a diary message on pyweek.org with ad hoc fixes and workarounds for issues discovered after the final period closes. Why? We love you, and we need you. :) And we want to play your game. And nobody can support your game like you can.

6. If your game has required modules, it is often very easy to copy the module into your game code library, use it as a local lib, and distribute it (not sure about licensing concerns, but it's Pyweek). It's not just laziness--although I admit I love not having to install requirements. "pip install -r" greatly simplifies things. But there are at least a couple good reasons, in my opinion, even if they might not agree with industry best practice. It's only Pyweek. :) Why? I have encountered at least one game that missed a requirement or two, and they guys were not available to help; had to hunt them down in the code, and figure out what their packages are called, and how to get them. Also, system modules change. If I go to play an old Pyweek game, and the modules it requires have changed disruptively over the years, that game will no longer work unless I can dredge up the old libs. Old broken games are sad games. Yes, I know virtualenv is sweet; but not on Windows, and a learning curve in general.

7. Multiplayer games. Don't know what to say about these. I can't play them. :( I guess I could invite my neighbor over, and force him to sit through crashes, and debugging sessions. :D I'm presuming these games have bugs and crashes just like many others. It's unfair to generalize, I know, but that's Pyweek. We're in a rush, and at the end of it you get what you get. It may be too much to expect a player-vs-envirnment mode (PvE). But even if it is dumb AI, or some trick to make the player think a pre-recorded run is an AI opponent, it will allow single people to play and join in the judging and feedback. This may not be difficult to add, if you have time and experience. Why? Single people are people, too. We want to be included in your fun. :)

8. Some kind of master volume control for sounds would be appreciated. It is easy to compute. sound.set_volume(per_sound_vol * master_vol), where 0.0 <= master_vol <= 1.0. I think most people use a per_sound_vol already, because not all sfx and music play at the level we want in our game. This is an easy trick to implement and costs nothing. Why? So someone can multitask while playing your games.

Post 4 of 4.

This was much longer than I anticipated. I hope you made it through all of it. You may disagree with some suggestions, and that's okay: hopefully you have better ideas. Again, this is intended to help the judges by reducing debugging woes and DNW, enabling self-help, and you being somehow available if they need help. And it is intended to help game creators produce a nicer finished product, and boost those ratings.

Please add your ideas to this thread, if you're so inclined, for anything that might have been missed or can be significantly improved. Please try to keep it simple, and on topic. And resist the urge to debate; if you have an alternative or counterpoint, just state it. Chances are if people find any of the many tips easy to accomplish, we will see improvements.

I look forward to next Pyweek, and another fun challenge, and beating the socks off you, and playing your games. :)