Brainstorming for Online Game Jams Using Discord

Brainstorming for online game jams using Discord

During 2020, I facilitated brainstorming using the communication platform Discord at three online or hybrid game jams. Discord offers voice and video chat support and screensharing which are used in this method for brainstorming. Joining a voice channel with strangers can however feel intimidating, and at a larger jam, coordinating small groups requires a bit of organizer effort. This blog post goes over how it works.

Brainstorming is a social facilitation practice of game jams, in which the organizer helps jammers come up with game ideas, and in the form I’m used to facilitating brainstorming, also sets the jammers up for forming groups. Facilitated brainstorming can take many different forms, and this method using Discord is based on the Finnish Game Jam Association’s guidelines for brainstorming, put together by Elina Koskinen for GGJ 2020 – you can see her presentation slides here. Since the feedback on the brainstorming sessions was positive, I decided to share these experiences and the method used.

I’ve also shared my brainstorming Google Slides presentation for you to use!

Reasons to facilitate brainstorming in an online jam:

  • get more social interaction in the online setting
  • help jammers get started and 
  • help especially first-time jammers find teams and collaborators

If all goes well, at the end of the session, the jammers will:

  • … have a game idea
  • … have a team formed around that idea
  • … have a channel for continued planning with the team
  • … have talked with the other jammers, at least a little 🙂

To make this easier for you, I’ve shared my brainstorming slides. The session can be done in around 60 – 90 minutes, but might take less or more time depending on how many and how chatty your jammers are. The session is planned for around 20 people, but (due to Discord’s limits) up to 50 people can join.

I hope you find this helpful! 

Let’s get to it: Brainstorming on Discord

The gist of this method is the following:

  • Everyone joins the audio channel Main, and the organizer shares their presentation through a screensharing stream
  • After some brief information, everyone quickly introduce themselves
  • The brainstorming facilitator shows a category and choices in the stream
  • Participants join a voice channel that corresponds to the choice
  • For a few minutes, the jammers on the channel gets to know each other, and discuss game ideas
  • Then, the participants rejoin the main channel to get the next category
  • After all categories, jammers have some time to prepare a pitch
  • The pitches are presented
  • Based on the pitches, jammers who don’t have teams can join a team
A category can look like the following. In this case, jammers who prefer green join the voice channel #Brainstorming-2, and jammers who like blue join #Brainstorming-3.

The method makes use of three functionalities on Discord: text channels, voice channels, and screen sharing. Therefore the session works best in the desktop version of Discord. This method can also be combined with a stream on a platform such as twitch, but in our experience, the lag makes it somewhat less ideal that way.

Remember to let your participants know ahead of time when and where the brainstorming will take place. This way, your jammers come prepared.


This is the rough schedule of the session (1h 15min):

  • 15 min information and introductions
  • 25 min brainstorming
  • 20 min pitch prep time
  • 15 min pitches and team formation

Needs – jammers:

  • Headphones + Microphone or a headset
  • Download Discord (desktop version recommended)
  • Join the server

Needs – organizer:

  • Brainstorming deck (slides)
  • Recommended: exports of the brainstorming slides
  • Headphones + Microphone
  • Recommended: Webcam
  • Highly recommended: Patience

So let’s get to it!

Step 1: Set up Discord

The brainstorming session needs a little bit of setup on Discord. A challenge in organizing a game jam over Discord is to make the information easy to find for your jammers. My recommendation is to use separate channels for this brainstorming session, rather than your #general or similar channel – simply to make it clear. 

Note: To create channels you need the server permission “Manage Channels”.

Create the following channels:

Voice channels –

  • #Main  – A main stage voice channel for announcements and brainstorming information.
  • #Brainstorming1, #Brainstorming2, #Brainstorming3 – Voice channels for breakout groups. As a rule of thumb, divide your participant amount by four or five – it’s hard to discuss in larger groups.

Text channels –

  • #brainstorming-main – A text channel for your announcement slides. This is where participants will check for instructions and prompts, and where they will post their pitches.
  • #brainstorming – A text channel for your jammers to discuss their game ideas. 

To create the text channels, click the little plus-sign next to your channels-listing:

Give your channel a name and press create channel:

