Ok well I have been looking over everything and all the links given. And it is all over kill for what I want. All I want to do is detect if the next tile is a 2 or less. If it is a 3 I will not be able to move onto it. I figured it could read the map and find all the number 3's and make them unwakable but I can’t figure out how.
Take a look at this and I think it does what they were explaining above. The code is very general and shouldn't be used literally in a real game but the concept is what counts. Hope it helps.
[Edited by - evillive2 on December 3, 2004 8:06:48 PM]
i dunno if this is where ur comin from, but if u use another array, ul burn major memory when it comes to making large, open maps. my suggestion (and what im currently implementing), is to have specific tiles having certain properties. let me explain.
i have an offscreen buffer with 256 tiles on it. each tile has an associating element in an array of elements, of type tile, like so:
class Tile { public: bool UseScript;//not necessary, i could us a null script but this is faster char scriptID;// the script to use if ur usin a script bool walkable;// determines if this tile can be walked on bool slowWalk // contemplate this after reading the article };
Tile Tiles[256];
now, what we do is we keep track of two things, and know one:
A)track the players current position in pixels b)track the tile hes standing on c) the direction the player is heading in (mine is multiplayer, so it ties in with dead reackioning, and also the sprite engine)
d)know the characters sprite size (should be standardised for npcs & player too)
now, what we do is calculate the players position in pixels, this can be done simply by using the upper left hand corner of your screen as 0.0, then just increment this value when we move. then we can obtaintheir position by using an algorith such as this:
the brackets are used for clarification, and so is the divide (replace it with a bitshift).
now we know where the CENTER of the character is, this is important, because lets think about it:if we test our collision with the center, we will end up with our sprites halfway through walls. so what we do, is use a byte to calculate the direction the character is headed in. examine the pseudo code below:
#define NORTH 1 #define SOUTH 2 #define WEST 3 #define EAST 4
byte CharaterDirection;
calculate center X; calculate center Y;
if up button pressed == true { CharaterDirection = NORTH; }
then, when we move, adjust your front edge in that direction by adding half of your players sprite width. now, what we have is the leading edge of the character, and what direction hes heading in. now, when we move, we checkif this leading edge corresponds to the next tile in that direction (we should also check to see if by moving we will enter the next square, and adjust accordingly). if so, we check the next tiles walkable value, and if we cant walk on it, we dock our players movement to the edge of that tile, or else move.
This might sound cryptic (feel free to pm me if u need help), but its 4:56 am. im on my fifth cup of coffee, and im pretty buggered. it works, and with some snappy multithreading, u can make it work a charm. It also likns into various other elements of the game, and can be adapted to an object orientated approach. BTW, this is for free movement, not square based (i REALY hate that). i might make an article on this (with visula aids and less typos).
PS: my notation isnt normallly this sloppy, but u get the idea
The major issue I have with a lot of tile tutorials and articles is that the term "tile" is not clearly defined. This is not because the authors of the articles/tuts do not define them for the current project, it is that it can and will be different for each type of game. The first thing that needs to be determined in a tile based game (IMHO) is what is each individual tile accountable for? Lets take a look at a classic game like Fina Fantasy 1. There is a utility you can use called ffhackster that hacks a ROM of the game and gives you access to the data that makes up the game for you to view and modify. Since it is illegal to possess a ROM of a game you don't own, and hacking it even then falls under some obscure laws, I will tell you of my criminal activity and findings to save you from incriminating yourself(I do own the original by the way, best game ever!). From what I can piece together, there is a set of images that represent each type of terrain etc. The actual tile itself is made up of movement flags and what, if any, monsters you can fight, what fighting background to use and some other stuff. The tiles are referenced by id's in the tilemap so that the same image can appear over and over but may have different attributes set to it. The closest thing I can complare this to is the structure of an 8 bit bitmap. You have your pallet of rgb values in a bitmap, and ff1 has a pallet of tiles. Each pixel in the bitmap is an index number referencing pixel data from the pallet, so the tile in the tilemap is an index number referencing tile data from a pallet of tiles. Now, the big difference here is that tile data may consist of a lot more than just image data.
For my own game, I take this another step. I have a generic tile structure that holds an image id and some other attributes like movement flags, etc. I make a few generic tiles in an editor that fills the structure up so that I have a nice pallet of generic tile data to work with.
I had stopped here before and made my tilemap from references to these tiles but realized that my tilemaps were only as unique as however many generic tiles I made. This was frustrating. In any event, the solution I came up with works for me and looks something like this. I created a tile class that holds a reference to a generic tile structure and has similar attributes to the structure. Why would I do this? Well, the tilemap is an array of tile objects in my case, and since each tile has it's own set of values, each tile value can change and go back to normal after x event or y time is up. This is mostly helpful in the map file department because I have an array of tile index values to instatiate the map, then I only have to have entries for how certain tiles might differ. This saves the problem of 3 dimensional maps and wasted/unused space.
Like I said, this works for me and I imagine your method will work for you, but it helps to put a little more time into planning what a tile needs to know and do to make your game development much smoother. BTW, the hardest part of game devlopment for me so far has been generating content such as art, decent maps/areas/levels. I suck at those things and they bore the hell out of me but the pitfall is that you can't test anything without it. oh well.
Evillive2, i see where you are coming from, my method just works for speed, and if you have a multilayered maps, you can have a special transparent no walk tile, to allow for thsi kind of thing without having to "harden" specific tiles.
But i like ur method too, ijust suggest that by using some intelligent design in your maps these shortcomings can be worked around.
