[Question] 2D Tiled "on map" house

[koolgraph]

Hello folks,

I don't know if there's a word for this so I'm gonna explain =D

Like the title says, I'm working on a 2D tiled game and i want all the shops/houses/buildings to be "on map". By "on map" i mean there's no need to warp 'em to another map to enter the shop for example.Sure there's lots of way to do it but i was wondering if u guys got any idea to do it, not only in an fast/good way but in an useful way too. I mean should i go with a TileAttribute and with some sort of algo determine which one to not draw when I'm in, or maybe a kind of MapEntitys with a list of every pack of dynamic tiles ? How would you do it ? Have you got any other idea ?

[mattheweston]

It sounds to me like you are trying to do something similar to the old NES Dragon Warrior. When you were in a town, you could walk into a shop or "inn" and the game wouldn't usually load anything new. Unlike the Final Fantasy series(nes, snes).
Now there were times when you would "walk into" a shop and the roof was removed to reveal the inside while you were there.

I can think of a few ways to do this. You could add a layer to your map and use that as your "room" or "shop" layer. Or you could set an attribute on your tile class. It really depends upon what your preference is.

Hopefully this points you in the right direction.

[koolgraph]

Yup, the only problem if i just add a layer is... if there's more than a shop on the same map, it'll uncover all of them. And to use a tile attribute... i can't find a nice way to do it without using the same method as A* (Seek for every tile around, if the attribute is on this tile, then add him to a list so u wont draw it and u wont have to recalculate it).
That's why i thought about a list of object and this object is a list of tiles (with position etc.) so i could do like... .Visible = false

Well the more i think about it, the more i find it's a good and viable option to do, but i still want your opinion, what you guys think about it. Let's discuss god dammit XD

[mattheweston]

pardon my ignorance, but it sounds like you want to step on a tile and then reveal the "shop" by setting an attribute (visible = true) then when you leave the "shop" you set the attribute (visible = false). What is the difference between that and having a teleport or warp to another "map" ?

Based on my understanding of tile maps, I feel like teleporting/warping is the way this is usually handled. Is there a reason why you are wanting to not do the teleport or warp to a new map?

[koolgraph]

No it's the opposite, i was talking about getting the roof on that list and put in Visible = false when i enter the shop. And i don't want to do the teleportation thing, first 'cause it's gonna give some more experience since i've never done that, and second 'cause i've always found it cool and so i want to do it

[dandymcgee]

Yup, the only problem if i just add a layer is... if there's more than a shop on the same map, it'll uncover all of them.

So don't uncover all of them. Determine which house/shop the player is standing in, and only fade out those roof tiles.

[Falco Girgis]

What the fuck, guys? It's so simple.

Just put the areas/houses far enough away on the map with black/empty tiles in between them that you can't see any other rooms. That's how almost every 2D tile-based RPG handles it. When you "warp," you're just moving the character to a different map location without having to reload anything.

edit: Owait. So yeah, do you want it like Dragon Quest where the roof stops being rendered/pops off to reveal the insides, or do you want the typical warp approach where you're "moved" to the inside of the building (on the same map)?

[koolgraph]

Wow Gyro, that's a pretty nice solution, the thing is the blank tile in between would consume memory so it's not really efficient, but either way I'd prefer the Dragon Quest like system.

[superLED]

Doesn't sound like a problem at all.

Does this idea work for you?

Code: Select all

class Roof : public Graphics {
public:
	int getX();
	int getY();
	int getW();
	int getH();

	void setPosition(int, int, int, int);

private:
	int x, y, w, h;
	bool visible;
}

int Roof::getX() {
	return x;
}
int Roof::getY() {
	return y;
}
int Roof::getW() {
	return w;
}
int Roof::getH() {
	return h;
}
void Roof::setPosition(int _x, int _y, int _w, int _h) {
	x = _x;
	y = _y;
	w = _w;
	h = _h;
}


const int numOfRoofs = 10;
Roof roofs[numOfRoofs];

// Setting up the position of the roofs
roofs[0].setPosition(10, 10, 20, 20);
/*
and the rest of the roofs...
*/

/*
drawing stuff
*/

// Drawing the roofs
for(int i = 0; i < numOfRoofs; i++) {
	//If the player is touching the roof...
	if(player.getX() + player.getW() > Roofs[i].getX() &&
	player.getX() < Roofs[i].getX() + Roofs[i].getX() &&
	player.getY() + player.getH() > Roofs[i].getY() &&
	player.getY() < Roofs[i].getY + Roofs[i].getH) {
		// The player is inside, don't draw the roof
	} else {
		// The player is not inside, so draw the roof
		Roofs[i].draw();
	}
}

