Tears unnumbered ye shall shed

[debo]

Oops. It feels deathly cold!

Oops. It feels deAbort

[chris]

All right, let's do this. I can wield this thing safely, right?

Oops. It feels deathly cold!

[Nick]

All right, let's do this. I can wield this thing safely, right?

[Magnate]

As regards the affix system, note that combat system is part of the last item on the list, all of which would be subject to review and negotiation.

Of course. If I'm still around at that point I'll happily help out - and if not, it should be possible to merge most of it from v4.

[Nick]

But really, the important thing is to have good separation between the game state and the UI. Once you have that, there's any number of good approaches you can use.

This is exactly the issue. The code needs to be divided between what is game, what is UI and what is both; once that separation is made, how to write new UI code becomes clearer (among other benefits).

[Derakon]

Pyrel's artists (i.e. the classes that are responsible for drawing things) all work on "layers" -- the map layer, the player status layer, the UI-prompt layer, the animation layer, etc. They just get drawn on top of each other in a specific order. As for the game knowing what is being displayed, right now all of the drawing logic is "pull"-based -- that is, the game says "Hey, here's the game state, and this is the current active prompt" and the artist draws what it thinks it should based on that, its window size, etc.

But really, the important thing is to have good separation between the game state and the UI. Once you have that, there's any number of good approaches you can use.

[nppangband]

