One way scrolling game == shame?

[Shiru]

I think the question should be defined differently, 'is there a reason for backtracking'. If it is not adds anything (or much) to gameplay, it is not needed.

In a game with one-axis scrolling a reason for backtracking could be inertia, when you need to take a run to perform long jump. It was a (minor) problem in SMB, and major problem in Kid Kool.

[thefox]

I think the question should be defined differently, 'is there a reason for backtracking'. If it is not adds anything (or much) to gameplay, it is not needed.

Also having no backtracking is a gameplay element by itself. For example, in the beginning of 1-1 in SMB1 there's a spot where you can either go down a pipe or get a hidden 1-UP or do both if you're careful (to not have the screen scroll past the pipe). In that sense, the limitation contributes to the gameplay.

[Bregalad]

I think the question should be defined differently, 'is there a reason for backtracking'. If it is not adds anything (or much) to gameplay, it is not needed.

I disagree. On the other side, the question should be "is there a reason for not allowing backtracking ?". If the answer is no, then please implement backtracking.

Also having no backtracking is a gameplay element by itself. For example, in the beginning of 1-1 in SMB1 there's a spot where you can either go down a pipe or get a hidden 1-UP or do both if you're careful (to not have the screen scroll past the pipe). In that sense, the limitation contributes to the gameplay.

Nobody will ever know if this was really intentional or not.

Uh... Super Mario Bros (1) isn't a shame... is it?

I'd play SMB3 over SMB1 any day personally.

[tepples]

In a game with one-axis scrolling a reason for backtracking could be inertia, when you need to take a run to perform long jump. It was a (minor) problem in SMB, and major problem in Kid Kool.

The inertia problem can be handled with limited backtracking, where the camera can move up to one screen back from its farthest point. This would allow unidirectional level encoding under vertical mirroring yet give the player a screen and a half to go back and build momentum. SMB Deluxe for Game Boy Color uses something like this to a lesser extent because the game is designed for a 256px wide screen, but the Game Boy Color's screen is 160px wide.

[Zepper]

Perhaps SMB1 mechanics were designed much like a shooter game. For 1985, well, the player would play by running Mario & scoring points, no way worried about getting items, but running against the time left. When SMB3 was released, I suppose the same player now had the ability *to explore* a level, rather than just scoring points + running against the time.

That's me, of course.

[Denine]

Now if there is any good reason to not allow backtracking exept your own laziness, then I'm all fine with it. But if there is no reason, I guess it's best to implement it.

Actually there's 2 reasons:
More important: I wanted it to be one way scroll only.
Less important:I'm not sure if I can handle loading objects in both ways.

In a game with one-axis scrolling a reason for backtracking could be inertia, when you need to take a run to perform long jump. It was a (minor) problem in SMB, and major problem in Kid Kool.

No, game is supposed to be very simple.only 5 collectible types, and few enemies types.Also you can't run, so this will not be a problem.

The inertia problem can be handled with limited backtracking

This may be a good solution.

For now I'll stick with one way scroll, and eventually add limited backtracking if levels will require it.Thanks everyone for input.

[UncleSporky]

I think the question should be defined differently, 'is there a reason for backtracking'. If it is not adds anything (or much) to gameplay, it is not needed.

I disagree. On the other side, the question should be "is there a reason for not allowing backtracking ?". If the answer is no, then please implement backtracking.

The answer is never no. There is always a reason not to implement backtracking: because it's easier to program. So many fewer variables to worry about, you've only got to deal with the screen you're on and forget about what came before, etc.

The gameplay reasons have to outweigh the programming reasons. That's why the question is always phrased the other way around - is this really worth my time and effort?

And the answer to that becomes more difficult as systems become older and new games will be played by fewer people. It's less of "will people enjoy this mechanic" because you know not a lot of people will even be playing it, so the question becomes "do I need to impress the small NES community with my fancy coding?"

Or perhaps as evidenced in this thread, "do I need to impress Bregalad, since most people don't seem to care?"

[Bregalad]

