Thanks for your comments on my game! I'm glad that you enjoyed it. :)

I've already discussed the game in my previous post, so I don't have much to say that I haven't said in it. I just want to comment on the "PS" portion in my previous post, because it's an interesting tidbit on the story of the development of the game.

I asked in that post whether there was a way to compute any boolean function with a level in my game (in theory). The answer is yes. The game has NOT gates, and doors behave in an OR fashion: it requires at least one wire to be on in order for it to be closed. Now, a NOR gate is an universal gate, meaning that we can construct all other ones from it, so if we can make one of those, then we're done. A door is not exactly able to produce output, but the feature I added in later levels does allow you to retrieve the output of a door: with track-powered sources, we can position a track, a door, and a source, so that the source is on if and only if the door is closed. This plus attaching a NOT gives us a NOR gate, which we can use to construct any other gate and therefore compute any boolean function.

In fact: this was what drove me to make a crucial decision late in the week. I was originally going to add AND and OR gates to be used just like the NOT gates. The reason is that having only the NOT gates limits the depth of the puzzle a bit. However, I liked the simplicity of having just one type of gate. So I thought, could I do something else that gives me the power of AND/OR gates, and yet lets me maintain this simplicity? For example, I had drawn a use case of AND gates where you had to keep a wire on in order to close a door behind you and avoid a track escaping. Well, in the second to last level, something similar is executed in the top right part of the level -- yet not with an explicit AND gate. The thing is, I realized that doors worked as an OR, but there was no way to capture their output. So I came up with the idea of track-powered sources, which emulated that and fit pretty well with the whole game. It just felt right: while you have to manage doors in order to take care of tracks, this feature made it so you also have to manage tracks in order to take care of doors, and we get a nice circular relationship going on. Time constraints only allowed me to make the 4 levels with track-powered sources in the game, but I think you can make some neat stuff. As a bonus, that was easier to implement than AND/OR gates. :)

Anyway, congratulations to the team winners, and thanks to blakeohare for hosting this Pyweek! See you all next time! (Also, xmzhang1, thanks for that cool award picture. :))

Well, this time I get 3.3, that is a high score for me, I know my game have many bugs, especially in player control, however, thank all the kind guys, they still give me such a high score, that give me a lot of encouragement. I have to say that English is still my weakpoint, 'let in' must be a phrase, you can't let him in here, means he is not here, you can't let him in. But I do not reallized it at the beginning, I think 'he is already in here', you can't let him still in here. When I played other game, I reallized this misunderstanding. However, as I said before, kind guys still give me high score, so many thanks! And also hope we still meet each other at pyweek 23.

If you haven't played our game yet at all, please go do so. You should be able to jump right in. This post is for people who've played for at least a few minutes and want to know what they're getting into.

The campaign is 9 levels (1-1 through 3-3). We estimate 3 to 10 minutes per level if you play at 1x speed, for a total of about 45 to 60 minutes. I recommend beating at least Stage 2-3 if you want to get the "gist" of the game.

Endless mode (unlocked after Stage 2-3) has a boss every 10 waves, and you're treated to a little dialogue for finishing each boss (up through wave 50). If you reach wave 51, you unlock the last item in the game and the waves become almost impossible. So it's technically endless, but you should call it quits at wave 51. This will probably take about an hour if you hack your save game (recommended), much longer if you start all the way over whenever you die.

To hack your save game, replace the file save/quicksave.pkl. This is auto-generated every 10 seconds, or whenever you quit the game within a level, or press F5. When you quit the game or press F5, a timestamped copy of the save is also made, for your hacking convenience. It looks something like save/quicksave-20160911122816.pkl. To pick up the game from a previous save, copy the timestamped file you want into save/quicksave.pkl.

If you like the storyline but you don't want to finish the whole game, you can see all dialogue by running this from the game directory:

    python -m src.dialog

Let us know if you get stuck or you want general strategy tips. Good luck!

Here's a complete walk-through in case anyone is having difficulty running the game or needs help getting past a level. Since the levels are puzzles its also a big spoiler, although there are other ways to solve the later levels!



Full walkthrough (spoilers)

Teaser trailer

This post is about a gameplay issue, not an ant.

