newbie: curses map in memory?

[Kannon]

I was wondering if anyone had any ideas on how I would represent the screen, independent of  it being drawn.
For example, right now for my simple curses wandering @ test, I'm using the characters on the screen to test. This likely would not work at all, were I to try to do anything interesting. (For example, for now there's no FOV or anything, just a wandering @ on an empty, fully lit map.)

So, it seems to me, the novice programmer, that I'd need some way to represent this in memory, then run the FOV, lighting, all of that fun stuff on it, and then display on the screen the appropriate stuff.

So, for now, it's

Code: [Select]

#####
#@..#
##.##
#...#
#####
Instead of:

Code: [Select]

#####
#@..#
##.##
  ..#
  ###

And as philosophically interesting as stuff not being there when you're not looking at it is, I don't think it'd make for a good roguelike. That, and pathfinding would be a bit.... difficult.

Or am I just looking at this completely wrong?

As I mentioned, I'm using python, and a newbie programmer, so complicated C stuff would probably go over my head with a rather impressive *whoosh*. I don't mean to be picky, but I don't want to frustrate people trying to help either.

[ywgdana]

To store the map in memory, I just used a list of lists.  Basically, each row of the map is a list of squares and the map as whole is a list of rows.  I store more than just the character, I created a class that will track (amongst other things) whether the square is passable or not, whether or not it is opaque (there are terrain types that are clear but cannot be passed though), and whether or not it is "open".  Ie., a square of water is clear, the player cannot pass through it but if you shoot or throw something, it will over the square.  A forcefield is clear but cannot be passed through and if you shoot at it, the bullet or arrow will stop as though it were a wall.

One thing I did waaay back at the start of my roguelike development was to have two separate grids: one for the map squares and one for the location information.  So the info about what items are on a square, what monster is standing on it, etc. is stored in a different grid than the map tiles.  This allows for a bit of memory savings, but I can't decide if the extra complication is worth it.

If you are using Python and you are a very new programmer, learn about lists and dictionaries; they are your dear friend.

[Slash]

If this is a basic roguelike, you can store cell type ids instead of their appearance, then you can check whether or not they are passable, opaque and their appearance in a separate data structure.

Alternatively, and for a more structured roguelike, you may use structs or classes to represent each cell. This has the advantage of allowing you to represent the appearance as an abstract property, amongst many other things.

[Gamer_2k4]

In the most minimal implementation, you'd have two arrays.  One would hold the tile character (#, ., +, etc.), and the other would hold a boolean value that says whether or not it's an obstruction.  As you move around, you update the second array based on whatever line of sight algorithm you used.  If the tile was made visible, display its character.  If not, display a blank space.

As you build up your game, you'll want to replace those primitives (char, boolean) with a single array of tile objects.  Each object will hold information such as the tile name, icon, color, etc.