Learn From Failure: How We Optimised Our Development Process

Our Journey Towards a More Optimised Game Development Process

Every successful company starts out small, and everyone makes mistakes. That is nothing new. 

However, the possibility to make mistakes and learn from them still needs to be standard, even in our fast-growing and modern industry. In many employers, there is pressure to perform, and if you don’t achieve, you put the company at risk. 

We have often made mistakes in developing our games, one of which was how we approached our development process regarding structure. Fortunately, at justDice, we understand that risks sometimes have to be taken and that learning from mistakes can ultimately yield the best results. In this post, I want to discuss how we refined our process to improve things.

From Zero to Miro

The biggest acquisition for our development process was the online whiteboard service, Miro. I don’t want to advertise here, and I’m sure there are more collaboration platform providers out there that are just as good for project management, but I will refer to Miro throughout this post.

The platform offers ample space to be filled with content and edited by multiple participants simultaneously. The handling is user-friendly, and the possibilities for embedding external content are enormous. At the same time, Miro offers various tools, such as Kanban boards, mind mapping templates, drawing tools and multiple libraries for emojis, icons and basic shapes for creating wireframes. All of which can be used to quickly and easily develop graphic interfaces for web applications.

A Single Point of Truth

After implementing the programme, we initially used it as a simple way to create flowcharts to graphically illustrate game features, the economy and the core loops. 

As time went by, the team got to know the platform better. So more and more information was transferred from other platforms to the respective Miro boards. We then declared the platform as the single point of truth for further projects. 

In this way, we deviated from classic game development, the core of which usually includes a Game Design Document (GDD). In this document, the game designer documents all game-relevant information. At best, the GD updates it regularly so that all parties involved, such as the art department, the developers and the QA department, can access all the essential information to them at any time.

As I said, at best.

Optimise Documentation

Because, in reality, no one reads the full documentation anyway. As a Game Designer, you often don’t have the time to check the entire GDD after every small change to a feature or a mock-up to see to what extent this change affects the overall concept. 

Especially since the layout only allows the flow of information in a vertical direction, you have to scroll for quite a long time to find the correct information. 

Of course, you can work with anchors, but documents of this kind are mainly text-based, and graphics, diagrams and mock-ups must be created and entered externally.

This is the great strength of Miro. You can spread out in virtually any direction and accommodate information without being bound to a scripted layout.

We could use this space to do just that. The game designers could document their features and prepare the flow diagrams they needed to illustrate processes for the developers. The artists could create mood boards, upload concept art and provide design sketches for the user interface (UI).

Data Overload

The downside of this approach became particularly apparent with our biggest project to date, an auto chess game. The development of the MVP took a few months, and over time the corresponding Miro board filled up with more and more content. The more features we developed, the more playable characters entered the game, and the more we iterated existing systems, the more information had to be made available to the developers, and, of course, the more artwork and UI designs were needed.

This resulted in two problems:

Performance

The first was performance. Miro is designed for an optimal amount of individual elements (graphics, text blocks, images), which offers some leeway to be filled with content. 

At some point, however, we had exceeded this amount by more than five times. This led to massive delays because loading the board took several minutes, making constant work impossible, especially when several people were working on it simultaneously. 

Clutter

The second, much more significant problem was the need for more structure. We had roughly created areas for each discipline but underestimated the space they would take up. 

We also left all the content unfiltered on the board without sorting out outdated designs, which was a problem, especially with the mass of wireframes for the individual screens, the descriptions of particular features and the character iterations.

Create Templates

Based on these findings, we designed a template for all further projects. 

To do this, we analysed where we could save elements, for example, by taking a screenshot of wireframes that consist of 43 individual graphics and then integrating this into a screen flow diagram, thus using only one element. 

We also checked which areas had to be significantly smaller or larger and where information could still be saved in external sources and only linked to Miro.

Embedded External Tools

Good examples of that are Google Sheets and Figma. 

We use Google Sheets mainly for our balancing tables, in which all values for the economy, monetisation, level systems etc., are balanced.

While you could also put these values in tables directly in Miro, Miro needs more formulas and processing methods than Excel or Google Sheets. 

So it is much easier to link the external tables.

Figma, on the other hand, is a good UI design tool for doing and saving all UI-relevant work there and then only storing the link in the Art area on Miro. And, at the very most, using screenshots of the current design to display screen flows.

Optimise Prototyping

In addition to Miro as a tool, certain processes have proved productive over time.

This applies especially to prototyping. 

One area for improvement in the past was that there needed to be more explicit guidelines regarding which features should be included in the first or second prototype, when we should hand over the unfinished product for testing and to whom, in-house or externally. 

In another post, my colleague Aram emphasises the significance of testing every aspect of the project during the development phase.

But back to the topic.

This unstructured approach meant that neither precise scheduling was possible nor was enough feedback obtained to speed up some processes or avoid others altogether.

Breakdown Structure

We roughly planned the project, sorted the individual features into epics, and prioritised them. This allowed us to create milestones and assign features to each of them that built on each other. 

The first step was to create a Project Breakdown Structure (PBS) in which every feature, every UI element, every intended reward and every part of the game economy was listed.

Afterwards, the data was filtered. What was unnecessary for the MVP and could still be included in later patches was removed. 

The remaining features were divided and prioritised according to core gameplay and meta-level. This allowed us to see exactly which features must be addressed first and which logically followed. 

This helped us to plan better milestones and set deadlines, which made the following project much more straightforward and accelerated its production.

Conclusion

In summary, it is essential in game development to regularly analyse processes and tools to optimise existing and upcoming projects and iterate content. Only by learning from mistakes can mistakes be avoided in the future.