Tiled world, walk off screen vs centered player

Casey talked about a tiled world, but will the player character be centered or do we go oldskool and walk off screen into new screen?

My preference would be centered player (maybe centered in bounding box that scrolls to centered when near the edge)

Thoughts?
I'd prefer something like LttP where there are "screen" boundaries but the boundaries aren't necessarily defined by the edges of the current view area.
So for dungeons it makes sense to have your screen centered on a particular room. For the overworld it may make sense to have continuously scrolling terrain.
Personally, I prefer continuously scrolling terrain with the player centered.

There may be some cases where this breaks down; for example when the player gets to a wall they should not be able to see past. I don't know whether that will be an issue with this game but hey, we might generate castles or some awesome top-level fortresses.
This is strictly personal preference, but we will be doing screens that you walk "off" and then switch to the next screen, like the original Legend of Zelda and Binding of Isaac.

The reason for this is mostly just because I like the old-school way of having a concrete notion of space that the player can easily understand and quickly correspond to a map. I find that it adds a layer of mental complexity to have differently sized regions with scrolling et al, and I would like to avoid that.

- Casey
Yeah I got that from the last stream.

Just hypothetical, if you'd do centered streaming, would you load the complete world/level in memory? And then render the visible portion?
Asset sizes are so big these days that for a 2D game, it's almost inconceivable that you would have to stream the world in. So in theory you would always have the world data available but you'd stream the assets so you'd never have a loading screen.

This is what we'll be doing for the non-scrolling version as well - I suspect it would probably be pretty easy for someone to turn the final HH code into a scrolling version if they wanted to, although there will be some stuff with scene compositing that they'll have to rework.

- Casey
Honestly, I don't see a benefit here. I guess if that's your preference, but it seems a little odd for the goals you set forth, like the idea of making things more complex intentionally to demonstrate the proper way of doing things. The screen-bound spaces are very simple.

I don't think it's very complex for players to understand, either. If the overworld were to be scrolling terrain, there wouldn't be individual "spaces" anymore. You could simply have the entire generated world open without borders. For a truly infinite world you'd have to generate as you went to avoid running into edges, but for a world that's simply massive enough to never be explored fully that wouldn't be an issue.

Another issue is that it limits game design and level design choices drastically. There is no way, with limited spaces, to have large structures in a way that isn't wonky. It puts a concrete size cap on any area or puzzle you'd want to design. And because it limits the variety of spaces you can design, everything starts to feel regurgitated after a while.

All that said, there have been many good games that have been designed this way. I'm just not sure it was intentional, for the most part, and not a product of limited hardware. I mean, would the original Zelda be any less of a good game if you could walk fluidly from one overworld area to the next instead of transitioning via "doors?"
The design is not up for discussion, so I'll refrain from commenting on that, but I would like to point out that this:

bpunsky
The screen-bound spaces are very simple.


is not correct. Whether game code is complex or not depends on what it is modeling and its performance constraints, and has nothing to do with how it is presented. Certain aspects of presentation can put certain requirements on parts of the game code, but whether they are more complex or not than something with a different type of presentation is often an entirely independent question.

I can personally guarantee you that our game code even as it pertains to the notion of individual screens will be vastly more complicated than most games that use scrolling.

- Casey
Thanks for clearifing all this. On the tilesize, don't you think that on modern resolutions the tiles would be huge if we only have 17x9? Maybe we'll see when we get some bitmaps in.

Maybe my question is, is a tile a single action item or can 1 tile have more than one thing going on? Maybe multiple enemies spawning or something.
Well, "tile" just means how we are conceptualizing what the terrain is functionally. There can be any number of things "on" a tile, certainly. So for us it's really just the "resolution at which we determine what the environment behavior will be".

So it's entirely a gameplay concept. Think of it as being the way the player understands whether they can cross a body of water, for example. If they have the "+1 boots of water walking" maybe they can walk across one tile of water, whereas if they have "+2 boots" they can walk across two tiles of water, etc. That is really all we're talking about when we say "tile". It doesn't even have any correspondence to the imagery that will illustrate the tiles, either, other than as a loose requirement that it must be clear to the player where the tile boundaries are and how large each tile is, etc.

- Casey
The fact that it's going to be tiled screens with no scrolling is a bit disappointing. At this point, I'm more interested in how the game is put together than the actual game/gameplay.
Well, scrolling is totally trivial, so, I'll make sure I have a flag somewhere that enables it just for you :)

- Casey
Will we be imitating Mega Man or Zelda where when you reach the edge of a screen, it pauses the action and the screen visibly "slides" over to the next screen?
I prefer instant switch, personally.

- Casey
cmuratori
I prefer instant switch, personally.

- Casey


Given your comment elsewhere about free scrolling being essentially disabled by a boolean, I'm guessing it won't be too hard to implement ourselves once the system is in place?

Edited by Andrew Chronister on