Customization of gamedata files

[tangar]

Well, define "code" and "data". Is stuff like dice "data"? It's an expression, with operands and operators, variables even... If dice is ok, why not conditionals? (as proposed) Why not loops? Then you'll end up with a full blown programming language. And if that's the intention you'd better using some ready made one. Like Lua... or, indeed, C.

lol this talk remind to me debates about old webdesign subject. In old times a lot of people get used to create website with simple HTML. Such websites could have hundreds of unrelated .html documents. So if you would need change one tiny thingy in your website design - you had to apply changes to all this hundreds files.

After a while new CSS technology appeared, which gave possibility to put all design to separate sheet file, so to changes something @ website, you had to change it only at one place, not in hundreds pages.

BUT. Loads of people was against CSS at the beggining. They get used to HTML, they didn't want to learn new technology (CSS is kinda 'language'). And they argued at forums and tried to prove that websites should be created only with HTML and do not need CSS (lets use 'frames' they said lol). Than this story repeated when CMS with databases appeared. A lot of 'old' folk didn't want to move forward in technological way and liked how it was in old times.

This is the same story. Angband moved forward a lot and put it's config out of the code, so now it's easy and comfortable to work with it. But as always, there are some folk who do not like 'new ways' and want to put all stuff back But time would pass and as in old times, they would understand and accept it

[t4nk]

That is very much not in the usual design patterns model. For dice, it would be an interpreted mini-language. Same for the various case statements for melee types (CRUSH, HURT, SHATTER, etc.) By and large, separation of code and data is very much a usual design goal.

Well, define "code" and "data". Is stuff like dice "data"? It's an expression, with operands and operators, variables even... If dice is ok, why not conditionals? (as proposed) Why not loops? Then you'll end up with a full blown programming language. And if that's the intention you'd better using some ready made one. Like Lua... or, indeed, C.
Anyway, you can separate code and data in C just fine. Angband's edit files just move parsing from C compiler's parser to the ones in parser.c or z-dice.c. And as far as I can tell, the only advantage is avoiding recompilation. It's indeed some advantage (justifying the existence of parser.c), but not a huge one for an open source game like Angband (so I don't think z-dice.c should exist).

[Pete Mack]

That is very much not in the usual design patterns model. For dice, it would be an interpreted mini-language. Same for the various case statements for melee types (CRUSH, HURT, SHATTER, etc.) By and large, separation of code and data is very much a usual design goal.

Well, if I were modding Angband, I'd move quite a lot of that back to C - that is, a .c file, to be parsed and compiled by the C compiler... Especially stuff like dices.

[takkaria]

Really to do localisation well you want something like Project Fluent. GNU Gettext is one way people do things but it's awful, and rolling a custom one will be even worse because it won't even coverthe edge cases that gettext does... https://projectfluent.org/

Annoying there's no C version, but there is a Rust version that could maybe have a C shim put on top of it.

[t4nk]

I am not clear on how you want configuration to be stored as an alternative to text files?

Well, if I were modding Angband, I'd move quite a lot of that back to C - that is, a .c file, to be parsed and compiled by the C compiler... Especially stuff like dices.

[Pete Mack]

I am not clear on how you want configuration to be stored as an alternative to text files? Or is it just the format you don't like?

Angband moved a lot of stuff into text files, which I don't agree with (so I also don't agree with your proposal to move even more stuff into them). Ironically, the things that should logically be in the text files - the, well, texts - are still hardcoded in the binary and no one cares. If you're ok with stuff like in your link (which is no better than the English version, just like Chengband's Japanese version is also not any better), it shouldn't be difficult to understand why someone would be ok with programming stuff remaining in C.

[Nick]

One of my (less immediate) aims is to get all the game messages into a data file or files. Monster messages are almost there already (see list-mon-message.h), all that needs to be done is for the actual messages to be pulled out into a data file - there will still need to be a linking file to match the messages with the code for them. It would be a bit of work, but feasible.

