It’s just your typical high school dance, full of awkward and confused teenagers. Play Cupid and shoot your arrows into matching pairs to help them find true love! (Probably not...) Match everyone by midnight when the dance ends, but be careful not to mis-fire or hit the obstacles!
Use the mouse to aim and shoot arrows through matching boy and girl pairs.
This was the second game I created for my Experimental Games class. After the first solo project, the class became a series of mini game jams: every two weeks, we would be divided into new groups of one artist and one coder to create a game based on a single-word prompt. This first project's was "Love", and so my partner and I decided to create a cupid shooting gallery set at a high school dance. The underlying social comment about jocks, band geeks, and goths only pairing up with other jocks, band geeks, and goths was purely coincidental, I assure you.
As for the "experimental" part, a lot of the things I had never tried before ended up being rather trivial to implement, such as screen wraparound and sprite rotation towards the mouse position (to aim shots). It was only slightly more difficult to make the "mis-fires" affect the larger game, such as having a hit speaker turn down the sound volume, or a hit light darken the screen. One of the more creative ideas was how I managed to avoid doing real animation by instead implementing a simple sprite-swap on all of the moving objects. Every half-second, the displayed sprite just toggles back and forth; no further complexity was necessary.
The matching aspect was implemented by giving my Target class both matchID and genderID member variables. The matchID represented each target's social status (jock, geek, and the rest), and originally that was all I was using. Then I watched one of my playtesters pull off a shot angled such that they were able to use one arrow and hit two girls of the same type, next to each other at the very edge of the screen. That player both made a match and rendered the game unwinnable afterwards. genderID was introduced to solve this problem.
One last point: generally sound effects in Unity live on the GameObjects that need to make use of them. But in this game, things were getting destroyed or deactivated all the time, and the sounds wouldn't get a chance to play. How do you play a sound from an object that's no longer around? The answer was Unity's PlayClipAtPoint() function, which I could pass the sound effect to before the object was gone, then have the built-in AudioSource class take care of the rest.