Hi all,
First off, thank you to the Angband development team for putting together such an amazing open-source project.

I've been working on developing my own open-source game/simulator in C, relatively unrelated to Angband but storing a great deal of game information in a similar fashion (the game is essentially a fantasy city simulator, so instead of monsters or weapons it has buildings and citizens).
While I may well end up using a language like JSON or YAML to store this data, after browsing through the Angband GitHub repo I found that the parser and data file format it uses would actually work very nicely for the kind of storage I would want, ensuring extensibility, readability and compactness.

My question is, has anyone made an effort to let the Angband parser be used separately from Angband as its own parsing library? I've spent a fair bit of headscratching trying to figure out if I could disentangle it and port it over to another program, but I expect starting on the task would end up wasting a lot of time I'd prefer to spend working on my project's other niggly details.

I strongly encourage you to go with a standard, like JSON or XML or YAML, rather than the home-brew format that Angband uses. Standards will be easier to integrate into your system, less buggy, familiar to other people, easier to write, more portable (any system that can parse the format can read your files), etc. There is zero reason to re-use Angband's format unless you're making an Angband variant. Even then, one of the first things I did when I started working seriously on Pyrel was convert the data format into JSON.

To answer your question, no, I am not aware of anyone who tried to extract the Angband parser out of Angband.

Yeah, I think you should use JSON or some other more standard format, but if you want to use the angband parser it would be pretty straightforward. It is not really that entangled with the rest of the code at all.

Also, maybe don't write a new game in C... it's a fine language and all, but you will end up wasting half your time writing boilerplate that many other languages will give you for free.

Thanks for the comments, guys. I've decided to go ahead and use JSON to store everything rather than contort myself. Derakon, you make a good point about familiarity and portability.

I'll admit, C seems like a rather insane choice; I mostly wanted to challenge myself and review my C experience from my undergrad CS courses. I may end up switching to a more OOP-friendly language if I decide it's not worth reimplementing things as takkaria referenced.

If this is long term project, PLEASE don't do this in C or C++. If it is and it really does require "soft real-time" then do it in Rust. Otherwise, choose the thing you know... unless it's a learning experience, in which case choose a high-level GC'd language. There are multiple choices in that space depending on how comfortable you are with types... you can go LISPish with Racket or 'intermediate' with O'Caml and go type-nuts with Haskell/GHCJS.

Please ask if you're not sure about any of those options. I have a lot of hard-won experience. (As I'm sure many others on this forum have.)

As a matter of fact, I went and looked at C++ right after the first few responses, and then looked around some more when I grasped how huge the language is. I've mostly programmed in Python, Java and C in the past, with some experimentation in Racket, JS and C#. I don't really want to deal with Java's verbosity much, and I felt like using something other than Python this time around.
In the interest of exploration I went and started reading through the Rust docs (loving the language so far -- all my favourite features of C, Racket and Python are present!) I'm glad to hear you recommend it, AnonymousHero!

The project likely doesn't require Rust's safety or concurrency features (although they could come in handy if I wanted to get very fancy with it). Nonetheless, I'd certainly like it to be long-term and running with a low performance overhead (ideally a compiled language, though it makes less of a difference nowadays), and I quite like Rust's style (and package manager!) If I feel like I'd rather stick to something a bit more familiar, I'll probably use C# or Racket.