(Sorry for the slightly OT post, don't want to bother creating an account on npp forums for just this one post.)

Very interesting to see. I've moved ToME 2.x to C++11 (not public yet, but I guess I might just push as-is soonish), and I've been experimenting a little with replacement front-end libraries...

I've tried SDL 2.x, Allegro and SMFL so far, and none of them seem to be very good fits for the way the ancient "virtual terminal" interface in the ToME 2.x codebase wants to -- I've tried various sprite/texture-based approaches, and haven't been able to make updates even remotely efficient. I don't imagine things have changed that much in this interface between the ancient T2 code base and Vanilla (or NPP), so I'm beginning to think that a major overhaul (including removal of all the old front ends) will be necessary to get a modern front end up and running well.

I had briefly considered Qt, but postponed it due to the "not quite C++" moc bit, but I think that's only really required for the GUI bits which could be sequestered away from everything else.

Of course, you also get a huge amount of cross-platform lower-level library goodness in Qt, so I guess it might be worth switching out some of the z-*.c crud too.

The biggest problem with Angband source code is that the game really has no idea what is onscreen at any given time. Because so many menus and prompts write over the dungeon screen, you can' count on what you want to be displayed actually being there all the time. I think at least half of the Angband code is basically a bady outdated game library and ui.

I was thinking along the same lines as what you are pondering. All the ports need to be scrapped. Most of the Z-*.c files and most of util.c need to go as well. I was thinking of front-end with a dedicated dungeon screen that never gets written over by any game dialog or text (except by specific player commands, such as the store interface or knowledge screens). It would involve the painful process of making sure all game prompts come up in dialog boxes and menus, but in the end I think the payoff would be huge. All messages should go in a separate window.

But I think step 1 is having the code base able to be compiled as C++. There just seem to be so many more game libraries, and front-ends that could be used with C++ rather than C.

I would be interested in hearing more about your attempts with SDL and Allegro. We considered those, although it appears QT is the front runner at the moment.

[AnonymousHero]

By the way, a group of us are seriously considering doing the core-ui split on the NPP codebase, making the necessary modifications so that NPP compiles as C++ code (not actually converting any code to C++; just keeping it as C but setting up for any C++ code to be added in the future), deleting about half the code and making a modern front end using either allegro or QT, with the added benefits that the game can have a front-end specifically designed for tablets.

http://forum.nppangband.org/viewtopic.php?id=1561&p=1

Not sure which one of us is more crazy at the moment.

(Sorry for the slightly OT post, don't want to bother creating an account on npp forums for just this one post.)

Very interesting to see. I've moved ToME 2.x to C++11 (not public yet, but I guess I might just push as-is soonish), and I've been experimenting a little with replacement front-end libraries...

I've tried SDL 2.x, Allegro and SMFL so far, and none of them seem to be very good fits for the way the ancient "virtual terminal" interface in the ToME 2.x codebase wants to -- I've tried various sprite/texture-based approaches, and haven't been able to make updates even remotely efficient. I don't imagine things have changed that much in this interface between the ancient T2 code base and Vanilla (or NPP), so I'm beginning to think that a major overhaul (including removal of all the old front ends) will be necessary to get a modern front end up and running well.

I had briefly considered Qt, but postponed it due to the "not quite C++" moc bit, but I think that's only really required for the GUI bits which could be sequestered away from everything else.

Of course, you also get a huge amount of cross-platform lower-level library goodness in Qt, so I guess it might be worth switching out some of the z-*.c crud too.

[Nick]

For all the long years
Spent in the Pits of Angband,
Beleriand waits.

No matter what, I'll be back to it

[Whelk]

Beleriand

Dreams of an effort to dwarf every other,
A project so vast, so beaut'ful and grand,
Yet hon'rable duties call Nick elsewhere, brother
Alas! Alas! to Beleriand.

:'(

[nppangband]

That is brilliant, and seems to align very largely with my ideas. I assume you would not mind me stealing stuff, as you never have in the past...

Absolutely. If we get it working I would be happy to help you merge it with the Vanilla code.

[Nick]

Long-term, I remain convinced that maintaining a consistent code style and a high standard of comment quality and quantity is worth the initial headaches, but I know that other Angband developers don't always agree.

I think I'm somewhere in the middle, but in a kind of messy way. I guess it depends on what you mean by code style:

• Things like indentation and where you put braces (talking C here, not python!) I like to be uniform, but I'd rather see code with this "badly" done than no code
• Comments quality and quantity somewhat similar, although I guess with both these things "that can be fixed later" too many times leads to problems
• Code structure - things like consistency and clarity of purpose - I'm prepared to go to war over

[Derakon]

Speaking as one end of the extremes Magnate listed, the tradeoffs between the dev-team model (Vanilla) and the dictator model (Pyrel) are basically:

Dev team model:
* Development can happen quickly, since many people have direct commit access to the repo.
* Code style guidelines are not strictly enforced.

Dictator model:
* Development speed depends on the free time of the dictator.
* Code style guidelines can be strictly enforced.
* Pull requests can involve a lot of back-and-forth (depending on how picky the dictator is and how "finished" the code was prior to submitting the pullreq), which can aggravate contributors.

Long-term, I remain convinced that maintaining a consistent code style and a high standard of comment quality and quantity is worth the initial headaches, but I know that other Angband developers don't always agree.

[Nick]

Release policy

Final tip: don't release nightlies. Release often, but do it after finding out what the latest changes have broken.

This is a significant suggestion, and deserved a separate answer. I guess there are times when you want people to be able to play-test changes, but there's no reason why those times should coincide with code commits.

I've been looking at this release model, and would value opinions - it's probably not really all that different to how the Angband development process has worked, but it clarifies some stuff for me.

[Nick]

I can offer some reflections here.

Thank you, this is very helpful.

it gives you the responsibility of balancing the quantity of contributions against the quality. Give commit access to too many enthusiastic amateurs like me and you end up with the "dodgy design decisions" to which Antoine referred in the previous thread - note that this dodginess will often have nothing to do with the contributions themselves, but their interaction with some other part of the game.

So it seems to me like you have a fundamental choice between the approach takkaria took with V and the one Derakon is taking with Pyrel - Derakon is an awful lot more exacting, but has many fewer contributors. (I know that's not an entirely fair comparison because Pyrel started from scratch.) At one end of the scale you write the whole thing yourself and it's perfectly coherent, and at the other end it's rapidly evolving, unbalanced chaos.

This expresses the issue perfectly. I think team dynamics won out in the end - my gut feeling, without a lot of playing, is that 3.4 is well-balanced, and 3.5 clearly better than it in every direction. But moving to a new maintainer would change those dynamics, and have the potential to derail everything again.

Luckily, I have nominated basic code restructure with no gameplay change as the first thing I would do. This leads to some advantages:

• Team all get used to n00b maintainer and possible new members
• 'Game-breaking bug' means game crashes or doesn't run, which is fine in the context of a code restructure
• Everyone involved gets to know the overall code structure better

Personally I think you're insane for taking this on, and it's particularly painful for me because this will be the THIRD time I've written the bloody affix system (if you'll have me) - but I can't say I'm not impressed.

Have you not noticed the use of "would" rather than "will"? This thread is like the first stage of XP allocation in Sil - you can see what you're buying, but you haven't bought it yet

As regards the affix system, note that combat system is part of the last item on the list, all of which would be subject to review and negotiation. I can say that writing the affix system twice has been a valuable life experience for you