Z+Angband dev

[Pete Mack]

OK, that makes sense. The way angband 3.0 used it really didnt.

[droof]

Lua is used by game engines. Scripted story sequences, scripted levels, complex quests, new game modules, total conversions and in case of Doom 3 I think it was even used for artificial intelligence monster behaviour.

But Angband is a game, not a game engine. It's not like anyone could write a total conversion mod in Lua for Angband, instead that gets hacked into the code in C.

If Angband was really a game engine and Vanilla Angband was a Lua module for the game, then that would a different story. That would be like the T-Engine.

[Pete Mack]

Lua is overrated, IMO. Yeah it allows flexibility in spell set, but 8t turns out that the flexibility is almost never needed. When a spell can be described by a line or two in a text file, and there are a h7ndred or more spells, adding even a small amount of boilerplate multiplies fast. Text file+simple parser really is considered a software best practice. It's right there in all the textbooks.

[johnretroreload]

I'm really enjoying the discussion of the code and potential directions of a new Z+Angband project.
2.7.5 was the definitive return to the soul of zang for me which Z+angband has continued. Quests and randomisation remain key for me on this variant.
That will explain why I was having trouble with the Win and Dos build in enabling the sound+music, thanks for highlighting.
Lua in newest TOME - I haven't considered that.. Nice comment by droof about migrating and syncing for a v3.5 for easier future coding concept.
Fun and fresh while being authentic to vanilla zang is key for me.

I've looked around in Z variants. Poschengband completely replaces Zangband 2.4, just everything is better in Poschengband. It's the "static quest" Z branch.

Zangband 2.7.5 is a different beast though and Z+Angband has continued development on that version. This looks like the branch with the promise for a true random wilderness and dynamic interesting quests. So it makes sense to continue development on Z+Angband.

Zangband and Z+Angband only have sound support for Amiga and Mac Carbon. Oh Amiga, good memories there. Sound and music don't work, this needs SDL mixer code for modern sound support.

ZangbandTK is interesting in that it has all game commands and options in window menus. I haven't seen that in any other variant yet. That's very useful for feature discoverability.

[droof]

I've looked around in Z variants. Poschengband completely replaces Zangband 2.4, just everything is better in Poschengband. It's the "static quest" Z branch.

Zangband 2.7.5 is a different beast though and Z+Angband has continued development on that version. This looks like the branch with the promise for a true random wilderness and dynamic interesting quests. So it makes sense to continue development on Z+Angband.

Zangband and Z+Angband only have sound support for Amiga and Mac Carbon. Oh Amiga, good memories there. Sound and music don't work, this needs SDL mixer code for modern sound support.

ZangbandTK is interesting in that it has all game commands and options in window menus. I haven't seen that in any other variant yet. That's very useful for feature discoverability.

[t4nk]

Hi t4nk check out the progress I made on angband.live, I think it's taken a different direction since we spoke about it and I don't expect work from you but it is nice to see you came back to angband after all.

That looks pretty fancy. I see you've even forked Poschengband? Congratulations

[Gwarl]

Hi t4nk check out the progress I made on angband.live, I think it's taken a different direction since we spoke about it and I don't expect work from you but it is nice to see you came back to angband after all.

[Pete Mack]

Hmmm. One reason I like the current model is that every class of game data now has an iterator associated; that is, it forrms a normalized relation. I come from databases as much as programming, and this just seems natural to me. Take a look at the lore code to see why this can help.

[t4nk]

Besides migrating or rewriting, maybe there is another refactoring option. Zangband still offers Lua. That language hasn't declined in popularity and has a reputation for being easier and faster to work with. In theory, can parts of Zangband be continued or rewritten in Lua to make refactoring and a careful modern UI integration job less time consuming? Has anything like this been tried before in previous Angband versions?

I found C, for the most part, sufficient for UI; the biggest problem was bad support for Unicode, especially the lack of Unicode-capable printf(). Some other things are: variable size of wchar_t, mbstowcs() doesn't work on Windows, and I don't know what it actually guarantees w.r.t. normalization, etc. Anyway, UI is a fairly low level work (well, the kind of UI that is in Angband). I actually think Lua would be more useful for the core - monsters, objects, stuff like that.
I don't know Lua much, but I'm sure writing a roguelike in (mostly) Lua is more reasonable than doing it in pure C Come to think of it, the newest TOME is just like that?

[t4nk]

I'd be more worried about parsing datafiles

E.g., like this:

https://github.com/martin-tornqvist/ia/blob/develop/src/item_data.cpp

see init_data_list()...
And it would be even better/cleaner in C99 (because C++ is so bad )

and writing and reading savefiles.

It's a struct full of bytes, don't think there are any problems with those. Just dump its sizeof.
Of course it would be better if C had some compile time reflection (other than sizeof and friends). Well, there are many reasons to not use C

