Z+Angband dev

[droof]

Maybe so, but it's the language Angband is written in. As Derakon indicates, any project that starts off as a complete redo of many thousands of lines of code is so ambitious as to be almost certain to fall short.

A much easier route is to start by making small changes, getting more ambitious as you better understand the language and the codebase. If starting from current V, my ongoing efforts to move stuff from C code out to the text datafiles should help with that.

Note that I'm not suggesting no change for the sake of no change. It's just that I've been doing Angband coding for 12 years or so now - starting from pretty minimal knowledge of C. Feel free to ignore me though - learning from one's own mistakes is usually more effective

I don't suggest a rewrite. Refactoring in small steps is the right way to go.

And I agree that C can be learned. Troubles with C for me are mostly pointers, pointer to data type conversions and 32-bit / 64-bit compatible code. In other languages I never had to think about these situations.

It is difficult and I have to figure out a lot of stuff myself. This work requires dedicated developers and plenty of developers who would code games won't endure that much. I know plenty of developers who are not this ambitious.

I don't think Python would make it a whole lot easier, except for the new object code, which was horribly plagued by stray pointer issues. A lot of complexity in Angband is language-independent.

That's something you know best and I can only guess at. Most of the complexity is from Angband itself, but how much complexity is from pointers and limited data types?

[droof]

So in summary, T-Engine is a Lua API for rogue-like modules.

Angband is moving to rogue-like modules by text file configuration. Configuration over scripting.

[takkaria]

And I agree that C can be learned. Troubles with C for me are mostly pointers, pointer to data type conversions and 32-bit / 64-bit compatible code. In other languages I never had to think about these situations.

It's true, when you are dealing with the nuts and bolts, it is harder. It makes you a much better coder though!

That's something you know best and I can only guess at. Most of the complexity is from Angband itself, but how much complexity is from pointers and limited data types?

There's some (a lot of) boilerplate because you're in C but I wouldn't call that complexity. String handling is a pain but it works fine. I'd say most complexity in Angband is down to the sheer weight of previous decisions in a game that's had stuff added to it for ~30 years in a haphazard way and was originally translated from a different programming language. (Moria started off life in VMS Pascal.)

Obviously if you were writing a new game, you wouldn't start from here: you'd make different design decisions, you'd have less 'flavour' to retain, and yes, you'd choose a different language. I'd probably write it in Rust if I was going to start from scratch now.

[droof]

Okay then, maybe this will make coding in C a little easier. Forget embedded languages and scripting languages. How about Cello from libcello.org?

It's native C. Usage is drop-in and optional. No embedding or rewriting anything. No additional language. It enables higher level programming in C with dynamic types, eliminates direct usage of pointers, functions accept and return dynamic types and it offers easy object list manipulation. In other words, it allows me to treat C like Python without Python, or like javascript with underscorejs.

Cello is non-standard and would have to be compiled alongside the code. Unless it's included in the codebase and make file, compiling would be more difficult because of this library.

[Pete Mack]

Yes. Configuration wherever possible.
There are two places where C really gets in the way: the Object code as I mentioned before, and the event listening code, which is really quite ugly.

So in summary, T-Engine is a Lua API for rogue-like modules.

Angband is moving to rogue-like modules by text file configuration. Configuration over scripting.

[takkaria]

Okay then, maybe this will make coding in C a little easier. Forget embedded languages and scripting languages. How about Cello from libcello.org?

It's native C. Usage is drop-in and optional. No embedding or rewriting anything. No additional language. It enables higher level programming in C with dynamic types, eliminates direct usage of pointers, functions accept and return dynamic types and it offers easy object list manipulation. In other words, it allows me to treat C like Python without Python, or like javascript with underscorejs.

Cello is non-standard and would have to be compiled alongside the code. Unless it's included in the codebase and make file, compiling would be more difficult because of this library.

What an interesting library! I have wondered about if you could do something like this with C so it's fun to find out someone has. Why people think a weak type system is a feature is beyond me though, it introduces a whole class of errors into your code that you can only detect at runtime.

I'm not sure what the benefits of Cello are over C++ though, and it has many disadvantages (no-one else uses it, it's ugly, only compatible with 2 compilers). You can do a lot of this stuff in C++ with much more readable syntax.

[Pete Mack]