Scope
There is a timing issue that has been seen on an under-powered system. Though it can happen on any system, it may only impact lower end platforms which allow too large a time gap in between operations. Even so, applying this fix is recommended.

Problem
The game starts and presents the intro, which is a series of four combo story-help screens. Pressing a key to proceed to Next skips all the game levels, and displays the end game credits screen.

Fix
Edit the file gamelib/main.py, the function definition for _update_top_context() like so:

    def _update_top_context(ls, dt, simt):
        context_top().update(dt) if context_top() else None
        context_update()    # Add this line

The full main.py file with the fix can be retrieved here.

I uploaded a gameplay video to YouTube. Check it out here (or go check out the game itself!):

Not a complete game, just something we did put together in the few hours we could reserve for this.
Heroes want to save the Princess, you are the evil monster that wants to block them (him).
Everybody moves randomly in the map.
Heroes tend to go to the right towards the princess.
You (the monster) have to block the heroes before they catch the Princess.
You can click on doors in the map to close them. You can close max 3 doors at the same time, the fourth previous one reopens automatically.
You can click on left/right side of the screen to increase chance of monster moving in that direction (the monster image flips to show where he tends to go).
Pay also attention to do not kill the princess by yourself.


You need kivy installed https://kivy.org/ to run this game from source.
Differently, on windows/wine you can run the windows executable
As third option you can run it on android device (maybe also android emulator, I didn't try) by installing Kivy Launcher app available at https://play.google.com/store/apps/details?id=org.kivy.pygame&hl=en
You have to download the source files and unzip them on /storage/emulated/0/kivy folder (if it does not exists just create it).
Pay attention to not "double" folder tree when unzipping, this should be the final outcome:
/storage/emulated/0/kivy/PW22_Doors
and not /storage/emulated/0/kivy/PW22_Doors_v3_source\PW22_Doors
If files are properly copied you will see the game listed in the Kivy Launcher app.

To say the least, it was a wild week (where week is defined as mostly just the last 3 days of a standard week and then some). Off the top of my head, here's a rough summary of how this game's development went:

The Super Wicked Sick Nasty Radical Development of Super Wicked Sick Nasty Radical Guitar Game

Day(s)	What happened	Progress
1	Planning, mutual feelings of dread after realizing nobody in group actually knows Python very well (or at all, really)	0%
2-3	Desperate struggle to learn Python and PyGame while also preparing for start of school year, small amount of groundwork laid	5%
3	Valuable geography homework time (aka sleep) is sacrificed for creation, thorough playing of guitar mechanic	15%
4-5	Other game mechanics agonized over before simplest way to implement crude mockeries of them found	25%
5-6	Slapdash job of implementing game mechanics 80% complete	60%
6-7	Slapdash job of implementing game mechanics 86% (an A!) complete, graphics added (the lovely guitar at the start of this post)	70%
7-8	Slapdash job of implementing game mechanics 100% complete, work begins on fixing major bug (rest of graphics non-existent)	75%
8	Bug-fixing completed to acceptable degree by last 5 minutes before hard deadline	100%, I guess

Although our game ended up being.. our game, we felt it was pretty good considering the apocalypse of obstacles between us and actually finishing this game by the deadline. In fact, it is likely that the only reason we ended up having a game instead of a DNF was because the problems and setbacks we faced interweaved in some sort of cosmic, unknowable way to metaphorically bring our game crawling and at death's door to the finish line about 5 minutes before the event staff went home. The largest obstacles included school, gross incompetence, numerous other time commitments, and deep programming-related despondency. In the rest of this post, I will further elaborate on this game's development and some other related stuff.

Day 1: The journey begins (tomorrow)
Beyond what was given in the summary, nothing of note happened on this day.

Day 2: A casual stroll against time
This entire day was spent grokking Python and PyGame. We also decided on the game idea. Here are all of the ideas we had, copied verbatim from the planning document:

• A game where you have to stop guests from entering a house, you are a bird and poop on people
• Overused: Space shooter (Stop the aliens/asteroids), could do this with submarines
• A zombie style game, where you shoot down zombies and stop them from entering a house
• Tower defense style game
• Hold back, somehow control some people who are holding onto a rope, and they are holding back someone (or maybe an object/animal)
• Mooks vs 1 guy, You respawn a number of times as a "mook", and try to fight a boss
• Something like tower defense: a person attempts to get somewhere and your goal is to put as many obstacles as possible to make them late (difficulty comes by making strategies for different kinds of people with different capabilities)
• A sort of guitar hero game with arrow keys or WASD or whatever. Have a graphic where you playing guitar/whatever instrument is keeping people out of your personal space. If you done played too well then the people you don't want in your room/house enters.

We ditched the "guitar hero" part of the idea in favour of the current algorithms to determine music dissonance idea as we figured it would be less work that way, and replayability would be better.

Day 3: Trials and tribulations (MIDI and .mp3)
I personally spent around half of this day writing the code for the guitar. I spent about an hour deciding on the control scheme, 3-4 hours working out MIDI issues before giving up, 1-2 hours struggling in vain to work out issues with playing MP3 files before remembering that OGG exists and completely wipes the floor with MP3, and 2 hours actually programming.

This pattern of spending too long on a solution that is difficult to implement before spending too long on a simpler solution initially implemented incorrectly before finally getting it right would end up rearing its ugly head repeatedly, no matter how much begging and pleading and how many invectives were directed at it.

Day 4: The calm before the storm
School had already started at by this point, so we didn't do much. I spent all of my development time messing with possible ways to implement ways to detect the sonance of the player's playing: that is, how good or bad it sounds. I had written a cool patch in PureData a long time ago that generated a bunch of random sine waves and only played them if their roughness: something that I'm actually still not very clear on, but know it has something to do with how bad notes sound together, fell below a certain threshold. This model was used in both my old PureData patch and the game. In the meantime, the rest of the CAVE SQUAD spent their spare time working on various things and learning git. We didn't end up using git and GitHub very much, but it's definitely good to be familiar with a version control system.

Day 5-6: The actual storm
The team met up at the local library. One of Jason's friends dropped by, and by sheer luck, he was familiar with both music theory and fancy math stuff like Fourier analysis and fundamental frequencies, the 2 things the sonance mechanics needed and that nobody in the team really knew or understood. After talking with him, I decided to use the last 2 notes after being run through a fast Fourier transform as the model's inputs.

The next day was pretty much the same thing except it was just us 3, so we were completely clueless the entire time at the library rather than most of the time. The rhythm part of the sonance mechanic was added here. Also, after realizing that the game was still so unfinished and there was so little time left, I worked on the game until I accidentally turned my short break at 3 in the morning into a really long break. This was the day when weird stuff like trying to make our code maintainable or legible took a nosedive in importance.

Day 7: The bigger storm after the initial relatively small storm
The CAVE SQUAD began panicking as we realized that our game still wasn't very done and it was technically the final day of the competition. The rhythm and roughness mechanics were finished up, and the combo mechanic was added in the hopes of improving the fun of the game. It was also meant to replace a unified sonance value in determining whether or not the crowd would move toward or away from the player. Eventually, we implemented both in a pretty nice way: current and previous roughness and rhythm averages were compared, then -1 was returned if they indicated consonance or 5 if they indicated dissonance. The combos were then used as weightings for the sonance value, then the final result was used as the number of pixels to move the crowd. The core of the game was essentially done at this point.

Day 8: The hurricane after the bigger storm, or: Holy crap, how did we not DNF?
Panic amongst us members of the CAVE SQUAD reached a crescendo as we encountered a major bug: the game had pretty much no graphics. Sure, there were some nice pictures, including a coloured and additionally-stringed successor to the original dope_guitar (which can still be found in every copy of Super Wicked Sick Nasty Radical Guitar Game alongside its ancestor and almost every other art asset ever used in the game at any point in its development), but they weren't actually in the game. Patching (read: cutting and hacking while waiting for our standards to drop enough to accept what we've done) commenced and happened at light-speed relative to the rest of development. This bug was successfully-enough fixed with about 15 minutes to spare, although some components of the fix like the player firing different waves at the crowd that visually indicate when and how hard they get pushed back and moving the combo system from the command line to the actual game were left on the cutting room floor or not done at all due to time constraints. A bit of time was spent doing some quick last-minute polishing of the game, then it was zipped up and successfully submitted to PyWeek within the last 3-5 minutes of the submission deadline, unfortunately without a screenshot.