[Nick]

IYou know, all these flags could just be bools... yeah, that would waste some memory... the horror

struct object_flags {
    ...
    bool blessed;
    bool burns_out;
    bool takes_fuel;
    ...
};

if (obj->flags.takes_fuel) {
    ...
}

People use stuff like CPython, where everything is a pointer to some compicated struct just to save themselves some (programmer's) time... It's ok to waste several hundred kbs of memory in a roguelike videogame just for better syntax
So I disapprove of bitflags, too

I'd be more worried about parsing datafiles and writing and reading savefiles.

[droof]

All this still has to be fun. If I didn't have fun working on my Friendband branch, it would've gone nowhere. Now it's the way I personally prefer to play Unangband when I play that, even if I mangled Unangband with my hacks and no one else likes it. It's still useful to me and I'm having fun with it. It should all be about having fun.

If having fun is measured in gameplay hours, then I've spend most time on Zangband variants. These variants have features that make them more enjoyable to me than angband and angband variants. It's not just the wilderness. I don't want to lose whatever makes Z enjoyable to me.

I want to avoid the netscape problem. Netscape 4.5 was popular, but the code was outdated and considered too difficult by developers. So they rewrote netscape 6 from scratch. As a result, many dedicated netscape 4.5 users were missing features in netscape 6 that made 4.5 popular with them in the first place. In hindsight, netscape should never have rebuilt on a new codebase and lose much of made netscape popular in the process.

Besides migrating or rewriting, maybe there is another refactoring option. Zangband still offers Lua. That language hasn't declined in popularity and has a reputation for being easier and faster to work with. In theory, can parts of Zangband be continued or rewritten in Lua to make refactoring and a careful modern UI integration job less time consuming? Has anything like this been tried before in previous Angband versions?

For migrating, Z 2.7.5 has multiple code files that have a word difference less than 10% with V 3.0.8, the oldest V I could find on github. Looking at changelogs, Z might have kept some files and code in sync with V 2.9.3. If some files can be synced and auto-merged upward in small version steps while fixing any problems in other code files, maybe there is a road to V 3.5.

[t4nk]

@t4nk-
It is arguguably easier to read in small chunks, sure. But the new stuff you only have to read once, where previously it was repeated over and over--in the case of spellcasting, roughly a hundred times.

I'm not saying the old code was good. Especially what I think was Harrisons code; different parts of the program communicating via obscure globals (inkey_scan?), meaningless names for things (TERM_XTRA_SHAPE?), useless one-liner comments, gigantic functions... But, I'd rather deal with all that than with the huge amount of indirection in V.
Now, this is clearly a matter of taste/opinion, but I think it's reasonable to provide an opinion that is different from yours and Derakons... just for balance, you know

And there is no more object flag1 flag2 and flag3, which was just impossible to read.

What? It was stupid, but definitely possible to read. Also LOL. You know, all these flags could just be bools... yeah, that would waste some memory... the horror

struct object_flags {
    ...
    bool blessed;
    bool burns_out;
    bool takes_fuel;
    ...
};

if (obj->flags.takes_fuel) {
    ...
}

People use stuff like CPython, where everything is a pointer to some compicated struct just to save themselves some (programmer's) time... It's ok to waste several hundred kbs of memory in a roguelike videogame just for better syntax
So I disapprove of bitflags, too

edit: I just recalled that C even has bitfields... no one uses them, though, and I don't quite remember how they work

Moving the data to .txt files and .h files makes the code a lot more maintainable.

How so? .txt files are just like .c files, except they require the parser (while c compiler already has its own parser). And define-include trick breaks ctags and grep (and yes, I used that trick too, and I regret it now).

[Pete Mack]

@t4nk-
It is arguguably easier to read in small chunks, sure. But the new stuff you only have to read once, where previously it was repeated over and over--in the case of spellcasting, roughly a hundred times. And there is no more object flag1 flag2 and flag3, which was just impossible to read.
Moving the data to .txt files and .h files makes the code a lot more maintainable.

[t4nk]

On the other hand, I found that old code (specifically, Sangband and Sil) is just easier to read. There is a lot of indirection in V now, mostly due to so much stuff being in the text files. I don't see value in most of them. Yes, if that stuff is in C, you need to recompile after editing and that's a problem because? Also, the text files break ctags and grep (constants.txt become z_info, etc.)
Also, why is V's main loop (run_main_loop()) so convoluted? (Actually, I think I know why, but I do recommend all of you to (re)read it and try to aswer this question...)
So, if I were contemplating an Angband's variant, I probably wouldn't start with V, even though I have pretty good understanding of how it works (including the parser, main loop, dungeon generation, z_dice, and of course the ui and the command queue...) But I also think that using C for a videogame in the 21st century is a bad idea (unless your goal is to learn C), so.