A few months ago I took part in my first game jam. While I’d told myself I’d take part in some of these as they cropped up, I hadn’t expected to get invited to take part in one of these so soon after starting my degree. I didn’t entirely feel ready for it, but at the same time it seemed like an exciting opportunity to get a better sense of the practicalities and challenges involved in game development. The team leader and myself reached out to some of our peers, eventually finding ourselves an artist and an additional programmer (who later became our main programmer). I worked mostly as a designer — brainstorming several ideas around the topic of climate change and sustainability, some more practical and realisable than others. I pitched these ideas to both the team leader and the rest of the team; we made some edits, and I accommodated some of the suggestions which seemed to work well with the design. I later developed the game design document for us to refer to and edit as we went along, detailing the various tasks we needed to complete over the two days.
When the game jam arrived, one of my main jobs was simply in populating and maintaining a board of user stories for myself and the rest of the team:
Maintaining this was surprisingly exciting for me — it was my first experience of seeing a design gradually become a reality as assets got made and features implemented. Members of the team picked tasks from this board, moved them over into the ‘working on’ column, and finally into the ‘To Test’ or ‘Done’ columns. I felt like I was developing a practical sense of the workflow of a development team.
The design in question had the player guide and nurture a sapling into a fully-grown plant of sorts, steering it as it grew upwards towards sources of nourishment (rain and light, most notably) and away from area-specific obstacles (stationary and falling branches, acid rain, smog/pollution, thunder and lightning). It was designed to be a fairly minimalist (directional controls only) game which had a certain narrative arch mapped out onto the environment and gameplay: the player would begin in the forest clearing, make their way through to the tree tops, break through to witness the smog and pollution of an industrial world, before struggling against the storm clouds and breaking through into the epilogue. The design was built around a specific play experience we had in mind: something meditative and reflective, letting the player experience the act of cultivating and protecting something precious (while reading some text prompts I wrote for it). The game, while nothing exactly groundbreaking, was designed to reinforce the overall theme of guiding and nurturing the planet. The tone isn’t something I naturally go for — I’m much more used to having downtrodden or bittersweet tones rather than consoling ones — but for the purposes of game jam in question I decided on something quietly optimistic (a bit like, for me at least, the closing lines of The Lorax).
But it would be dishonest for me to dodge around it: I personally wasn’t too happy with the final product. I found the experience of the game jam incredibly rewarding but I feel there was a lot more we had to give. On the one hand, it taught me about the necessity of certain compromises within a development team (particularly in a time crunch), but on the other hand it taught me there are certain things we shouldn’t compromise on unless we absolutely have to. In planning out five different areas for certain tones, narrative moments, and gameplay experiences, we’d spread our resources thin — there was only so much a single artist, for example, could do in that time frame. In spite of the stress, we always tried to keep our calm, have feedback sessions and scheduled breaks, and treat each other well. It was towards the end of the first day that I had a good conversation with our team leader who seemed to voice some of my own concerns. We were at a point where we knew we wouldn’t be able to complete most of the original design — the question was now a matter of how much of a finished product we wanted. It would have seemed unthinkable to me at the start of the project, but I needed to revise the design so that the game took place within one level. It wasn’t easy, but over the remaining hours I revised the design in accordance with how much we could feasibly get done, aiming at the very least to deliver the core play experience of ‘a short, reflective game of nurturing and cultivating something precious’.
I think on the whole we coped well as a team. We didn’t crack under pressure, we always made an effort to keep our hopes up, and we’re still on very good terms on the other side of it. I took several notes during this game jam, particularly of some of the lessons I was learning. Most of all, I took note of the things I could do better:
- If I think a feature’s really important to the play experience, make sure, personally, that it gets implemented. Push your team to make something they can prove has been implemented fully. In some cases, implement the feature yourself if it’s within your ability — being able to contribute something tangible or practical can be invaluable in team-building exercises like these (especially with a time crunch).
- Be very clear about what you want, especially with your artists. It’s always better to be too specific rather than less specific. Do a rough sketch for them and make sure they understand (potentially ask them what they think you mean). It’s worth the risk to be overbearing in the beginning in order to stop them spending time on something that isn’t to specification and can’t be used.
- Don’t be too ambitious with your game design. If you have strong narrative interests for your design, ensure the narrative arc can be realistically achieved in the time frame with your team. For the design itself, be as creative as you can when brainstorming, try to think outside of the box, but then ask yourself how much of this can we feasibly get out within this time, and is that amount enough? And, more fundamentally, ask yourself whether the core gameplay loop provides enough that couldn’t really be undone by a lack of content/levels. An MVP should largely be about getting these core mechanics working correctly.
I find it incredibly beneficial to generate and consider constructive feedback like this for myself. In terms of what I think went well, personally, I believe I had an organised workflow, checked in with the team regularly, generated a generous number of ideas for us to work with, and was willing to make some compromises to ensure we had a ‘complete experience’. There is, and will probably always be, things for me to improve and bear in mind. I thoroughly enjoyed this experience, and having the opportunity to design for and coordinate a team was both a pleasure and a privilege. I’d be eager to do something like this again.
