MAngband version 1.0

[Fink]

Think of all the cool ideas you've had for MAngband over the years. Think of the number of bugs we have uncovered over time. Think of all the features that are in the game that could be changed or tweaked or grown to be cooler/better/different. If you really start envisioning all that (and imagine a sizable base of people thinking of their own ideas as well), you may begin to realize it's actually a pretty massive and overwhelming list. Take a look through the bug forums or the wishlist forum. Think back over conversations you've had with other players about the game. The result of all this is an incredibly huge hodgepodge of ideas, features, changes, fixes, and bugs.

Together, we have a massive library of things to do, and things to consider persuing. Over time, I worry that we may have veered off a bit from the course originally set to take us through this huge library of stuff. I'd like to encourage a bit of a stepping-back to get a look at where we are, and where we set out to get to.

A decade ago, some crazy guy had the completely kooky idea of taking a turnbased roguelike and making it not only realtime, but mutliplayer. Insane! I'm going to call this the Basic Mandate of MAngband: go forth and code up a realtime multiplayer version of Angband! The then-latest Angband code was snagged (2.7.9), and thus began our beloved variant. This is a key point: the mandate was not "go convert Angband, toss in huge loads of cool extra stuff, totally redo other stuff, have the game auto-order pizza for you via RSS at shop 7, have multiple cities in the game, and make Morgoth a playable race." The starting basic mandate was just "get out there and convert Angband to run as a realtime multiplayer game". Clearly, there were loads of possibilities, but you have to get the basic idea implemented first.

Keeping in mind that Basic Mandate (convert Angband to MAngband), I'm beginning to wonder if instead of being at a place where we are slowly inching along from one ill-defined point to another, we are in fact pretty damned close to being at MAngband version 1.0. Think about it: for literally years, we have been logging on, building up characters, collecting loot, clearing dungeons together, stashing loot in houses we've bought, rescuing eachother when we die, and trading loot back and forth at a great clip. Seriously, if that aint MAngband 1.0, I don't know what is.

Once we put a stake in the sand about where we are, then we have a point of reference to evaluate our huge list of stuff against. With it, we can decide if an issue is a bug to fixed now, or if it really isn't critical and is instead related a later goal. With it, we can decide if a feature is critical to our current version, the next version, or perhaps if it's actually best left to variant work because it doesn't directly relate to our fundamental idea of a vanilla MAngband.

So, I bring up the idea that we are actually very very close to MAngband version 1.0 not just for its own sake, but also because doing so, I feel, helps us get a handle on how to place the elements of our to-do lists into a timeline.

Do we have bugs? Sure. Could we use some new features? Sure. Would it be nice to have some existing features expanded? Totally. But these are not 1.0 issues! New or changed features, medium/low priority bug fixes, and tuning/balance passes, are all post 1.0 issues. Version 1 of a software product is to make something and get it working. Then, you learn from what you've made, identify needs and possible changes, make lists of the medium and low priority bugs, and get cracking on the next version.



With this in mind, here is what I propose as a long term plan for the ongoing development of MAngband:

                           

v1.0 "Multiplayer Angband"
Convert Angband 2.7.9 to realtime multiplayer

• Stable
• Basic feature set in place to support realtime multiplayer gameplay.
• High priority bugs fixed: (crashes, severe gameplay issues).

                           

v1.1 "Basic Content Infusion"
Add in the basic monster and equipment content  that is easily portable from contemporary Angband.

• As this process has already started in variants, add in a basic drop of newer Angband monsters.
• Explore basic equipment additions from Angband that can be easily added without the requirement of significant work, changes, or retuning.

                           

v1.5 "Sync and Diverge"
Evaluate contemporary Angband in light of MAngband, and adopt/adapt/reject the Angband features and content as applicable.

• Perform a top to bottom review of what's new and changed in the latest versions of Angband.
• Evalute these changes and additions with an eye toward what would work in MAngband, and what would not.
• Evaluate and implement difficulty retuning based on existing data, new content, new features, and the Ang/MAng divergence created due to selective feature/content borrowing from Angband.
• Medium priority v1.0 bugs fixed.

                           

v2.0 "Beyond Angband"
Extend MAngband into new directions, grow features useful for variant makers.

• Add and extend features not present in Angband that are meaningful for realtime multiplayer, while staying true to the idea of a "vanilla" MAngband.
• Add systems and features to support modification and variant making for developers who wish to explore "non-vanilla" additions or changes.
• v1.0 low pri bugs fixed.
• v1.5 medium pri bugs fixed.

[Warrior]

