One of the rules for programmers is to pre-test their own code before submitting it for integration with other tasks and passing it to QA (Quality Assurance) testing. For example, in Java, this is done using JUnit.
Also, if you are working on a project yourself, you need to incorporate a great deal of self disciplined. For example, in my line of work, I must adhere to the SDLC (System Development Life Cycle). http://en.wikipedia.org/wiki/Systems_development_life-cycle
To further clarify, a perfect world example would be as follows. And please, I'm only including the part related to this thread:
As a designer, you need to develop a flow chart, UML or other form of plan'o'gram that gives you a general idea of what you need to make the most basic, working application possible. Once you have this, you need to break it down in tasks. Normally, tasks are broken down in classes. You only further add to the design after you reach the criteria of the current design. You stop at each level of your design. Assuming you planned out your most basic working application, you stop here for now.
As a developer, you need to give yourself one task at a time as if you were taking the tasks from a basket offered to you. When you work on your task, you must pre-test your results. You should not work on another task until you are confident that the task you took responsibility for, works. You continue doing this until you have no more tasks left. If you find a problem that prevents you from finishing that task, you document and move on to the next task. If you have any incomplete tasks due to problems, you then revert back to a designer to amend then return back as a developer to apply the change. Assuming you have no further tasks and no problems, you switch to QA..
As a QA (Quality Assurance) tester, you need to spend hours, if not days trying to break your program. Don't fix anything as this is micro management and a bad habit. You document, and you do A LOT OF DOCUMENTATION. Make sure what you document is well defined and well coupled with a bug. Create severity levels to associate with the bug. (e.g., Understand the difference from a hard crash (CTD [crash to desktop]), a soft lock (endless loop resulting in a unusable program), and partial lack of functionality but a running program none the less). Once you can't find any more bugs, you stop here. If their are bugs in your quota, or the project is not ready to move into the implementation phase, you go back to your developing phase to apply the fix and/or designing phase to move into the next design model of your program.
You repeat this cycle until either you reach your time quota or the achieve your design expectation; which ever one comes first. Then you move to the implementation phase; that's where you often see games moved into beta, for public testing.
To summarize, if you want to make a game unbreakable, you need to adhere heavily on the SDLC model, and you must practice extreme disciplined on yourself since its likely your doing it yourself. The two things that cause a game to be breakable is a deviation of the SDLC model or a time restraint. Remember that.
Hope this helps. Feel free to amend anywhere I'm wrong or add further in areas I am weak on. Thanks.
Edited by Subtle_Wonders, 31 December 2013 - 08:21 PM.