/*
Drawing some other stuff...
*/

You can use a struct instead of a class. I just used a class because... Well, I don't know.

[koolgraph]

That was almost the thing i imagined, except it was not just for roofs but for everything. Still i feel better now that i know it wasn't that dumb XD

[szdarkhack]

This is just a suggestion since i don't know how your tile engine is structured, but here goes:

My idea would require a "flags" field and an "id" field for every tile. Your character should get (and store) the id of the tile it's stepping on every time it moves. You should set the "id" field of outdoors tiles to 0, and for indoors tiles set it to a unique id for each building (e.x. all the tiles of the 1st building should have this set to, say, 1, all tiles of the 2nd building to 2 etc). Set the same id for the roof tiles, but also set a flag to indicate they are parts of the roof.

When you render your quads, check to see if you're rendering a roof tile, and if you are check if it's id matches the character's stored "ground" id. If it does, don't render it.

So, in pseudo code:

foreach (tile in map.visibleTiles)
{
if (!(tile.flags == FLAG_ROOF && tile.id == myChar.groundID)) // note the ! (not)
{
// render current tile
}
}

Of course this is just one way of doing it, and you can easily optimize this code. If you use vertex arrays though, you would have to store each roof in a separate one and disable the whole thing. Anyway, just an idea, i hope it helps a bit

(The edits were for fixing some typos)

[k1net1k]

No it's the opposite, i was talking about getting the roof on that list and put in Visible = false when i enter the shop. And i don't want to do the teleportation thing, first 'cause it's gonna give some more experience since i've never done that, and second 'cause i've always found it cool and so i want to do it

I would say you really only have one option :

If you are making a tile system consisting of Cat, Rats, Scary Monsters and Nice Sprites with your friends Alejandro and seventeen others, you certainly have several render technology options at your disposal. The best rendering method is SSS (Slats Slats Slats), but it can often make your spaghetti code jump out and say "this is a shark attack" to anyone with any degree of engine development experience. This is certainly the hardest way to do it, but yields the best results. Others key figures in the game development industry have also spoken out against RPG style tile maps, and to quote the great Father (John Carmack) "No Mercy, Only Violence !" - And we all know that guy is a Golden Mummy's boy

The other option is to skip all of this and just go "in for the kill" (so to speak). However if you choose this anti-alising method you will need to scream and shout as if this was a drop dead tune, in order to convince your artists that it was worth it even if it takes a little longer. The assumption is that most key people in your team will be against the LDM (Long Drive Method), but whilst maintaining good code syntax can be bitter, it still tastes like a good beer, sensual seduction with your lustbug of a girlfriend, or any other make things for smile once you complete the project. That part is really up to you to decide how you celebrate the completion of your game - Audiosurf.

All I ask of you is that you try your hardest to make this game suitable for all age groups 13+. We dont need any more idiots on the Elysian Shadows forums posting "Daddy said i cant make games with your friends". People who continue to belittle you for your (mildly inefficient) database structure can only be described as "all american rejects"

Always remember my personal motto : "Rock n Roll will take you to the mountains, but if you want to get to the ocean you should expect people waiting there on your arrival" Some of these haters will post on the forums things such as "This is a shark attack" or "Fucking Die". I can only suggest you dont take these comments too harshly and wait until weekends where you can tell your true friends " MY NAME IS SKRILLEX !!!" and laugh in the face of danger when your game goes platinum on Steam.

[M_D_K]

No it's the opposite, i was talking about getting the roof on that list and put in Visible = false when i enter the shop. And i don't want to do the teleportation thing, first 'cause it's gonna give some more experience since i've never done that, and second 'cause i've always found it cool and so i want to do it

I would say you really only have one option :

If you are making a tile system consisting of Cat, Rats, Scary Monsters and Nice Sprites with your friends Alejandro and seventeen others, you certainly have several render technology options at your disposal. The best rendering method is SSS (Slats Slats Slats), but it can often make your spaghetti code jump out and say "this is a shark attack" to anyone with any degree of engine development experience. This is certainly the hardest way to do it, but yields the best results. Others key figures in the game development industry have also spoken out against RPG style tile maps, and to quote the great Father (John Carmack) "No Mercy, Only Violence !" - And we all know that guy is a Golden Mummy's boy

