2D Top Down Tile/Map System Programming Question?

(Boardkeystown) #1

Hello,
currently tinkering around with a game and experimenting with things. I was wonder if anyone had concise information or tips that they could share with me about top down 2D game design. I noticed there is two camps when it comes to top down 2D games and 2D games in general for the arduboy.

So on hand you have games that use use a top down system similar to NSE legend of zelda where the player moves around the screen and (what I am going to refer to as) the render window updates a full area when you move out of screen bounds. Examples of Arduboy game that does this Ardynia.

Then you have the kind of top down system where the render window updates continuously similar to pokemon games. Example of Arduboy game that does this is Virus LQP79

What I am trying to figure out is how both work in terms of rendering and what their advantages/limitations are.

So the way I see it is that you create an array to hold your bitmaps and then render that array to the screen but in a way the will respectively display to the area on the screen. But then how do get that array that holds your bitmaps to update to represent different levels and such in a manner that feels continuous?

I know I figure it out eventually but maybe some of you experienced programmers can pass some wisdom on to me.

Thanks!

0 Likes

(Pharap) #2

I’m going to call the former approach the Zelda system and the latter approach the Virus system.
(Originally I was going to go for Pokemon system or Earthbound system for the latter, but Pokemon constrains the player to moving on tiles and Earthbound’s mechanics are slightly different - subtle but significant.)

Firstly I’d like to point out that both cases actually only use one area at a time,
so there are only two real differences between the two approaches:

  • How big the immediate area is
  • Consequently, how the camera behaves
    • On the Zelda system the player is free to roam around the screen because the area is exactly the size of the viewport
    • On the Virus system the camera follows the player

The Zelda system is a lot easier to work with from a programming perspective because the rendering calculations are less complex and you don’t have to worry about negative values, all coordinates are on-screen coordinates (in the (0, 0) to (123, 63) range, thus unsigned).

In contrast the Virus system is more complicated in terms of code complexity - you must factor in off-screen coordinates and draw the tiles at the correct offset, which can be a bit of a headache if you don’t already know how to do that.

Each approach has an impact on player experience.
A Zelda system can make the player feel constrained to a tiny area, but gives them more freedom of movement within that area.
A Virus system gives the player more freedom to roam the area.

I was going to say that the Zelda system uses less memory,
which would be true if the tiles are loaded into RAM.
However, on the Arduboy it’s more likely for tiles to be read from progmem,
so that aspect isn’t as important.
Regardless of which approach you take, the RAM usage will be from entities rather than tiles.

Memory would only be important if you needed to modify the tiles for some reason,
in which case the tiles would need to be loaded into RAM and then the Zelda system .
(An example of a game that does this is @Dreamer2345’s RogueBoy.)

So basically the two big deciding factors are code complexity and the feel of the gameplay.

Actually, the usual technique is to have is a grid of tile indices (each tile index identifies a tile type) and then the render function translates the tile type into the appropriate image.

E.g. using Sprites you’d pass a frame index derived from the tile type, like so:

In pretty much all games the maps have boundaries.
Having a single continuous map would be quite difficult.
You’d either have to:

  • Have one big map of tiles and designate abstract areas (e.g. rectanglar boundaries) that load more enemies when that area is entered
  • Have the map divided into various areas, load more than one area at a time and when you pass from one area to another, unload an old area and load in a new area

(When I say ‘load’ and ‘unload’, if you’re only storing tiles in progmem, that’s pretty much just a matter of changing some pointers around. If you’re storing tiles in RAM, that’s a mass copy of tile data from progmem to RAM.)


When it comes down to it, all the little details and decisions will depend entirely on what kind of game you’re trying to make.

2 Likes

(Boardkeystown) #3

Wow, that makes things much clearer to me thanks!

That example program is very useful. :grinning:

1 Like

(Pharap) #4

It’s also open source under Apache 2.0, so if you want to use any of it in your own code, modified or unmodified, then you’re free to do so as long as you include the copyright & licence notice and clearly state that you’ve modified it (if you’ve modified it).

Obviously the actual collision logic is for a side-scrolling platformer, but the render logic would work fine for a top-down game (the only real difference between the two are the physics and how the sprites look).

0 Likes

(Gavin Atkin) #5

You can also check out the code for Arduventure and play around with the World Editor for a large scrolling open world that is continuous. It’s kind of a combination of methods that definitely gets kind of confusing, but the results are satisfying.

1 Like

(Boardkeystown) #6

Thank you, I will definitively look at the source code for that one.

If you have the time could you look at my new post Procedural or OOP for games design paradigms on the Arduboy?

0 Likes

#7

I posted WIP of my next Topdown game up on github to help you. This one pans smoothly and I just figured out collision detection issue I had that I couldn’t solve. Hopefully it’ll help you out.

Looter3

2 Likes