What would game jams be like if they lasted 1–2 hours instead of 1–2 days? And to take it further, if jammers tried out a dozen game designs in that time rather than focusing on prototyping one? A bit like a brainstorming session with paper-prototyping materials, but still producing playable digital games as output, like a game jam.
We've been hosting rapid game jams to experiment with one way of answering that question. Our answer involves a parameterised mobile game engine (called Gamika) paired with casual-creator style mobile apps that allow player/designers to explore this parameterised design space rapidly, without coding, and with quick context shifts between mobile game playing and designing.
We call these design apps fluidic games, because they're playable like regular games, but leave as many design decisions as possible "fluid" and easily changeable at runtime. We've experimented with the fluidic-games concept in a number of contexts, of which rapid game jams are just one (other contexts include a longer-running after-school game-design club, and an AI-driven art installation).
Our first released fluidic game, Wevva, is free on iOS for iPhone and iPad (Android port in development). The trailer gives an idea of how it works:
(Note: "We" here throughout is the MetaMakers Institute of Falmouth University's Games Academy, where I work. My colleagues there deserve primary credit for the research discussed in this post.)
Game jams can be summarised as "accelerated, constrained and opportunistic game creation events with public exposure". They're often promoted as a forum for free-form experimentation that is quite different from traditional, more methodical and constrained game-design processes, such as those used at large companies, or even at smaller indie studios during "normal", non-game-jam development periods.
While they're comparatively free-form, though, what actually takes place at game jams is still largely software development, albeit rapid, messy software development along the lines of a hack session. Teams participating in game jams generally start with an idea that, after some initial refinement, is implemented over the course of the jam without major changes in design direction. The concept may be scaled down or modified if aspects turn out to be infeasible, and some directions may be pursued opportunistically, but the time is mainly spent on producing a working prototype of that idea, rather than more free-form design experimentation.
Due to the large proportion of time at typical game jams spent implementing a prototype, the experimentation that takes place is therefore largely of the style described as opportunistic programming, a form of design experimentation focused on improvisation within the context of technical implementation. This is understandable, since producing working software is hard; much of the advice to game jam participants focuses on how to simply finish a playable game in the allotted period of time. The results are interesting in their own right, but this does put the focus of game jams more on technical implementations of specific game prototypes, rather than brainstorming or playing with design spaces. This code-first style of design experimentation therefore emphasises specific facets of the much larger set of techniques that go into game design in its full breadth.
The jams we've held so far have been 90 minutes long, and partipants have primarily been school groups and other youth groups visiting Falmouth University. The 90-minute length works nicely from a practical perspective for these kinds of visits, because typically groups visit the university for either a full or half-day, and rotate between different departments and activities.
The 90-minute jams are split into three segments:
In the initial familiarisation period, participants play games that we have already designed and saved in the same design app, so they can understand the basic controls and start to get an idea of the possible games within the app's design space. There's nothing special about these built-in games, though. They were designed in the same casual-creator app, and they can be edited to produce other games in the design space.
After the initial 30 minutes, we give participants a brief introduction to editing games and encourage them to try out a bunch of different designs in the second 30 minutes. By this point, a number of participants have usually already unofficially started doing so anyway since the editing interface isn't locked out and from what we've observed, seems to be pretty discoverable.
Finally, in the last 30 minutes, we encourage participants to choose one or two of the games they designed that they'd like to share, and swap devices to play and comment on each others' games (games are also shareable over a network without swapping devices, but we've found this just adds complexity). In a few cases we've also had awards for best games in various categories. Participants seem to like that, but it's difficult for judges to actually play enough games and make award decisions within the time left.
We've held a number of these rapid game jams, and analysed survey and design results from four of them, reported in a recent paper. In these four, 105 participants from Girlguiding Cornwall visited Falmouth University as part of a larger Girls Can Code event, and kindly agreed to fill in surveys and let us analyse the games they designed to help us better understand the rapid-game-jam concept and improve the design app. The released version of Wevva is significantly changed from the one discussed in the paper, based in part on feedback from these jams.
Going forward, one of the big open questions is design of the parameterised design spaces that these apps build on. Parametric design is well established in areas like architecture, but parameter spaces there often fall out directly from a "universal" representation, such as a NURBS surface. It seems unlikely that games have a nice universal representation like this (though I'm willing to be proved wrong). And that's especially true when the parameters are supposed to be directly editable by end-users. Covering that is a post for another day, but later this summer we're going to present a paper on the method we've arrived at for designing these parameter spaces.
Paper: Swen E. Gaudl et al. (2018). Rapid game jams with fluidic games: A user study & design methodology. Entertainment Computing 27: 1–9.