Tears unnumbered ye shall shed

[debo]

I will totally run a comp but I take no blame if emphasis is on sil

[Antoine]

> I don't know exactly how me as maintainer and a devteam would work, but I think we could muddle through.

I would be interested in doing the occasional small, self-contained piece of work. I did the new monster groups with fizzix and that seemed to work well.

I like theorycrafting too.

A.

[Mondkalb]

Hm, I'm really worried about the impact on Beleriand because I am looking forward to it and can't wait to see it.

A major rewrite of the Angband code seem to be an enormous undertaking. My personal wish: If it turns out to be too complicated, leave it as it is and go on working with Beleriand.

[Magnate]

Originally Posted by Nick

I don't know exactly how me as maintainer and a devteam would work, but I think we could muddle through. Probably the best of takkaria's many achievements as maintainer was the team process, and I wouldn't want to mess with that too much. I'd be inclined to start slowly and let things evolve as they evolved. I would possibly look at recruiting some specific people, too.

I can offer some reflections here. I agree that it was takkaria's greatest contribution, but it gives you the responsibility of balancing the quantity of contributions against the quality. Give commit access to too many enthusiastic amateurs like me and you end up with the "dodgy design decisions" to which Antoine referred in the previous thread - note that this dodginess will often have nothing to do with the contributions themselves, but their interaction with some other part of the game. Eddie was assiduous in pointing out how every change I made broke something else, even when the change itself was a good one.

So it seems to me like you have a fundamental choice between the approach takkaria took with V and the one Derakon is taking with Pyrel - Derakon is an awful lot more exacting, but has many fewer contributors. (I know that's not an entirely fair comparison because Pyrel started from scratch.) At one end of the scale you write the whole thing yourself and it's perfectly coherent, and at the other end it's rapidly evolving, unbalanced chaos.

Personally I think you're insane for taking this on, and it's particularly painful for me because this will be the THIRD time I've written the bloody affix system (if you'll have me) - but I can't say I'm not impressed.

Final tip: don't release nightlies. Release often, but do it after finding out what the latest changes have broken.

[Nick]

Originally Posted by Magnate

I can offer some reflections here.

Thank you, this is very helpful.

Originally Posted by Magnate

it gives you the responsibility of balancing the quantity of contributions against the quality. Give commit access to too many enthusiastic amateurs like me and you end up with the "dodgy design decisions" to which Antoine referred in the previous thread - note that this dodginess will often have nothing to do with the contributions themselves, but their interaction with some other part of the game.

Originally Posted by Magnate

So it seems to me like you have a fundamental choice between the approach takkaria took with V and the one Derakon is taking with Pyrel - Derakon is an awful lot more exacting, but has many fewer contributors. (I know that's not an entirely fair comparison because Pyrel started from scratch.) At one end of the scale you write the whole thing yourself and it's perfectly coherent, and at the other end it's rapidly evolving, unbalanced chaos.

This expresses the issue perfectly. I think team dynamics won out in the end - my gut feeling, without a lot of playing, is that 3.4 is well-balanced, and 3.5 clearly better than it in every direction. But moving to a new maintainer would change those dynamics, and have the potential to derail everything again.

Luckily, I have nominated basic code restructure with no gameplay change as the first thing I would do. This leads to some advantages:

• Team all get used to n00b maintainer and possible new members
• 'Game-breaking bug' means game crashes or doesn't run, which is fine in the context of a code restructure
• Everyone involved gets to know the overall code structure better

Originally Posted by Magnate

Personally I think you're insane for taking this on, and it's particularly painful for me because this will be the THIRD time I've written the bloody affix system (if you'll have me) - but I can't say I'm not impressed.

Have you not noticed the use of "would" rather than "will"? This thread is like the first stage of XP allocation in Sil - you can see what you're buying, but you haven't bought it yet

As regards the affix system, note that combat system is part of the last item on the list, all of which would be subject to review and negotiation. I can say that writing the affix system twice has been a valuable life experience for you

[Nick]

Originally Posted by Magnate

Final tip: don't release nightlies. Release often, but do it after finding out what the latest changes have broken.

This is a significant suggestion, and deserved a separate answer. I guess there are times when you want people to be able to play-test changes, but there's no reason why those times should coincide with code commits.

I've been looking at this release model, and would value opinions - it's probably not really all that different to how the Angband development process has worked, but it clarifies some stuff for me.

[Derakon]

Speaking as one end of the extremes Magnate listed, the tradeoffs between the dev-team model (Vanilla) and the dictator model (Pyrel) are basically:

Dev team model:
* Development can happen quickly, since many people have direct commit access to the repo.
* Code style guidelines are not strictly enforced.

Dictator model:
* Development speed depends on the free time of the dictator.
* Code style guidelines can be strictly enforced.
* Pull requests can involve a lot of back-and-forth (depending on how picky the dictator is and how "finished" the code was prior to submitting the pullreq), which can aggravate contributors.

Long-term, I remain convinced that maintaining a consistent code style and a high standard of comment quality and quantity is worth the initial headaches, but I know that other Angband developers don't always agree.

[Nick]

Originally Posted by Derakon

Long-term, I remain convinced that maintaining a consistent code style and a high standard of comment quality and quantity is worth the initial headaches, but I know that other Angband developers don't always agree.

I think I'm somewhere in the middle, but in a kind of messy way. I guess it depends on what you mean by code style:

• Things like indentation and where you put braces (talking C here, not python!) I like to be uniform, but I'd rather see code with this "badly" done than no code
• Comments quality and quantity somewhat similar, although I guess with both these things "that can be fixed later" too many times leads to problems
• Code structure - things like consistency and clarity of purpose - I'm prepared to go to war over

[nppangband]

Originally Posted by Nick

That is brilliant, and seems to align very largely with my ideas. I assume you would not mind me stealing stuff, as you never have in the past...

Absolutely. If we get it working I would be happy to help you merge it with the Vanilla code.

[Whelk]

Originally Posted by debo

Beleriand

Dreams of an effort to dwarf every other,
A project so vast, so beaut'ful and grand,
Yet hon'rable duties call Nick elsewhere, brother
Alas! Alas! to Beleriand.

:'(