Alright... right now, a friend and I are beginning development on our first DirectX/Windows game. We are using Microsoft Visual C++ 4.0 (it came with some silly game construction kit I bought, so be quiet :]), and DirectX 5.0 SDK through a modified GPDUMB engine that came with Windows Game Programming for Dummies by Mr. LaMothe (it''s a very cool engine... helps make things a lot easier). And don''t worry, I do understand directX, I''m just using this engine to make things simpler, especially in terms of all the initialization/shutdown things that I don''t want to deal with. Anyway, the first thing that needs to be created in the game will be a the editor. This will allow us, and anybody else that wants to, to create tile-based levels, and then put then smash all the levels together into an episode (so that the levels will run in order, one after another). I''ve decided on a foramt in which we will store the files... we will store them in ascii text format, where each row will have represent one tile (so we''ll have a BUNCH of rows), and something like: "D 1 22" which would say to the game upon loading: "that tile is a door that goes up, and activated by a corresponding button which will have the target "22". Thus, I had posted asking about windows dealing with input/output :] Well, seeing as the board will be the basis of our game, I''ve been thinking about how we should store and access it... I''ve come up with a few ideas: A) Have a maximum number of each type of tile, and have up to that maximum stored in an array of file structures with the information (so that door[x] would have the information: x, y, direction, etc.). The only problem I see with this, is that while it is easier to understand and implement, every time a person moved, the game would have to do massive amounts of iterated loops checking which tile(s) would have the matching x and y coordinates. B) Have tile data structures, which are held in a two-dimensional array (for x and y), each which will contain massive amounts of properties, as well as the type of piece. Then I would only need to do massive amounts of loops for checking which door/lift would match up to the button that was just pressed. ... there were also some ideas I had originally about having each tile point to a one of a dynamic array of a specific type of tile held on the heap. I think in the end, though, any idea like that would end up becoming far to difficult to handle. Well, these are just some thoughts, and I''m sure there are many people here that have a LOT more experience with tile-based game engines than I, so I''d like your input... thanks! :] - Goblin "A woodchuck would chuck as much wood as a woodchuck could if a woodchuck could chuck wood. Deal."

You could do something like type B but with pointers to the tile data. That way the map size stays small and any duplicate tiles only have to have one thing kept in memory. And at the begining you could go through the level and all the tiles that have buttons you could set a pointer to the door they activate.

Then while the game is runnning you just use the pointer.

These are example classes sorta

Map
{
Tile[X][Y]; //basically a 2d array of 2 ptrs small
TileData[]; //list of tile types if any duplicates
//just include once
//these two will be about the same size but possibly smaller
// if a lot of duplicate tile types

Button[]; //list of buttons
}

Tile
{
TileDataPtr* //pointer to the tiles type in the map
ButtonPtr* //ptr to the button in map
}

Button
{
ButtonObjectPtr* //object that needs to have action taken on
}