1. From Concept to Release By:Kevin Cherry Co-Owner:Timothy Wright http://www.protohacks.net/xna_debug_terminal

2. 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’s 1 in-game console and.Net reflection 2 Choose a Concept

3. 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

4. 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

5. 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

6. 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

7. 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

8. 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

9. Occam’s Razor 4 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

10. Website: http://www.protohacks.net/xna_debug_terminal

11. 1.http://msdn.microsoft.com/en-us/library/f7ykdhsy.aspxhttp://msdn.microsoft.com/en-us/library/f7ykdhsy.aspx 2.http://www.evl.uic.edu/rlk/electro/electro.htmlhttp://www.evl.uic.edu/rlk/electro/electro.html 3.http://en.wikipedia.org/wiki/Code_freezehttp://en.wikipedia.org/wiki/Code_freeze 4.http://en.wikipedia.org/wiki/Occam%27s_razorhttp://en.wikipedia.org/wiki/Occam%27s_razor References