Roadmap for angband

[Timo Pietilä]

Now that Takkaria has resigned and committee has taken over how about posting a roadmap here as sticky post.

I respected Takkarias ability to keep angband angband, but I don't trust committees to do the same job right. You need to agree about future development just as well as current development and making every and all changes some developer just thinks could go into game fast changes to anarchy or at best just visionless game.

[Nick]

I'm not sure how well it fits with your idea, but here is a current roadmap.

Mind you, I'm also not sure of the future of rephial and trac.

[Antoine]

I'm not sure how well it fits with your idea, but here is a current roadmap.

Mind you, I'm also not sure of the future of rephial and trac.

It would also be interesting to hear who will fulfil Takkaria's role on the devteam (in particular, as an arbiter of what changes will be accepted).

I am sure someone has all these things in hand, I'd just be interested to hear what the plan is...

A.

[Timo Pietilä]

I'm not sure how well it fits with your idea, but here is a current roadmap..

That's just to-do list. Not why something is being changed or what are the reasons to do something. What I wish is that kind of "roadmap", because without that game will most certainly go variant. IE. it stops being angband and begins to be something else.

[konijn_]

Now that Takkaria has resigned and committee has taken over how about posting a roadmap here as sticky post.

I respected Takkarias ability to keep angband angband, but I don't trust committees to do the same job right. You need to agree about future development just as well as current development and making every and all changes some developer just thinks could go into game fast changes to anarchy or at best just visionless game.

Frankly I wonder if we should nominate a non-developer to be the arbiter of the team ? Someone that knows how to balance this game since a really long time.
You know, someone that actually played Frog-knows..
Just sayin'...

T.

[Magnate]

That's just to-do list. Not why something is being changed or what are the reasons to do something. What I wish is that kind of "roadmap", because without that game will most certainly go variant. IE. it stops being angband and begins to be something else.

It's worse than that - it's a to-do list for V *and* a to-do list for v4, in one place.

Part of the problem with doing proper long-term planning for development is that nobody on the team knows who will be able to do what by when - which is kind of essential for any serious planning. I don't even know what I'll be able to do myself, let alone what any other devs or other contributors will do.

@Antoine: actually the discussion we had in the team before takkaria departed was that we would try to operate without a titular maintainer, i.e. by devteam consensus. If that doesn't work, I guess we'd then look for a new maintainer (not necessarily one of the current devteam). In the meantime, anyone is welcome to join the team - we hang out in #angband-dev at irc.freenode.net

[Antoine]

actually the discussion we had in the team before takkaria departed was that we would try to operate without a titular maintainer, i.e. by devteam consensus.

I'm sure that can work fine, so long as some person (or combination of people) on the team exercises the role of vetoing "Kewl" new features.

Perhaps what Timo is looking for is not so much a workplan as a manifesto - i.e. what kinds of changes are appropriate for V, and what are not. (I think Geoff Hill and Takkaria both made some comments along these lines in recent weeks, perhaps in the establishment-of-V4 thread.)

A.

[Magnate]

I'm sure that can work fine, so long as some person (or combination of people) on the team exercises the role of vetoing "Kewl" new features.

Perhaps what Timo is looking for is not so much a workplan as a manifesto - i.e. what kinds of changes are appropriate for V, and what are not. (I think Geoff Hill and Takkaria both made some comments along these lines in recent weeks, perhaps in the establishment-of-V4 thread.)

Yeah, I think we pretty much feel we've done that, with the whole v4 thing.

Basically, my view is that pretty much nothing goes into V except bugfixes and changes about which there's complete consensus - this was the whole point of creating v4 - to appease the people who said "V should be about bug fixes and UI improvements". So gameplay changes should go into v4 first - if it's uncontroversial it can go into V quickly, and the length of time it takes to migrate to V should be in direct proportion to how big/radical/controversial it is.

Underlying improvements, like UI and refactoring, can go the other way - done in V first to get them out to the world, and ported to v4 when someone feels like doing the work.

The thing is, there's not a lot of coding going on at the moment. v4 is already quite different from V, but there aren't yet lots of discrete changes that could be propagated to V (though some small fixes have been, and the object detection nerf). I'm about to merge Nomad's new room parser into v4 tonight, which should be a good candidate for going into 3.4 if people like the new rooms.

Having said that there's not much going on at the moment, let's not forget that the 3.4 dev versions are already really quite different from 3.3.x - new pits/nests, improved mimics, nerfed detection, reduced stack size, etc.

In a few months time I envisage that there will be quite a few things in v4 which are getting various different critical receptions, and the good/popular ones can be migrated to 3.4 while the, er, less polished ones stay in v4.

One thing we're all agreed on is that we want to get Shockbolt's tiles working for 3.4. Once that's done, we'll have a proper discussion about a release date for 3.4 and what else ought to go in it, and when to enter feature freeze, and who will be release manager, etc. etc.

[nppangband]

My only question is, what happens if there is not a consensus? Who decides? Somebody has to fill that role & be the game visionary. Otherwise Angband just becomes several variants all rolled up in the same executable(d_mband, fizzixband, magnateband...etc). Of course those sound like fun variants with plenty of good ideas, but it wouldn't be Angband either.

[Shockbolt]

Were it up to me, I'd push it even more towards the Middle-earth feel, after all, it's Angband..

[Magnate]

