Jump to content

  • Log In with Google      Sign In   
  • Create Account

Valgor

Member Since 07 Oct 2012
Offline Last Active Nov 03 2012 01:10 PM

Posts I've Made

In Topic: Looking for a code/desgin review of continous map implemention

31 October 2012 - 04:52 PM

Thank you so much for taking the time to respond in so much detail! There is much to think on.

A player will never reach the edge of the world ( tile 0_0 at position 0,0) because the world will be one large island, or blocked by impassable mountains.

Using a camera rectrangle - I like this idea. I've thought about it before but figure that might be something to mess with later. QuadTree research and implemention was next in line after getting a continous map working.

When you say to store the tiles in a 2d array and/or have a TextureDB class, I just want to be clear you aren't suggesting we load all maps and textures into the memory? I'm loading maps from the harddrive as they are needed. I would toy with the idea of a buffer, but if the entire map is huge?

Thank you for the break down of my class and suggestions to the over all design!

In Topic: Looking for a code/desgin review of continous map implemention

31 October 2012 - 06:10 AM

Hello Valgor

I am working on the same thing as you, except I call my "tiles" "cells" instead, because the word "tile" is reserved for little blue and brown bricks that make up the world. What I do is I keep a 3x3 2d array. array[1][1] is the center cell, and the others are the neighbor cells. Every time the player changes to a new cell, all the surrounding 8 cells are loaded too.


Using the word "cell" does sound like a better idea! I started out with the idea you have, using the surrounding 8 cells, but I thought there would be too much over head updating and moving content around the data structure that holds the current world (in your case, an array). So if you move to the east, then you have to load three new cells and move 6 cells in your arrays. I wanted to smiplfy this, so I am assuming I will be using larger maps and will only need to update at max 4 cells ever.

In Topic: Looking for a code/desgin review of continous map implemention

31 October 2012 - 06:05 AM

Hold on, I'm not quite sure I understand how you're describing your maps...

Is it a tile based system, where you have a 100x100 grid of tiles, all rendered on the screen at once?
Or is it a system where each map grid is an area which fills up the entire screen (like old school Zelda) and you move in the cardinal directions to go to the next area?


Not like Zelda. The world is, say, a 100x100 grid of tiles. If you are in tile, say, 5_5 and within a boundry inside of that tile, then that is the only tile loaded. If you pass that inter boundry then neigboring tile are then loaded. Only a maximum of four tiles will ever be loaded. So if you are in 5_5 and move the northeast corner of that tile, then the following maps get loaded: 6_5 (east tile), 5_4 (north tile), and 6_4 (NE tile), and 5_5 is still loaded. Once you move into another tile and move within it's inter boundry, you can unload the older tiles, leaving only the current tile you are in in memory.

In Topic: Looking for a code/desgin review of continous map implemention

29 October 2012 - 08:47 AM

I'm not sure I understand the need for all the code about directions ... you could just figure out which tiles need to be loaded based on the player's current position in the map


Figuring out which tile to load is what the direction code is about. It's a book keeping system to see which one to load based on your current tile and also helps to let the program know where to render that tile on the screen.

In Topic: Looking for a code/desgin review of continous map implemention

28 October 2012 - 07:26 PM

For some reason there are no spaces between the boxes! It is a matrix transformed into another matrix. Written out:

[ N, NE, C, E, S, SE] ---> [ NW, N, W, C, SW, S]

Match this with what I have in the above post. Hope that makes sense.

PARTNERS