Resetting the automap?

[Aran]

Is there some way to reset the automap of a town after the players have already explored it? I don't need to block the automap feature completely, I just need the game to "forget" this area has already been explored.

 

The call could even be made once upon entering the town; I don't need to reset the map while the player inside the town. This is because there are substantial changes to the town, and I can't have the automap showing the previously explored, but now changed areas.

 

I'm trying to avoid having to generate a new town for this, since it needs to happen at least several, if not an almost unlimited number of times - is that possible?

[Kelandon]

You need to make it a new town. There really isn't any other way of doing it.

[Aran]

I see. Nasty.

 

What happens when a script makes changes to the town while the player is inside it - is the automap immediately redrawn, or only once the player goes through that part of the town again?

[Imban]

Only once the player goes through that part of town again, I'm pretty sure. You can get a pretty bugged-up Automap this way.

[Donald Hebb]

This may be a bit drastic, but before you send it out for release, you can make all of the terrains and floors have no editor icon or an editor icon of just blackness.

Well, okay. That's more like disabling automap. But there you go.

[Aran]

Perhaps it would even be enough to have a special set of "unmappable" terrains and floors. Since the cave would only need cave wall, floor and perhaps a few special features, it would not take a lot of slots.

 

I'm currently thinking (vaguely; I haven't got a solid plan yet) about how one could implement a randomly generated dungeon or even an infinitely continuing dungeon as in Adom or Angband. Generating a dungeon randomly was basically impossible with nodes, but I haven't yet learned enough about Avernumscript to know that it is hopeless in BoA as well.

[Donald Hebb]

It was not impossible- see, for example, Echoes' town 8.

 

It was effectively impractical and useless, though...

 

As for the dungeon idea: It would have to be something along the lines of the Ancient Cave of Lufia II. There are a set of rooms in each level, and some of them have a treasure chests, in which is an item (random). There are given monsters, randomly determined. The rooms are joined to one another randomly (sometimes omitting whole rooms).

 

Practically, this could be done by clearing all monsters via erase_char and then reviving random ones. Chests can be set to have randomized existences, and when they do exist, they can become blank terrains and have items inside. If the town is to be used multiple times, you can customize the objects in each room (set them up beforehand and use set_terrain(x,y,0) to ranzomize), and erase items on all spaces when the town is enterred.

 

Okay, that's really bizarre and time-consuming... But it IS possible.

 

EDIT: Also, you can use set_level and alter_stat calls to revert the party back to level 1 like Lufia II does... You'd just have to make sure to revert it afterwards.

[demipomme]

I'm currently working on a scenario that features randomly generated levels and although I wasn't going to mention it until release, it may help you to see what I've been doing. I can send you the scenario file if you're interested.

 

I noticed the problem of automap change and, whilst annoying, I've decided to ignore it in the hope that it will go away (which it won't unless force_automap_redraw() and set_seen(short x, short y, short seen) become the reality I have fantasised about).

[Donald Hebb]

This is a horribly roundabout way of going about things, but still, have you tried this:

 

Code:

leadchar = 0;while(char_ok(leadchar) == FALSE){leadchar = (leadchar + 1);}rctx = 0;while(rctx <= 47){rcty = 0;while(rcty <= 47){relocate_character(leadchar,rctx,rcty);rcty = (rcty + 1);}rctx = (rctx + 1);}

It's very unlikely since you might run the 64000 commands limit pretty quickly, but if you absolutely need to call such a node, well... It exists.

[demipomme]

If I am interpreting this script correctly, this makes the whole map "seen", which I suppose makes the automap look neater. I kind of want something that will make the whole map "unseen" (or at least a bit of it).

 

The cave in my scenario is meant to be magically enchanted so that the walls are constantly moving. Each time you enter the cave it is different.

 

