Video Game Production With Codecks from A to Z

Case Study for how Maschinen-Mensch uses Codecks.

Codecks is created by game devs using it to create actual games. We think that gives us invaluable insights for designing Codecks. But how do we actually use it ourselves? You’ll learn (almost) everything you ever wanted to know about how the indie games company Maschinen-Mensch (co-creators of Codecks) handles the game production process with Codecks.

Read on if you’re interested in which project structure we apply, which processes we use and how we manage our community with the help of our trusty Decky bot.

Project Structure

Codecks represents tasks and documents as cards that live in decks. Cards are quite flexible and can contain any type of information you choose (e.g. documents, tasks or bug reports). This allows us to not only maintain all our tasks inside of Codecks but also our full game design document.

To allow switching seemlessly between both we apply a deck setup which we call the ✨hero’s journey✨: we create one project that contains game design docs, and one project that contains production tasks. We use journeys to link between these projects in a magical way. I’ll describe how that works now.

Game Design Project

Our Game Design Documents (GDD) project contains decks organized by player-facing areas of the game. These highly depend on the game that we’re currently working on.

Each card inside these decks describes the design of a distinct entity type. Some of them might contain well-defined and complex game design and content descriptions.

The card text editor allows us to write up big documents with complex formatting and to link between different related areas of the GDD project. Often these cards will contain various image attachments and links to other related cards.

Some of the cards might also just be very loosely described (e.g. “giant snakes 🐍 are cool”). We like to keep everything in our idea decks, from small idea to big center pieces. You can think of the content in these decks as the backlog of all our content ideas for the game. Not every idea card will make it into the game, but generally all ideas that make it into the game where at some point a card inside the GDD project.

If you’re a scrum-aficionado you can think of these GDD cards as kind of user stories in that they focus on outcome instead of specific work tasks.

Production Project

The production project contains decks organized by developer-facing work areas (you might also call them departments). These highly depend on team that is currently working on the game.

In contrast to the overreaching cards in the GDD project these are filled with concrete work tasks that are done by individual members of the team to implement an idea into the game.

Connecting GDD and Production with Journeys

In the hero’s journey implementing an idea inside a GDD deck means breaking it up into individual task cards inside the production decks.

These tasks can be formalized into a repeatable pipeline template inside of Codecks, called journeys. Journeys break up game design ideas into actionable tasks in an automated in a super intuitive way.

For the location ideas deck we set up a journey that contains 7 cards representing the 7 steps laid out above. Once we’re ready to commit to one of the various idea cards within the deck, we can start the journey on that card with just one click.

Triggering the journey automatically creates the fitting sub cards and attaches them to the original idea card, which now becomes a so-called hero card.

Hero cards allow you to bundle up related tasks and to quickly check their overall state. They allow you to quickly jump between the sub cards making sure that everybody knows what the overall goal of their individual sub card is and that no task is forgotten.

Each of the sub cards can be customized with a default title and text, priority, owner, effort, tags and deck. You can leave the sub cards in the same deck where the journey is defined, but the hero’s journey is in full effect if you customize each sub card to be placed in the fitting task deck inside the production project.

This gives us an amazing overview for our video game production plan! Browsing the GDD decks we can see all the content that is planned to be in the game, along with information how far their implementation has proceeded. At the same time since the actual task cards are inside the production decks, it makes it easy for team members to find relevant cards inside their production deck (e.g. programming or animation) indepent of which GDD goal they originated from.

From a production stand-point it is also easily to identify which work areas are facing the most tasks to do. There is even more to hero cards and journeys, like the template card and using hero cards for other purposes too. Check our manual page to learn more.

CEO Project

Apart from the CE2 projects, we also have several other projects. One special project is the CEO project where we keep confidential business information. To restrict visibility to that project we use the guest role, which allows to limit which projects a team member can access. We use the CEO project for cards that contain sensitive information that can’t be shared with the full team for privacy reasons.

Additional Projects