[tangar]

No problemo

Considering translation: it could be fun to separate texts from the source, eg to be able to implement proper translation. But it's not the topic of this particular discussion. Translation of the game and problems which connected with this process - it's very different subject and has nothing to do with 'game engine' - gamedata customization files; their .txt format doesn't meat that they contain texts; it's just config files. So if you are interested in Angband translation and linguistic aspecs - you better to create separate topic about it and propose your ideas to the community, than get annoyed there

[t4nk]

Meh, I started to write a reply, but decided against it... tbh, tangar, you just annoy me, which is not your fault, so I should probably avoid discussions with you. Sorry about that... I'll just elaborate on the translations stuff:
Angband moved a lot of stuff into text files, which I don't agree with (so I also don't agree with your proposal to move even more stuff into them). Ironically, the things that should logically be in the text files - the, well, texts - are still hardcoded in the binary and no one cares. If you're ok with stuff like in your link (which is no better than the English version, just like Chengband's Japanese version is also not any better), it shouldn't be difficult to understand why someone would be ok with programming stuff remaining in C.

[tangar]

"Almost everything"? If you're a racist, maybe Why should it be limited to player's race? What about class, stats, equipment, state (blind, hungry, wounded...), level type (classic, caverns), level depth... and all other things. Being limited to race is more like "almost nothing".

Please read previous messages. We are speaking about checks to gamedata files. Checks, Carl. Simple 'if' statements.

So.. "Limited to player's race"? Erm. What ar y speaking about, sir? Maybe you read the forum with mobile device and missed something? I've listed several basic files:

- object.txt
- monster.txt
- class.txt
- p_race.txt
- trap.txt

Stuff which you are listed ("class, stats, equipment, state") could be customized within this files with checks with a lot of success. "level type (classic, caverns)" and "level depth" modification do not really require checks in gamedata, it's too 'deep' stuff which should be modded in code.

So I've listed this files as minimal basis which conclude the most crucial points of gameplay where 'if' statements would make the most important features for game design.

This is already possible. If you want to do some programming, you'd better learn some programming language (such as C).

It's obvious that it's possible. Everything is possible. It's possible to write Angband in assembler. Please note that this topic called "Customization of gamedata files" and it's about enhancing staff in \lib\gamedata folder; enhancing Angband 'game engine'.

Speaking of "accessible", have you ever tried to translate Angband to, say, Russian? Doesn't it bother you that a lot of text is so thoroughly hardcoded into the game? (even grammar is hardcoded - plurals, articles)... Reminds me of Poschengband's "#ifdef JP"...

How come this question related to the subject which we discuss there? But actually there is Angband in Russian: http://www.gamer.ru/everything/angba...rsiya-rogalika So what?

As you see, Angband is not even supposed to be "accesible to _everyone_".

Such counterproductive 'elitism' approach wouldn't help to move Angband and roguelike genre forward. Ability to code and ability to create game design - it's different areas of creativity/technology. In early time all developers had to do everything by themself; but now there are instruments which could bring more people to the development process. And it could be not only brainstorm on Nick's ideas on forum (with all respect, I enjoy this discussions!), but actually giving community powerful tool for game design - a real 'game engine'.

And it's almost there, I'll say current customization looks like an 'alpha' version atm. It's provide a lot of interesting possibilities, eg even simple 'RANDOM' statement, which mentioned Takkaria, could bring loads of fun and experimentation to the gameplay and make it much more deep.

p.s.
And considering myself, as you've noted: "If you want to do some programming, you'd better learn some programming language (such as C)" - I'm learning C atm (it's not too hard as I had some experience in PHP and it seems all languages have quite similar principles). But it doesn't make this concept less valuable for me. Customization is future of Angband. This is next wave of 'open-source' approach - gives community direct access to the development process.

[t4nk]

That reminds me of process_pref_file_expr()... Horrible thing that no one wants to touch At some point I actually considered improving it - at least, splitting into lexer and parser, and maybe making more generally useful - but then decided against it