As you already know from our discussions about this I totally support this suggestion and I think it would do the game only good to take the "mandate" of MAngband into consideration for the next release.

What better way to celebrate MAngband than to release MAngband 1.0 on it's 10 year anniversary?

[Fink]

[color=8888AA]I originally wrote this in response to a thread relating to "where the heck is our maintainer" in topic. But, I realize that it is essentially a continuation of the topic I introduced above.[/color]


Once when I was on vacation, I sent an email to a buddy I work with, to say hi, tell him how my travelling was going, etc.

Now, I type reasonably quickly, and tend to approach emails in fairly conversational tone. So, it being a pleasant morning in some far-off land, I kicked back with a cupa joe and rattled off a big long email detailing my recent adventures.

The recipient, normally good about responding to emails, was silent. For days. Weeks. I finaly got back from vaca, and asked him "dude! why no response? nary a 'glad to hear you're having a good time'??".

He said, effectively, this: "You're email was long and detailed, so I felt like I should respond in kind. So I kind of put it off 'til lunch to respond. Then, I got kind of busy, so put it off till the next day. Well, I had a busy week, and suddenly it was Friday, and I hand't responded. Damn! 'Ok,' I promised myself 'Monday, I'll totally write an even longer, cooler, more in-depth email in response!' Then another week passed. And I felt like I had to write and even *more* elaborate, beautifully appointed, wonderfully composed email. And then another week passed where I didnt respond, because now the effort would have been greater than the original response would have been! Each week that passed, I felt like I owed an even more tome-like life-story email! Finally I just started avoiding all thought of the topic, and hid the email in a sub-sub-sub folder in Outlook because I didn't want to look at the subject line and be reminded of it. It was like a stone soup of email, in reverse!"

                                                                   


I suspect Crimson is kind of in this boat. Crim rolled onto the maintainership scene, full of piss and vinegar and roaring to go. He banged out loads of cleanup, bug fixing, optimization, and feature work. The the nuclear bomb of professional busy-ness dropped, and the Stone Soup Email syndrome (tm) kicked in, I believe.

Now, my suspicion is that he may feel a bit trapped. Each year that passes results in constantly inflating expectations, to the point where these expectations are pretty much insanely unrealistic. The further you get behind where you think you are supposed to be, the greater the promises to yourself of "ok, next vacation, I'll totally dive in and really hit it hard!" become.

This, I think, really brings focus to the very idea of just what the committment is of taking on the role of maintainership. I mean, think about it: is it really supposed to be a role you fill until the day you die? Is it supposed to completely open ended on all counts, in terms of duration, code work, bug fixing, site and back-end maintanence?

The way I look at it, Crim took up the challenge for something, but I don't know if what exactly that was/is ever got very well defined. It's all fine and dandy when it's a codebase that has reams of contributors and players like our parent Angband - they have potential maintainers up the yinyang. But MAngband, by virtue of its quiet obscurity, will necessarily have long periods where there will be the occasional tinkering from the users, and little else. When you step into a maintainership role, I think there is an unspoken agreement/expectation that there can be an an easy and no-problem end or reduction in the role when the time comes. Heck, thats the whole point: not el presidente for life, but fearless leader while able. The smallness of the MAngband community means there is rarely someone present of maintainer-level calibre for coding and development. The whole maintainer paradigm kind of assumes a minimum size of community that MAngband generally doesn't have. The contract, so to speak, ends up with some problem spots in it.

                                                                   


It was this thought that led me to post the MAngband v1.0 thread.  I very much believe that we need to step back, take stock of where we are and where we want to go, and come up with a roadmap. This roadmap should have definite goals laid out, so that when whoever has taken up the reins has a clear plan to follow that details where we want them to take us, and the codebase. This way, we can accomodate the smallness of the MAngband community and future-maintainer pool: our maintainers, when we have them, can thus avoid the effectively open-ended "I can never escape!" trap by instead comitting to a specific series of goals. Each milestone on that roadmap represents a point of fullfilling the maintainership agreement, and a decision point where the maintainer can modify their role if they so choose.

We've been experiencing for a while a state that I think we should formalize a bit more: a mangband "simmer" mode. That is, a point where a portion of the recipe has been followed, and the soup is now put onto a low burner and allowed to simmer until the next chef rolls around. I say, let's embrace this as being an understandable effect of being a small community. It simply is not realistic for us to expect that a maintainer who signs on is effectively signing their life away in perpetuity, until maybe one day in the distant future when another maintainer-calibre person rolls on by. Sure, those guys over in Angband have gazillions of people all over the place, so its like shooting fish in a barrel to find a new maintainer for them. We need to accept that the small scope of the MAngband community creates a different scenario which we need to adjust to.

                                                                   


