- Dec 26, 2020
- 2
- 9
Hello all, especially developers!
When looking for games, it is often difficult to recognize how far a title has come along. That's why I would encourage every developer to use the standard software versioning scheme, presented in the following.
Software version numbers should be written in a "X.Y.Z" format. Sometimes, developers even add a fourth component at the end, more on that later.
X, Y and Z are integer numbers that are increased with new versions. If a number is increased, all numbers to the right are set to zero. Additionally, these numbers are not decimals. This means, each one of these numbers can be 10 or higher without increasing the number to the left. If "Z" is zero, it can be omitted.
"X" is the main version of the build. It is only increased, when the software is feature complete. Say you want to make a game with 4 chapters. After finishing the fourth chapter, you can increase the main version to 1. With most games on this site, that would be equal to the "Completed" tag.
"Y" is the minor version of the build. It is increased, when a release with a set of new features (content) is finished. This equates to a new chapter in most visual novel games, or possibly just any new content you publish to your audience.
"Z" is the bugfix version number. It is increased when bugs a fixed, gameplay or balancing changes are made, without any new features in the release.
Some examples:
The first ever version you are working on is "0.1.0", or "0.1". The game is most likely not feature complete. And it includes the first set of features you want to release.
You have released version "0.9.0" (="0.9") of your game already, and are ready to release another set of features. The next version you use is "0.10" (="0.10.0").
You released version "0.7.1" previously, and after the next set of features your game will include all planned features. The next version will be "1.0.0" (="1.0").
The optional fourth component of the versioning scheme:
This component is mostly used by developers that have some automated build system running, which might automatically build a new release of the software nightly or with every commit to a code repository. This is often referred to as Continuous Integration (CI). Depending on the interval between feature releases, this number can get quite high. It is also not very helpful to end users, so i would not display or communicate it to the public. It might be helpful when giving test builds to testers.
I hope this helps some of you and will lead to more meaningful game release versioning in the future.
Happy Coding!
When looking for games, it is often difficult to recognize how far a title has come along. That's why I would encourage every developer to use the standard software versioning scheme, presented in the following.
Software version numbers should be written in a "X.Y.Z" format. Sometimes, developers even add a fourth component at the end, more on that later.
X, Y and Z are integer numbers that are increased with new versions. If a number is increased, all numbers to the right are set to zero. Additionally, these numbers are not decimals. This means, each one of these numbers can be 10 or higher without increasing the number to the left. If "Z" is zero, it can be omitted.
"X" is the main version of the build. It is only increased, when the software is feature complete. Say you want to make a game with 4 chapters. After finishing the fourth chapter, you can increase the main version to 1. With most games on this site, that would be equal to the "Completed" tag.
"Y" is the minor version of the build. It is increased, when a release with a set of new features (content) is finished. This equates to a new chapter in most visual novel games, or possibly just any new content you publish to your audience.
"Z" is the bugfix version number. It is increased when bugs a fixed, gameplay or balancing changes are made, without any new features in the release.
Some examples:
The first ever version you are working on is "0.1.0", or "0.1". The game is most likely not feature complete. And it includes the first set of features you want to release.
You have released version "0.9.0" (="0.9") of your game already, and are ready to release another set of features. The next version you use is "0.10" (="0.10.0").
You released version "0.7.1" previously, and after the next set of features your game will include all planned features. The next version will be "1.0.0" (="1.0").
The optional fourth component of the versioning scheme:
This component is mostly used by developers that have some automated build system running, which might automatically build a new release of the software nightly or with every commit to a code repository. This is often referred to as Continuous Integration (CI). Depending on the interval between feature releases, this number can get quite high. It is also not very helpful to end users, so i would not display or communicate it to the public. It might be helpful when giving test builds to testers.
I hope this helps some of you and will lead to more meaningful game release versioning in the future.
Happy Coding!