tabstorm wrote:Basically everyone knows hunger doesn't do anything unless you are playing an extremely contrived character or are remarkably bad at the game. It can't just be removed, because of hypothetical optimal play concerns. What if players choose to go atheist (for no piety decay) and spend 30000+ turns per floor in lair or whatever, waiting for enemies to come to them in advantageous melee positions like in DoomRL? This will provide a negligible benefit, just like hypothetical optimal play around floor traps as we saw from the recent Ultraviolent4 game. Nonetheless, there is a desire for a progression clock for purely ideological reasons, on the same level as floor traps continuing to exist. The difference is that you can more or less ignore floor traps and be no worse off for it, but you can't ignore the need to feed without playing a Mummy or Vampire, and who wants to do that?

Weren't you the guy who recommended rewriting Crawl from the ground up?

I don't think anyone will actually do it, I don't plan to, certainly. But I can still suggest that maybe it wouldn't be so bad, in some ways. Let's look at a few examples:

-The crawl combat formulas are a total mess. Most people, me included, don't have anything but a faint idea of the marginal value of an increase in str/int/dex, base damage vs. enchant, of the relative value of Fighting, and so on. All I know is "base dam good, big weapon good, me smash, dex > 18 bad", and "Int good", and then everything is hacked together with stepdown functions. There are other games that do this more effectively.-The weapon skill system. Different weapon types aren't hugely different in practice except for Axes, and the delay system seems to just be a hack to force decision on a weapon type and prevent midgame swapping. This system always seems to confuse players, and hides the fact that the marginal value of weapon skill above min delay is very small. And yet, other games like Sil let you change to an axe or whatever and there don't seem to be any problems. Excessive fine-graining of speed causes a large memory burden on the player, especially when you have things like energy randomization introduced as a hack for pillar dancing.-Numbers in crawl are too big. In the late game we see monsters like Juggernauts being introduced to have a chance at killing high level PCs. Combat which relies on ever more extreme swings as the game goes on is less than desirable, imo.-The branch structure. Due to semi-open-ended structure, players are encouraged to leave rune vaults unvisited until as late as possible, so runelock had to be introduced as a hack to preserve the specialness of vaults, in part because we have issues like Shoals actually being harder than a late-midgame branch (V: 1-4).-The hunger system. The player has to eat WAY too often. On mages, in particular, a character may eat 700+ chunks per game in addition to 30+ rations. Is this really necessary? It seems like there are multiple systems (hunger, piety decay, OOD respawns) to force players to progress, except that due to semi-open-ended structure, they must be lax enough to allow backtracking and yet not so lax that scumming is easy. Right now, these systems are pretty much at the point where they're just annoying because they're also intertwined with, for example, magic, as a carryover from Nethack. There are also species with awkward hunger interactions like Ghouls and Vampires that prevent easy reform of hunger. Let's not forget how awful Centaurs were when they had Herbiovre.

I really like how GDD threads have a preset structure that our otherwise incredibly chaotic board seems obliged to follow.

To wit, the first poster will suggest a small and prudent change; for example, that trolls should be able to eat entire corpses from the ground for the total nutrition that its chunks would give, because carnivore and fast hunger means they'll c e e e e e e a lot of times during a game. A second poster, invariably an experienced player, will then simplify this idea by making a suggestion to chop an entire important mechanic from the game. This post will always be an one-liner, like "remove trolls" (what, you were expecting something else?), but may be followed by a well-elucidated explanation about why said mechanic is bad for the game. The whole board will then drop everything it has been doing and discuss the merits and demerits of the second proposal.

"Recode Crawl" isn't even the final form of GDD discussions. Clearly it is optimal for a player wishing to win to remove Crawl entirely, thus fully eliminating the chance to die.

To wit, the first poster will suggest a small and prudent change; for example, that trolls should be able to eat entire corpses from the ground for the total nutrition that its chunks would give, because carnivore and fast hunger means they'll c e e e e e e a lot of times during a game. A second poster, invariably an experienced player, will then simplify this idea by making a suggestion to chop an entire important mechanic from the game. This post will always be an one-liner, like "remove trolls" (what, you were expecting something else?), but may be followed by a well-elucidated explanation about why said mechanic is bad for the game. The whole board will then drop everything it has been doing and discuss the merits and demerits of the second proposal.

