From Concept to Release
By: Kevin Cherry
Co-Owner: Timothy Wright
http://www.protohacks.net/xna_debug_terminal
• In General• Find a “hole” in the market
• Make sure it fills a need that is not already well taken care of by other software
• Get inspiration from other projects and technologies you like
• XDT• Good visual and easy-to-use XNA debugger
• Visual Studio’s built-in debugger not suited for games. Very few popular alternatives
• Electro’s1 in-game console and .Net reflection2
Choose a Concept
• In General:• Figure out all features initial release will have
• Implement simple cases of each to ensure feasibility
• XDT:• v1.0
• Basic C# language expressions including literals, object member access, method invocation, and some assignment
• Basic UI for entering expressions and receiving results
• Customizable appearance
• Generic, catch-all error messages
• Special commands for extra power
Decide on a Feature Set
• XDT:• v1.1
• Further support for basic C# expressions
• New special commands
• Bug fixes
• Unit test project
• v2.0
• More C# expression support
• Better parsing system
• More accurate error messages
• Better UI
• More unit tests
Decide on a Feature Set
• Don’t get carried away and stray from your original concept/feature set• Some deviations are normal, but keep to a minimum
• Get it working first, then optimize
• Try using test-driven, agile, or another form of software development that is well known
• Try using well known design patterns where appropriate
• Use a form of version control such as svn or cvs and commit often
• Set a deadline and try to stick to it
• After your feature set is complete, only fix bugs (known as a “feature freeze”3)
• After bug fixing is complete/at a satisfactory level, stop coding for that version (known as a “code freeze”3)
Implement
• In General:• Create a set of unit tests and design a way to automate them
• Create sufficient tests for every feature
• Do not allow a feature to be released if it performs poorly on its tests
• XDT:• v1.1 has 137 unit tests
• v2.0 has 478 unit tests
Write Tests
• In General:• Often lacking in other projects• Ensure it is throughout, clear, and organized• Never underestimate the power of good documentation• Allow users to ask questions• Forum• FAQ• Email support
• XDT:• Webpage explaining, in detail, how to setup and use• Screenshots, sample uses, and a downloadable sample project• Downloadable chm document for entire interface• Pulls from xml comments found in every type, method, property,
and field in code• Google group for questions/comments• Email given on website
Document
• Make a website with your documentation, downloads, reasons to use your project, etc.
• Find ways to announce your project and website online:• Forums
• Wikis
• Emailing bloggers
• Tell your friends/classmates/co-workers about it
Market
• Occam’s Razor4
• If you think part of your documentation is unclear, assumes too much previous knowledge, overuses acronyms, etc., get feedback and rewrite it.
• Decide when enough is enough for a particular release
• Your project should be able to be downloaded from a maximum of 3 links from your home page. Don’t make users work for it.
• Don’t make your advertisement links bigger than your download links
• Take bug reports seriously and try to offer workarounds until you can fix it
• For open source projects, don’t assume everyone is a programmer and has the time to fix your bugs
• Asking for help is ok. Expecting it is not.
Points to Remember