Scrolling Transitions: The Superior Method?

Started by
3 comments, last by wodinoneeye 15 years, 9 months ago
So I've been thinking a bit about three different scrolling methods lately, which could apply to pretty much any genre featuring a world larger than the screen. Let's assume that you have quite a large virtual game world, in which the player controls a character which moves around it. You'd need some form of scrolling to be able to show the whole world to the player. The first method I'm thinking of is the more simple "screen-by-screen" way, meaning that the player only sees one area at a time, and when he/she touches the edge of the screen, the viewport is moved to another screen. This can be seen in
">Knytt. The second method I've found is a perfectly scrolling world which never drastically swaps from one screen to another but instead always has the player centered on the screen, like in real life. An obvious example would be World of Warcraft. No need to show a video for that, I guess. The last method is a combination, which means that many screens are combined into one big screen, and when the player is about to leave the big area, there camera swaps into the new place. Another example of this is
">Golden Sun. From the level designer's perspective, I'd say that the first one is easily the best one. It allows you to hide secrets much easier, since the player has a more limited vision than in the other scrolling methods, and it is also much easier to do transitions since the screens do not need to fit perfectly with each other. But I'd guess that the other ones are more appealing to the player, since the game doesn't become as "jumpy" as it would've been otherwise. What are your thoughts on these types of scrolling? Which do you prefer?
Advertisement
I'm actually using the last one in a project, it's harder than the first and easier than the second:)
I like that you can move without waiting every five seconds for a new area and that you don't have to program a very efficient engine:)
Let he who will move the world first move himself--Socrates
I use a highly modified version of your perfectly scrolling method. Basicly treating the camera like a special game object. This allows me to smoothly scroll over a big map (say 10 by 10 screens) and yet have a section within that map that the camera won't show until the proper time (say a 2 by 2 screen castle in the center of that map that the camera won't scroll over until the player obtains a key). And by makeing the camera scriptable it can do all sorts of things (scroll screen by screen NES Legend of Zelda style, quickly scroll over to show a door open then scroll back to the player, basicly allowing you to do most anything you want).
I think a motionless cemera has visual advantages. The gameplay can also feel more solid. Scrolling for every inch of movement causes the game perspective to be in flux 99% of the time.

This is true in 3D with third person and first person games as well. Compare Resident Evil with Hitman, or Virtual Cop with Doom. The 3D motionless camera comes with limits and restraints, though, inflicting serious handicaps on players. You couldn't see right in front of you with Resident Evil, and you couldn't control your perspective at all with Virtual Cop.

For my own (3D third person) shooter, I've implemented a cursor mode. The player can press a key to switch from camera-aim mode to cursor-aim mode. They can still move around, and the camera will follow, but it won't rotate to look or aim. You wouldn't believe how much easier it is to aim when the entire world doesn't transit for every inch you shift your gun. It's also much more realistic; you don't need to rotate your head or vision to shoot at different trajectories. But it has its problems. Most notably, it's clumsy having to switch back and forth between modes in order to look more up/down/behind to shoot.


Of course theres also the 3D games where the direction you are looking require large distances to be visible (and if you can turn quickly then you have to have that worls content immediately available 360 degrees around.

LOD (level of detail) mechanisms can be emplyed to minimize the data that is required at distances where less detail can be distinguished.

The 'window' area on the world might be quite large if you want to simulate seeing to the horizon. Tricks like hazing with distance can help.

The chunk size may be decided by other factors (like disk loading performance) where loading many small chunks (ie- rows of tiles) wastes too much overhead but too large chunks loads more data which often doesnt get used (remains outside the view window when the player never goes far into the 'chunk').



In the system Im building the chunk/zones are also loaded into the server in a similar window pattern as the player moves. It has a very large world with alot of dynamic interactive content which executes changes with time in an abstract simulation, but then gets expanded into its full detail when the player comes close enough to see/interact. All the behavior scripting/object data for active objects is loaded in the server as part of the zone/chunk.
3 different levels of LOD are used to limit the furthest distances (7 zones out) to simplified terrain and an intermediate level (3-4 zones out) where large objects and full detail terrain is shown and then close range where all detail is available (2 zones out - a 5x5 window around the player). There has to be enough data preloaded so that the shift between LODs isnt too obvious
--------------------------------------------[size="1"]Ratings are Opinion, not Fact

This topic is closed to new replies.

Advertisement