In the days after Milestone 5, I’m working on laying out my plans for Milestone 6. This is a bigger milestone than usual. I’m not yet quite sure how big, but it’s definitely going to take longer than the two weeks for Milestone 5.

But first, I want to look back on the last two weeks and evaluate what went well, and what didn’t, so I can handle future milestones more effectively.

First things first; the obvious “what went wrong”: Back in Milestone 4, I accidentally released a Mac build which had been compiled in debug mode. That mistake finally convinced me to write a script which creates the Mac milestone builds automatically, without any human steps being taken. I did the same for the Windows builds, mostly, but there were still a few human steps involved, which were simple enough that I didn’t bother to figure out how to make those scripts absolutely bulletproof. As a result of those incomplete build scripts on Windows, in Milestone 5, I accidentally released a Windows build which contained the data files from the Milestone 4 build. Predictable, really.

So the first thing I did after uploading a fixed Windows build was to fix the Windows build scripts. Now, like the Mac build script, the creation of a milestone build is completely automated, and builds completely from scratch — no human intervention required, no chance of accidentally including an old, no-longer-relevant file. I should have done this before, but..

With that out of the way, let’s talk about how Milestone 5 went, other than that.

What went right

• I like the shorter development cycle; it felt like there was a lot more pressure to get things done in a timely manner. By comparison, Milestone 4 (January -> June) seemed to drag on forever.. although much of that was before I went full-time on MMORPG Tycoon 2. It seems to me like the right milestone duration is probably around a month. Maybe up to two. Maybe I need to continue to produce regular public builds, even outside of the milestone schedule, just to keep myself honest. Would there be interest in more frequent builds, instead of only getting them at the milestones?
• Mostly had a design for the new features right up front. The general functionality of the quest panes (drag up/down to reorder, and off of their window to destroy them) was unchanged for the whole duration of the milestone. The method to edit quests was much later, and ended up being a real hack. Don’t get me wrong; it works, and I like the way the UI feels. But making it work was surprisingly complicated.
• Focus on “make it work” rather than “make the code beautiful”. This came from the shorter development cycle. In the MS5 build, there are basically two separate implementations for buttons which can be dragged around into different slots; there’s the one for the new quest buttons, and one for the action bar buttons. When it occurred to me that I’d already implemented something that handled dragging of buttons, I thought about trying to make that functionality generic, and driving both sets of buttons from one set of logic.. but in order to be anywhere near the milestone deadline, I decided to implement the generic functionality, but not to spend the time modifying the action bar buttons to use the new generic functionality. I can still do that later, if necessary, but it wouldn’t have delivered any real benefits for MS5.
• Ignoring the exact placement of the info panel, I really like the system I eventually settled upon for aggregating content to go into the panel. It’s extremely flexible, and has some useful built-in layout tools which allow different types of data to be formatted together nicely.

What went wrong

• See comments above, RE: the first Windows build which had the wrong data files.
• Info panel design paralysis. I went through four different designs for the info panel during the Milestone 5 time. Originally, it was in a floating window. Then, it was in a HUD panel on the left side of the screen. Then, it was in the middle on the right. Then in the top right. I still think it’s in the wrong place. For a while, I thought that it should replace the context matrix, but obviously the quest editing wouldn’t fit into so small an area. I still think that needing to click the little “Info” command to show the info panel is completely the wrong interface; it should show up automatically when an object is selected — I’m just not sure where it should show up automatically.
• Lots of “design days”, where nothing concrete was accomplished. Largely due to the above design paralysis, I spent about ten days on the info panel, but only about three days on the quest editing itself — the quest editing which was supposed to have been the whole point of the milestone build.
• No support for editable values in the info panel. I really wanted, for example, to be able to rename a region, or change its color, or etc. But due to the number of times I threw away work on the info panel, I never quite had the time to add actually add support for editable values. (Although some of the functionality I added for the quest editing could be adapted, in future builds)
• On this very short timeline milestone, I spent a few days fixing bugs from Milestone 4, including crashes from placing roads and etc. Maybe I shouldn’t have put those sorts of bugfixes into the same timeline for adding new features? I don’t know. They take basically the same time no matter where I put them, so maybe it doesn’t matter.

Really, the big surprise takeaway from MS5 for me is how much I like this shorter duration between deadlines. If folks are interested, I might start doing public builds every two weeks, or every month, regardless of whether or not there’s a full “milestone”.

Anyone have thoughts?