As far as development stuff goes, that's pretty much it. It was a grueling, but fairly rewarding experience: we all learned a lot about Python, our strengths and weaknesses, and the power of lowering and cutting expectations in the pursuit of success. Although the concept behind the game we find is pretty cool, the demands of the second year of the International Baccalaureate Diploma Programme mean that continued work on this game within the next 9-10 months will be anywhere from brutally difficult to laughably impossible, so this is where the story of Super Wicked Sick Nasty Radical Guitar Game and probably the CAVE SQUAD too ends.

TROUBLESHOOTING

1. If you are confronted by failure to run, there are three logs deposited in the game root that you can check:
opt-out.txt
pyknic.log
out.txt
You can also try run_game_debug.py. This prints copious messages to the console. You may want to redirect the output to a file. DR0ID and Gummbum will ask for these logs if you wish to report a problem, so save them please.

2. There's a bug when running on one Slackware system that we can't figure out. The game fails to present any of the levels, and goes straight to the end game credits.

3. When the mouse exits the window the game auto-pauses. This is by design. There is one report that exiting the window area with the mouse pressed leaves the vacuum powered on; a click in the window is required to turn it off. We could not reproduce this.

4. If you are having trouble with a specific level and want to bypass it, there are two ways to cheat: a) change settings.starting_level and (re)start the game; b) turn on cheats by touching cheats_enabled.txt in the game root, and using the ESC or RETURN keys to skip a level (documented in settings.py). You can note the current level in the game title bar while the game is running: L:n where n is the current level number.

