Tile Management

Game Mechanics
#1

Hey, i’m in the early process of writing a side-scrolling tile based game, and i have been trying to figure out which is the best way of caching tiles.

Idea 1:
I would store an instance of a tile class such as grass for every tile in the game (sounds very costly), this allows each tile to have its own unique properties (still being a subset of grass ofcourse).

Idea 2:
I would store the id of every tile in the game, and use a tile lookup table to retrieve a singleton instance of that tile, this option seems to be more fitting however then each tile of the same type must be the same globally, and couldn’t have different properties to other grass tiles.

Which idea would be the most viable, and if you have a better idea, please feel free to share it :).

#2

Combo breaker!

Bad joke. Really, what you should do is something close to a combination of the two. If you know that there will be some set of values that will always be the same for a given tile type, regardless of location, etc. You store that data in a singleton-holding data structure. Or, I mean you could use an enum, which for semi-small numbers of types works like a charm and pretty much removes the need for you to do that. Hah.

Then, you pass that enum object to the Tile on creation, so that it has access to the TileType which stores all of its general data, without having to make a copy of it.


public enum TileType {
    GRASS, DIRT, ETC;
    //Fill in data that is the same for -all- types of grass.
}



public class Tile {
    private TileType type;
    //Tile specific data.
    public Tile(TileType type, ... ) {
        this.type = type;
    }
}

If you don’t think an Enum will cut it, try making a Factory of some sort instead.

Pass reference, not id. (Looking up this data could be costly, or not, but let your language do the work for you there.)

#3

that idea of having a tiletype and each tile having a reference to a tiletype is EXACTLY how i have it atm, named the same, exactly the same code and everything lmao. Thanks and I’ll probably go from this and work out the kinks as they arrive but if anybody has any better ideas hit me up :slight_smile:

#4

Idea 3:
Default case is sharing of tile objects, but whenever needed, just create a new tile instance with private unique properties and assign it to your tile map. If needed, add a flag “shared” or something.

Idea 4:
No individual Java tile classes at all, but each slot of the tile map stores an integer tile class property where tile properties are set as single bits and are modified during runtime, like door-tile, open-door, closed-door, wall, etc.
(from my current game, not for OO-freaks)

#5

idea 3 is sort of what i’m working off now, and idea 4 could work for some primitive tiles but i’m looking for a bit more functionality, e.g. tiles will interact with the player.