Introduction and Goals - Timmeey86/Mindustry GitHub Wiki

Essential Features

If this was the 90s and Mindustry was a product being sold in a box, it would maybe look similar to this:

(Mindustry Virtual Product Box)

The essential features listed in this picture should always be in the back of your head when developing anything for Mindustry. These are features that usually only change (if even) between major releases.

Why is Mindustry being developed?

Anuke created Mindustry as a hobby project in order to create a fun game which is accessible to many people on many platforms. In addition to that, the development of mindustry shall provide experience on how designing and distributing a game can be achieved for several platforms at the same time.

Which quality attributes are most important?

Ordered from vital to important:

  • Time Behavior and Operability: A game of Mindustry might run several hours and require to do an increasing amount of calculations during that time. If it's slow or gets unstable, people will eventually stop playing it, give it bad ratings and ruin the fun for any contributor.
  • Resource utilization: While not as important as a smooth and stable gameplay, using too many resources could prevent Mindustry from running on some devices. Remember, Mindustry shall be available to many people.
  • Modularity: Mindustry should consist of several loosely coupled, but strongly cohesive modules. Remember how Mindustry is supposed to provide experience for multi-platform support? This is most clearly visible if there is a core package, and a package for each platform.
  • Functional Correctness: The satisfaction of the people playing Mindustry is inversely proportional to the number of bugs they encounter during gameplay. We'd rather have people wait another day or two for a new feature than supply a quick but unstable solution.
  • Installability: A software which is difficult to install can be very frustrating. Installing Mindustry should be intuitive and be similar to what is standard for each platform (for example a single click on 'Install' in Google Play Store must be sufficient).

Code Quality Constraints

  • In the context of entities, try to keep use of concrete classes to a minimum, instead using 'trait' interfaces like TargetTrait (can be targeted), SolidTrait (has a hitbox), TeamTrait (has a team), etc: avoid using "Unit" unless necessary
  • Keeping formatting the same across all files (e.g. no extra spaces). We will try to provide an IntelliJ formatting template here soon.
  • Try using American English only. If you learned only British English, this is hard, but having mixed class names in BE and AE is a lot worse.
  • Avoid getters and setters unless they're part of a trait or are very implementation specific. If something is final, there's definitely no need for a getter. IntelliJ can auto-generate getters/setters if it becomes necessary. Public (and if possible, final) fields should be used for data classes.