Heya All,

Yesterday I posted the second revision of the feature list for the MiniMORPG, which, by and large was just a more fleshed out version of the original feature list. I was surprised by how many people either posted a response to the journal entry, PM'd me, or eMailed me with "wow, that's a big project, sure you can handle all that? Shouldn't you start with something smaller?"

I just wanted to real quick say (assuming the voice of a TV announcer), "This experiment was performed by professional developers, please, do not try this at home; or while under the influence of alcohol or medication. Actually, Alcohol is fine." [lol]

Actually, in all seriousness it is a lot of work, but that's the whole point isn't it? MMORPG's (or rather 3D Multiplayer RPG's of ANY size) are a lot of work, even a relatively scaled down version.

I also wanted to comment on a common misconception about development. More times than I can recall a project lead, boss, or even a friend has said "I need a . Is it possible for you to make something like that?" My usual approach was to make a quick checklist of the features in my head, careful to take into account error in estimation, etc...and assign a time value for each component. Then add up the total time estimated and say "Yes, and it will take me this long."

You see, humans tend to think hierarchically in subject matter, but our abilities to subdivide time into smaller chunks isn't implicitly hierarchical. So one often finds that given a list of three things to do (even knowing that each of those 3 divide into 3 more things) we will give an erroneous estimate, as we're not summing the value of each of the subcomponents. In other words, 9 times out of 10 you will find that taking the 9 components and adding them up, results in a larger number than taking the 3 numbers and adding them up.

So what's this mean? The more subdivided your analysis, the higher the granularity of your task list when making the estimate on time, the more accurate your estimate will be. I suspect that given the initial task list I presented a few days ago, people made the quick estimate in their head and came up with a number in the weeks to few months range. Given the new feature list (which is just a more granular view of the original task list) people are starting to realize how much work is really involved. And before we move on to the design phase there will be at least one or two more drafts of the analysis, each resulting in a more accurate and descriptive list of features and behavior.

Also, someone commented on whether a project of this size goes against the rope bridge philosophy. But keep in mind that the rope bridge is an implementation paradigm that can be applied to a task or problem of any size, whether it's writing a method, a class, a system, or even an enterprise application suite. Each sub-component must be approached as a separate, yet related rope bridge, and be dealt with accordingly.

If anything, having more detail (or a larger project) doesn't go against the rope bridge analogy, it works for it. Imagine trying to build a bridge from one side of the cliff to the other, without knowing where the other side of the cliff was.

The analysis phase of of the development cycle (of analysis, design, implementation, and optimization) is simply to determine where the other side of the chasm is. There's no actual building of any bridge yet. Another way to think of it is:

- Analysis is determining where the other side of the chasm is
- Design is determining the best way to build the bridge, given how far away it is
- Implementation is building the rope, and suspension bridges
- Optimization is building the supported bridge

I'm glad it's starting to seem like a lot of work though. I know quite a few people who calls themselves game programmers, but despise programming games. You see, they're in love with the IDEA of being a game programmer, without enjoying or looking forward to the process of programming. Their projects tend to be either way too small, or way too big, and either way tend to never actually get started.

So if you're starting to look at the workload involved and realizing what kind of commitment it will be, then you're taking the first step in the process, and that's a good thing.

/discuss