EDIT: So you need to re-explore every time (and that won't infuriate players...)

[Lilith]

Quote:

Originally written by demipomme:
If I am interpreting this script correctly, this makes the whole map "seen", which I suppose makes the automap look neater. I kind of want something that will make the whole map "unseen" (or at least a bit of it).

Easy. Make the entire cave out of blackness to start with, and only place the walls and rooms after you've danced the party through all the blackness. That way, the whole map is "seen", but it's "seen" as blackness.

(It isn't necessary to put the party on every space in town, though -- just make the initial blackness non-opaque, and dump the party on every 4th space or so. That'll still result in the whole town being mapped -- or rather, unmapped -- or better still, demapped.)

[demipomme]

I haven't checked, but I think the automap remembers what squares the party has seen and then displays on the automap exactly what's there, so your method would effectively reveal the entire map. But thanks for the idea and I will go and check just to make sure I'm not chatting mumbo jumbo.

 

EDIT: In fact I wouldn't mind if the automap remembered the exact map as it was and this changed as you got to it. This would fit in with party exploring and mapping an area (thus having a map of how it was) and then coming back to see the walls moved and thinking this is weird.

[Donald Hebb]

Well, what you could do is use rectangle calls to clear the whole town and then place the party on every sixth space or something. Then, you'd use the stairway node to place the party back at the beginning of the town.

 

(Stairway nodes reset all terrain to the way you set it in the editor.)

[Aran]

What does this "command limit" entail - the commands you can execute in a certain town throughout the game, or the commands that can be run while the player is in a certain town (reset when he leaves), or what?

 

Setting the town to blackness and forcing an automap redraw this way would be a possibility - blackness would take the place of unexplored terrain.

 

But combined with the functions that generate the dungeon (which will likely use a lot of commands), it'd be a lot of stuff for the script to do. Where are the limits?

[Kelandon]

That limit is the number of commands you can run in a row. If you do, for example, this:

Code:

 while (TRUE) {print_num(i);i = i + 1;} 

Then you will run into the limit. Once a tick has elapsed, the number resets.

 

As far as relevant BoA limits, you have a limit on the length of a script — something like 4000 lines — and the number of commands you can run in a row — something like 60000. You can have at least 100 states, probably many more. So in other words, this is not likely to be a problem.

[Lilith]

Quote:

Originally written by demipomme:
EDIT: In fact I wouldn't mind if the automap remembered the exact map as it was and this changed as you got to it. This would fit in with party exploring and mapping an area (thus having a map of how it was) and then coming back to see the walls moved and thinking this is weird.

This is how it worked in BoE. You may be right about it working differently in BoA, although I wasn't aware of it.

[Aran]

So it's a safeguard against endless loops, I assume. Well, 64k is still quite a lot, especially considering that you don't need to call them all at once.

 

Quote:

Originally written by Shingai no Junkyousha:

Well, what you could do is use rectangle calls to clear the whole town and then place the party on every sixth space or something. Then, you'd use the stairway node to place the party back at the beginning of the town.

 

(Stairway nodes reset all terrain to the way you set it in the editor.)

Every sixth space due to the range of LOS, presumably. Is it possible for the player to have a reduced LOS for some reason?

 

By the way, is this noticable to the player? They do get moved around somewhat after all. Does the screen get redrawn in that time, or is the moving invisible?

 

Oh... if the stairway nodes reset the town's terrain (does that include the floors, btw?), then I could just start out with a blank town and generate the dungeon on each entry after the stairway node, it would save the blanking out.

[Kelandon]

The screen doesn't get updated unless you use a force_instant_terrain_redraw or run_animation or something. Floors and terrains get reset to their original (editor) states when you leave and re-enter, so yes.

[Lilith]

Quote:

Originally written by NaNoWriMo:
Every sixth space due to the range of LOS, presumably. Is it possible for the player to have a reduced LOS for some reason?

Yes, if it's dark.

[Aran]

Mh. It would probably be better to have full light in the cavern - it's impossible to have varying light anyway, and that will make it easier to redraw the outmap.

 

This is getting interesting. Once I'm done with my Nano writing, I'll see if I can make some test or proof of concept thing for an infinite cave.

[Aran]

Couldn't hold the ideas back any longer - I've started to make some basic functions that generate rooms in an ascii-format.

 

Of course, coding functions like this in Avernumscript rather than PHP or Java will be a lot different - besides, walls are no longer separate floor squares unlike in the Exile engine.

 

Still.

 

Code:

                             ##############                                                                   #............#                                                                   #............#                                             #######################............#                                           ###..................................#                                           #......##################............#                                           #......#                ##############                                           #......#                                                                         #......#                                                                         #......#                                                                         #......#                                                                         #......#                                                                         #......#                                                                         #......#                                                                         ########                             #############                                                                    #...........#######                                                          #####.####............#                                                        ###.....#  #............#                                                       ##...#####  #............#                                           ########    #..###      #............#                                           #......#    #.##        #............#                                           #......#    #.#         ##############                                           #......#    #.#                                                                  #......######.#                                                                  #.............#                                                                  #......########                                                                  #......#                                                                         #......#                                                                         #......#                                                                         ########       

A function to create a room, and a function to connect two rooms via a single-space tunnel, randomly. It would need a lot of work even in the present form, and after that, porting it to Avernumscript would be something else entirely.

[KernelKnowledge12]

You could convert the Angband code into Avernumscript. It might be easier.

[Aran]

It is always easier to port something you have coded yourself. Also... do you *have* the Angband code? Because I sure don't, and don't know where or how to obtain it if it is available anywhere...

 

Edit: New idea! I could leave the walls out in the beginning, and then go over the map to check for boundaries between blackness and cave floor, and put walls in. Not sure if the 64k command thingy would kick in by that time though...

[KernelKnowledge12]

Angband source: http://www.thangorodrim.net/download.html#source

 

Quote:

besides, walls are no longer separate floor squares unlike in the Exile engine.

This shouldn't stop you from treating a wall as just a floor. If a spot is to designated a wall, put the corresponding terrain and nothing else.

 

EDIT: typo

[Lilith]

Quote:

Originally written by KernelKnowledge12:
This shouldn't stop you from treating a wall as just a floor. If a spot is to designated a wall, put the corresponding terrain and nothing else.

There's still the non-trivial issue of working out which wall type to place in each spot, though.

[Aran]

There's a function in the editor that puts walls around an enclosed space, right? Perhaps one might adapt that somehow...

[Lilith]

Not every editor function has a corresponding script call.

[KernelKnowledge12]

I looked at the Angband code and all the dungeon creation code seems to be in generate.c. The code is basically straight C, the functions are in an ascending order of importance (meaning the very last function generates a random level) and its very well commented, so it shouldn't be too hard to extract a generic algorithm for each function.

 

EDIT: The code is in generate.c, not dungeon.c.

[Aran]

Quote:

Originally written by Thuryl:
Not every editor function has a corresponding script call.

No, but the editor is open-source, and assuming that Jeff somehow coded an algorithm that sets these walls, it might be possible to use the same algorithm to set the walls in the game.

[Kelandon]

It would probably be easier just to write the algorithm yourself. I mean, seriously.

[Lilith]

I predict that the 64000-command limit is almost certainly going to be a problem if you try anything too fancy. You might have to make each level of the cave fairly small.

[Aran]

With infinite variety for the cave design, a small cave would not be a problem. Even the 48*48 (that's the minimum for BoA, right? There were smaller ones in BoE, though) square would be big enough for a few rooms and tunnels, and a couple of monsters placed strategically. Add to that a bit of fancy stuff to randomly generate monsters - this could be called while the player explores, which should move it out of the initial thread of commands - and the level is done...

 

Of course, it sounds way easier than it would be. Still, after November is out I might fiddle around a little with the editor and try out some of these concepts.

[Thralni]

Isn't it much easier to just designing maybe 50 small towns, and link them to certain stuff done flags? Then, while the player walks around in the tunnel, the player gets messages, saying "you hear stone grinding on stone and slight vabrations make you blah blah blah......." When this messages gets triggered, a certain town has been moved into another place, or a wall was shifted. This way you would get a huge number of possibilities and things to change. The only problem is maybe that in the end the player will get tottaly frustrated by the constant moving and changing of the tunnel.... I could actually easily make a story arounf this now that i think of it. This would make a nice scenario: "the tunnel of shifting rooms," or something like that. Good one, aran!

[Aran]

The idea is to have the levels change both ways - going up, and going down, the level is regenerated anew every time. Even after reloading from a saved game, the levels would be generated differently.

[demipomme]

Here's my code for putting walls round stuff:

 

Code:

  x = 3;y = 3;while (x < 60){while (y < 40){if (get_floor(x , y) == 71) {if (get_floor(x , y - 1) != 71) {set_terrain(x,y,2);} // Northif (get_floor(x - 1 , y) != 71) {set_terrain(x,y,3);} // Westif (get_floor(x , y + 1) != 71) {set_terrain(x,y,4);} // Southif (get_floor(x + 1 , y) != 71) {set_terrain(x,y,5);} // Eastif ((get_floor(x , y - 1) != 71) && (get_floor(x - 1 , y) != 71)) {set_terrain(x,y,6);} // North and Westif ((get_floor(x , y + 1) != 71) && (get_floor(x - 1 , y) != 71)) {set_terrain(x,y,7);} // West and Southif ((get_floor(x , y + 1) != 71) && (get_floor(x + 1 , y) != 71)) {set_terrain(x,y,8);} // South and Eastif ((get_floor(x , y - 1) != 71) && (get_floor(x + 1 , y) != 71)) {set_terrain(x,y,9);} // East and North}y = y + 1;}y = 3;x = x + 1;}

It only works if each pit square is in groups of at least two. This is because the walls are being put on the pit square and squares can't have walls on more than two sides (a downside of the engine if you ask me, hint, hint, cough, cough).

 

The command limit is an issue. I break my code into three separate bits: the random room creation is done in init_state; the walls are added by a special node; and the terrain is frilled up by another special node.

[Aran]

I haven't had a chance to try it, and won't for the next few days, but that looks awesome!

 

Quote:

It only works if each pit square is in groups of at least two.

One square pits shouldn't be an issue really - after all, they really don't occur that often in everyday town designs, and when they do, they rarely need to be walled in.

 

Many thanks for that code!

[demipomme]

Oops! I forgot to mention that I use pit for all squares on the map that the player is not meant to go on (this way they look black on the automap). I then use this code to put the walls on the pit squares, giving walled in caves. This leaves the cave squares free to be frilled up (with stalactites, nests, bones, thermonuclear weapons and any other terrain types relevant to the town).

 

The pit squares MUST be in groups of at least two in each dimension or else putting walls on the doesn't work. This is kind of hard to explain, but I think you'd realise if you had a go.

 

I'm excited to see your random room generation, as my random maker isn't that sophisticated.

 

EDIT: You could easily change the code to look for blackness rather than pit, I just use it as this is the way by random maker works.

[Aran]

Yes, I'd figured as much. To have a wall around it, you need this kind of square as the smallest unit:

 

Code:

.....BB..BB.....(B=blackness)

What does the script do when it finds a smaller pit? Wall it improperly, return an error, or just leave it alone?

[wz. As]

Does anyone know if arithmetic operations are included in the limit? If not, then I came up with a different algorithm based on demipomme's that might be more efficient:

 

Code:

 // Assumes that the only regular floor is 1, and everything to be surrounded with walls is 0set_flag(100,0,0);	// None: No terrainset_flag(100,1,3);	// Westset_flag(100,2,4);	// Southset_flag(100,3,7);	// South & Westset_flag(100,4,5);	// Eastset_flag(100,5,0);	// East & West: No terrainset_flag(100,6,8);	// East & Southset_flag(100,7,0);	// East, South, West: No terrainset_flag(100,8,2);	// Northset_flag(100,9,6);	// North & Westset_flag(100,10,0);	// North & South: No terrainset_flag(100,11,0);	// North, South, West: No terrainset_flag(100,12,9);	// North & Eastset_flag(100,13,0);	// North, East, West: No terrrainset_flag(100,14,0);	// North, East, South: No terrainset_flag(100,15,0);	// North, East, South, West: No terrainx = 3;while (x < 60) {	y = 3;	while (y < 40) {		if (get_floor(x, y) == 0) {			i = 8*get_floor(x , y - 1) + 4*get_floor(x + 1 , y) + 2*get_floor(x , y + 1) + get_floor(x - 1 , y);			set_terrain(x, y, get_flag(100, i));		}		y = y + 1;	}	x = x + 1;} 

I haven't tested it extensively, so I don't know how many operations it uses, but if anyone wants to give it a try and let me know how it compares, I'd appreciate it.