Z+Angband dev

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

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

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

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.

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

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

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.

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

[Pete Mack]

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.

[Nick]

I think the C language is a barrier for new developers to try working on their ideas for a new variant. It was for me back in 2013.

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

[Derakon]

Speaking as someone who tried to rewrite Angband in Python, more or less: it is a ton of work. Especially if you want to do a clean rewrite, rather than just re-implement C code in a different language.

Ultimately, it turned out that I don't care that much about Angband that I was willing to see the project through. I still feel bad for the people here that contributed to the project, only to see it die on the vine...

[droof]

I think the C language is a barrier for new developers to try working on their ideas for a new variant. It was for me back in 2013. Maybe Lua isn't a good language either for creative feature coding, but there are plenty of alternatives. For example, Python is gaining popularity and is replacing Lua in some game engines and IoT platforms. Python is also used for education and serious work.

If we want variants that offer something unique and different from what we've seen before, then that requires coding and changes to core functionality. Text files only extend or theme what's already in place.

With text parsers maybe we can get new stories in D&D. With scripting, someone should be able to turn D&D into Pathfinder.

[Pete Mack]

Oh gods yes. The way it was done in 3.0 was WORSE than the initial and temporary hack of turning it into a giant case statement in V3.1. It just added a second language AND extra boilerplate. Parsing text files is so much cleaner all around. So is generating code with CPP where necessary.

"let's use Lua to avoid doing a parser for dice-arithmetic" (Angband)... which is pointless and awful.

[AnonymousHero]

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.

Just shows that people don't learn from their mistakes As a practical matter, yes, it has been used successfully... but the so has Visual Basic.

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.

This is an excellent and apt point. I have an aversion towards Lua because my first encounter with it was while porting T2 away from Lua into C/C++[1]. I don't think the science is anywhere near settled on dynamic/static typing in terms of defect rates, but Lua just seems to make all the wrong decisions even for a dynamically typed language: Arrays are really just magical hashes, indexing the wrong thing doesn't say "hey! you indexed the wrong thing", it just returns "nil", there doesn't seem to be any data structure other than hashes, really, etc. It just awful... and my hypothesis is that the only way the big studios have been able to make it work is because they can throw a lot of people/testing at it. (Of course, DarkGod isn't a big studio, but DarkGod is DarkGod.)

[1] ... and you're absoultely, right T2/Angband was not using Lua as a higher level scripting over a high-perf C engine. It was just "let's write C in Lua" (T2) or "let's use Lua to avoid doing a parser for dice-arithmetic" (Angband)... which is pointless and awful.

[johnretroreload]

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.

Coding as clean and efficiently as possible, thanks for clarifying. I'm weak on programming these days.