The Framework

The Secret Sauce

💡 The “secret” to making any OGD Cohort work is **the community.** Not the community created by OGD, but the community that **exists before OGD starts.**

One of the strongest factors for motivation, engagement, and safety noted by participants was Cohort 1 was proposed within a community that already existed, that was reasonably safe (a moderated, private discord based upon shared marginalized identities with a verification process), where people at the very least knew of the person proposing the program and the other participants.

Most participants would not have considered joining if it didn’t start within the community, and all most all report they would have been less motivated and engaged.

Values

Below is a list of values that were either established at the community level, or were requested of the cohort and the participants.

Community Values

Taken from the #rules channel of the private discord

• be excellent to each other
• take things in good faith, be patient, let people have boundaries
• ask! (before DM’ing people etc, respect boundaries)

Cohort Values

• No shame. It was made clear participation was opt-in, as people could sustain. If people needed to drop, they could. If they wanted to return, they could. A number of people dropped as life responsibilities grew, and a few even returned by the end of the Cohort!
• Time boxed. The cohort was not going to be a infinitely long pipe dream project. The deadline was set at 3 months of production time, and the cohort would have to work backwards from that timeline to decide what was in scope.
• Collaborative. Decisions were to be made semi-democratically, while allowing people with expertise to take ownership of areas. No person would be involved in every decision, but all doors were open.

Participant Values

The values requested of participants:

• Collaborative and generous spirit. We’re here to work together. To learn together, to create together. If someone else around you isn’t where you are, be encouraging. If someone else around you is further in their career, don’t put them on a pedestal. We’re here, as human equals, from dramatically different walks of life to make something, together.
• Honesty. The success of this project is deeply dependent on honest self-evaluation of our own talents and skills. If we set a scope too high, or a feature too complicated because we oversold ourselves and our abilities, that only hurts us.
  • We are in control of the scope of this project, and therefore will do our best to adjust it so that we have time for everyone to contribute and learn. But just as we want to be flexible to incorporate everyone, you have to be flexible in how involved you can be.
  • Please do not oversell (or undersell!!!) yourself in the survey. It will only make our lives harder in the future when deciding on scope. The survey is not an application. It’s just information gathering. If you’re already in the server, you’re already eligible to participate.
• (Your version of) Consistency. One of the first things we’ll do is draft a working agreement that outlines how we expect ourselves to act, communicate and collaborate. A large part of this is expectations, and expectations are easiest to have under consistency. Even if you’re Consistently inconsistent! The amount of time you elect to contribute to the project (averaged over a week) will help us determine what work you can take on, and therefore what we can collectively accomplish.
• A sustainable mindset: This is not a three-month game jam marathon. This is going to take time. It will be smaller in scope than any of us want, and that’s because we’re going to finish it, under reasonable workloads that we can contribute to without damaging ourselves. For some people that could be up to full-time. For most it will probably look like less than part-time, and that’s not only okay, but encouraged.

Logistics

This is a rough model of the logistics for Cohort 1, improved upon by the lessons learned in the post mortem. Cohort 1 was a success, but not necessarily a sustainable or repeatable one. These recommendations should be taken with an enormous grain of salt, and the knowledge that Cohort 2 may have dramatically different logistics than the previous one.

Staff

Active Staff

It is recommended you have an active “staff” person per 4 participants. They attend every meeting, and are generally very active, as participants are relying on them. Staff’s purpose is to:

1. facilitate the project,
2. conduct and organize meetings,
3. check in with participants,
4. lead production processes
5. diagnose and resolve development roadblocks
6. provide guidance towards things like scoping and high level processes
7. help integrate participants work into that game

These responsibilities can be be broadly separated into 2 roles:

• A producer: leads the process across many responsibilities
• A developer: participates in guiding the process, lends technical knowledge, and responsible for making sure all participants work gets integrated.

Mentors

For domain specific problems, or to give guidance to staff members, it is recommended to have mentors. The involvement of a mentor is dramatically less, occasionally attending meetings and chatting with staff members. Identify the weak spots in your staff and cohort early and seek mentorship in those areas.

Philosophy

Active staff and even mentors form the only layer of hierarchy that should be present in an Open Game Dev project. That hierarchy should be acknowledged, and the purpose of it. And staff should approach every interaction as a peer first. Many of Cohort 1’s participants expressed they were subjected to strong power imbalances and hierarchical prejudice in their day to day, and found the high trust, peer-like, open collaboration to refreshing and deeply moving. The purpose of staff is to help the participants have an enjoyable learning experience. Not make their dream game with free labor.

