Did you work in a team?
We are a team of three people, each with fairly specific roles.

Music and Sound Design: Niall Reynolds.
Artwork: Chris Wu
Programming: Ted Bendixson

Overall, we would say it has been a fun experience. I think the team worked well together, and we seemed to have natural slots for everyone's abilities.

By design, the team has complimentary skill sets.

Was the resolution a challenge?
The biggest challenge is clearly communicating gameplay ideas with so few pixels. Since this is a puzzle game, you can't communicate a gameplay idea that requires a ton of detail or you will lose players.

For example, how do you communicate the idea that the moose will charge at you and you can't move into a space where he will hit you?

With this constraint, we had to rely on solid colors and layering of sprites to get people to understand.

We couldn't use an arrow to indicate the direction the moose would charge because it is possible to stand directly in front of a moose while it is angry.

Interestingly, I think the constraint led to us making better decisions than we would have otherwise, since there simply was no option to solve a problem by using highly detailed artwork. We had to pick the simpler thing.

The other challenge is the relatively small tile map. With just 8x8 tiles, it's difficult to come up with many interesting puzzle ideas. It really forces you to cram puzzles into a tiny space and to work with what you have.

We still came up with some interesting puzzles that fit into the space, but I think we could come up with some better ones with a slightly more expanded tile map.

What did you learn?
It's hard to get a game to work well and look good when it is contained inside of a webpage. We did a bunch of game engine work before the jam started, just to get a head start on working with Web Assembly.

That said, we still did quite a bit of HTML / CSS and browser support during the jam itself, and I think some of that work could have been avoided and spent on more game-specific things.

Also, having to use raw WAV files for the audio can be quite limiting, and in the next jam I want to make sure our web-based game engine supports compressed audio formats like mp3/m4a etc.

That way, we can cram more sound into the game without increasing load times.

On the organizational side, I think it was really helpful to quickly pick a game idea early on and just go with it. We had settled on the idea by day one, and just ran with it the whole time without going back and questioning it at all. The team had good cohesion in that regard.

We also learned that spending roughly 1/2 of the jam on polish is the right mix. We had more or less wrapped up gameplay by the end of the first week, and then we spent the second week doing nothing but polishing it.

The amount of time given, two weeks, was kind of ideal. Two weeks is enough time to scratch the surface of a new gameplay idea, to suggest that there might be something deeper. You do the gameplay in the first week, and then you polish the second week.

I have learned that I probably wouldn't want to do a shorter game jam since I would be rushing to do gameplay and wouldn't have much time to polish it. I would have to choose between exploring new gameplay or having something nice and polished, which sort of defeats the purpose of a game jam (in my opinion).