The role of the MAngband maintainer consists of a number of elements that I think we should break out into its component parts, and deal with individually. These are:

• Maintaining and hosting the web presence of MAngband
• Maintaining the flagship server, its internet connection, and its hardware.
• Maintaining the code respository, interacting with user contributors, keeping fresh batches of code and binaries available for download.
• Developing MAngband code ("upper-case-M" Maintainer)
• Acting as custodian/"lower-case-m" maintainer of the code and contributed code (deciding which user additions should go mainline and which should not etc, separate from doing full-on development)

Now, we will always need an ongoing presence of someone who literally owns the mangband.org domain, hosts the website, and sundry things like this. In my "simmer" way of thinking, I'll call these "custodian" tasks (that is, the non-dev tasks listed above). When you break out the uber-maintainer list of tasks into pieces, you can see that it's really kind of easy to envision a custodian role that doesn't have to also contain the full code development role. Our simmering Custodian always needs to be present, but the comittment is much more realistic in an "in perpetuity" sense.

With this in mind, I propose that we hash out, with Crimson, a milestoned plan of what needs to be done into the future for MAngband, and then ask that he comit only to that first milestone if he chooses to (in my "1.0" thread, this is the v1.0 milestone that I mentioned). After reaching this point, he could then choose to continue as both Custodian and Maintainer, or instead choose to step back to just fill the Custodian role if he feels real-life demands dictate it (ie, enter MAngband Simmer Mode (tm)). This would represent a new mode of opperation for us - one that I think would be much more realistic, better reflect the realities of our beloved variant, and put a much more realistic set of demands on the shoulders of a simmering leader.

As well, I kind of like looking at the broken-out list of Maintainer tasks listed above, as it suddenly makes the whole issue more approachable: its a damn tall order to find people who can fit the entire bill. But, its much more realistic to find people who are capable of individual components of that list. That is, it can be tough, as Crimson would no doubt attest to, for one person to consistently cover all of those tasks all the time. But it is much more realistic to find people who have the time and skill to do different bits of it. Approaching the issue from this angle means we can get partial coverage on many elements over time, instead of trying to throw all demands and tasks on those rare induviduals who can theoretically (but maybe not realistically) cover the lot.

                                                                   


Put more simply, if you are the chef, the maître d', the waiter, the doorman, and the bartender, you might be understandably wary of answering a phone call from the restaurant while you're at home. But if you're just the bartender, I suspect you'd be much more willing to show up.


-fink

[Billsey]

I like your task list for the Maintainer, though I might change many of the 'Maintaining' to 'Coordinating the maintenance of', since many of those tasks might be better handled by others. The key is that who ever takes on the responsibility of Maintainer doesn't necessarily have to do everything, just see that the tasks are done. More of a manager than engineer.

I also really like to idea of switching to 1.0 for the current release with the well known bugs removed, then setting goals for various milestones. I'd also really like to suggest that we move to a SourceForge hosted code base. I believe that would go a long way to helping make sure that bug reports and feature requests are dealt with. The SVN database that Jug did is a great start, but not as transparent to the end user as SourceForge would be.

So what's the next step? Does Crimson have a current code base different to what's on the web site? For that matter, is the code that's actually running on Mangband.org available? I wouldn't mind too much redoing most of the things I've worked on with my server to allow a clean compile using Visual Studio 2005 Express if I were rolling those into the base instead of working off Jug's version. Or maybe that version should be the base...

Bill

[Fink]

Re: "coordinator of..."

Extremely well put, Bill - this was the idea I was kind of orbiting around above. The tasks need not be onerous when broken apart from both eachother, and from the 900 pound gorilla of active code development. A buddy of mine likes to use the phrase "sustainable development" to describe the idea we have going on here: matching methods with reality, so things can continue to move forward at a varying and realistic pace, instead of an unrealistic binary manner.

I think your idea about Source Forge is spot on: keeping the code public and easily accessible, with Crim as arbiter as to what goes into mainline based on quality and adherence to standards, "vanilla-ness", and agreed on goals. I'd love to hear what other people think about this idea.

One initial wodge of stuf to digest here would be Crimson's changes that he has made past what is available in the code from mang.org. I know he has done work on a variety of fronts, intending, I believe, these changes to be part of "0.8.0". Perhaps a first step could be to open these up and detail them for discussion and digestion, so we could start a process of combining everything we have at present (his work on vanilla, and vanilla-level work by others) into an initial first dump of code for a public repository.