Sign in to follow this  
Cerasti

Scrolling Transitions: The Superior Method?

Recommended Posts

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?

Share this post


Link to post
Share on other sites
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:)

Share this post


Link to post
Share on other sites
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).

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites


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

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this