Loadable module support - Am I mad?

[calris]

OK, time for a seriously crazy idea

After mucking around with the sound module I thought, hey, sound is basically implemented as a message handler - Angband sends a message request with a 'message type' and the module simply plays the corresponding sound for that type. It would be a trivial case of turning sound into a loadable module which Angband can load dynamically (a .o file in Linux, a DLL in Windows)

But then I thought, hey - couldn't Angband just call a loadable module that handles dungeon generation. And what about objects, spells, etc, etc...

So I'm now thinking, why not just reduce Angband to all the UI stuff (display, keyboard and mouse input), core object handling, and visual effects (breath cones, bolts, beams, etc.) and put EVERYTHING else (races, classes, object types, spells, combat, etc.) into loadable modules. Angbang would then act as an event driven message broker.

Am I mad?

[takkaria]

OK, time for a seriously crazy idea

After mucking around with the sound module I thought, hey, sound is basically implemented as a message handler - Angband sends a message request with a 'message type' and the module simply plays the corresponding sound for that type. It would be a trivial case of turning sound into a loadable module which Angband can load dynamically (a .o file in Linux, a DLL in Windows)

But then I thought, hey - couldn't Angband just call a loadable module that handles dungeon generation. And what about objects, spells, etc, etc...

So I'm now thinking, why not just reduce Angband to all the UI stuff (display, keyboard and mouse input), core object handling, and visual effects (breath cones, bolts, beams, etc.) and put EVERYTHING else (races, classes, object types, spells, combat, etc.) into loadable modules. Angband would then act as an event driven message broker.

Am I mad?

Yes. Any advantage is massively outweighed by the added complexity.

[debo]

IMO Angband 5 needs to be deployed as microservices to the cloud.

[calris]

Yes. Any advantage is massively outweighed by the added complexity.

Really? I have always found that breaking something down into discrete components with clearly defined interfaces actually reduces complexity. It can be difficult to initially tease apart all the inter-related code, but once that is achieved, modularisation makes life easier moving forward.

I guess one of my main inspirations is the Linux kernel - sure it was a royal PITA to modularise all the code, but now code management is much simpler, and hacking one module runs a much lower risk of bringing bugs into another part of the code.

[takkaria]

Really? I have always found that breaking something down into discrete components with clearly defined interfaces actually reduces complexity. It can be difficult to initially tease apart all the inter-related code, but once that is achieved, modularisation makes life easier moving forward.

I guess one of my main inspirations is the Linux kernel - sure it was a royal PITA to modularise all the code, but now code management is much simpler, and hacking one module runs a much lower risk of bringing bugs into another part of the code.

Sure. Modularisation/componentisation is definitely a sensible design strategy, and its pursuit has directed Angband's development for a long while. But there's always questions of degrees and of method.

I think the analogy with the Linux kernel is interesting, but I think it would be a mistake to think that you can break a game into truly discrete components. All the things you mentioned - races, classes, object types, spells, combat - are interrelated in ways that, say, a network driver and a graphics card driver aren't.

Changing combat system will mean changing races, classes and object types. If you want to add a new capability to a race (say, a power you can activate every N turns a la ZAngband) then you will need to edit the UI to allow that. If you want to add walkable burning lava to the game, you'll have to edit dungeon generation, terrain info, and add code that triggers damage to the player every turn they're on it. etc.

None of this is to say there aren't meaningful components in the game - obviously there are - but just that they're still more tightly coupled than the analogy with Linux suggests. This means that there's no real purpose to splitting things up to the extent that they could be dynamically-loadable modules, because you'd have to modify multiple modules at the same time, and likely also change the interfaces between some of them.

I think Angband's already pursuing modularisation in a way that makes sense for it. More and more game data is being pushed into external text files, and the event messaging system that you mentioned is part of a long piece of work to split the game logic and UI logic of Angband and use a message-passing/event system to communicate between the two. The code of Angband is much more split up into individual units than it used to be, too.

[calris]

I think the analogy with the Linux kernel is interesting, but I think it would be a mistake to think that you can break a game into truly discrete components. All the things you mentioned - races, classes, object types, spells, combat - are interrelated in ways that, say, a network driver and a graphics card driver aren't.

Changing combat system will mean changing races, classes and object types. If you want to add a new capability to a race (say, a power you can activate every N turns a la ZAngband) then you will need to edit the UI to allow that. If you want to add walkable burning lava to the game, you'll have to edit dungeon generation, terrain info, and add code that triggers damage to the player every turn they're on it. etc.

I wholeheartedly agree

None of this is to say there aren't meaningful components in the game - obviously there are - but just that they're still more tightly coupled than the analogy with Linux suggests. This means that there's no real purpose to splitting things up to the extent that they could be dynamically-loadable modules, because you'd have to modify multiple modules at the same time, and likely also change the interfaces between some of them.

Yes, I have been pondering this - It was never my thought to be able to take the magic module from X and plug it straight into Y - It was more a case of, if you want to develop a variant without magic, you could take Angband, see clearly where all the magic interfaces were, and work towards cutting them out. Sure, you would need to modify the class, race, monster, object, etc. modules, but there would be clear instances within the code where those modules say 'Hey, Angband, tell the magic module X'

I think Angband's already pursuing modularisation in a way that makes sense for it. More and more game data is being pushed into external text files, and the event messaging system that you mentioned is part of a long piece of work to split the game logic and UI logic of Angband and use a message-passing/event system to communicate between the two. The code of Angband is much more split up into individual units than it used to be, too.

Yes, I've seen that there has been work put into a messaging system already - that's partly what made me think of modularisation - some of the groundwork has already been done. But it seems to be that this work has hit a bit of a wall. In real terms, this stuff is all under the hood, and I think Nick (quite rightly so) is focusing energy on things that improve the player's experience.

Looking at the Rune ID patches shows how well the code is already 'modularised', but then looking at PowerWyrm's efforts cross-porting my sound module code is a bit of a concern. am aware that the code bases have diverged a lot over time, and loadable module support won't cure this, but what it might help out with is being able to clearly identify the interfaces and give some comfort in that if the interface hasn't changed, a cross-port is likely to be a lot easier.

[Nick]

Yes, I've seen that there has been work put into a messaging system already - that's partly what made me think of modularisation - some of the groundwork has already been done. But it seems to be that this work has hit a bit of a wall. In real terms, this stuff is all under the hood, and I think Nick (quite rightly so) is focusing energy on things that improve the player's experience.

So in (the likely) case you missed recent development history, here's a quick rundown:

• takkaria was maintainer for several years, and recruited the current devteam
• After a joke that went badly wrong, I took over as maintainer with the advertised intention of doing (in cooperation with the devteam including takkaria) a large restructure of the code base to make it more flexible and general
• That process took about 18 months, and resulted in 4.0 (here is a reasonable summary)
• 4.0.0, unsurprisingly, required considerable bugfixing, so that process (which has finished in 4.0.5) has taken nearly another year
• As 4.0 settled a bit, the process of implementing new features for 4.1 started, but that is still fairly new

So I am certainly very happy to see more "under the hood" stuff being done. Anyone doing that sort of work, though, should be aware that a lot of that has changed fairly recently - and equally that there are bits which probably should have changed but didn't

EDIT: Also note, there are logs to the #angband-dev IRC here - you might want to check the latest

[AnonymousHero]

EDIT: Also note, there are logs to the #angband-dev IRC here - you might want to check the latest

That link gives a "Forbidden" response for me.

[nikheizen]

That link gives a "Forbidden" response for me.

Just type in the url to the top level (logs.aerdan.org) manually and navigate to freenode/#angband-dev from there.