To create voice channels, click the plus-sign next to your Voice channels-listing. Then, remember to check “Voice channel”, name your channel and press create:

Test voice calls and screen sharing:

During the session, you’ll also need to do the following things. If you’ve never hosted a call on Discord before, or are unfamiliar with the user interface, it’s a good idea to run through the technical side with a small group before the jam, just to make sure everything works.

Joining voice channels

To join a voice channel, click its name in the channel listing. Ask your participants to mute themselves when they’re not speaking – clicking the microphone button does it. You can leave the voice channel either by joining a different voice channel or by clicking the phone button.

Sharing your screen

Start by joining the voice channel. Then, down on the left, click “Screen”.
In the window that pops up, choose an application window to share. In the settings screen, default settings are usually alright. The jammers also join the voice call, and then join the screensharing stream by clicking the stream’s preview in the voice call. 

More information about screensharing:

Moving members between voice channels

It can also be helpful to know you can move your members between voice channels – simply drag and drop users in the voice channel listing (note: you need the server permission Move Members to do this). Be careful though – it can be disorienting.

If you want, you can also set up roles on your Discord server – if you’re curious about reaction roles in a game jam setup, you can check my guide here: 

Example of my brainstorming deck – link: Chride’s Brainstorming Deck

Step 2: Prepare your brainstorming deck

Next, make yourself a brainstorming presentation. In our jams, we’ve used Google Slides downloaded as a PDF document – simple, static slides without effects or videos. This way no information is lost due to streaming problems.

Technically, you can do brainstorming without a presentation – but since audio quality may be dependent on internet connections, I highly recommend you use written prompts and instructions. To make it quick and easy, you can use mine! You can find my brainstorming slides over here: Chride’s Brainstorming Slides (Google Doc)

This deck is almost ready to go, but contains placeholders for times and names. Create a copy of the file into your own Google Drive, or download it and open it in PowerPoint or Keynote, to edit the times, and make it more your own. The presentation notes contain information on what the goal of the slides are. If you want to create it from scratch, here are the slide backgrounds for you to use:

Feel free to change anything you want — reorder the slides, or throw out or add categories to fit your jam better!

Step 3: Brainstorm

Now that you have your brainstorming deck and Discord set up, you’re ready to run the session! Remember to invite your jammers as well. The brainstorming doesn’t have to be mandatory, but I’ve found it’s good to invite all jammers regardless if they already have a team.

Here are some more quick tips:

Keep the criticism away

Keep the session light-hearted. You can give silly examples (cats are a crowd-pleaser) to show that there are no bad ideas during brainstorming. The goal isn’t to have a realistic idea at the end of the session, but rather, one that the whole team wants to work on for the whole jam. The work of refining the idea starts once everyone has a team.

Amount of categories

This depends a lot on your jammers, but typically around 5 are a good amount. In the slides I shared, there are 7 prepared for you!

Prompts as images

During your brainstorming session, it’s really helpful to post the categories as images in the text channels as well. This way if your jammers aren’t quick enough to rejoin the stream on the Main channel, they can still see the prompts. 

Step 4: Pitching

Once your jammers have brainstormed and worked on their idea for a while, it’s time to pitch! 

We asked our jammers to prepare an image or short description in writing, so that in case audio cuts out, there is a visual aid to remind the other jammers of the idea:

Our pitching sessions have usually been quite short. I’ve started the pitching session by reminding everyone that the goal is to find a team, and that if an idea sounds interesting, the jammers should boldly ask to join. 

After this, we’ve gone through the ideas that have been posted in the text channel. One representative of the idea at the time unmutes, and presents the idea, while the facilitator shows the pitch’s image or description in the stream. 

For one jam, we used a google sheet to keep track of teams and team names. Unfortunately, the anonymous nature of Discord can invite bad behaviour like trolling, so be careful with editing rights to communal documents. 

Generally, I haven’t cut off the pitches at 30 seconds, but in case someone goes on for more than 2 minutes, it might be good. At the end, I ask who the team members are, and what skills the team is looking for, and ask if others are welcome to join as well. Usually the answer to the last question is yes – but the organizer asking it alleviates fear of rejection.

After the game ideas have been pitched, jammers can pitch their own skills. Make sure to listen as well – these are jammers that it’s good to check in with, to see if they did find a team.

