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

Website:

http://www.protohacks.net/xna_debug_terminal

1. http://msdn.microsoft.com/en-us/library/f7ykdhsy.aspx

2. http://www.evl.uic.edu/rlk/electro/electro.html

3. http://en.wikipedia.org/wiki/Code_freeze

4. http://en.wikipedia.org/wiki/Occam%27s_razor

References