110 likes | 306 Views
XNA DEBUG TERMINAL. http://www.protohacks.net/xna_debug_terminal. From Concept to Release By: Kevin Cherry Co-Owner: Timothy Wright. Choose a Concept. 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
E N D
XNA DEBUG TERMINAL http://www.protohacks.net/xna_debug_terminal From Concept to Release By: Kevin Cherry Co-Owner: Timothy Wright
Choose a Concept • 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’s1in-game console and .Net reflection2
Decide on a Feature Set • In General: • Figure out all features initial release will have • Implement simple casesof 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
Implement • 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 cvsand 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)
Write Tests • 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
Document • 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
Market • 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
Points to Remember • 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.
Website: http://www.protohacks.net/xna_debug_terminal
References • http://msdn.microsoft.com/en-us/library/f7ykdhsy.aspx • http://www.evl.uic.edu/rlk/electro/electro.html • http://en.wikipedia.org/wiki/Code_freeze • http://en.wikipedia.org/wiki/Occam%27s_razor