Timeline

Application: 2-4 Weeks

Write a proposal outlining the project, it’s goals, and it’s timeline. Put this out into what ever community the project will be taking place in. If you are not a part of that community, it is highly recommended you either partner with someone who is an active participant in that community, find a community you are an active participant in, or become an active participant in it first.

💡 Before the project starts, the only person(s) related to the project are the proposers. This can make a big difference to who will be interested in participating.

Regardless of if there are selection criteria for the cohort, there should be an application / survey to join the cohort. This is to collect important demographic data to help prepare the staff.

We ended up asking for:

• Names
• Email addresses (for calendar invites)
• Discord usernames
• Game dev experience
• Game dev tool experience
• Source control familiarity
• Areas they wanted to work in
• Personal goals for the project

Having this information up front helped us prepare the cohort to start on a good foot.

First Meeting: Working Agreement

The inaugural meeting of a cohort is the perfect time to establish the norms and expectations for the project. Cohort 1’s working agreement covered:

• Meeting cadence
• Async communication norms
• Ownership of the game and assets
• Production norms

It’s really important for the working agreement to feel as though it has been made by the participants. Without their contributions, it won’t reflect the needs of the cohort, and its unlikely anyone will follow the agreement.

Ideation: 2 Weeks

It is recommended to start the project with a time of open ideation towards what game the cohort will work on. While this process has some risks, if done well, leads to a bought in cohort who will show up even during times of ambiguity because they are invested in what game they are making.

It is recommended you start the ideation by acknowledging the constraints around the project. For cohort 1 it was:

• The tools: Unreal Engine, Blender
• The production timeline: 3 months
• The number of (starting) participants: 12
• The strengths of the cohort as a group

💡 When ideation starts, it’s important to ask people not to contribute ideas they are attached to. Game development is a complex and messy process, and what is ideated and agreed upon is not always what ends up getting created. People pitching their “babies” can make a very productive ideation and production process go sour very quickly.

With those constraints up front, we then did some brainstorming exercises to identify themes, mechanics, genres and art styles individuals were interested in. The facilitators then identified commonalities and developed them through group conversation. During this process, its really important to have active staff members to guide the conversation. It’s important that the final game is within a reasonable scope for the timeline, and does have outsized expectations for any particular area of development.

Production: 3 Months

Production will look different for every type of game, so this is just a list of suggestions:

• Get everyone in engine immediately. Teach them how to use the source control. Teach them how to run the game. It’s important for every individual to feel connected to what they’re making.
• Get a working skeleton ASAP, even if the “game integrator” has to pitch in. The faster you have this, the easier people can contribute to the game, the higher morale will be.
• After the working skeleton, break down the remaining timeline into milestones. Dedicate a milestone to polish.
• Use a simple task tracker. Think trello. Teach people to estimate, and break down work.
• Run meetings regularly, the recommended cadence is once a week. Plan the meetings, provide meeting notes for all participants.
• Encourage participants to meet outside of the regular meetings, to talk about ideas, collaborate, and give feedback. Participants from Cohort 1 reported their 1:1 times with other participants as some of the most productive and motivating moments in the project.
• Dedicate the last 20 minutes of the meeting to two things:
  • Have people update their tasks and estimates for the week.
  • Give time for people to schedule 1:1 meetings with each other. Start by suggesting a meeting, or schedule a check in with a participant. If 1 gets scheduled often many more will follow.

Process recommendations

• Try to avoid changing tools, but do so if it needs to happen.
• Try to avoid dramatically pivoting the game, but do so if it needs to happen.
• Make meetings accessible. Text chat should be an viable and encouraged way of participating. Don’t require video. Take breaks, at least 5 minutes every hour.
• Let the participants speak first, encourage them to engage, but move on if no engagement is happening.
• Have a different participant take notes every meeting.
• The less experience a participant has, the more structure they will need, and the less likely they will be able to express what kind of structure they need. Provide structure, check in, and experiment with it.
• Keep all documentation available to everyone. Ideally on a collaborative tool like Notion.
• Use a locking source control! PlasticSCM is a good choice for cheap and usable.
• Make the initial game pitch smaller than you expect.