Beyond the two main projects for CE2 we also use several other CE2 projects for specific freelancing areas. Using the guest roles described above, this allows us to restrict visibility to only the area that the freelancer requires to see, which makes their life easier. Instead of seeing dozens of decks, they only see the few decks that they require for their work.

Team Meetings

We work with weekly sprints loosely inspired by Scrum. For each week we manually set up a invidivual milestone in Codecks.

Daily Sync Meeting

We used to do a scrum inspired “What did you do yesterday, today, what is hindering your work”, but we found that these questions are already answered very well by Codecks, so since switching to home office during the Corona pandemic, we moved towards using the morning meeting to just have some shared smalltalk in the morning. We usually talk about what we did on the weekend or what games we’re currently into.

Sometimes this is a good time to remind the team about some important upcoming milestone or quickly clarify something. The later part usually happens in small breakout groups that stay in the call after the call (we use google hangout).

Planning Meeting

We have our weekly sprint kick-off on Wednesday morning. Everybody plans their tasks on their own. This happens quite organically by picking cards from the appropriate task decks and moving them to the next milestone. The Wednesday morning meeting is then used to present to everybody what you’ll be working on this week. This is an opportunity to make sure that you have all the support you require to do your work and that we’re making sure that we’re working on the right things.

There is a strong argument to be made for using proper story points but we’re using a time based effort system, where each point corresponds to around 2 hours of work. 0 points go to tasks that take less than 15 minutes to complete. 1 point for 2 hours, 2 points for 4 hours and so on. We assume 3 points of work per full working day (2 hours are spent on extra activities like meetings, conversations, the computer randomly rebooting and other activities that happen during the workday that are not tied to the planned tasks).

During the meeting we take turns in sharing our screen and presenting our cards in the Codecks milestone. In contrast to Kanban tools Codecks allows to slice and dice the cards as is most useful right now. During the meeting we usually sort by owner, seeing exactly how much everybody has on their queue for the upcoming week. The number next to each team member shows at a glance how much effort has been assigned to that person and we can quickly spot if somebody is overbooked and make some last-second modifications.

So often the milestone might also contain cards from the bonus category that we plan to do if there should be time left (there usually never is).

The planning meeting surfaces situations like:

“Oh, I didn’t you realize that you wanted to work on this already, let me give you my insight on something I didn’t mention before”

“Mhmm that task is not needed anymore because I found another solution which I forgot to mention”

“Ah, you’re working on that! You’ll need this other thing as well that you might not have thought about”

In general it gives everybody a chance to get on the same page and builds shared excitement about where the team effort is going next.

Review Meetings

Our reviews happen on Tuesday evening. We take turns in presenting what we have accomplished during the week. Again since we’re in home office, this means sharing our screens and filtering by our own card (shortcut q) and sorting by priority usually.

We make sure to enable the archived card filter, so that cards that were done earlier in the week are also present. We discuss all the green cards and briefly talk about the undone cards as well. Where it makes sense we jump into the game and show the content in-game. For content that is more complicated to show in the game, some team members add images of the accomplished work as attachments and use these to illustrate their progress during the review.

We’re constantly communicating and reviewing through-out the week via Codecks conversations, but for sake of efficiency not everybody will be involved in the dozens of reviews that can go on during a week of game production. Like the planning meeting, the review meeting allows the whole team to sync up with the rest of the team outside of more detailed review rounds that happened on the individual cards throughout the week.

After the review we reserve some time for a loose retrospective: “What is bothering you? What is hindering your work?”. Sometimes these topics naturally emerge during the daily syncs but we found that having a dedicated space for asking this question sometimes surfaces additional points. This is the time to rant about bigger topics, like feeling worried about the overall state of some feature or talking about bigger team improvements.

We recently also started doing fun homeworks for the retrospective meeting.

Sometimes these are silly and just serve to spread some good mood. Sometimes these can surface potential areas of improvement that did not appear naturally in other spots.