TIPS FOR SUCCESS

5. Short sweeping attacks work best. Use them to advantage where several ants converge in a group or line.

6. Empty the hopper before it alarms. It's a bit inconvenient to race after a speedy or burly ant chowing down on your chips, and have that last ant fill your hopper. "Come on you slow thing..." Munch, crunch, chomp chomp chomp. :)

7. It takes a lot of juice to slurp up the burly ants. If you get low on power and there are still many ants to vanquish, slurp the little ones. You can pull the burly ones to a corner and take care of them later if there's juice left. Otherwise, you can make a last ditch effort to crush them with the dead vacuum. All ants, regardless of their toughness, are instantly smashed (but they are adept at dodging into the nooks and crannies under the vacuum, so crushing is by no means an ideal tactic).

8. If you got plenty of juice and a handful of burly ants to manage, you can get one stuck in the vacuum nozzle and drag him over to another. The peripheral suction is powerful enough on the T-1000 that the nearby ants will stop and cling lest they be pulled in too. This temporarily pauses their march toward your towers of chips.

HERE BE SPOILERS

9. Some folks may have trouble smashing ants with the dead vacuum after the battery loses all its juice. As any house wife knows, this is an extraordinarily difficult way to battle ants. Unfortunately, it is against battle ethics to use cowardly methods. So when the chips are down, regroup and retry. (Yuck-yuck. :)) Fortunately, there are only a couple levels where you may have to smash ants this way, depending on how many burly ants spawn.

10. Some folks may have trouble with the strong ants. Here are some visual cues. When the vacuum power is on and drawing near the ant, he will crouch and cling to the ground. If you move the vaccum over his head - directly above; move the nozzle around a little - until his legs start kicking, he is then officially stuck and after a few moments of struggling he will go into the vacuum.

11. The boss encounter works the same way as in #10. But the boss has mega hit points, so you're vacuum will overheat. Just give it a quick rest and get back at it. And yes, an ant way bigger than the T-1000 can be crammed into the hopper. It is, after all, the legendary T-1000 of olde.

12. The heroic end game treasure stash is 24 million potato chips. Surely that is hours of munching fun for all those disenfranchised ants. You have three choices to finish the game here. Only one of those choices is honourable. Choose wisely.

The original plan was for the game to be about not letting people in in traffic, but going as slow as possible was about as fun as it sounds so I switched gears (hehe) halfway through. Tested on 2.7 and 3.4, let me know if there are any issues.