Angband code for dummies?

[Timo Pietilä]

I used to be able to interpreter vanilla angband code and what does what, but currently I find it more a uncommented spaghetti code that is impossible to follow. Is there any Angband code for dummies around? Some sort of flowchart that tells which function is doing what? Which files have which purpose? Anything?

[konijn_]

Originally Posted by Timo Pietilä

I used to be able to interpreter vanilla angband code and what does what, but currently I find it more a uncommented spaghetti code that is impossible to follow. Is there any Angband code for dummies around? Some sort of flowchart that tells which function is doing what? Which files have which purpose? Anything?

Ew, can you point us to some places that you found not documented enough to or too spaghetti-like ?

T.

[Timo Pietilä]

Originally Posted by konijn_

Ew, can you point us to some places that you found not documented enough to or too spaghetti-like ?

T.

Everywhere. File relations, function relations etc. For example I need to look inside three different files to figure out simple damage calculation for manastorm: what exactly does it do, and I'm not sure that is even enough. Nobody can figure out that without some help or memorizing out every single file what they contain.

[Derakon]

Hm, I'm generally able to find what I need, by searching for a string I know occurs in-game, and then working back from there. For example, if I want to look up shards damage, I would search for "You are hit by something sharp!" (the message you get when hit by shards while blind), which would get me to the code that processes shards hits, and I can search for what calls that function, and find one for breathing which refers to BR_SHAR_MAX, which I can search for to find that the damage cap for shards is 500.

Ultimately it's mostly a matter of being good at using search utilities. I will freely admit that Angband would be easier for me to read if it had a more object-oriented design, mostly because that's the kind of design I'm used to dealing with. But we'd need a full-on recoding effort to make that happen. I'd recommend just learning how to navigate unfamiliar code that isn't laid out the way you expect. If you're expecting to program as part of your career, it's a skill that will hold you in good stead.

[Timo Pietilä]

Originally Posted by Derakon

I'd recommend just learning how to navigate unfamiliar code that isn't laid out the way you expect. If you're expecting to program as part of your career, it's a skill that will hold you in good stead.

A flowchart of somekind would help as well as documentation what is the purpose of each file.

I already have IT career (have been over a decade now), but all I need is some scripting skills which I already have.

[Magnate]

Originally Posted by Timo Pietilä

A flowchart of somekind would help as well as documentation what is the purpose of each file.

I already have IT career (have been over a decade now), but all I need is some scripting skills which I already have.

It's not that difficult. Start with main.c, find the function called "main". See that it does init_stuff, makes paths, processes command line arguments, sorts out gfx and sound, then calls play_game. Now, at this point it's not clear which file play_game is in - this is a fair cop. I use a grep alias which searches recursively through src/, so "grip play_game *" tells me it's in dungeon.c (if you're a programmer then your favourite IDE will do this much more easily than using grep).

So you open up dungeon.c and find play_game, and you notice that everything else follows from there. In general, the z-* files are the really low level things - messing with numbers, strings and files. The subdirs player/, object/ and monster/ are pretty self-explanatory. I guess the tricky stuff is in the cmdX.c files, which take a bit of getting used to.

[Derakon]

Originally Posted by Magnate

(if you're a programmer then your favourite IDE will do this much more easily than using grep).

My favorite IDE is grep. Ź.Ź

[Timo Pietilä]

Originally Posted by Magnate

It's not that difficult. Start with main.c ... it's not clear which file play_game is in - this is a fair cop. I use a grep alias ... open up dungeon.c and find play_game, and you notice that everything else follows from there

In other words in order to find something you need to memorize entire code or if not that do multiple searches for every single function in order to figure out what they do.

A spaghetti code. A very hard to figure out spaghetti code.

Except maybe if you are a professional coder.

[Ycombinator]

IMO Angband is in pretty much good shape for a 20-year old C project maintained by a team of volunteers.
I think the biggest source of complexity isn't the hairy call graph (grep and ctags really rock at finding what is where), but lots of global state and inherent algorithmic complexity of some parts of the code.

[Pete Mack]

Timo, I think you are wrong on this.
It used to be, the damage calculation was mixed up in the code, and if you changed how (say) darkness worked, you would have to change code in two or three places.
Now it's all in a single .h file.
It could be better (and is, in NPP and Un). But it's much better than it was.

My preference would be to have spell and breath damage in a single .txt (or .xml) file.

The recent complaint about poison damage is an exception to the rule: the .H file was wrong. The complaint about that was well taken.

But the code is certainly less spaghetti-like than it was in 3.0.6