Development methodology

[SteveAdamo]

im sure you address this in more detail in your book, but in general, how would you characterize your development methodology? specifically in regards to RW, do you intend to have rapid development cycles (weekly builds), with smaller internal groups used for testing, with those builds then being released publicly...

or do you prefer having more time between builds, allowing for more folks to participate between releases?

[GC13]

Well, Tynan just mentioned updating the game "every month or so", so I'm assuming the latter.

Monthly is a good cycle. Lets some real differences stack up between releases, so release notes don't start to read like "I fixed three bugs and we added new sprites for plants grown in hydroponics".

[Tynan]

My methodology is super-agile and super-fluid. I make use of all the advantages I gain by

1. Working alone (with contractors).
2. Having a super-broad skillset that lets me do all sorts of tasks myself.

This allows me to prioritize myself to any task, which gives great flexibility and means I can always do the most important thing.

I don't plan ahead in any traditional way. I organize myself with a priority queue of stuff to be done, which I am constantly shuffling and reshuffling to make sure that the stuff that really matters is at the top. Not planning allows me to make use of current knowledge instead of past knowledge when making decisions about what to do now. I consider this one of the most important parts of my methodology. RimWorld got made not because of mad programming or art skills, but because of smart task prioritization. I don't get sidetracked by irrelevancies or low-impact tasks because I'm always re-evaluating each task against tens or hundreds of others in the queue. I work really hard to avoid tunnel-visioning. Usually there's a more important task you just aren't thinking of.

Sometimes I may release builds (for testing) every day or two, sometimes they may be weeks apart. Needs change according to what you're doing. There is no consistent cycle that covers all situations, and the only reason to create one is to make a stable environment for multiple team members to work in (and even then this practice is over-emphasized IMO). Public releases will be spaced further apart but this is for the reason that GC13 cited, and so we can do a real testing cycle on them to make sure no killer bugs snuck in.

There's a ton more to this, but I hope you'll find most of it in my book

[SteveAdamo]

thanks for the insight Tynan...

and this is obviously consistent with your stance/comments during the campaign (in regards to stretch goals)... you prefer to collect feedback from existing users/builds, and use that information to move on to and address the next logical updates to the client, as opposed to mapping out that "X will be incorporated at Y time"...

i applaud that approach...