gummbum on 2018/05/12 18:33:

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.

gummbum on 2018/05/12 18:34:

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.

gummbum on 2018/10/21 02:25:

Bump :)

gizmo_thunder on 2018/10/27 21:32:

Would have been great if we could +1 or like the comments posted :) 

thank you for the post @gummbum