Thread: Development Process

Sorry for the text wall.

So I didn't know where to best put this, and I feel like a noob...probably because I am. :/ Anyhow, I'm making a project with a google code page and a Git and all that shenanigans, and I've ran into a rather simple problem that I think is very important. I don't know when to make releases. I have a general idea, but I don't know what makes a good point to make a minor release, and when to finally make my first official major release, Alpha 1.0. An even better question is to when an open source game should become Beta. Should I change the way I'm doing things now, by basically having the game be completely open source and public? I'm using Google Code, so I could make it "closed source" and "private" if I wanted too. Does that help create a more solid line between Alpha and Beta?
The final thing that has been nagging me is I use a Major-Minor-Revision (for hotfixes, and general bug fixes) system, but I've heard of people using a Major-Minor-Build-Revision system, how does that work, and what are the advantages? Finally, you can check out my super lame Alpha 0.0 and get a feeling for the organization I'm doing so far by checking out my Google Code project: lightofday-spacegame - A rogue-like space game with a twist: It just happens to be an arcade style shooter and free roam game at the same time. - Google Project Hosting

Compare other software's version numbers to the types of changes that took place between versions and this should give you a general idea, but really it is left up to the author of the code on what numbering system is used.
Generally my system starts with 0.0.0 code name alpha. This is the raw framework of the code that sets up an environment for the project, perhaps building window and ui components, data structures, just the raw basics, and updates along the way will increase the version number.

For example, in my project (which is in alpha) I need to add code to create a gui. So my solution is to create a specific type of window with a size and position that depends on the user's display size and resolution, because the way the user sees the gui is important to me. First I create a basic window and make it show. At this point I have code that does a task, and should be testable. My version number might be 0.0.1 now.

I decide for this project the window should be a perfect square that is 80% of the height of the display. So I write code to size that window. At this point it should be testable. The tests are run on various machines with various display sizes and everything looks to be working as expected. Happy with the code at this point, I save a snapshot as version 0.0.2

Now this newly opened window should position itself. Done, tested, and happy with the results, version 0.0.3

At this point I am completely satisfied with the window, and want to move on to the creation of some menu options. This is a major difference than adding on to code that works with the window specifically. I start the menu works with version 0.1.0. This means the window is working as expected (maybe there is a bug? maybe not...) From this version number forward I keep adding code and going through version numbers like 0.1.1, 0.1.2, 0.1.3 etc. Oops, a bug was found on the window. It is a +1 error on centering the window. My version number was 0.1.3 when the bug was discovered and the fix leads me to 0.1.4. With the centering working properly, I can now continue working on my menu code in 0.1.5.

Happy with the window and the menu, I am at 0.2.0. from here I work on what ever is next. Perhaps a colorful picture for a background. This is when a big problem was discovered. (ok pretend the problem is bigger than what is used in the sample) The previously designed perfect square window should have been a 4:3 ratio width:height. This will upset most of my version 0.1.x code! We are currently at 0.2.0, and making major changes. now all version 0.2.x belong to making changes to the window, previously 0.1.x set. Reshape the window, 0.2.1 tested and happy. Now we no longer want to center the window, but place the bottom left corner of the gui at the bottom left corner of the display, version 0.2.2. Everything seemingly complete, final tests are done, version 0.2.3

Somewhere around 0.532.25 the code has really taken shape. As it turns out the project was a hangman game. We have the window, the menu, some big splintered post to murder our stick man on, and the logic to start guessing letters. This is no longer in the birth stage of the project. This thing actually looks and functions like a hangman game. Version beta here we are. This is where my private team of testers play a few hundred thousand games of hangman. We love testing so we created a test class which will brute force test all words in our lexicon, as well as our team of testers who will actually play the game.

Everything looking good, all discovered bugs fixed, seemingly perfect, we release 1.0.0 to the customer as finished product.
Find another minor bug? Something spelled wrong, some +1 error? perhaps 1.0.1
Decide on a major change that doesn't really change the way the game is played, but major code work takes place, you may go through 1.0.2, 1.0.3 ...... and end on 1.12.4 by time you got the stick man on the left side of the post instead of the right.
Here we have an idea for multi-player hangman. Two people play, and it is a race! For every letter one player gets right, the other player has the next part of their stick man drawn! This will be a major change in the way the game is played, and the final version of this may look like 2.5.1


Oops, another +1 bug. So many on this project. 2.5.2 it is

but I don't know what makes a good point to make a minor release,

Generally bug fixes and small changes. (we get 5 wrong guesses instead of 4 before our stick man is fully drawn)

when to finally make my first official major release

When you truly believe the code is perfect as is, and are willing to put your stamp of approval on it

when an open source game should become Beta

When the code seems to perform the desired tasks, and is testable by people who don't normally write code.

Should I change the way I'm doing things now, by basically having the game be completely open source and public? I'm using Google Code, so I could make it "closed source" and "private" if I wanted too. Does that help create a more solid line between Alpha and Beta?

Ultimately version numbers have nothing to do with the decision to be open or closed source, and the decision on both accounts is left up to you, the 'legal owner' of the code.

Major-Minor-Build-Revision system, how does that work, and what are the advantages?

With the "system" I employ, record is kept of the code version every successful test phase including the test code. I keep record of which part(s) of the code are done in which version set (in the previous simple example the basic window 'owned' version set 1.1.x, and the menu owned set 1.2.x)

Cool. Thanks alot, you guys are super helpful.

Is it proper to use a sort of "prep commit" for A) preparing the particular release/development process for the particular development process/feature to be merged, and B) shaping the history to be more visually appealing and easier to follow?