No this is wrong, in fact I don't think it's impressive at all to scroll in 2 ways. I don't even thing it's hard to implement (as opposed to 4 way scrolling), but anyways I really don't care.

Just see the recent AVGN episode "Kid Kool" to see his opinion about 1 way scrolling...

[tokumaru]

I kinda disagree with the whole programming complexity talk. Even 4-way (or 8-way, or whatever) scrolling isn't significantly hard to implement (heh, I have rewritten my engine so many times that I can probably write down a whole scrolling engine on paper in a couple of hours!). I think that many other aspects of game programming are more complex than the scrolling.

[GradualGames]

I was originally going to have Nomolos be a 1 way scroller. The main reason I was going to do this was to constrain the project, and make it easier to get done. However, to upgrade to 2 way scrolling wasn't that hard, and did not significantly change the overall complexity of the project. The levels are still horizontal, 1 or 2 way scrolling doesn't change that. If I went to 4 way, that can square the amount of time needed to design levels!

Upgrading to 2 way introduced a lot of interesting problems with regard to enemy and item lifetimes, but these were not insurmountable. But I personally think it is wise to start out with as simple a project as you can, to ensure that you get it done and can release it. There's always the future for something more ambitious, and if you have a lot of completed projects under your belt it will give you a lot of confidence.

So no, I don't think there's any shame in 1 way scrolling. Any type of movement around in a game creates a unique feeling or atmosphere. I don't consider any of these better than the other with regard to gameplay value. Of course on the technical side, some are more challenging than others. But players don't give a crap about that, they want a fun, challenging game.

[Celius]

Depending on how your levels are stored, it may be harder to code backtracking.

I remember in an earlier system of coding levels, my level backgrounds were simply a list of objects stored in order of left to right. When you reach a certain point, a new object comes into range, and then the game decided to start drawing that object from the top-left coordinates specified. Now if that object is 100 pixels wide or something, it creates a problem for trying to move the opposite direction, because the map only stores the object's top left coordinates. When the top-left coordinates come into range, the rest of that object will have already been in range by 100 pixels. So you would have that nice little pop-up effect as a result.

Though to counter this, I decided to come up with a less complicated way of storing levels where everything is compressed into 8x2 metatiles. This way I don't have any of those problems, and I now scroll left and right.

SMB1 is great, though I will say the scrolling limitation is one thing I remember being frustrating. I think overall most gamers prefer the freedom to scroll both directions, but it doesn't kill your game to only scroll 1 way (as is evident by SMB1's success).

[tepples]

Two-way scrolling is possible even with a SMB1/SMB3/SMW style sorted object list, and even without rendering the whole map to WRAM. The code to render a column of metatiles scans the object list and draws the part of each object that overlaps the column.

[tokumaru]

The code to render a column of metatiles scans the object list and draws the part of each object that overlaps the column.

I do this for the few background objects I have, but my maps are still metatile-based. When these objects are processed, they check if there's a row/column update scheduled for the next frame and whether it overlaps the row/column, in which case they overwrite the tile/attribute buffers with their own data.

[GradualGames]

One interesting consequence of upgrading to 2 way scrolling is there are certain configurations of platforms, which could "guide" the player to move a fair distance horizontally (in other words, forced to backtrack), which would be impossible to put in a 1 way scroller because they could get walled off by the leftmost side of the screen.

[Bregalad]

When you reach a certain point, a new object comes into range, and then the game decided to start drawing that object from the top-left coordinates specified.

Top-left hotpoint was your choice.
In my engine I have no idea why but I chose center point, for me it was just what made the most sense !
So if you'd chose center as I, the "poping" problem would happen, but be half of what you mention and happen in both directions. Now if you handle say 2 screens at a time, with 1/2 invisible screens on the left and right and a completely visible screen, this problem will be completely solved.

I do this for the few background objects I have, but my maps are still metatile-based. When these objects are processed, they check if there's a row/column update scheduled for the next frame and whether it overlaps the row/column, in which case they overwrite the tile/attribute buffers with their own data.

Wow ! I guess I failed like 3 times doing it and gave up for now as none of my projects needs this. If you ever write a tutorial, even in bad english, I'm your man.