"Recode Crawl" isn't even the final form of GDD discussions. Clearly it is optimal for a player wishing to win to remove Crawl entirely, thus fully eliminating the chance to die.

Here's some context: there was an attempt to rewrite Crawl completely, by Brent Ross, the sole remaining developer of the team that took over when Linley Henzell left. From what I heard, his code was very good and the game was working. It's technically playable as Crawl 4.2 on CDO (I think). However, it's unplayable as a game. It proved so hard to tune balance into something working that Brent sort of gave up (he just disappeared). At this point the DCSS originators stepped in and incorporated 4.2 ideas piecewise into the old, bad code.

Why am I saying this: a honest-to-good, well meant plan to rewrite Crawl from scratch almost killed it. If this would happen these days, Crawl would probably survive, simply because more developers are involved. However, the resulting schism (should you spend *a lot* of effort on groundwork instead of changing the game?) would definitely slow down development.

And that's why I hate these throw-away comments. If you have concrete ideas how to improve the codebase, then say so. Otherwise, you are just distorting whatever the topic was.

How was tabstorm "distorting" anything? All of the problems he calls out are real issues that Crawl has. Nor was it exactly "throwaway," since he explained himself pretty thoroughly. Color me totally mystified by the fact that this is its own thread, especially since the OP is just a personal attack.

Dpeg there is really no reason besides time and money that crawl can't be written over, and it should be written over (hopefully in a more suitable language). Maybe another fork will do this as you representing your dev team have stated that you are unwilling

CypherZel wrote:Dpeg there is really no reason besides time and money that crawl can't be written over

Bolding mine; these are two pretty big reasons for a volunteer project. As he stated, the issue is finding volunteers who are willing to do nothing but spend time recreating what already exists, for an end result that most players won't notice other than it maybe speeding up performance in specific circumstances and seeing more frequent updates due to an easier to modify codebase. If those volunteers came from the current dev pool, development on the current Crawl would take a huge hit, and you might not see either have a release for a NetHack length of time between versions.

I'm pretty sure that if someone produced a well developed fork that did this, it would probably be highly appreciated, with willing support from the devs if the fork producer would accept it. I would like to hear your time estimate on how long you think this should take.

"a political leader who seeks support by appealing to popular desires and prejudices rather than by using rational argument."

Hmm, was the person who makes the well thought out posts with specific details and recommendations the one that had no rational argument, or was it the guy who periodically throws out one liners insulting large sections of the community?

Now, dpeg really can't be called a demagogue, because whatever faults you might find with his debate style, he's clearly not just trying to appeal to popular desires.