dynamic calls are OK in certain limited cases, especially if they allow call-by-name (which is currently done in a crummy way in CPP x-list.h files. It's vastly better than case statements (or lua) but it is not optimal.

[droof]

I think the problem with C++ is that the language is huge. Different teams use different subsets of the language, which makes sharing or transferring code between teams more difficult.

I have most problems in C with int-to-pointer-to-int situations. I get segfaults for wrong type conversions in multiple places in code. Then I have to deal with multiple data types for integers and strings, that's a headache. What's wrong with just using 1 int data type and 1 string data type that'll work on most common systems for most common situations and make life in coding a bit easier?

For the configuration vs scripting for modules, scripting is easier to implement, but more difficult to maintain. Configuration is easier to maintain, but more difficult to implement depending on the amount of allowed flexibility. Maybe something like YAML or ToML could bring more readability and flexibility to the config files while standardising the config parser. I still think independent room generators or multiple independent AI "personalities" are better off in scripting, but not necessarily Lua.

[t4nk]

I have most problems in C with int-to-pointer-to-int situations. I get segfaults for wrong type conversions in multiple places in code.

Well, that's the case of "doctor, it hurts when I do that"

Then I have to deal with multiple data types for integers and strings, that's a headache. What's wrong with just using 1 int data type and 1 string data type that'll work on most common systems for most common situations and make life in coding a bit easier?

Just use ints. As for strings, don't use wchar_t, these things are indeed a headache (they can be 16 bits or 32 bits). Strings in C are bad, that's just how it is.

[Pete Mack]

There really shouldn't be any int to pointer conversion in Angband (except in the really old-school winapi.) When there is such conversion, always use size_t as the integer type. That's pretty much it.

[mixer]

The different languages

As a long time programmer I give a little insight into your troubles. C was originally designed for very low level, just above machine code, for writing operating systems in. Along came C++ which built on C and with the thinking behind other languages like smalltalk i.e. object orientated, but again not really meant for writing user facing programs. After this people had Visual basic, then java and c#. These are all before we get into scripting languages like python.
So for C manipulation of memory was a primary point and the fore runner languages had no type checking, so C was better.
C++ is still a low level language but follows a different concept, object, rather than the functional style C.
Converting from C to C++ is interesting and converting from C++ to C is even more fun. I have done both in my lifetime.
The best language to write Angband from scratch would in my opinion be C# or Java. They are nearly the same and are easy to follow and code in.
I would not suggest we move the development of Angband to either as legacy code is painful to unpick. If you want to improve things then write front ends in a language that can use the current code. Personally, I don't have the time or energy to do so.

[droof]

I have some success with using data types limited to int, uint, char, uchar and the cptr and vptr pointer types. Slowly I'm getting better at this, very slowly.

I've played a bunch of Z+Angband and Debian's patched Zangband 2.7.5. Z+Angband has more modern features, but I'm not having much fun playing it. I don't like Z+Angband.

What captures my imagination in Zangband is exploration and the possibility of a quest centric game, more like how a skyrim or world of warcraft would play. Right now, quests are rare, but I can tweak the game so that towns have multiple castles and a selection of multiple quests. I would also be interested in adding more houses with mini-games, like the casino.

The problem I have with Z+Angband is that most quests are kill quests, requiring me to clear out levels while searching for all hidden doors and find that last monster. These quests are no fun for me and they are always too high level for my character, so I'm often forced to level up in the main dungeon.

Zangband 2.7.5 is much more open-ended in quests. Hunt down a bounty, make a delivery, discover a place or retrieve an item, as a player I can pick my own quests and complete them however I feel like. Meanwhile I discover more of the world and find interesting sites on the map like ruins, camps and clearings. Each with their own dangers and rewards. Increasing the number of quests here could work and having the character advance through the quests. The rewards probably need re-balancing then. I'd add more mini-games. Maybe porting over some of the friendband speech and town themes to give the game more personality, because now it's just "some world with towns with blubbering idiots". Shouldn't be too difficult to improve on that and I have the util code anyway

Z+Angband has more modern features, but if I'm going to make small changes while learning C and enjoying the playthroughs, I'd have to pick old Zangband instead. I don't think I can achieve that with small changes in vanilla Angband, not yet at least.

[takkaria]

I have some success with using data types limited to int, uint, char, uchar and the cptr and vptr pointer types. Slowly I'm getting better at this, very slowly.

Ah I forgot about those weird types that old bands have – I got rid of all of them when I was maintaining V. If you search and replace cptr with const char * and vptr with void * you might find the code easier to work with.

[johnretroreload]

Good points indeed, especially 2.7.5 vs Z+
I felt the same, for me zang was always about exploration, freedom and progression through quests (variety).
I never liked the forced progression as you say with quests when introduced v2.0+
I really look forward to your changes given your comments so far. Let me know if I can help.

I have some success with using data types limited to int, uint, char, uchar and the cptr and vptr pointer types. Slowly I'm getting better at this, very slowly.

I've played a bunch of Z+Angband and Debian's patched Zangband 2.7.5. Z+Angband has more modern features, but I'm not having much fun playing it. I don't like Z+Angband.

What captures my imagination in Zangband is exploration and the possibility of a quest centric game, more like how a skyrim or world of warcraft would play. Right now, quests are rare, but I can tweak the game so that towns have multiple castles and a selection of multiple quests. I would also be interested in adding more houses with mini-games, like the casino.

The problem I have with Z+Angband is that most quests are kill quests, requiring me to clear out levels while searching for all hidden doors and find that last monster. These quests are no fun for me and they are always too high level for my character, so I'm often forced to level up in the main dungeon.

Zangband 2.7.5 is much more open-ended in quests. Hunt down a bounty, make a delivery, discover a place or retrieve an item, as a player I can pick my own quests and complete them however I feel like. Meanwhile I discover more of the world and find interesting sites on the map like ruins, camps and clearings. Each with their own dangers and rewards. Increasing the number of quests here could work and having the character advance through the quests. The rewards probably need re-balancing then. I'd add more mini-games. Maybe porting over some of the friendband speech and town themes to give the game more personality, because now it's just "some world with towns with blubbering idiots". Shouldn't be too difficult to improve on that and I have the util code anyway

Z+Angband has more modern features, but if I'm going to make small changes while learning C and enjoying the playthroughs, I'd have to pick old Zangband instead. I don't think I can achieve that with small changes in vanilla Angband, not yet at least.

[johnretroreload]

Continuing development on 2.7.5 learning from Z+

Anyone interested in this project?