If it would be simple - it would be alright. Checks which I proposed are pretty simple - not need to know anything about coding, scripting, lua etc; they are ideal for game designers; with such checks they could achieve almost everything.

"Almost everything"? If you're a racist, maybe Why should it be limited to player's race? What about class, stats, equipment, state (blind, hungry, wounded...), level type (classic, caverns), level depth... and all other things. Being limited to race is more like "almost nothing".

It would enhance Angband customization enormously, would make really advancing (in possibilities, not in complexity) game design accessible for _everyone_, not only coders.

This is already possible. If you want to do some programming, you'd better learn some programming language (such as C).
Speaking of "accessible", have you ever tried to translate Angband to, say, Russian? Doesn't it bother you that a lot of text is so thoroughly hardcoded into the game? (even grammar is hardcoded - plurals, articles)... Reminds me of Poschengband's "#ifdef JP"...
As you see, Angband is not even supposed to be "accesible to _everyone_".

[tangar]

At some point, if you start adding checks to gamedata files, you end up with a (hard to understand and nonstandard) scripting language... at which point you might as well just add one. Angband tried this around version 3 and it was taken out in 3.0.7 because it was badly implemented and no-one liked it. I suspect there is limited appetite to re-incorporate one.

If it would be simple - it would be alright. Checks which I proposed are pretty simple - not need to know anything about coding, scripting, lua etc; they are ideal for game designers; with such checks they could achieve almost everything.

Yeah, I've already been down that road a bit with object_power.txt, which I suspect was overreach.

object_power.txt.. Before you noted it, I didn't check this file; now after a first glance - I didn't get what is it, until I've checked it's decription in object.txt:

# 'power' is used in calculating the power of the object for pricing and generating random artifacts. It reflects the power of the effect of the object; other properties are taken into account separately in power calculation.

Ok, now I understand how it works

Why I wrote my experience about this file? To show that it is _advanced_ stuff which is nice to have, but it's not obligatory. It's more close to coding stuff, than to game design; pretty deep thing. I suppose if it would be in the code it would be less comfortable to change this; so it's great to have! But a moderate game designer wouldn't use such type of customization for a long time.

I'm speaking about simple, but powerful stuff, which could give 'common' non-coding people ways to customize the game.

I think customization with checks and stuff could be limited to this files:
- object.txt
- monster.txt
- class.txt
- p_race.txt
- trap.txt

It would be more than enough to make a loads of innovative stuff which would provide players and game designers possilities to bring more interesting ideas and variants. It would enhance Angband customization enormously, would make really advancing (in possibilities, not in complexity) game design accessible for _everyone_, not only coders.

[Nick]

At some point, if you start adding checks to gamedata files, you end up with a (hard to understand and nonstandard) scripting language... at which point you might as well just add one. Angband tried this around version 3 and it was taken out in 3.0.7 because it was badly implemented and no-one liked it. I suspect there is limited appetite to re-incorporate one.

Yeah, I've already been down that road a bit with object_power.txt, which I suspect was overreach.

[takkaria]

At some point, if you start adding checks to gamedata files, you end up with a (hard to understand and nonstandard) scripting language... at which point you might as well just add one. Angband tried this around version 3 and it was taken out in 3.0.7 because it was badly implemented and no-one liked it. I suspect there is limited appetite to re-incorporate one.

[tangar]

/rfe
add customization in monster.txt - death message for monster

so when you 'kill' certain monster, you would see different messages about their defeat:

not only this:
<mob> dies!

But also:
Radagast the Brown defeated and teleported out of dungeon.
Bullroarer the Hobbit begs for mercy and you let him live.
Farmer Maggot is finally persuaded to return back to his country.

It would give possibility to deal with 'good' monsters and do not feel sorrow that you killed them (also there won't be need to remove this mobs from the game with upcomming 'tolkienization' process).

So actually it's like to add to monster.txt 'msg:' from object.txt