Angband.oook.cz
Angband.oook.cz
AboutVariantsLadderForumCompetitionComicScreenshotsFunniesLinks

Go Back   Angband Forums > Angband > Development

Reply
 
Thread Tools Display Modes
Old July 2, 2013, 15:27   #1
Nick
Vanilla maintainer
 
Nick's Avatar
 
Join Date: Apr 2007
Location: Canberra, Australia
Age: 56
Posts: 9,170
Donated: $60
Nick will become famous soon enoughNick will become famous soon enough
Manifesto

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
__________________
One for the Dark Lord on his dark throne
In the Land of Mordor where the Shadows lie.
Nick is offline   Reply With Quote
Old July 2, 2013, 16:03   #2
Derakon
Prophet
 
Derakon's Avatar
 
Join Date: Dec 2009
Posts: 9,024
Derakon is on a distinguished road
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.
Derakon is offline   Reply With Quote
Old July 2, 2013, 19:32   #3
Magnate
Angband Devteam member
 
Join Date: May 2007
Location: London, UK
Posts: 5,060
Magnate is on a distinguished road
Send a message via MSN to Magnate Send a message via Yahoo to Magnate
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.
__________________
"3.4 is much better than 3.1, 3.2 or 3.3. It still is easier than 3.0.9, but it is more convenient to play without being ridiculously easy, so it is my new favorite of the versions." - Timo Pietila
Magnate is offline   Reply With Quote
Old July 2, 2013, 20:24   #4
DaviddesJ
Swordsman
 
Join Date: Mar 2008
Location: Burlingame CA
Age: 58
Posts: 254
DaviddesJ is on a distinguished road
Quote:
Having parallel development in C and python can only be a good thing.
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.
DaviddesJ is offline   Reply With Quote
Old July 2, 2013, 21:30   #5
Derakon
Prophet
 
Derakon's Avatar
 
Join Date: Dec 2009
Posts: 9,024
Derakon is on a distinguished road
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.
Derakon is offline   Reply With Quote
Old July 3, 2013, 01:05   #6
Antoine
Ironband/Quickband Maintainer
 
Join Date: Nov 2007
Posts: 1,009
Antoine is on a distinguished road
Quote:
Originally Posted by Nick View Post
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
To help me understand - is the proposal to restructure the codebase, without any changes to interface or gameplay?

A.
__________________
Ironband - http://angband.oook.cz/ironband/
Antoine is offline   Reply With Quote
Old July 3, 2013, 01:12   #7
Derakon
Prophet
 
Derakon's Avatar
 
Join Date: Dec 2009
Posts: 9,024
Derakon is on a distinguished road
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.
Derakon is offline   Reply With Quote
Old July 3, 2013, 01:44   #8
DaviddesJ
Swordsman
 
Join Date: Mar 2008
Location: Burlingame CA
Age: 58
Posts: 254
DaviddesJ is on a distinguished road
Quote:
Originally Posted by Derakon View Post
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.
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.
DaviddesJ is offline   Reply With Quote
Old July 3, 2013, 02:47   #9
Antoine
Ironband/Quickband Maintainer
 
Join Date: Nov 2007
Posts: 1,009
Antoine is on a distinguished road
Quote:
Originally Posted by Derakon View Post
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.
One good thing about this project is that no-one will complain about anything you do because you will not be breaking anything from the user perspective. That should make it quite pleasing to be involved with.

A.
__________________
Ironband - http://angband.oook.cz/ironband/
Antoine is offline   Reply With Quote
Old July 3, 2013, 08:25   #10
Magnate
Angband Devteam member
 
Join Date: May 2007
Location: London, UK
Posts: 5,060
Magnate is on a distinguished road
Send a message via MSN to Magnate Send a message via Yahoo to Magnate
Quote:
Originally Posted by DaviddesJ View Post
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.
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).
__________________
"3.4 is much better than 3.1, 3.2 or 3.3. It still is easier than 3.0.9, but it is more convenient to play without being ridiculously easy, so it is my new favorite of the versions." - Timo Pietila
Magnate is offline   Reply With Quote
Reply


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
Sangband Manifesto camlost Variants 32 July 2, 2007 15:14


All times are GMT +1. The time now is 16:44.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2021, vBulletin Solutions Inc.