Since switching to home office we’ve noticed a lot of improvements about allowing team members more control over where and how they work, but we also miss the spontaneous and unplanned communication that errupted organically in the office. Making room for those through meetings that are specifically not super formalized helps in countering that drawback.

Other recurring meetings

We also have a bunch of other recurring meetings. On a weekly basis we meet for:

• Weekly biz strategy meeting
• Weekly CEO meeting (Johannes and me are both CEO’s of the company)
• Weekly game design meeting (if conversations on cards turn too long we often relegate coming to a final conclusion in this meeting. Sometimes we spend the whole meeting just making quick decisions on subjects where the basic arguments have already been laid out in Codecks conversations, sometimes we also use these for general discussion about the game and how we’re currently feeling about it)

Community Management

Discord

Discord is a central aspect of our marketing approach. Before we launched on Steam we ran an exclusive Discord alpha phase where you had to join our Discord server to participate. We used this approach to also build up our own mailing list (we use Mautic for managing it which reduced our email cost from several hundred dollars per year to literally less than 5$ to send a batch of hundreds of emails).

Once fans were signed up to the mailing list we invited a new batch of players with every alpha release that we did. We gave them custom keys and built a tiny Discord bot (Mr. Slippers is a corgy 😍) which users could send their key to and upon verification the bot assigned a special role to the user.

With this role, users would be allowed to enter a restricted server channel which contained a Discord channel store. Even though the shared storefront has been phased out by Discord, you’re now able to set up your own mini shop inside your discord server and let it handle payment and distribution. In our case we wanted to make the payment free, so that our most dedicated fans would be able to buy the game properly on Steam and be valid for leaving reviews.

Already selling the game on Discord would have forced us to also give away free steam keys with every purchase which would have made potential reviews from those sales invalid for the steam reviews. As an added incentive we only published the pre-alpha version on Discord. Once we launched on early access we took down the Discord store.

There are several different other aspects to this strategy which are beyond the scope of this blog post. Let me know if you’re interested in a dedicated blog post about this topic.

Decky

This Discord release strategy also allowed us to build up a Discord community that we’re now in constant communication with. It also inspired us to create Decky, our awesome community management bot, which interfaces directly with our actual Codecks projects. It allows fans to submit bugs and feedback and drives up engagement through leaderboards and automatic updates whenever we fix a user-reported issue. See this blog post for more details about Decky.

We have a bug channel where we allow users to report bugs using the !bug command. We have separate bug channels for CE1 and CE2 and both have been set up with commands that target separate decks inside our Codecks project. We similarly have feedback channels for ideas by the community. All of these are also accompanied with weekly leaderboards for bugs and features.

Bug Reporting API

Codecks is built on a powerful API from day one. This API will be documented soon, but we’ve been already using it internally for some months to report bugs from within our game. Players can at any point click on the bug report button to upload a bug report card directly into our Codecks project. The card will automatically contain their savegame, seed information, player feedback text and a screenshot and allows us to quickly triage hundreds of bug reports.

We plan to make this a Codecks feature that everybody can use and that will allow players to browse the list of known bugs and upvote them and also to be informed by email of fixes to their reported or upvoted bugs. This will not only drive down the number of bugs that developers have to triage but also engage the community stronger, creating a win-win situation.

We plan to release both the general API documentation and the Unity plugin in the future. Make sure to check the ROADMAP for more information.

Other tools

Codecks covers the vast majority of communication and project management needs that we have, but we’re also pragmatic and use whatever makes sense. Here are additional tools that we use internally:

• Google Suite for Google Drive, E-Mail, Calendar and spreadsheet calculations
• Slack for internal communication. Discord is close to replacing Slack also for biz communication but the thread support is still something that we’re dearly missing. Even with threads Slack can be unwieldy very quickly, so we use it mostly for banter and quick communication. As soon as a topic is identified and requires more conversation we take it to Codecks cards to create accountability and to schedule the task.
• Discord 💜 for community management as pointed out above.