Manifesto

[PowerWyrm]

Looks good. I'm happy to share my thoughts on how to design the core-UI split in a doc if anyone is interested. I have a bunch of work in my local repository that needs maybe another day of work, but is definitely a step forward towards a workable core-ui split.

If you want to see core-UI split in action, check the source code for PWMAngband. With a multiplayer variant, you have no choice: UI is on the client, game core on the server.

[Nick]

Looks good. I'm happy to share my thoughts on how to design the core-UI split in a doc if anyone is interested. I have a bunch of work in my local repository that needs maybe another day of work, but is definitely a step forward towards a workable core-ui split.

That would be absolutely excellent. I welcome doc and code with open arms, a spring in my step and a song in my heart.

If you want to see core-UI split in action, check the source code for PWMAngband. With a multiplayer variant, you have no choice: UI is on the client, game core on the server.

Oh. Right. Why didn't I realise this before? That might be quite handy in the sense of already having done a lot of the work and given proof of concept. Han-dy.

[Magnate]

Only in terms of saving time in the short term, though. Do you really want to base all your code on a brittle old framework that costs massive amounts of time to maintain?

I think this is about the nature of volunteer maintainership. The obvious answer to your question is no - for a dedicated developer. But for people who aren't sure how much time they'll be devoting to it on any given week, the answer has been yes for over a decade now ...

[ekolis]

I think this is about the nature of volunteer maintainership. The obvious answer to your question is no - for a dedicated developer. But for people who aren't sure how much time they'll be devoting to it on any given week, the answer has been yes for over a decade now ...

Thus adding to the brittle old framework in question, making it even harder on the next guy...

Maybe we need a Kickstarter so we can get one of those dedicated developers!

[Derakon]

Maybe we need a Kickstarter so we can get one of those dedicated developers!

You couldn't afford one. There's no way the community could afford the tens of thousands of dollars needed to pay a decent professional developer's salary for the time needed to truly clean up Angband's codebase.

[fph]

You couldn't afford one. There's no way the community could afford the tens of thousands of dollars needed to pay a decent professional developer's salary for the time needed to truly clean up Angband's codebase.

...in the meantime, Dwarf Fortress is averaging over 4000 bucks a month in donations.

I don't think we'll get remotely close, but maybe it's worth trying.

[DaviddesJ]

You couldn't afford one. There's no way the community could afford the tens of thousands of dollars needed to pay a decent professional developer's salary for the time needed to truly clean up Angband's codebase.

I could pay for it. The question is, what would the real value be? I am not sure that there is a sensible way to spend money to make Angband better. You don't want someone who's doing it for the money. You wouldn't likely get the results you want that way, either.

I'm not a big fan of Dwarf Fortress, but I think it has a lot more active players than Angband. Restructuring the code is a reasonable project, but it isn't going to vastly enlarge the audience for the game, at least not by itself.

[Nick]

The obvious answer to your question is no

I disagree - as I tried to indicate below, I think the obvious answer is to unask the question. I think the codebase is the opposite of brittle - it's ancient, but solid, and my whole premise at the start of this thread was that I want to continue working on it.

Thus adding to the brittle old framework in question, making it even harder on the next guy...

Funnily enough, with Pyrel, this is now less true than at any other time in Angband development history. Be happy

[Nick]

If you want to see core-UI split in action, check the source code for PWMAngband. With a multiplayer variant, you have no choice: UI is on the client, game core on the server.

After a good look at the PWMAngband code and a bit of a think, I've come to the conclusion that you've actually done pretty much all the core-UI split work that Angband itself needs. Moreover, the code common to client and server is pretty much what I've called Library, plus game-specific stuff that the UI needs to know about.

I'm finding this fairly mind-blowing, actually - this stuff has been sitting there for ages and most of us have just not noticed. In hindsight it is so obvious, but thank you for pointing it out.

takkaria - if you read this, I'd be really interested in your take on it.

[DaviddesJ]

Is the main purpose of refactoring the existing C code to aid future variants that may spring off from V, or to improve V itself, e.g., by enabling better UI and ports to more platforms? Or does it not matter, since the two goals have essentially the same path?

[Derakon]

Better separation means more flexibility means any new code work will be easier. If your workshop is tidy, then it's easier to make things in the shop -- and it's also easier to further improve the shop itself, or pack up the shop to move it into a different building, etc.

[molybdenum]

I'm on board with helping out. I was probably going to attempt this to some degree, since I have an unnatural joy for code cleanup and refactoring. A lot of what I would want to do is to try and use some modern techniques and patterns to increase maintainability and modifiability. In a way, I'm thinking of V as more of a platform for variants and one-off versions of the games, in addition to being a game itself. I realize that there are other roguelike libraries and tools, but I don't think that they, by themselves, are playable.

But yeah, it's an intimidating task. On a whim the other night, I decided to browse through some of the uses of p_ptr. Cleaning up Angband might be just as hard as playing the game (at least for crappy players like me).

[Nick]

Is the main purpose of refactoring the existing C code to aid future variants that may spring off from V, or to improve V itself, e.g., by enabling better UI and ports to more platforms? Or does it not matter, since the two goals have essentially the same path?

The latter, really. For example, I've been tying FAangband to the V codebase because then I get to use all the front ends, but working out which bits are game-specific is a bit of a pain; and clarifying things would certainly help all round.

I'm on board with helping out. I was probably going to attempt this to some degree, since I have an unnatural joy for code cleanup and refactoring. A lot of what I would want to do is to try and use some modern techniques and patterns to increase maintainability and modifiability. In a way, I'm thinking of V as more of a platform for variants and one-off versions of the games, in addition to being a game itself. I realize that there are other roguelike libraries and tools, but I don't think that they, by themselves, are playable.

This is pretty much exactly how I feel about it. In terms of techniques already started on, takkaria's (I think) list-*.h files are a massive step forward. Also, see the PWMAngband discussion.

[takkaria]

After a good look at the PWMAngband code and a bit of a think, I've come to the conclusion that you've actually done pretty much all the core-UI split work that Angband itself needs. Moreover, the code common to client and server is pretty much what I've called Library, plus game-specific stuff that the UI needs to know about.

I'm finding this fairly mind-blowing, actually - this stuff has been sitting there for ages and most of us have just not noticed. In hindsight it is so obvious, but thank you for pointing it out.

takkaria - if you read this, I'd be really interested in your take on it.

I don't know because I haven't looked at PWMAngband and I'm going away for a few weeks tomorrow. I suspect that my idea of core-ui split and PWMAngband's idea are different, though.

[Nick]

I don't know because I haven't looked at PWMAngband and I'm going away for a few weeks tomorrow.

If you do want to look, it's here.

I suspect that my idea of core-ui split and PWMAngband's idea are different, though.

I suspect not as much as you might think, and I found it very useful to look at. It is interesting, for example, to see how PWMAngband solves the spell problems you mention in your core-UI split blog post.

Anyway, have a good trip