Need info about invisible encounter areas

[OldFangle]

Hi

A few games I've played have invisible encounter areas until the player's sprite moves into the area. Encounter area squares then become visible around him.
I can't find information pointing to how to write code to do that. I'm using keywords like 'visible', 'invisible', 'encounter area', 'display squares' and so on, but I'm swamped with hits in the search engine for other topics.
Can you point me to tutorials on this subject?
Thanks

[keskiverto]

http://en.wikipedia.org/wiki/Fog_of_war#Simulations_and_games

[OldFangle]

Hi keskiverto

Yes, that's along the lines of what I'm talking about but in my case I'm interested in learning how terrain is kept invisible until the player's piece moves into that territory. The terrain becomes visible in the immediate area around player's piece as player explores that area.
I've always wondered how that's done. A terrain editor probably draws the territory and maybe it's within the terrain editor that some areas are coded to be invisible until they're explored? Or it's code in something like C++ which determines what areas are made visible..?

Thanks

[Disch]

There's no magic to this... you just have to write the code for it.

Your program is in control of what is being drawn on screen.
Your program also has knowledge of where the player is.

So, for example, if you only want the player to be able to see areas that are within 2 spaces of him... then when you draw the map, only draw spaces that are within 2 spaces of wherever the player is.

[OldFangle]

Hey Disch

Would I somehow number areas on the game terrain so that the code can identify those areas? I've just never seen any tutorials on how this is done. There are several games which only bring portions of the map into view once the player has explored them and I've wondered how it's done since the map that comes into view doesn't appear rectangle-by-rectangle, it's done smoothly.
What tutorials have you read on the subject?

Thanks

[Disch]

Would I somehow number areas on the game terrain so that the code can identify those areas?

You don't usually need anything to identify it other than its coordinates.

If you have a basic 2D grid with rectangular tiles, each tile is going to have an X and Y position. Those positions can be your "ID". The positions don't even have to part of the tile data itself... you can simply use the index in its array.

Here's a sloppy example.

I use a 1D vector to simulate a 2D array because the multidimensional arrays are horrendous, IMO.

class Map
{
private:
    int width;   // the dims of the map
    int height;
    std::vector<Tile*>  themap;  // the actual map
    //  simulate a 2D vector in row-major (ie:  "read like a book") order.
    //    so if you have a width of 10 tiles, themap[0] - themap[9] is the first row,
    //    themap[10] - themap[19] is the second row, etc.

public:
    //  get a tile at a current X,Y position:
    Tile& getTile(int x, int y)
    {
        return *(themap[ (y*width) + x ]);
    }

    //...
};

So now when you draw the screen, you can just loop through your map tiles and draw them:

for(int y = 0; y < visibleheight; ++y)
{
    for(int x = 0; x < visiblewidth; ++x)
    {
        map.getTile(x,y).draw(screen, x*tilewidth, y*tilewidth);
    }
}

Here I'm drawing tiles unconditionally. If you only want to draw what's within the user's field of view, then you'll have to throw some if's in there to check the tile to see if you want it to be drawn or not before actually drawing it.

I've just never seen any tutorials on how this is done.

There aren't tutorials for a lot of things. Once you get better at understanding programming concepts, you should be able to figure out how to do this stuff on your own. Like I said there's no trick to it... it's just coming up with the logic for it and putting that logic into code.

I've wondered how it's done since the map that comes into view doesn't appear rectangle-by-rectangle, it's done smoothly.

You can draw tiles anywhere. You do not have to draw them on tile boundaries.

Scrolling can be accomplished by moving a "camera" around. When you draw, everything you draw on screen would be offset by the camera's position.

IE, instead of drawing an object at position (x,y), you'd draw it at (x-camerax, y-cameray). That way all you have to do to scroll the screen is move the camera and redraw.

Of course even that isn't necessary in a lot of modern APIs because this concept is built in. IE, in OpenGL/D3D you would just work the camera position into your translation matrixes. In SFML you'd set up a 'View' which is basically the same idea as a camera. Etc.

[OldFangle]

Hi Disch

Thank you very much for all of that.

I'm putting that into a how-to.txt which I'll keep reading until I grow into it.

Cheers