Tweet
I know of at least one person who is still keen on *band-related coding in C (hint: it's me). In light of this, I have prepared an item for discussion.
Read and comment pls
Read and comment pls
-
One for the Dark Lord on his dark throne
In the Land of Mordor where the Shadows lie. -
All's I can say is, I wouldn't want to try to write Pyrel in C.
Of course, presumably you'd be able to re-use a lot of the existing code, so it's not as bad as that, but I'd wager a good 80% of the code will need to be touched or at least examined in this project.
I wish you luck! It'd certainly be nice to have an Angband codebase with good separation between layers. -
Well, since you asked. My first observation is that this looks to have quite a bit in common with both AngbandBase and CoreUISplit - two previous attempts to do part of this. Full marks for upping the levels of ambition and abstraction. FWIW I agree that it's good to have this and Pyrel going in parallel.
Second, I think this will only work if you get the categories right - and this is one of the rare cases where there *is* a right answer. In consultant-speak it's called MECE - Mutually Exclusive and Collectively Exhaustive. This means that any piece of code or game concept (either gameplay or meta) must fit clearly and obviously into one and only one category.
It's much, much harder than it sounds.
So, you've started with:
Library
UI
Game utility
Game interface
World
Character
Monster
Object
I won't attempt to set out a complete solution here - I don't have enough hours - but here are some disordered observations:
- monster spells and player spells should use the same code, which you've put in World. If player spell selection is handled by the UI that just leaves spellbook mappings in Character. Monster spell selection is part of AI in Monster.
- the Game Utility category should be dispersed: some of it can go into Library and others should be part of a Buildsystem category.
- Game Interface and Character aren't really distinct - the command handling is split across the two. I'd be tempted to put Options and Prefs and file handling stuff into UI. I think I might get rid of Game Interface altogether (I've redrafted this bullet about five times), dispersing its contents between Character and UI (and perhaps Library)
So that would give you Library, UI, World, Character, Monster and Object - and possibly Buildsystem. IMO that's cleaner but still not perfect."Been away so long I hardly knew the place, gee it's good to be back home" - The BeatlesComment
-
Why would parallel development in C and Python be a good thing? My intuition is that there is a relatively limited amount of resources available for "core Angband development", it would be better to focus those resources in one direction or the other rather than do both. E.g., if I were to get involved in core Angband development, I could work on a C version, or I could work on a Python version. If I do one then I'm not going to do the other.Having parallel development in C and python can only be a good thing.Comment
-
I suspect no one dev is going to try to evenly split their time between Angband and Pyrel. It's more that the two provide differing advantages and disadvantages:
Angband:
* Complete codebase; game is playable
* Many people know their way around the code already
* Large codebase
* Code may be inflexible and/or difficult to modify
Pyrel:
* Incomplete, unplayable
* Few people know how it all works
* Codebase is small
* Design is published (in forum posts, granted); code is relatively easy to learn
* Code is flexible and easy to modify
If you are a current variant maintainer, you would probably be much more interested in seeing what happens with a redesigned Angband than you would be in trying to adapt your own codebase to Pyrel. Most likely the redesigned Angband would be easier to port your code changes to -- after all, you've already written them, they would just need to be plugged into new places. And the non-code changes (i.e. edit file changes) most likely wouldn't require any modification at all.Comment
-
-
Correct. One of the big problems with making changes in the code right now is that it's hard to tell what bits of code use what other bits of code; the codebase is largely an unstructured mess of interdependencies. Cleaning that up would be a Big Win, making it much easier to make changes that do affect gameplay.Comment
-
Maybe, but I would think that most existing variants would just ignore the restructuring rather than try to adopt it. And for new variants it might be better to get the Python effort fully launched. I still have the feeling that there should be one effort aimed at "Angband restructuring" rather than two. I'm not trying to discourage anyone, just giving my thoughts.Comment
-
-
In an ideal world I'd agree completely - it seems silly to split scarce resource between to significantly overlapping objectives. But we'll never force people to use Python if they'd rather code in C, and Derakon shows no signs of abandoning Pyrel either, so we're stuck with both for the foreseeable. My point about this being a good thing was that it enables design learning made in one to be applied in the other (insofar as C/Python permits)."Been away so long I hardly knew the place, gee it's good to be back home" - The BeatlesComment
-
People actually prefer coding in C? Masochists...
You read the scroll labeled NOBIMUS UPSCOTI...
You are surrounded by a stasis field!
The tengu tries to teleport, but fails!Comment
-
If you're solving a big computational problem, coding in C could be a lot better than Python. For a game like this, where you don't care about performance, pretty much the only advantage is the existing codebase. That's obviously a big advantage, though.Comment
-
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?You read the scroll labeled NOBIMUS UPSCOTI...
You are surrounded by a stasis field!
The tengu tries to teleport, but fails!Comment
-
OK, this might be long. I'll start with some responses:
As I said, unoriginal Once you look, the same issues keep arising.
...and a partition in mathematician-speak
I actually said more or less that - that category was just laziness on my part. The Buildsystem category is a good point, although I guess I was taking that as a kind of outer assumption.
That extra layer of communication only really emerged as I was writing it down. You may be right; I think that Game Interface will make the whole thing harder to do, but increase the clarity of the final product. The other big advantage of keeping it distinct from the UI is that it simplifies the task of writing a native UI. It is really quite tricky - I see why you redrafted five times (but hyphen, not bullet - what kind of consultant are you?)
This is completely true - in the abstract. The point here is motivation, so I'll explain mine.
I have an existing variant and another, ah, thing, which (despite some temptation) have kept me from getting on the Pyrel train. These are fairly heavily based on approximately current Angband code, so the restructure is actually a win for me. I'm also kind of fond of the C codebase. We've had some good times together.
I also completely understand the motivation of the Pyrel people - python seems like a really good fit for Angband, and I think they'll make a go of it. Basically we do this stuff mainly for fun, so you have to go where the fun is. So if parallel development is happening anyway, we may as well make a virtue of it
Got it in one. As usual.
Yes.
No. Luckily it isn't brittle, it's not a cost, and I'm hoping to save time in the long run.
Finally, a little on ways and means. I have made a branch on my angband fork on github, called manifesto. But I'm not claiming any ownership of this process. We can just take it as it comes.One for the Dark Lord on his dark throne
In the Land of Mordor where the Shadows lie.Comment
-
takkaria whispers something about options. -more-Comment
Comment