Z+Angband dev

[wobbly]

Thats a shame, Just two participants? How can I submit a competition idea based on a development of Z+angband?

I played even if I didn't post a character dump as did others. It's not a bad game but the interface is painful. If you fixed that it'd help a lot. Also the wilderness was a pain to navigate. It's a bunch of inconvenience to play when there's a more modern variant forked off it.

[droof]

I'm probably weird in that I don't prefer ascii or multiple terminals. My favorite interface is from nethack, single window and graphical tiles so I can see what I'm up against, but also tiles that are eligible even when they are as small as an ascii character.

Procgen poschengband-style quests is what I'll be aiming for. I'll take some time to hack around and see what comes of it. And I'll also check out the different town houses that Kangband and Poschengband offer, I like those a lot too.

I played even if I didn't post a character dump as did others. It's not a bad game but the interface is painful. If you fixed that it'd help a lot. Also the wilderness was a pain to navigate. It's a bunch of inconvenience to play when there's a more modern variant forked off it.

I would like to know more details, can you elaborate? What needs to happen to improve the Zangband or Z+Angband interface?

[wobbly]

It's a while ago so I'll have to try it again to give a good answer. I think it lacked a working squelch? Stuff like that.

[Derakon]

Basically, play Vanilla, notice the interface improvements, and compare that to playing ZAngband. There have been a lot of changes since ZAngband first branched off ~15 years ago.

[droof]

The Zangband dev team were working on an improved random quest system to replace both random "kill monster" quests and static quests. But they never finished the system. So one task here is to finish that system.

To make Z modern, it's either updating Z with features from V, or porting features like the wilderness and quest system from Z to V. But Z had 11 years of development of its own. Is Z supposed to be very different from V or is porting from Z to the latest V possible without losing many important Z features?

Also, the older V version had tile support for X11, but the latest V only supports ascii for X11. Why were tiles dropped for X11?

[Nick]

Also, the older V version had tile support for X11, but the latest V only supports ascii for X11. Why were tiles dropped for X11?

I believe that happened in the process of getting V GPL-compliant, because the author of the x11 tile code couldn't be tracked down.

[Derakon]

Not having looked extensively at the Z codebase in awhile, I'm still inclined to believe that you'll have better luck "re-implementing" Zangband in Vanilla than the reverse, for the following reasons:

* Vanilla has had more consistent development effort over the years. Most Zangband development halted well over 11 years ago.
* Vanilla's maintainers have made a substantial effort to make the codebase clean and easier to make into a variant, which ought to reduce variant re-implementation costs.
* Conversely, copying Vanilla features over to Zangband's current codebase would be a substantial effort, as some features would require major structural reworks.
* Perhaps most important for the long haul, re-branching Zangband off of modern Vanilla will make it easier to incorporate new features as they get added to Vanilla.

You're looking at a substantial effort either way, though. Re-implementing a variant, especially one with as much history as Zangband, is no joke.

[Pete Mack]

One might aim to rebase with V 3.5, not V4. V4 had massive reorg. 3.5 has most of the code cleanup; the reorg is largely in name changes. But yes. Starting from V would probably be easier, since you'd just be adding or modifying procedures, not refactoring the codebase. That was a few hundred man hours.

[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.

[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]

@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).

[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.

[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.

[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

[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?