Happened to be jamming out to music with my friend trying to call me when the topic was announced. Immediately made a connection. What if instead of Guitar Hero where you play good music, you're playing bad music to keep people out? Day one was lots of very spirited discussions about the feasibility of associating quality of music with Python as well as a way to determine what exactly is bad music. Trello board filled with 4 urgent tasks (mechanics), 3 on the backburner (graphics) and 2 ideas for/if we have time. Day 2: got one mechanic done being the gameplay itself/instrument. Graphics are rough at the moment but will get better. Code is priority right now. Guitar is a work in process. Tomorrow will be full on going hard on the mechanics, and graphics will start seeing a lot more focus. Hopefully get a prototype up and running! Not so bad for 3 guys who've never touched python....? Only time will tell.

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.