Hi.
So, I'm developing new game.I have scrolling engine almost done, it can scroll in two ways(right and left).Everything nice and blah, blah, blah...
But in my game I want to make only 1 way scroll.Like SMB, only scroll in right.There's no technical problems.I just wonder if making a platform game that scrolls in 1 way only is a shame? What do you, guys, think about games like that? Any thoughts?
It's purely a design choice, so no shame in doing it. I doubt anybody is going to disagree with me.
I don't think it's that bad, just annoying when you miss an item and can't go back. What ever you want to do Denine, you're game.
It depends on a lot of things. If it's a game like Adventure Island where the goal is to move forward at a breakneck pace, then it's no problem. It's not a problem in a scrolling space shooter, or otherwise auto-scrolling levels.
If it's exactly like SMB, that might annoy some people, but if your game is properly designed around that limitation then it shouldn't be a problem. It might be looked down upon by some nesdev developers for not using the most advanced coding techniques to get around limitations like this, but guess what? You're doing this to make the kind of game you want to make, and if you succeed then you'll have made more progress than a lot of the people here!
So do whatever you feel like.
Chip & Dale Rescue Rangers was one-way scrolling, and I never saw anyone complaining about that part of the game.
Uh... Super Mario Bros (1) isn't a shame... is it?
I think designing a solid game is more important than one silly "feature" Any homebrewer who complains should either write their own better game or stfu.
There aren't much (completed and released) homebrew games with any scroll at all, so even one-way would be a major improvement.
Thanks, guys.I'll (try) don't give up:)
@Zepper
Of course SMB1 ins't a shame
Yeah, no problem with one-way scrolling here, either. Missing items is annoying, but as long as the design is good, such things can be blamed squarely on the player.
Chip & Dale Rescue Rangers is awesome, by the way. One of the few Disney games I've owned in my lifetime (apart from Kingdom Hearts, but KH just isn't as fun as Rescue Rangers).
I have to agree with everyone... As long as your game is designed for that kind of scroll, it's OK.
I personally prefer games where you can explore the level, go back and forth looking for things, rather than follow a straight line until the end, but both kinds can be fun if done right.
It's one of those things where you ask yourself, given the choice of going backwards, do I really go backwards that often? Depends on the game, of course.
A lot of Kirby's Adventure levels are quite linear and wouldn't suffer much from not being able to backtrack. In fact there are points in most levels where you actually can't backtrack, due to a star that warped you to your current screen, etc.
Now, some Kirby levels are maze-like and let you go all over the place looking for the exit, and that's fun too, but if those levels hadn't been present I don't think making it a one way game would've caused much uproar.
I don't like Chip&Dale NES games.
I love the Chip & Dale games! =) They are great in 2-player mode!
Sorry to not agree with everyone, but unless you have a really good reason for scrolling only one way, like memory constraints or something in the like, or if your game is a space shooter (which I don't think it is), you should allow backtracking.
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.
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.
Shiru wrote:
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.
Shiru wrote:
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.
Quote:
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.
Quote:
Uh... Super Mario Bros (1) isn't a shame... is it?
I'd play SMB3 over SMB1 any day personally.
Shiru wrote:
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.
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.
Bregalad wrote:
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.
Quote:
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.
Quote:
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.
Bregalad wrote:
Shiru wrote:
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?"
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...
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.
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.
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).
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.
tepples wrote:
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.
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.
Quote:
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.
Quote:
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.
Handling full 16-bit coordinates of objects is much easier than doing 9-bit math.
Who ever talked about 9-bit ?
I've always sad 8-bit was not enough for a screen, and that 16-bits were necessarly anyways to handle overflow and fine scrolling correctly.
As you said yourself if you use more than 8 you have to use 16 if you want to avoid extremely complicated operations, now it's up to anyone to use them as they want. I like have the middle 8-bits the pixels, so that the top 8-bits represent metatiles (up to 15 screens) and the low 4-bits the sub-pixel precision. If you use only 2 screens then it won't matter, any object outside $0000-$1FFF will be considered out of range.
Bregalad wrote:
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.
It's funny you mention this, because I do exactly what you're saying with the 2 screens. I have 1 visible screen, and then the two invisible halves on opposite sides. So I guess it still is possible. But then again, in my situation I won't go back and change anything because my metatile system happens to work quite nicely (and without a lot of complexity).
EDIT: Yay, happy 2000th post party for me.
I happen to like one-way, but game that can go both ways is also OK.