if someone were to rebuild crawl, possible create an engine for it so that you don't have to directly change the source code (I know huuuuge stretch ) so that it's easier for people to create there own concepts or maybe and entire fork would be far more beneficial then this current system, even if it is faster then nethack (I have never played nethack so I'm not actually sure how long their updates are). I would estimate that if someone were to just rewrite it by themselves and no life it it would take maybe a year

CypherZel wrote:if someone were to rebuild crawl, possible create an engine for it so that you don't have to directly change the source code (I know huuuuge stretch ) so that it's easier for people to create there own concepts or maybe and entire fork would be far more beneficial then this current system, even if it is faster then nethack (I have never played nethack so I'm not actually sure how long their updates are). I would estimate that if someone were to just rewrite it by themselves and no life it it would take maybe a year

Here's some examples of infrastructure rewrites I grabbed quick:

NetHack (the official version) took about 12 years (I'm pretty sure some of that time was just unlabeled hiatus) and no fundraising for a medium-scale (not full rewrite) infrastructure revamp + bug fixes/features on par with I would say 2-2.5 versions of DCSS (or about a year of DCSS dev time). Most forks of NetHack can probably be assumed to not mess with the general infrastructure, and were made based off of just adding/removing/modifying the source, so I can't use any of them for a replacement estimate.

Ancient Domains of Mystery (ADoM) had an IndieGoGo to raise funds for a new version in July 2012, which probably also included some major infrastructure changes to accommodate the new features. It was released on November 2015 on Steam (probably earlier to backers off Steam), so a little less than 3.5 years.

Using those examples, my guess would be 2-4 years as an optimistic estimate based off of what would need to be recreated. This is without your suggestion of improving modifiability for people who don't wish to code, which would probably throw another year or two on top at least. The amount of effort it would require would be large enough that I personally would rather put that time into development of an entirely different game at that point, because then I could make something new and unique over just recreating something that already exists.

tabstorm wrote:-Numbers in crawl are too big. In the late game we see monsters like Juggernauts being introduced to have a chance at killing high level PCs. Combat which relies on ever more extreme swings as the game goes on is less than desirable, imo.-The branch structure. Due to semi-open-ended structure, players are encouraged to leave rune vaults unvisited until as late as possible, so runelock had to be introduced as a hack to preserve the specialness of vaults, in part because we have issues like Shoals actually being harder than a late-midgame branch (V: 1-4).

I think most of your points are generally reasonable, but I'd quibble with these two.

I don't think larger numbers in the late-game are a problem; if anything, I suspect we're too reluctant to use them, which results in overuse of torment/damnation. Your concern is about damage variance rising over time, but that seems tangential to me.

As we've discussed before, I strongly disagree that the branch structure is a 'problem'. When players find themselves outmatched in an area, the 'semi-open-ended' structure of crawl's branches allows them to try other areas; recognizing and applying this is an extension of one of crawl's core skills, "running away". You and mps dislike it for that exact reason, iirc (since you'd prefer players to have to fight it out or die), possibly it's a fundamental difference of opinion about what makes crawl fun.

One last note: if you wanted to make a roguelike without being burdened with 20-year-old legacy decisions & code, i see no reason why you'd rewrite Crawl, instead of just making a game that's purely your own.

CypherZel wrote:if someone were to rebuild crawl, possible create an engine for it so that you don't have to directly change the source code (I know huuuuge stretch ) so that it's easier for people to create there own concepts or maybe and entire fork would be far more beneficial then this current system, even if it is faster then nethack (I have never played nethack so I'm not actually sure how long their updates are). I would estimate that if someone were to just rewrite it by themselves and no life it it would take maybe a year

Here's some examples of infrastructure rewrites I grabbed quick:

NetHack (the official version) took about 12 years (I'm pretty sure some of that time was just unlabeled hiatus) and no fundraising for a medium-scale (not full rewrite) infrastructure revamp + bug fixes/features on par with I would say 2-2.5 versions of DCSS (or about a year of DCSS dev time). Most forks of NetHack can probably be assumed to not mess with the general infrastructure, and were made based off of just adding/removing/modifying the source, so I can't use any of them for a replacement estimate.

Ancient Domains of Mystery (ADoM) had an IndieGoGo to raise funds for a new version in July 2012, which probably also included some major infrastructure changes to accommodate the new features. It was released on November 2015 on Steam (probably earlier to backers off Steam), so a little less than 3.5 years.

Using those examples, my guess would be 2-4 years as an optimistic estimate based off of what would need to be recreated. This is without your suggestion of improving modifiability for people who don't wish to code, which would probably throw another year or two on top at least. The amount of effort it would require would be large enough that I personally would rather put that time into development of an entirely different game at that point, because then I could make something new and unique over just recreating something that already exists.

(I'll be sad if I put this effort in responding to a sarcastic post)

Maybe it would take that long, but crawl has been in development for longer hasn't it. I'm not saying it will be easy but it's the best thing to do for the game

CypherZel wrote:Maybe it would take that long, but crawl has been in development for longer hasn't it. I'm not saying it will be easy but it's the best thing to do for the game

Any positive rewrite would be the best for Crawl's codebase, yes. What I'm saying is that you aren't likely to get that based on the estimated time and effort required unless you:1) Personally want to do it yourself, as the other DCSS devs would probably prefer to mess around with the game that exists right now than recreate the game under the hopes that people are still playing and interested in developing for Crawl by then, and that hopefully the remake hasn't been feature creeped out of relevance.2) Find funding for a team to develop it, with the knowledge that you will never see a cent of return profits due to DCSS being developed under GPL, making it pretty much an act of charity.

ok, I don't know how much work it would take for a rewritten fork vs. just overhauling the things I listed. But it would certainly be a lot of work to overhaul them. So "rewrite" is a bit provocative.

PleasingFungus wrote:

tabstorm wrote:-Numbers in crawl are too big. In the late game we see monsters like Juggernauts being introduced to have a chance at killing high level PCs. Combat which relies on ever more extreme swings as the game goes on is less than desirable, imo.-The branch structure. Due to semi-open-ended structure, players are encouraged to leave rune vaults unvisited until as late as possible, so runelock had to be introduced as a hack to preserve the specialness of vaults, in part because we have issues like Shoals actually being harder than a late-midgame branch (V: 1-4).

I think most of your points are generally reasonable, but I'd quibble with these two.

I don't think larger numbers in the late-game are a problem; if anything, I suspect we're too reluctant to use them, which results in overuse of torment/damnation. Your concern is about damage variance rising over time, but that seems tangential to me.

As we've discussed before, I strongly disagree that the branch structure is a 'problem'. When players find themselves outmatched in an area, the 'semi-open-ended' structure of crawl's branches allows them to try other areas; recognizing and applying this is an extension of one of crawl's core skills, "running away". You and mps dislike it for that exact reason, iirc (since you'd prefer players to have to fight it out or die), possibly it's a fundamental difference of opinion about what makes crawl fun.

One last note: if you wanted to make a roguelike without being burdened with 20-year-old legacy decisions & code, i see no reason why you'd rewrite Crawl, instead of just making a game that's purely your own.

e: beaten by floodkiller on that last one

Regarding large lategame numbers, I imagine it being pretty frustrating to die at 3/4 HP because an ancient lich max'ed on you with an LCS. This is rare, but in order to see the kind of hits that will kill a reasonable player character (like 70s) happen somewhat often through AC, you need to have a sufficiently wide damage distribution. Torment and Hellfire are different: It's an admission that the game can't kill player characters in extended without ignoring their AC/EV. Even iron giant throwing did this pretty well.

The thing I don't like with branches is not really the branches themselves, but the backtracking you have to allow, and the consequences of it. (though I think the Lair branches are too Poison-focused and don't like Tomb)

-You make things like stairdancing possible, or worse, have to design branches around it (Tomb)-Incentivizes excessive monster luring, rather than having to use items in a creative way to solve combat problems, just kite more-Prevents easily putting pressure on the player to progress, compared to having only downstairs, because you don't want to punish the player as they're coming back for later floors of the branch. I think pressure to progress that acts on the floor-to-floor scale is preferable to things like a long-term food clock, but it's hard to reconcile something like a level clock that gives bad Xom effects for taking too long with allowing backtracking. The sweet spot of "Not too short to bother players playing normally, but not so long as to encourage excessive degenerate play" ends up being annoying when you backtrack. Who likes encountering respawned goblins as you're trying to go back to Lair for Slime or whatever? Nobody likes dying hours later as a result of something they did early in the game, either, so things like a long-term food clock are also less than desirable.-Incentivizes farming XP in easier branches while introducing hacks like runelock to preserve the special character of end vaults. Why are Lair end vaults harder than Vaults:1-4? I think it's questionable that they are, except for Shoals, which is harder than V:1-4 as a branch.

If I had my way, I would probably have Dungeon/Vaults/Depths type monsters only, early game a little easier with less focus on running from unkillables, more Lair-type layouts, runes optional with contribution only to your score, no upstairs, no orbrun, level clock that triggers hell/xom-esque effects for taking too long to discourage excessive luring, and runes in portal vaults with a rank system that increases monster difficulty the more runes you grab.

archaeo wrote:How was tabstorm "distorting" anything? All of the problems he calls out are real issues that Crawl has. Nor was it exactly "throwaway," since he explained himself pretty thoroughly. Color me totally mystified by the fact that this is its own thread, especially since the OP is just a personal attack.

Better got to reply to the people in green: It's not the first time tabstorm said "rewrite Crawl". I tried to make clear that I consider this a pointless distraction (if written without thinking) or an aggressive act if he knows what he's talking about. Like my second posting said: DCSS exists because a rewriting-variant got stuck, leading to no Crawl at all.Of course there are lots of problems in Crawl, and obviously tabstorm has a good grip on them. But what do these have to do with a rewrite?(Side note: I have seen attempts to rewrite software in professional environments that had to be abandoned. There must be numbers out there, but I believe that many of you folks seriously underestimate the effort to actually do this.)

Last edited by dpeg on Tuesday, 4th October 2016, 01:54, edited 1 time in total.

tabstorm wrote:Regarding large lategame numbers, I imagine it being pretty frustrating to die at 3/4 HP because an ancient lich max'ed on you with an LCS. This is rare, but in order to see the kind of hits that will kill a reasonable player character (like 70s) happen somewhat often through AC, you need to have a sufficiently wide damage distribution. Torment and Hellfire are different: It's an admission that the game can't kill player characters in extended without ignoring their AC/EV. Even iron giant throwing did this pretty well.

The thing I don't like with branches is not really the branches themselves, but the backtracking you have to allow, and the consequences of it. (though I think the Lair branches are too Poison-focused and don't like Tomb)

-You make things like stairdancing possible, or worse, have to design branches around it (Tomb)-Incentivizes excessive monster luring, rather than having to use items in a creative way to solve combat problems, just kite more-Prevents easily putting pressure on the player to progress, compared to having only downstairs, because you don't want to punish the player as they're coming back for later floors of the branch. I think pressure to progress that acts on the floor-to-floor scale is preferable to things like a long-term food clock, but it's hard to reconcile something like a level clock that gives bad Xom effects for taking too long with allowing backtracking. The sweet spot of "Not too short to bother players playing normally, but not so long as to encourage excessive degenerate play" ends up being annoying when you backtrack. Who likes encountering respawned goblins as you're trying to go back to Lair for Slime or whatever? Nobody likes dying hours later as a result of something they did early in the game, either, so things like a long-term food clock are also less than desirable.-Incentivizes farming XP in easier branches while introducing hacks like runelock to preserve the special character of end vaults. Why are Lair end vaults harder than Vaults:1-4? I think it's questionable that they are, except for Shoals, which is harder than V:1-4 as a branch.

If I had my way, I would probably have Dungeon/Vaults/Depths type monsters only, early game a little easier with less focus on running from unkillables, more Lair-type layouts, runes optional with contribution only to your score, no upstairs, no orbrun, level clock that triggers hell/xom-esque effects for taking too long to discourage excessive luring, and runes in portal vaults with a rank system that increases monster difficulty the more runes you grab.

on damage distribution, you seem to assume that all damage has to be 1dwhatever (or even 3dwhatever). Most crawl damage does look something like that, but not all; one can certainly imagine damage that's 10dwhatever, or 5dfoo + bar... (or whatever the heck airstrike is.)

I hadn't been thinking about branches in terms of removing up-stairs entirely. Yeah, as long as you're expecting players to actually traipse back and forth between levels, you aren't gonna have a real clock. I think you could probably make a clock work with branches by adding some kind of portal system or abstracted quick-travel system ("spend 20 turns to travel to another known branch", say), but of course your complaints about up-stairs are broader than that.

I feel like your perspective on runelock is skewed by being used to pre-runelock crawl. It doesn't seem like a 'hack' to me.

Not sure what you mean about the existence of branches (or upstairs, even) encouraging excessive luring - could you explain that part?

You're incentivized to lure enemies back to the stairs when you start the level so that you can fight them safely and bail when unkillables come into view. This is mostly an issue of the early game.

Re damage dice: This comes back to one of the things I talked about where you don't know how much damage enemies can do. If an enemy did 10d7 vs. 2d35, the player should know this, but the finer points of Crawl's numerics are obscured, which is probably good because the formulas are so complicated. This is why I like having smaller numbers... It's easier to have a transparent, sensible combat system where the player knows what's going on and you can just say "This enemy does 5d7" or whatever. Another thing I think would be an improvement is to give monsters fixed ac/ev and not have them have varying ac/ev based on what gear they're wearing, varying damage based on what weapon they're using, and so on.

Shard1697 wrote:HardboiledGargoyle was asking an actual question and maybe instead of being a rude, condescending dick and telling him to "shut up" you could have just answered him

Brent Ross put an enormous amount of effort into his rewrite; insulting his ability as a developer, especially after it'd been confirmed that he did a good job on the build side of things (at least), is really rather rude.

HardboiledGargoyle wrote:Perhaps that failure speaks more to his competence as a game designer, rather than the folly of attempting such rewrites.

At best this is insensitive towards the amount of work Ross put into his build and how much Crawl has since benefited from his work. I played Crawl for a very long time as a player only and I think it's easy, as a player, to gloss over just how massive of an undertaking it is to be maintaining and updating a codebase this size with the level of quality we've all come to expect. So I possibly have a little more sympathy towards HG than the other devs. That said, the number of actual code changes that are made to the game are accompanied with many times more thinking and reflection on what wants to be changed: this is an enormous time and brainpower investment.

We do try to keep Crawl up-to-date and cleanly written as much as we can, limited by our available time, energy, and ability.

I think many DCSS players don't realize how good our dev situation is compared to many other rougelikes. I was looking at Angband variants the other day, and man it's just a desolate landscape of abandoned forks. The problem IMO is that many forks are one-man operations, and when that one guy tires of the thankless work, it's pretty much end of the line.

DCSS's setup is more sustainable, I think. Sure, devs come and go, just like in other projects, but unless everyone quits at once, there's continuity in place as older devs work with newer ones.

People who want to move DCSS in a different direction are free to fork of course, and indeed there are currently 2 active forks at the moment - Dracunos' gnollcrawl and Hellmonk's ambitious hellcrawl. Whether either grows into real variants is just a question of how much dev work gets put in, either by the original forkers or by succeeding ones.

A true effort to rewrite DCSS sounds like it would end up being a completely different game. Which is perfectly fine, there's room for lots more roguelikes. Good luck finding someone to do it though, as most people seem to prefer hacking DCSS' decade-old codebase than starting from scratch.

DracheReborn wrote:A true effort to rewrite DCSS sounds like it would end up being a completely different game. Which is perfectly fine, there's room for lots more roguelikes. Good luck finding someone to do it though, as most people seem to prefer hacking DCSS' decade-old codebase than starting from scratch.

On crawl damage formulas, the dominance of outlier damage outcomes is crucial to the dynamics of crawl combat. Without the narrow tails and high no/low damage rates, you get very static combat. See angband, for example.

On rewriting crawl, the game is overcomplicated, too long, filled with unnecessary and redundant systems. The random layouts aren't even very good. I suspect what tabstorm really means is a new roguelike with the spirit and themes of crawl, but designed from the ground up not to have the extra crap. It would surely be a major undertaking, but the 2-4 year numbers people are throwing around... probably not that major.

DracheReborn wrote:A true effort to rewrite DCSS sounds like it would end up being a completely different game. Which is perfectly fine, there's room for lots more roguelikes. Good luck finding someone to do it though, as most people seem to prefer hacking DCSS' decade-old codebase than starting from scratch.

It would be the same game, it's code just wouldn't be a shit show

I wonder how do you make sure the code will be better this time. This whole thread's premise is absurd, if you want to fix certain issues, you fix those issues, not do everything again (and create different issues, most likely).

Brannock wrote:Brent Ross put an enormous amount of effort into his rewrite; insulting his ability as a developer, especially after it'd been confirmed that he did a good job on the build side of things (at least), is really rather rude.

Note that it was his ability as game designer, not a developer, that was questioned. If 4.2 is widely considered unplayable, then maybe there is a point? I'm not taking a stance here, though, I don't feel informed enough.

stickyfingers: The old changelogs contain hints to what gameplay systems have been incorporated from Brent's Crawl, so he certainly knew what he was doing for gameplay, not just code.

I think what the "just rewrite it" folks miss, apart from the sheer workload, is the core problem: so you want clean combat formulas (for example, to give specific damage feedback like in Brogue). On the other hand, you want to replicate, or at least closely imitate, the current gameplay of Crawl. These two goals are very much conflicting, and I think this is where Brent got stuck. There are very many interacting systems (in codepaths and for e.g. damage distributions), and the complexity probably just exploded in his face.

Of course, they also miss that Crawl's source has been improved considerably over the years. Someone else should comment on this, but from time to time people mention how much more readable it is.

edit: Thanks for that Netscape link! Obviously, their codebase is magnitudes larger than Crawl's, but that article should be a must-read for anyone saying "rewrite".

dpeg wrote:stickyfingers: The old changelogs contain hints to what gameplay systems have been incorporated from Brent's Crawl, so he certainly knew what he was doing for gameplay, not just code.

I think what the "just rewrite it" folks miss, apart from the sheer workload, is the core problem: so you want clean combat formulas (for example, to give specific damage feedback like in Brogue). On the other hand, you want to replicate, or at least closely imitate, the current gameplay of Crawl. These two goals are very much conflicting, and I think this is where Brent got stuck. There are very many interacting systems (in codepaths and for e.g. damage distributions), and the complexity probably just exploded in his face.

Of course, they also miss that Crawl's source has been improved considerably over the years. Someone else should comment on this, but from time to time people mention how much more readable it is.

edit: Thanks for that Netscape link! Obviously, their codebase is magnitudes larger than Crawl's, but that article should be a must-read for anyone saying "rewrite".

Brogue avoids specific damage feedback though... your health bar just goes down. At least in Crawl I know I can die in 1 turn because I know how much HP I have and I can ask beem to query sequell and remind me how much damage a monster does because having this ingame would be problematic. In Brogue I can't really know this unless there have been changes in a new version. Another issue with that game is that there's no AC, as far as I can tell? It seems that armor is just the Crawl equivalent of EV, which is kind of misleading.

I don't think it's obvious that having clean combat systems necessarily conflicts with the gameplay of Crawl. It would be easier if you had smaller numbers for HP/AC/EV and stats, though. For example, do we really need more than 4 speed tiers, or monsters moving and attacking at different speeds, or more 5-6 weapons for each weapon type, most of which become floor trash 30 minutes into the game, or monsters having varying damage (and I think attack speed?) based on what weapons, armor, and jewellery they're wearing?

tabstorm wrote:It seems that armor is just the Crawl equivalent of EV, which is kind of misleading.

That's classic DnD AC, which is kind of like "a chance that attack will do nothing because you dodged it or blocked it or it didn't penetrate your armour". Very abstract, makes sense if you're rolling dice though, I guess.

dpeg wrote:I think what the "just rewrite it" folks miss, apart from the sheer workload, is the core problem: so you want clean combat formulas (for example, to give specific damage feedback like in Brogue). On the other hand, you want to replicate, or at least closely imitate, the current gameplay of Crawl. These two goals are very much conflicting, and I think this is where Brent got stuck. There are very many interacting systems (in codepaths and for e.g. damage distributions), and the complexity probably just exploded in his face.

As part of the last release cycle I contributed a fix for a fairly tiny bug to do with Qazlal's elemental protection not triggering in a lot of cases, and dpeg's point here really resonates with me. To fix it I had to understand how elemental damage actually gets applied, which turns out to be extremely complicated. This is just a tiny slice of the picture, relative to the whole codebase. The scope of what would need to be done on a rewrite is way more massive than the people here who haven't actually dealt with crawlcode realize, and "1 year" in particular is wildly unrealistic (unless perhaps you have a paid team with good management).

Now that diagram probably does indicate that something should be rewritten, and it isn't as if devs haven't talked about it before (e.g. devs who aren't even active any more were considering rewriting the staff code represented there years ago). But to seriously rewrite even this little bit of crawl, you'd have to (i) understand what everything does do, (ii) understand what everything is or was intended to do, which can differ from (i), (iii) decide if it should do that, which if it involves a team would require consensus, (iv) figure out what an actual improvement in code organization/structure would entail (many people making the rewrite suggestion seem to assume it would always be obvious), and then finally (v) actually do the rewriting. But we're not done, because (vi) is making sure it actually does what you intended (especially in terms of interactions with other systems). If you skip (i-ii) you might as well just write your own game (IMO), and (i-ii) are a huge amount of work in crawl. In a large game where there's a lot of interacting systems in place (vi) is quite overwhelming for an all-at-once rewrite.

But, you say, the devs already go through something like this process and know the codebase, can't they just rewrite the whole game from scratch? In fact that's maybe sort of what they're doing, but piecemeal over a realistic timescale for a volunteer large open-source project, not an instantaneous timescale. But even given this, while several devs helped me when I was working on this patch and knew something about how elemental damage worked, the only dev who was really an expert on it was inactive; I think the code base is large enough that there are many parts that no one is currently an expert on. I got the impression that the devs I was talking to (esp. neil) would've been happy with a rewrite of the elemental damage system, but someone would have to actually do that (it's fairly non-trivial, I estimated a month of solid free-time work for me, knowing this part of the code but not being especially good with crawlcode or c++, and that's not counting testing or getting consensus; in the end I just moved on with my life). So if you want to accelerate the rewriting process IMO your best bet is to actually make a positive contribution by rewriting pieces of crawlcode that need it. Of course this means you can't just impose your own will and need to actually communicate productively with the devs to reach consensus, which doesn't always go over well in tavern.

Also, maybe it's that I'm old, but when I hear "why don't you rewrite your open-source project from scratch", I think about GNU Hurd, which doesn't yet exist in any meaningful sense.

tabstorm wrote:Brogue avoids specific damage feedback though... your health bar just goes down. At least in Crawl I know I can die in 1 turn because I know how much HP I have and I can ask beem to query sequell and remind me how much damage a monster does because having this ingame would be problematic. In Brogue I can't really know this unless there have been changes in a new version. Another issue with that game is that there's no AC, as far as I can tell? It seems that armor is just the Crawl equivalent of EV, which is kind of misleading.

Brogue does provide this, though? When you hover over a monster, it will tell you the chance it has to hit, how much of a percentage of your current health it can damage you for in a worst case (max damage) hit, and how many worst case hits you can take from that monster at your current health before dying. Likewise, it also shows your chance to hit that monster, how much of a percentage of its current health you can damage it for in a best case (max damage) hit, and how many best case hits it can take at its current health before dying. It also tells you this information when zapping with a damage staff (although I don't think it conveys ally vs monster battle statistics or harmful potion throwing, but it's been awhile since I've played Brogue so it might now). The exact numbers are abstracted into percentages, but it is all available to the player from within the game.

dpeg wrote:I think what the "just rewrite it" folks miss, apart from the sheer workload, is the core problem: so you want clean combat formulas (for example, to give specific damage feedback like in Brogue). On the other hand, you want to replicate, or at least closely imitate, the current gameplay of Crawl. These two goals are very much conflicting, and I think this is where Brent got stuck. There are very many interacting systems (in codepaths and for e.g. damage distributions), and the complexity probably just exploded in his face.

The same mistake was done in Circus Animals fork IMHO. The dev created really nice formulas, they were easy to understand for players, with lots of symmetry everywhere, yet resulted in nightmare, even the most powerful melee characters are completely unplayable while casters are hilariously easy etc. So yes, current crawl formulas are probably fine and should not be changed