One of the things I wanted to post about was the process that I'm going to be using with Otto Von. I have always been a big proponent of agile methodologies, so I plan on implementing that kind of process with my company. You can read my posts over on my software development blog for more information about the whys and such, but I think that it tends to provide the best mechanism for making gradual yet complete improvements to a code base. It's easy, especially as an independent developer, to get lost if you try to work from a full feature list - you'll get some things partially done before you start working on something cooler. And in the end you'll end up with only part of the software done and that part is less than satisfactory.
There are some things that need to be sorted out in advance. For example, in Project Samantha I'm considering a lot of the game play design - how do things work together? what kinds of values will I use for various attributes? what kind of role does random chance play? But these are all parts of a user story about it. In the trivia game, for instance, I can plan the timing of the answer period and the number of points independently of how many questions make up a game. Or what format the question data takes. So those separately are user stories, but the vision and the interface of the various subsystems needs to be laid out a little more in-depth before I begin.
The main problem with 'agile development' is the tendency toward cowboy coding. In this case, I use it pejoratively to denote the "just get started" mentality - without vision, the coding ends up being no better than a prototype. And that's not the plan - I need a high-quality, high-value game at the end of this. That, or become a joke with the App Store crowd.
I've found some templates for game design that I've been using for some other project ideas I had. I'm going to be putting Samantha in that template so I can start play-testing the systems as well as capture some of the "cool" ideas I've come up with. :) That, and it should provide some kind of hint about how much work this is actually going to be. I may need to delay some things for an update (like things for higher-level players in Samantha). I may need to just dump some ideas outright (too much to handle). I won't really be able to make those calls and figure out what's really going to be in the "release plan" until I have the subsystems described.
Normally the user story would be very high-level and it acts as a token for a conversation to be had between the developer and the customer/designer. In this case, since I'm both, I'm planning on capturing the "conversation" in the story itself (or in the design docs). Ideally I would be either the designer or the developer, but it's a one-man show, so some accommodations needs to be made. :)
I'll post things up as progress is made about how well the process works/doesn't work and what kinds of adjustments I think need to be made to my base process. In the future, when I'm making money hand-over-fist and can afford to hire actual developers I'll be able to look back at this as the early definition and trial by fire of the process. Yeah, about that...