Keep notes of who is in what team, and create text channels and voice channels for the teams to work in. Make a small invitation message in which you tag the members of the team, so that they can all find their way, and so that jammers without a team can find the channel.

At the end of the pitches, I usually say a couple of words of encouragement. Once all the pitches are over, it’s time to help people find teams. If everyone found a team already, you can wish the jammers happy jamming!

Step 5: Helping teams form

And then, we get to the last part – helping teams form. If all went well during brainstorming, jammers already started gravitating towards ideas, and forming teams. But sometimes that doesn’t happen, and you’re left with perhaps one solid team, and a handful of jammers who want to work on five different games.

One solution is to suggest the “leftover” jammers form a team together, and work to Frankenstein their game ideas into one game. It usually works, but there might be someone who opts to work alone instead. In my experience with online jams, solo developers are quite common – and compared to on-site jams, solo developers can come from surprising backgrounds. 

A classic game jam constellation is a programmer, a designer and an artist working together, but game engines have become easier to use, and tutorials and learning resources have improved drastically in recent years. Teams might surprise you with what they’re able to achieve despite not having an experienced programmer.

Sometimes you still end up with lonely jammers. If they feel bad about not finding a team, perhaps you can make a game together with them? Still, unless you are organizing the jam for a group of students or children, it’s quite normal if regrettable that some jammers have a harder time finding a good team. Sometimes you can only do your best, and offer empathy and encouragement. 

Lastly – Good luck, and you’re awesome!

Online jams can be a really interesting social situation, but organizing one can be equally draining as organizing an on-site game jam. Social facilitation is a luxury, not a must, but it pays dividends in creating an encouraging and stressfree atmosphere. That said – it can be pretty stressful to moderate your Discord server, run the event and stay positive. So, keep in mind you’re only human – and you’re amazing for creating this game jam in the first place!

Let me know if you have any questions! 

Happy brainstorming and happy jamming!

– Chride

Ps – If you want to learn more about game jam organizing, you can check out and download my thesis “Game Jams for Learning” on ResearchGate

More from Chride’s blog:

Media Release: Run, Darling, run! – ‘Codename Darling’ update released for Windows, Mac, web and Android

Media Release: Run, Darling, run! – ‘Codename Darling’ update released for Windows, Mac, web and Android

An infinite neon noir platformer about the mysterious Codename Darling escaping Neon City

In this infinite, atmospheric platformer set in an alien jellyfish invasion, the player takes on the role of Codename Darling, navigating the perilous rooftops of Neon City. How far can you run?

To stay alive in this endless game, the player needs to time their jumps and double-jumps with increasing precision. A single lapse in judgment can send Codename Darling plummeting to their death, resetting the score.

The first version of the game was made overnight during Pocket Jam #5, September 14th – 15th 2020, in just under thirty hours. Pocket Jam #5 ran in conjunction with the Pocket Gamer Connects Helsinki conference 2020, and the game was awarded joint second place in the jam’s competition by the PGConnects judges.

The game’s aesthetic is inspired by film noir, as well as superhero cartoons and comics. The character animations were hand-drawn frame-by-frame by Lassheikki, and part of Neon city’s soundscape are field recordings by sound designer Rintanen. Krechmer’s layered and driving music pairs with the monochrome environment to set the scene for the moody, 80’s inspired dystopian megacity.

The new post-jam update adds major quality of life improvements such as level selection, sound settings and a high score, as well as updates to sound, graphics and music. Some changes have also been made to the game’s design, adding a double jump mechanic for gameplay variety and softening the learning curve. For fans of the original version (which features an unforgiving difficulty curve) the jam version is still available as a download on

Codename Darling is available to play and download for free on The game was created using Unity, and is available to play in-browser on computers and touchscreen devices, and as downloads for Windows, Mac and Android.

Credits & team:

Codename Darling was made by Henri Sarasvirta (code, design, postprocessing & Unity), Christina “Chride” Lassheikki (graphics, animation, VO), Simo Rintanen (sound design) and Leo Krechmer (music, sound design, additional graphis). Sarasvirta, Lassheikki and Krechmer have collaborated presviously on the Pocket Jam #4 winning game Mochabot Organic.

