Idea: YAMLband

[Derakon]

For what it's worth, Pyrel still has the monster indices in the data files, but it doesn't actually use them for anything, and monsters are looked up by name. It's pretty rare that you need a random monster, any monster, unique or not, from any depth -- usually you want to constrain your search somehow, which means you have to scan through the monster list to find applicable entries.

I really should start working on Pyrel again...

EDIT: the index is still helpful in Angband as a convenient way to index into the list of monster data structures, but this is more a side-effect of Angband being written in a language that doesn't have convenient hashmaps or other object-oriented features. Being able to index into a list is helpful in C; it's less vital in a higher-level language like Python which has more options for how to store information.

[Therem Harth]

Yay data structures! I'd forgotten about that side of things.

Any reason not to implement a hashmap in Angband though? It's not like we'd need something complicated/high performance.

Edit:

The real advantage of the current format is its compactness. It's nice to be able to fit multiple monster entries on the screen at once.

This is a good point, especially when comparing different monster entries. Personally though I think it would be better for that purpose to give the fields memorable names.

[AnonymousHero]

I think we're getting close to that, actually. The only reason there is an index still is because we need something to save in the savefile, and saving a string for each monster is wasteful. (Or at least, that's what my 1990s sense of storage capacity is telling me...)

Heh, though I'll bet just applying a gzip/deflate pass would yield much greater gains .

[Nick]

The thing about monster (and object and terrain) indices is that they don't hurt; they possibly make things slightly easier for parsing; and they provide a slight check against copy/paste errors in the edit files.

I did consider removing them, and decided there just wasn't any point.

[Derakon]

Yay data structures! I'd forgotten about that side of things.

Any reason not to implement a hashmap in Angband though? It's not like we'd need something complicated/high performance.

As a general rule, if you're thinking of implementing the kind of data structure you learn about in introductory CS courses, then someone else has already implemented and tested and optimized it for you, somewhere.

But also, what are you trying to solve? If you have a specific monster's "key" and want to look up information on that monster, it doesn't really matter if the key is an index into a list, or a string into a hashmap -- you'll get the same result in roughly the same amount of time (big-O sense) either way.

[Carnivean]

The biggest problem with the edit files is not how to store the data, but how to edit it. Some kind of gui interface to edit the edit files would make this argument redundant, except for programming efficiency.

[Derakon]

Well, there are also issues like the edit files not really lending themselves to representing large numbers of non-binary attributes.

[Therem Harth]

The biggest problem with the edit files is not how to store the data, but how to edit it. Some kind of gui interface to edit the edit files would make this argument redundant, except for programming efficiency.

Disagree strongly. GUIs for stuff like this are painful.

[Carnivean]

Well, there are also issues like the edit files not really lending themselves to representing large numbers of non-binary attributes.

I guess, but if you disregard hand editing of the files, then you can choose any format for speed and completeness.

Disagree strongly. GUIs for stuff like this are painful.

Given that GUIs have successfully formed the basis for game editors for years now, I'm confident that a GUI could easily handle editing Angband files. You could change almost any variable in Civ3, or create entire galaxies in Freelancer using a GUI. Reading lists from edit files and allowing multiple selection should be fairly straightforward.

That said, my original point is that it's the editor that makes the difference, not the data storage format.