Bit of a Game Jam: Quadruple Town
This weekend, I participated in Bit of a Game Jam at London South Bank University. I’d never done a game jam before and I thought it’d be a good idea to get into the indie spirit. The theme that was drawn on the first day was “Clouds / Fractals / Vengeance.” I wasn’t entirely sure what that meant. Was it one theme of all three? Was it to pick one of those themes? We decided to go with fractals.
First and foremost, we had no artists. We had two options: try to make art by ourselves or steal from the internet. We decided to go with the second option. We downloaded all of Dan Cook’s art sets and just picked out what we could use. We immediately decided to do the game in flash. More precisely, Luke wanted to do HTML5, but I just wasn’t having any of it. Given the decision to go with Flash, we decided to use the Small World set since it was a Flash asset.
Initially, we tried to get something up and running quickly with Flex, embedding the swf using the [Embed] tag. Normally, we’d have asset loaders and libraries and all that kind of thing, but it was important to me that for the game jam, if we ended up making something decent, which we didn’t (SPOILER), that people could just download the swf and play it without having to worry about external dependencies and internet connectivity.
However, we quickly ran into an issue with [Embed] and getDefinitionByName. We wasted about 3 hours on this issue and eventually, I moved from having a single embedded swf as a library to lots of different swfs that I didn’t need to load symbols from. In the mean time, Luke implemented a working version with file loading and applicationDomain.getDefinition. As far as I was concerned, both solutions were terrible. At this point, I decided that we should just move from Flex to Flash.
So once we made that switch, half of the first day wasted, things were a lot more smooth sailing. I implemented a “fractal” zoom. What was going to be the centerpiece of our game would be the fact that inside the church at the middle of the screen was a smaller version of the whole island. So if you load up the game and click the church, you’ll see a small version of the island, Cloud Island. See what we did there? Two of three theme elements worked in! Also, if you click on the blue background, it’ll zoom the opposite way.
The math for this is pretty simple. The island is two layers, the background and the church. When a zoom occurs, I just add another instance of the island between the two layers, scale everything and fade the parts that are disappearing. At first, there was completely different code for zooming in versus zooming out, but after I got it working, it was pretty clear that it was just the same effect, but backwards, so I combined the code for the two.
The only hiccup we ran into with this was that these assets are relatively complex and scaling them up to be huge was causing havoc on performance. Specifically, when zooming in or out, we’d drop down to about 2 frames per second. We didn’t even have any of the tiles in at that point. It was just background and church. So I implemented a function that takes a movieclip and makes a bitmap version of it. This solved all the performance problems, but then we ran into collision issues. Bitmap collision is by the block, not pixel collision. Usually what I would do at this point is to use InteractivePNG, a library by MosesSupposes. This time, though, I decided against it. I had a hunch that I would need to rely on proper hit detection rather than event fiddling at some point, so I implemented something strange. For each movieclip, I’d generate a bitmap version. However, I’d also create a movieclip version and line them up. Then I’d add them both to a sprite and set the movieclip version to the sprite’s hitArea and hide it. This way, I got the rendering performance of the bitmap, but the hit detection of the vector version. It was a horrendous implementation due to overkill, but it got all the functionality I needed at the time.
This was about the end of the first day.
We didn’t know exactly what we were going to do for gameplay. We were thinking of doing something like Maquette where you needed to solve an issue on one level by doing something on another level. We never got there. Luke had the idea of doing a matching puzzle game. He told me at the end of day that he hadn’t realized that Dan Cook, from whom we borrowed the art, was the same person who made Triple Town. It just so happened that they used some of the same assets. Ha ha. Anyway, I gave it a little thought and I started coming up with a rule set for our game.
The thing that kept coming back to me was that I liked the idea of matching 4 pieces and it creating a piece that was the size of 4 pieces. It would add a bit to our fractal theme and create some gameplay that matched. The down side of creating a piece of equal size when matching pieces is that you never remove pieces from the board. So you can’t get the feel that you get with games like Tetris where you need to get rid of pieces before it all fills up. Given this constraint, I decided it would be a space management game. We would cram you in and force you to sort the map out with the limited spaces that you had. The extra catch was that if you wanted some more space, you could shrink pieces by picking up a piece and moving it into the church. So there ended up being 4 rules for what I ended up naming Quadruple Town.
1. Four matching objects in a square make a bigger object (Bush -> Tree -> House -> Gold)
2. Tiles can be shrunk, but not grown
3. Each tile can only be moved once
4. 1 point for each tile with Gold
I thought, although it was pretty broken as a game design and as a game implementation, it had some interesting ideas. I like the idea that shrinking pieces gives you more space, but drops the theoretical high score you can get. I like the idea that matching 4 tiles makes an object that cannot be matched with another of those tiles in either type or size. I like the idea that early mistakes can come back to haunt you terribly. VENGEANCE! THREE THEME ACHIEVEMENT!
So the second day we hacked things in bit by bit. I think we had implemented rule 1 by the time we had 1 hour left. It took us about 30 minutes to add rule 4. We took another 20 minutes to add rule 2 and I snuck rule 3 in at the very last second.
Other than the obvious bugs, there’s a lot that I would have done differently if I were to do it again. Firstly, I wouldn’t have wasted so much time trying to get Flex to work. I didn’t even have a working version of Flex anyway. I had Flex 3, but that broke when I installed Lion. We were using some ruby gem that compiled mxml files.
I definitely wouldn’t have made the island a cloud shape. It makes the gameplay unpredictable an infuriating. It also meant I had to write a goofy algorithm to determine what were valid tile positions. Oh yeah, I forgot to mention that. It was lucky that I decided to implement that bizarre version of bitmapping because it let me implement a raycast system to determine what were valid tiles and what weren’t.
All in all, though, I had a lot of fun and I’ve got this little swf to play around with. I think Luke and I have both committed bug fixes after the game jam. I think one commit each, but that’s more than I would have expected. Anyway. It was fun and I’d probably be interested in doing another game jam in the future.
Oh yeah, you can play the game here:http://quadruple-t.heroku.com/
And here’s the full source: https://github.com/lpetre/quadruple-t/
PS: Some snarky comment about how Quadruple Town is terrible, but still more original than Yeti Town. =)