The history of Sweet Jams
Sweet Jams is a project that my good friend Conan Veitch and I built in our second year of university. It was overhyped and overpromised, but it had great presentation and lives in infamy to this day. Sweet Jams is a monstrosity, but we all love it.
The course we were taking surrounded concurrency - basically, when computers need to multitask. A parallel in the real work is traffic intersections. How do multiple cars arriving at an intersection with stop signs effectively share the intersection? In Canada, if multiple cars arrive at the same time, you yield to the car on your right. However, what happens if four cars arrive at the exact same time? If each driver yields to the car on their right, everyone is stuck waiting on each other. In real life, some driver will be brave enough to go first. In computers, they will enter a state of deadlock.
The final project of this course was to build whatever cool thing you want, as long as it applied concurrency to solve some non-trivial problem. Some people built video game multiplayer servers, others used parallel programming to solve hard mathematical problems, but us? We built Sweet Jams.
What is Sweet Jams? What isn't Sweet Jams? Whatever our classmates asked about the project, we would answer ambiguously but confidently. ("Is it a music thing? Some kind of game?" "Yes!")
We had no idea what we were going to build. Conan really enjoyed games like Rogue, so he wanted to make a rogue-like game. I really enjoyed music video games like Rockband, so I wanted to make a rythym-based game. So, just like the Reese commercial, we just kind of mashed the two genres together and hoped a beautiful accident would come out of it.
Neither of us had really made a game before, but I was really interested in it. I was looking into learning OpenGL at the time, so I decided that the best way to make a game in Java was to use OpenGL through some wrapper library, which felt a little like calling assembly right from your code. (This was a bad idea.)
After bashing my head against the wall for a few weeks trying to write text to the screen, I eventually had some bare minimum proof of concept. I showed it to Conan. He said something like "Yeah, you can write text to the screen. That's what we do all the time, right?" I replied "No, no, it was much harder. This is like doing cool graphics card stuff."
I had kinda forgot we were supposed to do concurrency and then realized we only had a couple of days until we had to present. We had effectively nothing to show for my three weeks of work, though I did feel more confident about doing graphics work! It was too late to change the technology stack of our project, so we powered on through and hoped for the best.
I remember putting together a proof of concept of the game in class. One of my classmates said "Wow Kyle, your game looks like it's really coming along well!" I replied "While I appreciate the compliment, this is literally just me undoing and redoing a drawing in Paint." Things were not looking great with only a couple of days to spare.
We decided we would meet up the day before and stay up until the project was finished. We put on Space Jam for inspiration, ordered in some food, and got to work. We essentially did a game jam in one night. It was almost two in the morning, but we felt pretty confident on what we had accomplished.
We had built a weird disorienting Snake-like game. The twist was that anytime you collected a power up, something bad would happen like your screen would start pulsing, rotating, or flashing. The game got progressively harder to play as you collected more power-ups and the game got faster and faster. There were also obstacles and enemies that would end the game if you touched them.
The absolute best part of the game is that whenever the game state would update and all the characters would move. The game would alternate between saying "SWEET" and "JAMS". With a lack of sleep and sanity, we were in hysterics hearing our game say "SWEET JAMS" over and over again. It was just the right amount of stupid.
I was running the game through it's final tests, making sure that nothing would break when we went to present it. I wondered, "What would happen if I increased the number of enemies to 100?" I tried it and it worked a-okay. "How about 1000?" This was my critical error.
The game started and said "SWEET." The pulsating red background faded to black but never flashed red again. Everything stopped. It felt like the red heart of the game had stopped.
I looked at my console window:
java.util.ConcurrentModificationException
Uh-oh. I think "concurrent" was in the name of the class at university. This is bad.
I peeked my head over my laptop and looked over to Conan. "We, uh, might have an oops."
Conan looked concerned. "Like, a big oops or a little oops?"
"Give me a sec." I went back to my computer and went to fix what I thought the problem was. I didn't think it was actually a concurrency problem and figured it was a quick one line fix. My fix didn't work.
"...like a big oops."
Sleep was no longer on the menu.
As I said, one of the goals of the project was to do something with concurrency. How we implemented that was to have each enemy be on their own thread, meaning that they would work independently and in parallel. One of the things that each enemy needed to know is the state of the map - where each character was and where the obstacles on the map were. It would look at this map, do some thinking, and then reply to the game what direction it would like to move.
This worked great on a fast computer with only a few enemies. The game updated about once or twice a second and would slowly add more enemies and speed up. There was a hidden race condition though - the game state wasn't allowed to change while an enemy was looking at this map. If the map changed while the enemy was looking at it, it would lose it's place and get really confused. I imagine this as if a cartoon robot had reality change before its eyes, causing it's head explode.
We could easily hit this when we had lots of enemies, but this also meant that we could also hit this if we got good enough at the game to get to the higher speeds. We weren't sure what exactly the limit was but we couldn't think of a quick way to avoid it. We would need to basically rewrite our the "concurrent" part of our project to actually be concurrent.
Here's the commit with the rewrite. The commit message explains my mental state at the time:
Stopped leaking references
I HAVE TRAVELLED THROUGH CONCURRENCY HELL AND MADE IT OUT ALIVE
It was painful. Looking at the commit times, this took me between 3:00AM and 6:42AM to rewrite. Conan literally fell asleep with a textbook on his head while trying to do some marking during this time. Our backup plan was to have a ragtag barbershop quartet sing "We're sorry we didn't finish!" for our presentation. But after the rewrite... the game was invulnerable, and we felt great.
In our state of tiredness, we decided that the game needed some cheesy lines to help with the presentation. We just recorded whatever weirdness came to our mind and made a random line play whenever you collected a power-up. All of the lines are here, they're great.
We didn't have much time to do testing with others. Conan had the opportunity to show it off to someone and they hated it, which I guess is some measure of success? It turns out they were recovering from a concussion, and the spinning and pulsing of the game wasn't a good mix. Whoops!
We showed up just in time for our presentation. Our presentation was in a lecture theatre with a huge projector instead of the normal small classroom. We had put together some semblance of a presentation. The only part I remember is that it opened with the title Sweet Jams being revealed to the 2001: A Space Odyssey Theme Song. The audio was entirely too loud, and we might have listened to it for a full minute. I don't remember what everyone's reaction was, but it was the best a room full of second year computer science students could put together.
Our presentation was a typical computer science presentation: "Here's what we tried to do, and here's how it didn't work." Only ours did in fact have a working project at the end! We projected Sweet Jams on the large screen at the end of our presentation and played it live for the whole class to see. It was ridiculous.
My now-wife was in the lecture theatre next to mine. She said she could hear the loud "BOOF" noises through the wall in her class. It was a disturbing yet beautiful experience.
After all the presentations were finished, we yelled out that we were celebrating at the university's pub, and anyone who was interested could come play Sweet Jams there. We got a surprisingly large crowd, and things got pretty competitive. I had to make a commit to add a high score timer in the game, which I was pretty proud of considering we were a few pints of beer in. We kept track of high scores on a loose piece of paper.
My favorite part of Sweet Jams is that its legacy still lives on at the school. Conan went on to create Sweet Jams 2 for some upper-level class involving several programming languages (it had pixel art, multiple stages, and a sea shanty chiptune song!). Several newer students have tried to build the project from my GitHub but failed, so I created a runnable .jar release for the unscarred.
None of the code here was particularly interesting. The way we presented Sweet Jams meant that it would be instantly memorable and forever live in infamy. I learned that you don't really learn something until you do it the wrong way. However, the thing that still sticks with me today is that the professor only had this one question for us when grading: "You guys learned something, right?"
A lot.