Well, we are finally here. You have written and coded your game. You have optimized it so that it takes up as little memory as possible. You have run it through several phases of debugging, fixing errors as you encounter them. But you are still a little bit away from being done. You should first pass it through releases.
Releases allow you and others to test your game and report any errors before the final version comes out. Every time you fix a bug and release again, you can upgrade the version number to show your progress on the project. Once you have a solid, stable release, make it a major release by making the version number a full integer. A suffix "a" or "b" can be used to indicate alpha and beta releases, respectively. An alpha version is not a complete version, but good enough to try; a beta release is a full version of the program that may have unstable features.
A version history should also be provided with every release of the program. I often enclose it within its own document. It gives a user an idea of how stable the program is.
The second thing every good program needs is a disclaimer. This document should provide legal information about the program. It should contain the release date, whether the program is closed or open source, and distribution rights. It should also state what warranty is provided in the event that the software is defunct. Finally, it should cite contact information.
The final thing every good program needs is a help file, enclosed with the program. This file should cite basic information about the program, like how much memory it needs to install and run. It should provide troubleshooting information, information about special features, and a run-through of basic features. Finally, it should provide a technical section, so that other designers can avoid conflicting with it.
Once you have a stable program version, a version history, a disclaimer, and a help file, you are prepared for your final release. Compress all the contents into a ZIP file and upload it to your hosting site of choice. You have just released your first game. A program's first release is a huge milestone in a programmer's career. Remember that a programmer makes money only on an official release that sells. There are some programs that are released as freeware or shareware. These programs are all open-source, which means they may be modified and redistributed so long as the one distributing does not profit from doing so. A closed-source program means that it may not be modified but it may be distributed. Again, these specifics may vary from program to program. Check the disclaimer before doing anything expressly forbidden.
Your work does not stop after the first official release. Part of being an active developer means that you honor feature requests. The most loved developers tailor their programs toward what the community asks for. That means that you, the programmer, should be active and interact with your users, finding out what they like in the program, what they don't, and what they want added.
There is a stigma out there that programming is an anti-social field, but I can tell you, from experience, that it is not. Let it be noted that this tutorial was worked upon by a group of developers, interacting with each other. Most modern programmers feed this negative stereotype by spending time in little cubicles, mass-producing software with a myriad of features that no one will ever use, or even care about. But a true programmer is actively involved in the community he is designing for. He talks to users, and alters his software to satisfy them. He is a man (or woman) who actually cares about what others want in a program or game.