My only question is, what happens if there is not a consensus? Who decides? Somebody has to fill that role & be the game visionary. Otherwise Angband just becomes several variants all rolled up in the same executable(d_mband, fizzixband, magnateband...etc). Of course those sound like fun variants with plenty of good ideas, but it wouldn't be Angband either.

Well this was the debate we had about whether we needed a titular maintainer or not. One side of the debate made exactly your point - that without a figurehead, someone to whom the rest agreed to defer on these decisions, we would be unable to have that vision. The other side of the debate argued that operating by consensus could extend to the vision for the game - that decisions on which of my/fizzix's/d_m's great ideas should go in and which should stay in v4 could be made as a team, rather than by one individual. Eventually we ended up agreeing to give the latter approach a try. That doesn't mean your point isn't valid, just that we felt we would be able to work around it as a team operating by consensus.

P.S. I should have added to my previous post that one of the reason's there's been a coding hiatus is because we're trying to get the APW borg working for v4, after APW kindly pushed the code to github. Having a borg will make it *much* easier to find and fix bugs in v4 (which is going to have way more bugs than V).

EDIT: I realise that I didn't address your point about what if there isn't a consensus. I think the conclusion of our debate was that a consensus can be "agreeing to disagree". So even if some of us want a change to go in and others don't, we can reach agreement one way or the other.

[takkaria]

My only question is, what happens if there is not a consensus? Who decides? Somebody has to fill that role & be the game visionary. Otherwise Angband just becomes several variants all rolled up in the same executable(d_mband, fizzixband, magnateband...etc). Of course those sound like fun variants with plenty of good ideas, but it wouldn't be Angband either.

Since I proposed the idea I feel like I should defend it. I think V should move at the pace of the slowest voice. If the developers don't have workable consensus on an issue, it doesn't move forward. I think this fits the fundamentally conservative nature of V. There is the pressure from the community to the development team that means the development team is not going to have consensus that e.g. introducing Steam Mecha or a wilderness is a good thing for V, if they would ever have thought it anyway.

I don't think it needs a maintainer's grand vision - certainly, the only release I had a strong vision for was 3.1.x. We had a few all-devteam meetings to work out what we wanted to do for 3.3 (I don't remember what happened with 3.2). Everyone gives their input, and collectively we figured something out. The same process eventually gave rise to the announcement of v4. So the consensus process has been working for a while already, just behind the scenes. I guess my resignation just brings it to the fore.

[Timo Pietilä]

I don't think it needs a maintainer's grand vision - certainly, the only release I had a strong vision for was 3.1.x. We had a few all-devteam meetings to work out what we wanted to do for 3.3 (I don't remember what happened with 3.2).

For some reason I feel that 3.1 was the last real release of the game and subsequent releases have all been "work in progress" -beta versions. I guess I now know why I felt that way. 3.2 and 3.3 were a bit sloppy versions, too many changes that had to be reversed and again many changes that no-one had time to really playtest and understand how they affected the big picture.

"Dev team" does too fast job. There are changes coming in every which way without real testing. This leads to chaos and I just plain can't trust that they make a good team to control the development of the game. There should be also players, not coders into ranks of "dev team", and ultimately it should be the community that makes the final decision. This has been seen, even with single maintainer community vote overrules the choice if it is too controversial.

I'm all for fast changes if there is need for fast change, but when there is something completely new then it just plain takes time to see the complete picture. Like introducing add-one, lose-one potion, which in turn changed importance of nexus resist quite badly. I don't think no-one considered that side-effect before it had changed to "fixed feature" of the game. Not that it was bad change, it just has unseen side-effect. These unseen side-effects happen in almost any change. Everything affects everything.

Something small, like change in how rarities were calculated: as side-effect many earlier very rare artifacts were now just rare, not very rare. No-one really understood why, because that change came in without testing, or even discussion should that be done and what are the potential effects of the change. It took really long time before people started to realize that while still being rarest possible, artifacts like The One Ring and Ringil were now a lot less rare and it wasn't just changes in artifact.txt, TMJ -fight or other game changes that caused that.

Test everything. Discuss. Not only between yourself and with terms of code. Include community. There needs to be human-readable explanation of the change. Reasons why and what are the consequences. What else needs to be changed in order to make it work, and what are the consequences of that and so on.

[Magnate]

I think it's really quite difficult to do this. It's often very hard to explain changes which are quite small, and impossible to know all the side effects of changes of any size. And it's not usually the case that we make changes which haven't been discussed - it's more that we subsequently have an idea for implementing a change which has already been debated in one or more threads.

Your examples - the gain-one-lose-one potions and the change to artifact rarities - are perfect illustrations of why we created v4. In many cases it's not possible to know how a change will play out until it's tried, however much it is explained and discussed. So v4 allows this to happen without any damage to V, and it means that changes will only go through into V when their full implications are understood by people who have tested them.

Non-coders are very welcome to join the devteam - there are a number of non-coding jobs that need doing:
- testing
- stats generation and analysis
- help text
- flavour text
- ticket management
- PR
- release management (requires ability to compile but not code)

[Antoine]

> I think it's really quite difficult to do this.

True but it's probably still an ideal to keep in mind.

> Your examples - the gain-one-lose-one potions and the change to artifact rarities - are perfect illustrations of why we created v4. In many cases it's not possible to know how a change will play out until it's tried

Just so. Of course a change that is bugfree / OK for game balance in v4 may not be in V... but it's a good place to start.

A.