Hello.

I am hoby programer and i decided to make a 2d, top down, tile based(moving in tiles and mechanics are related to tiles instead of radius and such), with focus on rogue like, equipement and progress.

I am doing it souley for practice and fun.

The language, IDE and libs that i know and have at my dispossal are: c++, Visual studio 2012, sfml, boost and standard libs.

The topics:

1: Map format, collision with map.

2: Searching thrue the map for events.(connected with 1).

3: How to handle items and looks of character, how do i manage the sprites and whats idea behind that?

1: Map format

Id like to disscus what map format and how to structure the map would be ideal for a 2d top down tilebased game.

I am well known with vector of tiles that holds tile data, but id like to experiment.

What are some other ways you have made your map?

2: Searching thrue the map for events.(connected with 1).

In past with the vector of tiles i had issues how to handle events such as (Spell, 1 AOEradius...) i didnt figure out a formula for this one.

i just hardcoded a function that would return tiles for specific radius, the issue is that is, each radius means more code.

For a spcific Map format could you suggest a way to search tiles and such so i would somehow would be able to have effect like (3 tiles infront of X, 2 AOE radius around X)

T=target

Green = AOE radius 1

Green+Orange = AOE radius 2

Blue+Orange+Green = Aoe radius 3...

i dont know how to get such code to be efficient and ive seen games using it and not lagging as when i made it

3: How to handle items and looks of character, how do i manage the sprites and whats idea behind that?

I have never done this one so i set it as a main chalenge to achieve.

I am thinking about of items of (head, chest, pants, boots, weapons. off hand, gloves, amulets, ring) but that being said its kinda too way much for a first build so i will go with (chest, weapon) for first run.
That being said i have been thinking about it, and i got some ideas but the execution of them is not efficient, did you do such a feat, and if so would you care to share what to do and what not to do.

Not sure if i am supposed to post it in for beginers but i cant find anywhere suitable for it.

1. The Map format:
   • I can suggest you to use an XML format which form it has is up to you. The Idea behind it is that you first can use boost::ptree to read and write those map files -> easy access
     • You could, if you want, manipulate your map with your hand
     • It's human readable
     • You can store all meta data like which tileset you need, etc in it
     • Example:

<Map name="Example" version="1" width="100" height="100">
    <Layer id="10" name="CollisionMap" width="100" height="100">
    </Layer>
    <Layer id="0" name="Ground">
        </Tileset TilesetID="1" name ="Example"path="path/to/tileset/.." width="100" height="100">
        </Tile tileset="Example" tileID ="1" xpos="0" ypos="0">
        </Tile tileset="Example" tileID ="1" xpos="1" ypos="0">
        </Tile tileset="Example" tileID ="1" xpos="1" ypos="0">
...
        </Tile tileset="Example" tileID ="1" xpos="100" ypos="100">  
    </Layer>
</Map>

2. Searching thrue the map for events.(connected with 1)

Because of boost::ptree it is really easy to use this way. You can check if the player is something hitting or is triggering an event because of his position just by iterating through the map and of course a function which check what should happen now or instead of develop your own map format you could use the TMX-format https://github.com/bjorn/tiled/wiki

TMX is very common from what i know and you have a Mapeditor too which you could use to build your maps.

1. Map format

Ok, theres two things here. One, how do you store your maps on disk to save, load and build them. Second, what is the actual data structure of the map.

For the first one you have (how to store map on file):

-Store the map as a picture (eg. png) where pixel color corresponds to tile type. Works for simple maps. You can edit it in an image editor. But its limited and you will eventually need to move forward when you need more features.

-Binary format. Create a protocol for storing the map as bits and bytes. This is the most flexible feature wise. It is not practical to edit this by hand, youll need to make an editor. It is also more vulnerable to bugs because you cant really see what you are doing.

-Human readable text format (like the xml shown by exOfde). Same benefits as binary excepts its in a human readable form, and thus easier to work with. The only problem is that it is not very compact in memory and thus will take more space than a binary format as well as likely take longer to load.

-An already existing format with editors available. This might be a good choice, so you dont have to worry about editing your map. Of course, being somewhat out of your control, you might at some point face limitations in what the format or editor for the format can do.

The second one, theres not so many ways you can arrange your data in memory. Its more about what features you need:

-Grid in memory (X*Y tiles). Use a format like this for the tile data, to tell what material each tile is.

*Use this only for data that most tiles have

*You can also add an ID to the tile data, and store the actual data in a different place. Eg if a tile has a list of objects contained, you want to store it in a separate structure because you dont know how many items there are. You dont want each tile to have space for 1000 items. You want each tile to point to a list of items that is resized to fit the items.

*Later you might want to be able to have multiple grids (chunks) which form a continuous grid made of many parts. This allows it to be easily resized by adding or removing chunks. This is if you want procedurally generated terrain, or if you want to load only a part of the terrain in at a time from disk or network.

-Freely placed objects (list of objects, each has x,y position)

*Consider this for things that are not really a part of a tile or are rare

*Players, other moving objects...

*Some special locations like spawns so you dont have to scan each tile to find what tile is the spawn in

2. Map access

The access pattern you described is easily achieved by flood filling limited to an amount of steps which is the range. Specifically:

-Have 2 list, one for tiles in range and second for recently flooded tiles.

a) From the center tile (the player) flood all the neighboring tiles. Add them to the list of tiles in range and the recently flooded tiles.

b) Treat all tiles in recently flooded tiles as center. Clear the recently flooded tiles list and flood from the tiles that were in it further out (dont flood back to tiles we already covered)

c) Repeat until RANGE steps

or something similiar. Google on flood fill algorithm. This isnt exactly filling because we terminate after X steps but the logic is the same.

3. Customization of player

The game logic of this should be simple, your player has slots you can equip stuff to (eg a WeaponType member, which you can use to find the weapon details such as appearance and damage. As in WeaponTypes[player.WeaponType.getID()].getDamage())

The appearance is more complicated. The weapon you can probably just draw as a separate sprite to the correct position when it exists. For smaller details you might need to do something like programmatically color the ring in the players hand or have a ton of sprites to cover all the possible combinations of things the player can wear.

The best would be to just figure out how to compose a player from multiple sprites so you can swap them easily.

2)

I used this formula in a python game, you will have to adapt it to c++, shouldn't be hard:

def target(m, x, y, radius):
    yMax = len(m) - 1
    xMax = (len(m[0])) - 1
    yMin = 0
    xMin = 0

    size = 1
    mRadius = (radius * 2) - 1
    posAdjust = -int(mRadius / 2)
    while size <= mRadius:
        for t in range(size):
            if (posAdjust != 0):
                xToTest = x + t - (size/2)
                upperYToTest = y + posAdjust
                lowerYToTest = y - posAdjust
                if ((xToTest >= xMin and xToTest <= xMax) and (upperYToTest >= yMin and upperYToTest <= yMax)):
                    m[upperYToTest][xToTest] = 'x'

                if ((xToTest >= xMin and xToTest <= xMax) and (lowerYToTest >= yMin and lowerYToTest <= yMax)):
                    m[lowerYToTest][xToTest] = 'x'
            else:
                xToTest = x + t - (size/2)
                yToTest = y + posAdjust
                if ((xToTest >= xMin and xToTest <= xMax) and (yToTest >= yMin and yToTest <= yMax)):
                    m[yToTest][xToTest] = 'x'

        size += 2
        posAdjust += 1

m is a matrix that represented the tile map.

x is the x coord of the spell

y is the y coord of the spell

You can guess what radius is

Thank you on suggestion!

I have read about them over past few days and i did make out what i will do.

thank you on sharing.