Pocket Jam #5 was arranged from September 14th to September 15th, 2020 as part of Pocket Gamer Connects (PGConnects) Helsinki 2020 by the Finnish Game Jam association. The jam’s submissions can be found at:

Contact – email:

classheikki [at]

Play and download ‘Codename Darling’ at:

Media images:

App Icon
Full logo
Promotional image


New article out – ‘Designing Games as Playable Concepts’ in DiGRA 2020 Proceedings

Designing Games as Playable Concepts: Five Design Values for Tiny Embedded Educational Games – article out in the DiGRA 2020 Proceedings

Hello everyone!

Currently I work as a research assistant in the Aalto Online Learning-funded Department of Media pilot project Playable Concepts under the supervision of games scholar doctor Annakaisa Kultima. During the spring, our team also included Solip Park (now doctoral student at Department of Media) and Tomi Kauppinen from Aalto Online Learning and the Department of Computer Science, with some additional support from programmer Teemu Kokkonen and game designer Noora Heiskanen. Our aim is to explore how tiny, embedded and partial games communicate – if they do – and how to teach new game makers to adopt games as a communication tool!

To further explain the framework, we wrote an article, and it’s now available in the DiGRA library (free for personal and classroom use!):

Designing Games as Playable Concepts: Five Design Values for Tiny Embedded Educational Games. 2020. By: Annakaisa Kultima, Christina Lassheikki, Solip Park, and Tomi Kauppinen.

Click to Access PDF in the DiGRA library.


Digital games transform our lives; they provide an opportunity to engage with other worlds in a playful way, in many ways similarly to what other forms of audio-visual communication (like movies, paintings or photos) have offered for a longer time. However, learning materials still use rather traditional ways for accompanying media, ranging from static figures and graphs to videos and animations. In this paper, we explore the notion of Playable Concepts: tiny games that are embedded as part of educational material instead of separate and standalone products. We argue that games could be in a similar role as static graphical elements in educational and communicational material, embedded in the text, together with other media formats. We suggest that the design space of Playable Concepts can be framed with five distinct design values: Value of Partiality, Value of Embeddedness, Value of Simplicity and Immediacy, and Value of Reusability.

Playable Concepts is a pretty exciting project in the field of game development education and educational games. In addition to the research, so far we’ve created a library of 12 moddable playables and a graphics and sound asset library for people to use that is CC-by-3.0, and written tutorials.

We’ve also organized a handful of workshops on the basics of game making for different audiences, including the Academic Mindtrek 2020 conference audience, the Turku Edu Game Jam for high school students, Aalto games students, and Aalto staff and educators in the A!OLE community. The global pandemic forced our concepts to become fully online, and so some of our workshops were carried out over Zoom.

PlayCo Workshop at Academic Mindtrek – Tampere, January 2020
PlayCo Workshop over Zoom – Topical content for March 2020
Asset library – CC-By-3.0 Licensed pixel art assets for games by yours truly

During the academic year 2020-2021, we’re further improving our learning resources, and looking further into science dissemination through games – How could researchers use playables as figures to help explain and illustrate complex concepts?

Take a look at the paper if you’re curious about our design framework, or head over to our Playable Concepts platform to start learning how to make your own playable concepts using Construct 3!

Tips for solodev game jamming

This post was written following my first solodev game jam experience, and originally published on the community March 30, 2020.

Are you considering flying solo for your next game jam, but you’re feeling a little nervous? Perhaps you aren’t that experienced a coder, or you’re just wondering what it’s like compared to working with a team?

I’m a narrative designer and game artist who’s all about game jams, clocking in at around 20 over the past five years. I’ve taught game development through jamming, and even wrote my MA thesis on game jams and learning. (You can download it over at ResearchGate if you’re curious about my findings)

Over the past week I tried my hand at solodeving a game for the first time for a game jam! The result is Grumpy Librarian, a visual novel / game made in Ren’Py. You can check it out and play it over here if you’re curious: 
It was made for the Aalto University Games Now! Online Jam 1, and this was also my first time doing a fully-online jam.

So what did I learn from jamming alone, and what are my tips to you? 

Let’s get to it – Solodev game jamming vs. team game jamming:

