Beleriand status

[Nick]

Latest

Some progress, but also some scope creep.

I have pretty rudimentary (and buggy) map generation going. I have changed the scale again to make the map even bigger, with each game grid having an in-game width of 2 metres. I have played a bit with the idea of a zoom function, so the player can see a bigger area while moving, but my current implementation has some performance and other issues.

I then decided to leave the map for a bit and move on to gameplay. My intent from almost the beginning has been to use Sil-style skill trees, and the current Sil competition has led me to go in and look at Sil mechanics a bit more. This has led me to two conclusions:

1. I really want to incorporate a large part of Sil - monster behaviour, probably combat, singing to replace magic, smithing, ... - so Beleriand is starting to look to me like a Sil variant;
2. Incorporating the code to do this looks like a massive exercise, so I have decided that the "easiest" way to do this is to actually rewrite Sil to use current Angband code (modernising stuff like datafiles and parsing, modularity of effects, UI separation, etc) first.

This is a clearly ridiculous course of action, so maybe I will change my mind (it's not like that never happens). But at this point it looks like I am taking on preparation of an unofficial version of Sil to go with maintaining Angband and FAangband and preparing Beleriand. Please feel free to tell me how stupid I am being - I am literally asking for it.

[HugoVirtuoso]

Is there any way you can provide a preliminary alpha version for gameplay testing on webserver or elsewhere?

[Nick]

Is there any way you can provide a preliminary alpha version for gameplay testing on webserver or elsewhere?

It's actually being autobuilt like V and FA here, but most of the changes are downstream updates from those, and the actual "game" is mostly non-functional, and the bits that do work are slated to be replaced by other bits. So if you're prepared to be completely misled, go right ahead

[clouded]

"After the refactor" is just classic Nick.

[Nick]

"After the refactor" is just classic Nick.

Well, when you put it like that...

[Quirk]

[*]Incorporating the code to do this looks like a massive exercise, so I have decided that the "easiest" way to do this is to actually rewrite Sil to use current Angband code (modernising stuff like datafiles and parsing, modularity of effects, UI separation, etc) first.

If I were implementing a new version of Sil and prepared to invest enough time to refactor it properly, I would not refactor it but would start from scratch. There is a good deal which is not fit for purpose which should be simply thrown away - in particular, anything related to level generation or item generation. A good deal of the codebase is simply dead code.

Of the rest, it's sprawling and disorganised and repeats itself in far too many places. There is a lot of magic global nonsense going on. The interfaces for the tiles are limited in the extreme and I had to institute some very dirty hacks to make various overlays work. Anything related to the UI is a royal pain.

Attempting to keep too tightly to the existing codebase risks inheriting its many and severe limitations.

Probably the only thing worth studying in depth before reimplementing would be the monster AI - it's not horrendously complicated, and doesn't sprawl too badly by Sil standards, but it's non-trivial. Much of the rest would be faster and better implemented from scratch to modern coding standards.

[Nick]

If I were implementing a new version of Sil and prepared to invest enough time to refactor it properly, I would not refactor it but would start from scratch. There is a good deal which is not fit for purpose which should be simply thrown away - in particular, anything related to level generation or item generation. A good deal of the codebase is simply dead code.

That's essentially what I'm doing - the aim is to get the gameplay of Sil in a codebase that looks like it's been forked from current Angband. I have made decent progress with modernising the data files, and also making changes to support that (parsing, etc). It's going to take a while, but I'm currently feeling it's doable.

You're quite right about dead code.

Whether you would ever want to redo Sil-Q on top of the finished product when it emerges is a whole nother question. The advantages would be better tile, UI and front end support; the disadvantages are obvious

[Quirk]

That's essentially what I'm doing - the aim is to get the gameplay of Sil in a codebase that looks like it's been forked from current Angband. I have made decent progress with modernising the data files, and also making changes to support that (parsing, etc). It's going to take a while, but I'm currently feeling it's doable.

Doable yes but probably months of full-time effort.

The fiddly stuff to rewrite around geometric calculations you probably already have from Angband, so this makes things much easier and you are probably the best placed to do this. The sound dispersal (for stealth/song) and morale system are probably the only interestingly algorithmic bits needing ported across.

However, reading and understanding the existing code will be a substantial time cost and there are many elements that will still need design work after a reimplementation e.g. the level generation, which is currently following a terrible algorithm not guaranteed to terminate in a viable level, will still need to handle forge placement after an improved version is written.

If you have the time and are interested in doing this, why not?

Whether you would ever want to redo Sil-Q on top of the finished product when it emerges is a whole nother question. The advantages would be better tile, UI and front end support; the disadvantages are obvious

Unfortunately my own time is at a premium right now as I flit between continents and the day job ramps up. I was substantially restricted in my ability to make even simple improvements because the codebase dysfunction made them rather less trivial than they should have been.

I am likely to pause Sil-Q development for quite a long time. If you wanted to use it as a basis for the refactoring I would have no issues with this - a lot of Sil bugs were fixed over the period I worked on Sil-Q - but I haven't made any significant attempts to clean the code up so it would be no easier as a starting point.

[Nick]

Thanks, that helps my thinking along. We'll just see how it goes, I guess.

One of the benefits of doing this is that it has the potential to highlight places where the Angband code could be better written or organised - in fact, this has started to happen already.

[Pete Mack]

Quirk--
I don't think you are aware of how much the Angband codebase has improved, post 3.0.5--it doesnt look anything like NPP anymore, by and large.
A lot of duplicated code is just gone, with loops and/or function pointers replacing case statements.

[Quirk]

Quirk--
I don't think you are aware of how much the Angband codebase has improved, post 3.0.5--it doesnt look anything like NPP anymore, by and large.
A lot of duplicated code is just gone, with loops and/or function pointers replacing case statements.

I'm sure it has, but I was talking about the Sil code, which has undergone a lot of messy evolution on top of the copy and paste.

My brief impressions last I looked at the Angband code were that it had been very much improved. Unfortunately though, moving Sil across to a newer cleaner framework involves parsing the existing tangle first.

[Nick]

Unfortunately though, moving Sil across to a newer cleaner framework involves parsing the existing tangle first.

Fortunately (as you observe) I am probably uniquely well-placed to do this, having worked on code from Oangband (forked from V2.8.3) right through to current. While a few of the changes made by NPP are unfamiliar to me, mostly I can recognise quickly what is new Sil code and where it needs to be placed in the Angband framework. In particular, starting by turning the edit files and their parsing into the modern idiom works really well, because it then leads naturally into changes in things like spell effects and ID. The hardest bits to do will probably be those you identify as interesting

[Quirk]

It's a bit of a shame that there is not (to the best of my knowledge) any source controlled repo available that tracks the development from NPP to Sil. This would have been useful to provide more context for many of the changes.

I imagine much of the item flags stuff around slays and resistances will port across straightforwardly. Sil's light level implementation shouldn't be too hard to replicate even if it doesn't perfectly align with what Angband does already. The abilities have quirks in places - many or most are quite simple, but a few require more book-keeping or add complexity to overly large functions such as those dealing with the player hitting or shooting a monster.

One challenge is to identify the dead code which is not obviously dead - gated by variables that never take certain values in Sil. I think there's a bunch of randart stuff that falls under this umbrella.

[Nick]

It's a bit of a shame that there is not (to the best of my knowledge) any source controlled repo available that tracks the development from NPP to Sil. This would have been useful to provide more context for many of the changes.

There is this, which I'm using heavily.

One challenge is to identify the dead code which is not obviously dead - gated by variables that never take certain values in Sil. I think there's a bunch of randart stuff that falls under this umbrella.

All the randart stuff, as far as I can tell

[Quirk]

There is this, which I'm using heavily.

That probably helps!

All the randart stuff, as far as I can tell

Yup. Also the automaton, and Amiga support. I think there are a few flags in the Windows support also but it's been some months since I last had to wrestle with them.