View of a Scrolling Dungeon

[AquaTsar17]

Hi all,

I've been experimenting with a RL for a bit and have implemented a scrolling dungeon. However, I'm not really sure what would be the best way to view this dungeon.

For example, should the player's view onto the world automatically scroll so that their character is always in the direct center? Or should the view only scroll when the player's character reaches an edge? And then, how close to the edge?

Right now I've got it centered and auto-scrolling, because that was easiest, but I'm curious what other people think of that idea. Any thoughts?

[Fenrir]

Having the view scroll when you move to the edge only makes sense to me if your game's world is divided into chunks, Legend of Zelda (NES) style. Otherwise, nasty things will be able to strike you from beyond your view.

[purestrain]

Hi all,

I've been experimenting with a RL for a bit and have implemented a scrolling dungeon. However, I'm not really sure what would be the best way to view this dungeon.

For example, should the player's view onto the world automatically scroll so that their character is always in the direct center? Or should the view only scroll when the player's character reaches an edge? And then, how close to the edge?

Right now I've got it centered and auto-scrolling, because that was easiest, but I'm curious what other people think of that idea. Any thoughts?

I sense a soul in search for answers... what about a user selectable behaviour? (well; i would never switch to anything else then player-centered) Is it smooth scrolling?

[Rabiat]

Scrolling when the player reaches the edge (as in Angband) is the traditional way to go, but IMHO scrolling with the player in the center (as in Crawl) is the most user friendly. I believe 'Angband mode' was invented so the program can do partial screen updates, which is easier on the CPU. 'Crawl mode' is easier to code, but the game must be able to handle the extra screen updates smoothly. 'Angband mode' requires the game to keep track of the player's location on the display, determine edge collisions, prevent off-screen attacks, and it would make sense to implement partial screen updates.

You could prevent off-screen attacks in 'Angband mode' by scrolling the map display >1 tiles away from the edge, but that would cause overlap in the displayed sections, and/or the player character jumping several tiles in a single turn.

[Krice]

should the player's view onto the world automatically scroll so that their character is always in the direct center?

I think this depends on the size of gameview. I don't like scrolling with every movement, which is funny because Kaduria has that kind of view (Crawl/Ultima -style). Maybe I'm a bit bored to that after years of development.

[AquaTsar17]

Giving the user the option to change scrolling style would be nice, as it makes the game playable for more people. I already know there'll be some config section of the game (possibly just in an external file) so I could put it in there. Besides, I'm using ASCII instead of Tiles so that will already restrict the number of people interested in it.

I'm not sure what you mean by smooth scrolling though. Is this more of an animation of things moving? The scrolling I have right now is the same as Crawl, but I may experiment with Angband-style scrolling. I'm writing it in Java so I'm less concerned with CPU usage and moreso with memory.

[AgingMinotaur]

The scrolling I have right now is the same as Crawl, but I may experiment with Angband-style scrolling.

This is how I would think: since you already have a working system, you might as well stick with it for now. Scrolling in itself isn't what makes a RL interesting (although it's an important part of the overall game). Rather, I would argue, content is. I'm sure there are plenty of things to do and features to add. For instance, an interface for setting config options Of course, if you feel like implementing Angband-ish scrolling right away, go ahead. If it is what you want to do right now, it's probably also what you should be doing, I think.

When and if you ever end up with two working systems, allowing a config option to toggle between the two sounds like a good idea. For now, you could just use the one you like yourself, and leave the other handing around as code or comments, so that you can switch it on at will.

I'm not quite sure which type of scrolling I prefer. It probably depends on how the maps look. Ideally, I prefer RLs that don't scroll at all, but that would be moot point to bring up now

As always,
Minotauros

[Numeron]

I would say that the Crawl style, with the player locked to centre is my personal favorate...

What you can do though, is try to implement a variable which is something like the number of tiles from the edge of the screen before the map scrolls. That way you and/or the player can easily adjust the size of the area in the centre of the screen you can roam around in without the map scrolling.

For those who dont like the scroll so much, they can set it to the minimum: the LOS distance, while people like me can set it to the maximum: the distance from the player to the edge, so it always scrolls.

[Z]

I generally agree (I like the centerview and I think that scroll-when-close-to-edge was invented because the computers were too slow for centerview).

I think sidescrollers (platformers) use yet another system: the game is trying to center view on some point in front of the player (so that the player can see more of what is in front of him). But probably this would not work very well with roguelikes (even ones with facing).

I'm not quite sure which type of scrolling I prefer. It probably depends on how the maps look. Ideally, I prefer RLs that don't scroll at all, but that would be moot point to bring up now

I think that's a good point, actually. The standard screen size of 80x25 is enough for an interesting roguelike (ADOM plays very well in that size). Larger screens do not really provide that many new possibilities, but they provide some annoyance. Of course there are things which are impossible with 80x25.

I once had an idea about a cross between a roguelike and a shoot'em up: the dungeon is of screen width and of infinite height, and it is constantly scrolling upwards. The player has to be faster than the game is scrolling.

[AgingMinotaur]

I once had an idea about a cross between a roguelike and a shoot'em up: the dungeon is of screen width and of infinite height, and it is constantly scrolling upwards. The player has to be faster than the game is scrolling.

But still turn-based, you mean? So that the map scrolls eg. one tile every two turns? That sounds like it could be pretty nifty, actually.

As always,
Minotauros

[Rabiat]

I once had an idea about a cross between a roguelike and a shoot'em up: the dungeon is of screen width and of infinite height, and it is constantly scrolling upwards. The player has to be faster than the game is scrolling.

I thought of the same thing when I read about Eller's maze generation algorithm. Somehow the idea of getting squished between a moving wall and the bottom of the screen is both disturbing and fascinating (especially if some passages loop back enough to create the tension of having to escape from dead ends). Other than that I'm having trouble thinking of how such a game could be fun to play, or even fair. If someone can think of some simple, decent game mechanics, I'd be willing to try a 7DRL type implementation.

(Sorry for going entirely off-topic, btw.)

[Z]

But still turn-based, you mean? So that the map scrolls eg. one tile every two turns? That sounds like it could be pretty nifty, actually.

Both real-time and turn-based make sense, IMO. In my idea it was real-time (which is more shmup-like, and as shown by Jeff Lait's Jacob's Matrix, a roguelike with a real time limit could be fun). Anyway, it's just a general idea, feel free to implement it one way of another if you want to try it yourself.

[AquaTsar17]

Numeron's idea is exactly what I was looking for: something that could address both always scrolling and only occasionally scrolling. Now I just have to stop changing my lighting implementation and I'll have the main UI stuff done.

(Sorry for going entirely off-topic, btw.)

Hardly off-topic, auto-scrolling is still relevant to the discussion. I imagine it would have to be slow enough to still be playable though, so it's probably not a good thing to use for falling from the sky. Maybe falling down a hill or ramp though.

[BirdofPrey]

I've been thinking of my own scrolling scheme I wish to implement soonish... Eventually I'd like a scrolling smoothly animated screen that keeps up with you depending on how far you venture from the center, that automatically shifts the camera to a spot between you and all visible enemies, though you could move it yourself at any time by holding spacebar and moving it around with the direction keys. Tapping spacebar would center the camera.

What do you think of this setup? Any problems that I didn't think of?

[AquaTsar17]

What do you think of this setup? Any problems that I didn't think of?

How does the view scroll when there are enemies all around the player? I don't mean the player being surrounded (and thus can't really move), but when the player is moving towards a ranged enemy but there's other ranged enemies being him. Will the view just stay focused on the player in that case? That's really the only issue I can think of, though there may be others.