In order to be able to work efficiently with several developers on ever-growing software projects, a common way of working must be found beforehand. To do this, several questions must be answered together.

  • How do we version our software?
  • How do we develop features?
  • How do we test and how are bugs handled?

These are all questions we want to address in this blog post and thus offer a little insight into the daily development routine at Minecraft Legend.

How do we version our software?

We have agreed to use Git as a version control system (VCS) in conjunction with Github. Git is currently by far the most widely used VCS.

In connection with Git, the platform GitHub is mentioned very often. GitHub is a free platform for developers to manage their Git repositories. Therefore, it is very popular among open source developers. However, GitHub also provides good opportunities for private organizations to manage repositories both publicly and privately.

Currently, two of our projects are OpenSource and hopefully more will follow.

Additionally, a way to have projects built automatically via GitHub Actions was added last year. This has made the platform even more attractive.

However, one of the main arguments for using GitHub was that we don't have to host our repositories ourselves in contrast to GitLab for example, and guarantee a high uptime therefore.

Git Workflow

Git Workflow

Our Git workflow consists of a slightly modified version of Gitflow. A Git repository has at least three branches that reflect our different systems.

  • prod: The source code in this branch represents our production systems.
  • stage: Once a week the developed features from the dev branch are merged into this branch. This stage branch is then tested by our game designers.
  • dev: Source code in this branch is under constant change, as our developers merge all new features into this branch from time to time.

In addition, there are two other types of branches, both of which serve a separate purpose. These are our bugfix & feature branches. These are where new features are developed and bugs are fixed. After these have been roughly tested on our dev system, they are merged into the dev branch.

How do we develop features?

Development of game features

New content is elaborated by our game designers and documented in Confluence. Confluence is an enterprise wiki software that makes it very easy to work on documents with multiple people. For each new feature, both the head developers and game designers determine a prioritization of the content. Depending on the prioritization on the roadmap, features are developed one by one.

At the beginning of the development of a new feature, the entire development team usually sits down together and works out suitable concepts to implement the game content quickly and efficiently in the game. Then one or two developers are going to implement the concept into our game.

Extensive testing also takes place during development. To be able to provide test servers quickly and dynamically, we use Pterodactyl. Pterodactyl offers its own web interface, where the developer can change configs, upload plugins and much more. We also provide the possibility to connect to the Java debugger via VPN to be able to test a developers respective feature properly. The test environment mirrors our production environment as good as possible to provide an almost identical system to test the developed features on.

How do we test and how are bugs handled?

Stage System

After new content is developed, it is merged into our dev branch as described above. At least once a week, they are transferred to the stage system. On the stage system, mainly game designers, but also other team members, extensively test the new features and give feedback to the developers and report bugs.

The Stage System is 100% the same as our production environment. The system landscape of our Stage environment is shown in a very minimized way on the following drawing. Many systems and components of the visualization will be described in more detail in future blogposts.

Following blog posts

There will be more blogposts in the coming months, introducing our infrastructure itself and some concepts.

Rough breakdown of the next blogposts:

  • HashiCorp Stack (Nomad, Vault and Consul)
  • The Multibungee problem and possible solutions
  • Real-time data processing in Minecraft
  • Minecraft with JUnit