FAangband, NarSil, Beleriand - state of play

[Nick]

One thing I'll just say, its probably worth picking up a Sil/Narsil win when you have time to play? I mean I'm not expecting you to go hardcore, and even not hardcore is a challenge some people don't meet. But you'll understand the mechanics better if you get a basic 1 Sil win through. Just find/pick the easiest win (We could have an angband comp? test Narsil, conditioned around 1 Sil wins). I don't know, mostly a perspective thing?

Not a win, but I have had a serious game (of Sil-Q, but still). And it certainly has informed me a whole lot.

Note that I did know your advice was correct, I just wasn't following it

[davidk64]

I fired up the latest Beleriand release containing an executable for a look. I hope asking questions about it might help with clarifying what you are planning for the future.

1. As it stands you are showing generation of terrain on a single level, without any zoom implemented? 4 x 12 sectors. I can't see a command in list to change zoom?
2. At present the number of terrain types is small and I think there is an argument for small rather than large going forward. I say that because I feel playing with or without tiles there is a limit to how much you can differentiate with the user being able to learn to recognise by sight without having to employ a looking mechanism - which longer term detracts from emersion? So I imagine that when a player first starts playing Beleriand they will need to use looking command to check what terrain is present in the area but over time they should be able to reach a point where they can glance at the screen and know what each grid point is representing. If the average player can't do that then maybe there are too many terrain types?
3. Sand and sand dune are both yellow dots. Would you differentiate the representation going forward? Are you planning for them to have gameplay differences.
4. I can't see a pattern in the way the terrain is revealed as you move around, it doesn't seem to be line of sight and or light radius based?
5. I like colour of ascii character giving a clue to terrain type.
6. I like that the terrain you are standing on is shown at the bottom of the main window.
7. Is the terrain generation purely random or informed by some sort of template or set of guidelines. If based on a template, would you think of exposing the template as a user editable data type where they can add new templates, adjust rules, add new maps?

Just trying to encourage you Answer all, some or known as time permits!

[Nick]

I fired up the latest Beleriand release containing an executable for a look.

The answer to all your questions really is that it's too early to say. The executable you are looking at actually resulted from me moving stuff around in preparation for moving what I had done over to being based on NarSil. Things have moved on significantly since then, although what you are seeing generated at surface level is still fairly unchanged. The main progress for the last few months since I've been working on it consistently (and since what I wrote in this thread) are:

1. Move my existing progress - ie what's in the executable you've looked at - to be based on NarSil and still working (this was a lot of work, chiefly in making sure that persistent dungeons actually generate without crashing);
2. Get the zoom function working; this was easier than I expected and I'm pretty happy with it;
3. River generation. This is a really complex business which I believe I am probably more than halfway though, but I'm not to the point of actually generating bits of river to sanity check my work, so who knows really.
4. In parallel with the first three a lot of thinking about future work I have to do and how the the game is going to play.

I still don't know when there will be something that's even worth preliminary playtesting; I'm going to say maybe this year as a bit of a spur to myself. But thanks for your interest

[davidk64]

Thoughts on quests

In Narsil 1.4:

1. You earn experience during the game
2. You spend some of that experience to increase the 8 skills (Melee, Archery etc.)
3. By increasing skill levels, you open up access to more expensive abilities where the expense is a combination of:
- skill level attained
- temporary decrease in stats (Strength, Dexterity etc.)
- additional experience cost

My idea is to have a quest structure in the same way you have an abilities structure

1. You go into character screen via "@"
2. You press "q" instead of "a"
3. For each of the 8 skills (Melee, Archery etc.) you have a list of quests of increasing expense
4. The expenses are of the same types as for abilities

How do you meet these quest expenses? A few possibilities:

1. Maintain two experience earned counts, one for abilities and one for quests where every time you earn experience it adds to both counts e.g. you earn 60 experience points for killing a monster, so both the abilities and quest experience earned totals get 60 added to them.
2. Double the experience earned for everything that now earns it and put half in each category.
3. Double the experience earned for everything that now earns it and maintain just one count of experience earned and let the player decide what proportion they spend on purchasing quests and abilities.

Haven't got as far as working out whether it's possible to create a set of quests that tie into each respective skill!

An extension of this idea would be to have a set of say vocations in parallel with the set of skills and players buy vocations points to get access to more expensive quests in that vocation group.

An alternative to a set of vocations is a set of quest themes or chains where within each quest theme you purchase access to the more expensive quests in the theme with earned experience.

A different approach again would be tying the quests into the abilities menu. So, in order to obtain an ability, there is an additional cost being completion of a quest specifically tied to that ability.

The common idea is that in order to take on increasingly difficult quests you have to earn experience by doing the normal base activities in non-quest situations and you have that meta game task of deciding how much experience to spend in the different quest groups depending on how far you want to progress in each quest group. In the same way you have a finite experience pool to spend on seeking the more expensive and interesting abilities.

Happy to attempt some examples if a particular approach is along the lines your thinking

[davidk64]

The answer to all your questions really is that it's too early to say. The executable you are looking at actually resulted from me moving stuff around in preparation for moving what I had done over to being based on NarSil. Things have moved on significantly since then, although what you are seeing generated at surface level is still fairly unchanged. The main progress for the last few months since I've been working on it consistently (and since what I wrote in this thread) are:

1. Move my existing progress - ie what's in the executable you've looked at - to be based on NarSil and still working (this was a lot of work, chiefly in making sure that persistent dungeons actually generate without crashing);
2. Get the zoom function working; this was easier than I expected and I'm pretty happy with it;
3. River generation. This is a really complex business which I believe I am probably more than halfway though, but I'm not to the point of actually generating bits of river to sanity check my work, so who knows really.
4. In parallel with the first three a lot of thinking about future work I have to do and how the the game is going to play.

I still don't know when there will be something that's even worth preliminary playtesting; I'm going to say maybe this year as a bit of a spur to myself. But thanks for your interest

Regarding the river generation. Is that in order to create the rivers on the map you linked? Or is it for the creation of random rivers additional to the map rivers? Or both? If it's random rivers, are you attempting to inform the river generation by the surrounding generated terrain, in the sense of reflecting elevation. Or maybe just making sure they proceed in a general direction and don't form knots. Just curious

[davidk64]

Earlier you said, "About three years ago I made a concerted effort to at least get an implementation of the map in place, which can be seen in the GitHub repo" Does this mean the current Beleriand is generating terrain corresponding to a representation of Beleriand? Without an overview I just assumed it was generating random terrain?

This was meant to be in the last post as an edit - blowed if I can work out forums

[Nick]

My current feeling on quests is that they won't quite have that formal a structure. There may be some higher priority, or just identified, places to go and map. I'm not planning to have any hierarchical system of them, or formal access to them. In fact, I have one idea which is kind of the opposite way around - that there are some abilities that you can only get by going to particular places. It's possible that there will end up being a natural hierarchy, or at least order, of attempting objectives, but I'm seeing that as arising out of kind of "naturally" imposed conditions. This is all fairly vague at the moment

On river generation, I have made data files mapping the rivers as marked on the map at the resolution of a data point every square mile. The tricky bit is that the map is only being generated - at 880 x 880 grids per square mile data point - as the player encounters it. So as the player moves across the map, I have to map the local piece of any river encountered, make sure it connects correctly with any other bits already generated, and make sure to retain the data needed to connect it to future bits to be generated. Getting all this to work in a way that generates organic-looking rivers turns out to be quite intricate.

[davidk64]

Thought I'd try crunching some numbers based on what you've said about the map.

Beleriand size: approx. 500 miles square, 2640000 feet square (5280 feet in a mile x 500)

Map generation chunk: 1 mile square, 880 pixels square

Pixel: 6ft square (5280 / 880)

Horizontal screen traverse: assume 1 minute

How long to cross Beleriand on a monitor 1920 x 1080, scrolling sideways at 1 min per screen width:

(500 miles x 880 pixels per mile) / 1920 pixels per screen width = approx. 230 screen widths, which at 1 min per width = 230 minutes = approx. 4 hours

1 min per screen width = 1920 pixels x 6 feet = 11,520 feet per minute = 2.18 miles per minute (11520 feet / 5280 feet per mile) = 130 miles per hour

If we assumed an average walking rate of 3 miles per hour and wanted to move at that rate we'd need to traverse the monitor width over 44 minutes.

I'm starting to get a sense of the scale!

I'm trying to understand the Beleriand map. If it's 500 data points square and each data point is one terrain class? How do you generate the 880-pixel square chunk for a given data point terrain class? Say the data point is river, how do you decide on the river width and where in the chunk the river is? Is that algorithmic with the remainder of the chunk filled in with a selection of other terrain features? If the river is flowing on the map from Northwest to Southeast how would the algorithm know that so as not to put it flowing Southwest to Northeast for example?

Pondering how I'd tackle it. Distribute the game with all the chunks pre- generated as far as vector data like roads, rivers, town locations and randomly fill in chunks with flora/fauna etc. as required at runtime? It sounds more and more like generating terrain for a flight simulator to me - minus the elevation considerations.

I know you're busy coding (and no doubt RL) so only answer if you have time and it's easy to explain! (The balance between whetting our appetite versus getting stuff done)

[Nick]

Your scale is about right. For generation, the square mile data points are things like plain, forest, etc - rivers are not data points individually, but are defined by which ones they pass through, in order moving downstream. So when the player enters a square mile, it will be checked for pieces of river, and then a course will be plotted across it. For generation and storage purposes the square mile is divided into 20x20 chunks of 44x44 grids. So first we work out which side the river is coming from, then which it is going to, then plot which chunks it will pass through (that's about where I am now). Next is to determine the width the river will be (fairly constant across the square mile), and decide and record where it crosses the chunk boundaries. Finally when the player actually reaches that chunk, those boundaries are used as beginning and end for the river as it crosses the chunk.

All this is ignoring the other terrain; currently I have different algorithms for each of forest, mountain, plain, etc, and the river will then just be put in after and replace the terrain that was generated.

I could have done it by generating an entire map upfront, but that would take time and storage - I haven't calculated how much. The advantage of this way is that each bit of map is only generated as needed, and only a fairly small part of it is kept at any time. For parts that need to be restored, all that needs to be saved is the state of the RNG so that it can be re-generated, any river borders that have been determined along the way, and any changes to terrain made while the player was there (rubble dug or trees destroyed, for example).

Doesn't sound hard when you say it quickly