Skip to main content

This is a long-form post, written in a way that some insights apply to all interested in game design, game production, game tech and beyond. The blog post shares our experience with the collaborative tools we use and the pipeline we have built over the years. We hope it is helpful for all fellow game devs! Let’s dive in:

Game development is a team effort and our collaborative tools empower all team members to participate in as many parts of game development as possible – from concept to live-ops. 

Players for mobile games expect a solid stream of content updates and have a stable game experience at the same time. Switzerland’s game studio Gbanga has created the country’s largest Merge-3-Game (currently at over 10’000 Ratings and 4.6 average stars) and offers insights into their collaborative setup for the casual game Migros Merge on the two most important aspects of game live-ops: content creation and content management. The game lives on tailor-made content such as themed merge items, merge chains and characters that push the story forward.

Impression of the Merge-3 mobile game Migros Merge created by Gbanga

Planning in the concept phase

At the beginning of every game stands the concept phase. Besides exploring potential game mechanics and core loops, content is key. To have great content, it is crucial that as much brain power gets into content and level crafting. It is our core belief that we want to empower all team members to participate in as many parts of game development as possible, especially level creation – so we work with tools that are collaborative in nature. 

It all starts in the concept phase where we outline possible workflows to create content with our collaborative tools at hand. The specific workflow for Migros Merge is described in the next section.

Crafting a content production pipeline

The pipeline to create content is individual to each game. In this post, we go into the details of our game Migros Merge. Migros Merge features a story campaign where  protagonist Mia travels to time epochs to meet and interact with characters of the time. The overview shows the tools we use for each step, like Google Docs, Sheets, Figma, Directus and Tiled. The steps are explained in more detail in the following sections.

Overview of steps in the production pipeline in the game Migros Merge.Overview of steps in the production pipeline in the game Migros Merge.

From narrative to actual game content

After a brainstorming, we define the environment (epoch, time of the year, biome, etc.), work on story arcs and narration for each campaign chapter – all with the help of the 5Ws:

  • who (characters → NPCs) is going 
  • when (epoch → 3D valley / 2D design) 
  • where (places → 3D valley / 2D design) and 
  • why (motivation, external forces) and 
  • interacts with what (theme, subject, props → items, merge chains).

As you can see from the comments in brackets above next to the 5Ws, we can then derive the game content directly. We work with content lists on Google Sheets such as:

  • an NPC character list including how the characters look and how they are named
  • a 2D asset list including items, vanity items, tiles and decorative elements
  • a 3D asset list consisting of objects and scales
  • a level list with high-level guidance for level designers
  • a narrative list with lines of dialogue for each level

Those lists are helpful to keep the overview during production. The whole team then starts producing the elements in each list. At the end, all should result in assets such as:

  • NPC portraits
  • Isometric PNGs depicting all items
  • 3D models representing the objects for the valleys
  • Level designs with game logic
  • Lines of dialogue entered into the localization sheet

An asset list we use at Gbanga; with automated thumbnails fetched into Google Docs from Directus, and the states in which the assets are during production.An asset list we use at Gbanga; with scripts for automated thumbnails fetched into Google Sheets from Directus, and the states in which the assets are during production.

Directus: Content management system (CMS) for levels

As outlined in the section above, you can notice that there are many moving parts in game content production. To help organize all this, we work with a CMS, short for content management system, that allows us to upload, update and retire every single part of content. Namely, we store characters, items, props, tiles, stages. The data consists of images representing game entities and JSON which defines game mechanics and other logic.

We are great fans of the open source software Directus and use it for data management from the first prototype to live-ops with millions of sessions, but also as a no-code solution for administrative tasks and for our game API to let our game communicate from the app on the mobile phone with the server where all assets are stored. Directus allows our game studio Gbanga to focus on creating games, by organizing content in a central place that is accessible to the whole team, where every single team member can update just every part of game content directly.

Technical deep dive: We have extended Directus with our own extensions that help us in game content creation and data conversion to platform specific texture formats ASTC_8x8 and ETC2_RGBA8 for mobile platforms, used by Unity directly (which probably deserves its own post). And we have several Kubernetes/Docker instances of Directus for development, staging and production, where we copy data back and forth.

The interface of Directus that Gbanga uses to manage game content data, such as characters, items, props and level stages. Parts of the data are made available to the game API that our game apps consume directly. Thanks to the no-code approach in Directus, it is very convenient to set up this API.

Tiled: Powerhouse for level creation

As we have outlined above, Directus is great for structured data. However, game level creation has additional requirements which are covered in level editors such as Tiled, the flexible open source  level editor maintained by Thorbjørn Lindeijer and others. We’re proud backers and use it as a WYSIWYG editor for level creation. We have extended Tiled to interact directly with our game’s Directus instances. All our team members working on levels can load and store levels and tilesets with a few clicks and share with everyone working on the game.

Before we start crafting individual levels, we outline the levels in an online spreadsheet (namely Google Sheets). This spreadsheet is then used to parametrize the level generator, a command-line script that downloads the spreadsheet data and pregenerates the initial levels that we then manually adjust and decorate with cursor tools that we have added as extensions in Tiled.

The Tiled editor with Gbanga’s own extensions to interact with the Directus API. It shows the list of levels on the right, visualizes level 11 in the center and shows a list of available tiles on the right.The Tiled editor with Gbanga’s own extensions to interact with the Directus API. It shows the list of levels on the right, visualizes level 11 in the center and shows a list of available tiles on the right.

This elaborate setup of Tiled and Directus also allows testing as a team effort, as all levels can be shared within a few clicks. In a commissioned work environment, this is especially helpful as it allows to also share all elements with the customer who can give feedback, review all moving parts and can give feedback. Thanks to the open source nature of the chosen tools, we can extend and integrate it with the tools we already use such as Slack, which we explain in the next section.

Test through technical checks with a validator

Since game production is an iterative process where elements change frequently, we heavily rely on continuous integration and continuous deployment (CI/CD). This helps us have peace of mind and lets us confidently make changes to the game. 

Our CI environment continuously builds the server and game apps, but also runs tests on game data. We call those tests on game data «validators». Our validators run 3 times a day on our development, staging and production environments and identify structural inconsistencies. Like that we can detect corrupt levels and missing references. 

Most often issues occur through renaming of existing assets, typing errors or through retiring deprecated parts of content. Our validators are Node.js applications that make use of the Directus JavaScript SDK to access the game data. The validators then automatically post the reports in our Slack channels to notify the team.

For peace of mind, our continuously active validator script keeps an eye on consistency and notifies the Gbanga game developer team when there are missing references or typing errors.For peace of mind, our continuously active validator script keeps an eye on consistency and notifies the Gbanga game developer team when there are missing references or typing errors.

We hope this post was helpful and please drop us a line with your own insights. We are always on the lookout for team members becoming part of our collaborative workflow 🙂

Download Migros Merge

 

Join our team

 

Become playtester

Technologies mentioned in this post

  • Unity, game engine
  • Directus, content management system and no-code API
  • Tiled, flexible game level editor
  • Kubernetes, Docker, application container
  • Jenkins CI, continuous integration server
  • Node.js, JavaScript runtime
  • npm, JavaScript Package manager
  • Slack App integration

We are the serious games agency Gbanga. As a specialist for gamification games and playful experiences, Gbanga implements games for contract customers. We would love to work with you on your next game!