The other option is to skip all of this and just go "in for the kill" (so to speak). However if you choose this anti-alising method you will need to scream and shout as if this was a drop dead tune, in order to convince your artists that it was worth it even if it takes a little longer. The assumption is that most key people in your team will be against the LDM (Long Drive Method), but whilst maintaining good code syntax can be bitter, it still tastes like a good beer, sensual seduction with your lustbug of a girlfriend, or any other make things for smile once you complete the project. That part is really up to you to decide how you celebrate the completion of your game - Audiosurf.

All I ask of you is that you try your hardest to make this game suitable for all age groups 13+. We dont need any more idiots on the Elysian Shadows forums posting "Daddy said i cant make games with your friends". People who continue to belittle you for your (mildly inefficient) database structure can only be described as "all american rejects"

Always remember my personal motto : "Rock n Roll will take you to the mountains, but if you want to get to the ocean you should expect people waiting there on your arrival" Some of these haters will post on the forums things such as "This is a shark attack" or "Fucking Die". I can only suggest you dont take these comments too harshly and wait until weekends where you can tell your true friends " MY NAME IS SKRILLEX !!!" and laugh in the face of danger when your game goes platinum on Steam.

wtf

[Falco Girgis]

Wow Gyro, that's a pretty nice solution, the thing is the blank tile in between would consume memory so it's not really efficient, but either way I'd prefer the Dragon Quest like system.

Actually, that's not true.

Think about it. How would you otherwise keep track of layers? Either an entire second array THAT IS THE SIZE OF THE ENTIRE MAP, or adding a flag to EVERY MAP LOCATION for its layer. Either way, the size increase will be the size of your entire map * your datatype.

And the other solutions using separate arrays/lists representing roofs are MUCH MUCH worse. Not only are you allocating additional memory for every roof (as opposed to a static map), but now you have to iterate through your list every frame O(N) and determine which should be rendered. Or you'd have to write some sort of BSP/scenegraph algorithm to lower that to O(logn). So with these approaches, you're wasting memory AND processing time.

Not to mention storing each room as a separate map file that requires an HDD read every room swap is going to be waaaaaaaaaaaay slower than having larger maps containing dozens of rooms spaced apart.

Then you are also going to get into persistence issues with your engine. If I move an item in one room and head to the next (which reloads from my drive) then go back, the item is back in place. If I go to one room, watch an AI script move a guy halfway down a hall, then leave and com back, you will have reloaded him, and his AI script will be back as it was. That's a poor design for having inter-area persistence. You'll have to add additional complexity to keep certain objects in RAM when you reload areas like that.

There are dozens of reasons why empty tiles in between rooms is a much better idea than each room being a separate map...

[Falco Girgis]

Doesn't sound like a problem at all.

Does this idea work for you?

Code: Select all

class Roof : public Graphics {
public:
	int getX();
	int getY();
	int getW();
	int getH();

	void setPosition(int, int, int, int);

private:
	int x, y, w, h;
	bool visible;
}

int Roof::getX() {
	return x;
}
int Roof::getY() {
	return y;
}
int Roof::getW() {
	return w;
}
int Roof::getH() {
	return h;
}
void Roof::setPosition(int _x, int _y, int _w, int _h) {
	x = _x;
	y = _y;
	w = _w;
	h = _h;
}


const int numOfRoofs = 10;
Roof roofs[numOfRoofs];

// Setting up the position of the roofs
roofs[0].setPosition(10, 10, 20, 20);
/*
and the rest of the roofs...
*/

/*
drawing stuff
*/

// Drawing the roofs
for(int i = 0; i < numOfRoofs; i++) {
	//If the player is touching the roof...
	if(player.getX() + player.getW() > Roofs[i].getX() &&
	player.getX() < Roofs[i].getX() + Roofs[i].getX() &&
	player.getY() + player.getH() > Roofs[i].getY() &&
	player.getY() < Roofs[i].getY + Roofs[i].getH) {
		// The player is inside, don't draw the roof
	} else {
		// The player is not inside, so draw the roof
		Roofs[i].draw();
	}
}

/*
Drawing some other stuff...
*/

You can use a struct instead of a class. I just used a class because... Well, I don't know.

I mean no offense, but now each roof is allocated as a completely separate structure that must be iterated through. This kind of completely destroys the point of a tile-based engine. How do you handle collision on the roof? How does this roof at all fit in with the rest of a tile-based engine, considering it is now a giant image, rather than being composed of tiles?

szdarkhack's solution is going to be much better. That's my recommended way. Just make sure that instead of iterating through the whole map, this is in your loop for only rendering tiles that are in view.