A note: This is not an exhaustive list, and in no way a guarantee that the game you make turns out good. But these are things I’ve found helpful. Take them with a grain of salt, or a slice of lemon if that’s your preference.

1. It is definitely possible, but you’ll have to make sacrifices

Let’s start off this list by saying; YES, you can do it, and NO, it doesn’t have to be the hardest thing you’ve ever done in game development. A solodev game jam can be super fun, and my Friday was mostly spent cackling at the project I was working on.
Making a game by yourself is also a very good exercise for any aspiring developer, since it makes it clear just how much work goes into creating a full game and how much expertise each role in game dev requires to achieve professional results. I definitely recommend it to anyone aspiring for a directorial role or designer role, since it shows you just how you deal with the responsibility of a full game experience.

One of the sacrifices you are making in taking on this extreme generalist role of solo developer is that your core skill probably won’t get to shine. Most people find it at least somewhat difficult to switch between tasks and different mindsets. For me, the experience made me more empathetic to how my demands as an artist or narrative designer might look to other disciplines.

Then again, when we’re talking game jams, we’re not talking professional results to begin with. I wouldn’t based on this jam game apply for audio positions at game companies, and I’m doubtful whether or not the game I created works as a portfolio piece in any of my core disciplines, even. Considering the time I had to create character art, it’s pretty amazing, yet on an objective level I can tell it isn’t up to snuff. Same goes for dialogue. And, of course, code, which leads me to…  

2. You don’t have to be a coder, but it helps, kind of?

 I am not a coder, but… // I am not a game programmer, but… // I am not a computer scientist, but…

These are all ways in which I’ve started sentences while teaching game development, because, even though I am not trained as a programmer, through game jamming and narrative design I’ve gotten proficient enough with code and scripting that I can read code. Not with ease – it’s kind of similar to trying to understand the meaning in a poorly translated Facebook post.

So, here are some of my strategies for coping with coding at a game jam as a non-coder:

1. Don’t panic – You can always ask for help, if you need it. I recommend having a person in mind to turn to if you run into big issues. It helped me not panic, and in the end, I didn’t need their help.

2. Focus on your strengths – be it art, sound, design, music, or writing. Make a game that emphasizes the things you are good at. You don’t have to prove your worth as a coder, so don’t. Is there a tool you already know? Use that, if you don’t explicitly want to learn a new one. Embrace the spaghetti code; embrace the bugs; embrace that the game has simple mechanics.

3. Start by modding a tutorial project – You have limited time at a jam, but I would still encourage you to start from an official tutorial project and modding it into your own thing. Learning the most basic ropes of your engine will save you time in the end, and the engines I’ve used so far have pretty good tutorial projects offered to get you started (Good examples: Unity, Unreal Engine, Construct 3, Ren’Py. Not so much: Godot, Twine)

4. Start by reading relevant documentation, and then look for examples on forums of how it’s used. This one I’ve learnt the hard way. For example, I spent over an hour fixing a splash screen issue for Grumpy Librarian because I tried to figure this out from forum posts and source code alone. I even looked at the game on different browsers to figure out where the splash screen was coming from. It turned out the solution was well-documented in the official Ren’Py documentation, and took all of ten seconds to implement through simply placing the splash screen in the correct folder.  Similarly, I spent a silly amount of time trying to adjust the volume of the music from looking only at the documentation, not understanding that the issue was about syntax.

5. In general, when switching between languages, syntax will be your biggest source of frustration. To be honest, my coding is at the level of “I guess I could make this well, but maybe I can get this done with simple if/else logic and for and while-loops?”. Again, I am not a coder, and you, an experienced programmer, are allowed to frown at me. The good part about that, however, is that most languages support all structures I can come up with. When switching engines, I don’t have to learn everything anew, and I don’t have to learn the engine fully to get started. You, an experienced programmer, are allowed to cringe at that statement. What will however frustrate you for the first few hours is syntax. I chose Ren’Py for this jam, something I had never used before, and compared to Twine, it is much, much stricter with indentation. It took me a while to understand why I couldn’t use ‘&&’ in my conditional logic statements (and I sighed so hard when I found out you simply use the word ‘and’ in python). My first two hours were spent screaming at error messages I didn’t understand. And that leads us to…

