Hello everyone, i want to know the programming tricks of endless 2d sidescroller game like z.tsunami, whale trail, jetpack joyride.
In supermario, the whole world is loaded and display only what the monitor can occupy. But in 2d endless games, you cant load the whole world because its endless. LOL. so my question is, how do i display the world?
when i leave the part that is not displayed on the screen, is it needed to display?
I need only the concept, not the code.
Im currently working on android game development using OpenGL.
What is the programming tricks of 2D endless sidescroller game?
Author
Split the world into pieces. Only load and draw the pieces that the player can see. If the game uses random generation, generate each piece on the fly at runtime when the player starts getting close to that piece of the world. Otherwise, randomly pick from a set of pre-created pieces.
For games that only scroll to the right and never let you go backwards, you can delete anything that goes off the left side of the screen.
For games that only scroll to the right and never let you go backwards, you can delete anything that goes off the left side of the screen.
Author
Ah, nice. thankssssssssss. So i will build many pieces and use random generator to pick those. Whatever it picks i will load it to the screen, whatever pieces that leaves the screen i will delete it. THanks for clarifying. Gamedev is such a nice place to ask questions. A 100times thanks to you.
Split the world into pieces. Only load and draw the pieces that the player can see. If the game uses random generation, generate each piece on the fly at runtime when the player starts getting close to that piece of the world. Otherwise, randomly pick from a set of pre-created pieces.
For games that only scroll to the right and never let you go backwards, you can delete anything that goes off the left side of the screen.
or better yet, rewrite and reuse anything that goes off the left side. (you can pretty much eliminate reallocation if you know the maximum size of a block.
For Android using the normal SDK (Java) it is fairly essential to minimize garbage since the GC can be quite annoying otherwise.
Author
that went to my head too. I found out that trick too in youtube. thanks for the reply
More than likely tiles. The image can be a large atlas which just contains all the image tiles for one level. Then when you render different tiles, you just render only a portion of the atlas image that represent that one tile. This may increase your performance from avoiding constant texture change bindings every time you render a single tile.
Most side-scrollers, A.K.A.'platformers' use repeatable objects that show up everywhere such as a stone block that is repeated along the ground to form the base plane which the character moves along.
You don't want to continuously delete and reload these objects. You want to prevent them from being drawn when they are out of view.
The 'chunks' method is good for preventing a distance check on every object which would require a lot of CPU time.
To implement this, you only need to supply the player position to an if() statement that encompass the draw calls for every chunk.
Here's the code that said you don't want, for each chuck you would have something like this
if (playerPosition >= -10.0 && playerPosition <= 10.0)
{
#include "levelChunks/chunk_5.c" //as best as you can, put everything for drawing and collision here.
}
That chunk will only be processed when the character is between -10.0 and 10.0. Aside from this it will be ignored.
If the level is 5000 chunks wide, then all of these if() statements will now start to add up in CPU time, in this case you'd want to test for chunks of chunks.
You can also scale the 10.0 and -10.0 values if you want to zoom in and out.
Split the world into pieces. Only load and draw the pieces that the player can see. If the game uses random generation, generate each piece on the fly at runtime when the player starts getting close to that piece of the world. Otherwise, randomly pick from a set of pre-created pieces.
For games that only scroll to the right and never let you go backwards, you can delete anything that goes off the left side of the screen.
I wonder if there are any pseudo-random number generators that can run backwards, so you could reconstruct those pieces if the player walks back.
Split the world into pieces. Only load and draw the pieces that the player can see. If the game uses random generation, generate each piece on the fly at runtime when the player starts getting close to that piece of the world. Otherwise, randomly pick from a set of pre-created pieces.
For games that only scroll to the right and never let you go backwards, you can delete anything that goes off the left side of the screen.
I wonder if there are any pseudo-random number generators that can run backwards, so you could reconstruct those pieces if the player walks back.
When you construct/pick a chunk, you could store a seed (or something like a seed) that lets you recreate the chunk the same way each time. If you can instantiate multiple random number generators, you can use one RNG to generate a per-piece seed integer. Store those seeds for the rest of the game session, and use them to initialize piece-specific random number generators to fully reconstruct a piece any time you want to bring that piece back into existence.
Depending on the RNG implementation, the extra overhead shouldn't be too bad.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
