# Creating the “game space” for a 2D game

How does one setup the game space for a game so that obstacles can be spawned?

Examples would be ice climber or the iphone doodle jump. Tile maps are limited in size and would need to change often if the user jumps a lot.

How would this be done in another way than tile maps.

How or what is used to create the notion of a game world where these spawned ledges/obstacles are placed as the user progresses through the stage?

What is actually moving if the user jumps from ledge to ledge, what are the ledges based on in terms of the game world/space. What data structure or representation could the game use to reference and manage the spawning of these obstacles/ledges?

How is a continuous environment created which creates collision objects as the user progresses?

-
Are you talking about 2D or 3D or both? – Nate Mar 9 '11 at 23:13
I would like to know about 2d implementation – Helium3 Mar 9 '11 at 23:21

As far as my experience goes, there are two ways to implement a world space.

note: feature means an object with which your player may collide with. A feature can be a wall, a monster, a bullet...

Per unit of space Usually the choice for 2D games. You make a grid out of your world, where each square (or triangle, hexagon, or whatever you wish) can be as large as a tile, down to a single pixel (or even less if you want). A value in the grid determines how to act when the player collides with a given location (commonly 0 for no-collision and 1 for collision). Collision detection is O(1), and memory usage is O(w*h) where w and h are the width and height of your space respectively; regardless of whether or not there are features in it. Data structure is as simple as a 2-dimensional array.

Per feature Usually the choice for 3D games. You have a set of features, and collision detection is performed per-feature. There are interesting data structures, such as KD-trees, that help you determine which features are likely to be in a collision with the player, so you don't have to check it for every single object. Collision detection is non-trivial, and is O(n), for n features, and memory usage is O(n) as well. Data structure is a list, tree or dictionary that lets you do lookup by x,y,z location.

However, per-feature is also used in 2D (or pseudo 3D). Take for instance old shooters. Walls can be implemented as lists of line segments, which is a simple variant of the per-feature technique.

Dynamic feature placement is possible with both techniques. In the first technique, you simply modify your array during execution. Set an element in the grid from 0 to 1, and bam! you have a wall where you didn't before. In the second technique, just add a feature to your features list, and you're ready to go.

-
Thanks. I still have an issue understanding how to connect the back image which should appear to scroll, the users position(does it increase as the user moves up the screen) and the data structure. I get that the data structure is checked to find the relevant data for the player object. Im just not sure how to manage the player objects positions in a screen of nothingness. If there is a tilemap, there is something to work against. How are the positions of the player managed for just a screen? – Helium3 Mar 10 '11 at 3:49
@alJaree In my opinion, the easiest way to keep your sanity with this kind of problem is to completely separate your world logic, including collisions, from the display code. So, for your game, your player's position is an x,y pair (in world coordinates), and your space is a binary array the size of your entire world divided by the size of a single tile. Then, for drawing, a simple way is to keep your player in the center, so you simply draw from the player's location minus half the width of the screen for the x coordinate and half the height for the y coordinate. – slcpfmmm Mar 10 '11 at 4:11
+1 for a thoughtful O() analysis – Bill Mar 11 '11 at 2:48