6. Error messages could be much, much easier to understand. You have my sympathy. This is true for any engine I’ve used. Ironically, the ‘easier-to-use’ engines and tools don’t necessarily have easy to understand error messages. The best strategy is therefore usually to Google the error message, but here the size, and activity, of the development community online matters. Depending on what you are working with, there is or isn’t a community of newbies like you who are asking the most basic questions. For Unity, there’s a lot of complete beginners asking silly questions about the first steps, so you’ll find answers easily, even if the engine itself isn’t the most beginner-friendly.

3. Deadlines and rules are arbitrary*

Look, you should aim to make the game happen in the time assigned for the jam, but more than that, you should simply finish your game, even if you run out jam time. Jake Parker, comics artist and the founder of Inktober, has two mantras that I strongly stand by (despite no longer standing by Parker): firstly, Finished, not perfect, and secondly, You need a product, not a project. This sentiment of finishing things being the ultimate teacher is also a rule in the game industry: Just Ship It.

Controversial opinion? Well, I’ve never been that respectful of game jam deadlines or design constraints, which comes from being a member of the fairly non-competitive Finnish game jam community. It’s all about fun, learning and building networks, less so than winning competitions. Think of it as a NaNoWriMo sort of challenge: everybody wins by participating, finishing something teaches you more than abandoning the project, and you are competing only against yourself. This strategy is actually the same for me as a solodev as in a team.

My strategy goes something along these lines:

1. Scope the game to fit the time-frame of the jam. This usually means a game that plays in 10 – 15 minutes, single-location, few characters and one game loop.

2. Realize I won’t be able to finish the game during the jam, because I got distracted from the initial design.In the case of Grumpy Librarian, distraction was making art for 7 characters.

3. Get the game ready enough during the jam, so that I want to finish it in the following two-three days, when I still feel motivated.

It usually helps if what I leave for after the jam is easy to do and fun. If you leave gaping holes in your game design, or big scary bugs in the code you won’t want to go back. But, if you just don’t put in the animations, or need to add some writing to a specific scene, that’s much more fun to do. After the jam, I (or team mates) usually only want to make changes that are direct and fast improvements and polish to the game. Which brings us to motivation in general…

4. Task lists help you keep up the motivation

From what I’ve talked to other developers, staying motivated during your solodev jam is harder than if you have a team cheering you on. I found it helpful to keep a task list. In the task list, I list out what needs to be done, but more importantly, every single thing I’ve already done. Seeing that row of green makes it so much easier to feel accomplished, and not feel like the list is endless.

Even if it’s just for myself, keeping a task list helps me focus. These kinds of lists are what I usually make if I am the producer at a game jam, and they give structure to what I’m doing.

Here’s my task list for Grumpy Librarian at the start of the jam:

Screenshot of partially filled in excel spreadsheet with columns for “What?”, “Status?”, and “Important?”. Categories I use are Art, Sound, Writing and Code. I divide art tasks by character assets, environment assets and graphic design / GUI.

Here’s my task list for Grumpy Librarian March 30th:

Screenshot of mostly filled in excel spreadsheet. Note the fleshed out character art list especially and red status of some essential code…

A few tips I’ve found good for your task list:

1. Let the list live. Some things will move about, some will be removed, some will be added.

2. Don’t mark things in red before you have green markings. Seeing the whole sheet in red is almost certainly guaranteed to make you feel demotivated.

3. Prioritize, but don’t get boggled down by what you’ve marked high priority. As you can see, one of the first things I marked OK was fonts. Why – the default font of Ren’Py isn’t that bad, is it? Well, it isn’t. But by switching the font I learned how to edit the GUI files, which was important. (Sidenote: Also, in a text-based game, typography is going to be visible on every single development screenshot...)

5. If no one is around to hear your terrible puns, does it make them less terrible?

Alright, here’s my last tip, and this one goes out to all of my game writer colleagues: it is funny, but not that funny. Practice a little self-restraint. Or then don’t. This is your chance to make a game that looks exactly like you want – in good and bad….

Hope you found my tips helpful!

Overall, I definitely recommend trying your hand at jamming alone. I still prefer working with a team, and in person, but if I can do this, so can you 🙂

Do you have any tips & experiences of your own? Questions?