Hello my friends.

While developing a single player 2d action rpg for the pc, Im stuck in something I believe to be both a design and a programming issue.

First of all, I store my character and npcs in a couple of lists. I have control of them, and I know where they are on the map, but they are not stored IN the map.

Which means that when Im going through the map to check collisions, I dont have the position of an npc stored in a determined tile and from a computing point of view, I think that it could be really a lot of processing to do on every single movement, to get all npcs on the map and see where they are, every time my character tries to move.

What I do now, is I go through the npc list, and check collisions with the character when I try to move. Afterwards, I check collisions with map elements.

Do you think thats a viable way of doing so, or would it be better if I integrated the npc positions in the "collision map" to check for every collision at a time?

Another point Im thinking about is:

My characters have a determined step size, that is, a fixed number of pixels that he will move when taking a step towards a direction. (n, s, e, w, nw, ne, sw, se)

Now im working on mouse movement, and decided that the character will be moved in a tile based pattern, to facilitate path finding within the map, using the tiles. But it seems like a weird mix of systems, I mean. Imagine if my character is, and he WILL be, off the center of a tile, cause you know, Ive been moving him around.

Now, I want to go to a certain place, so I mapclick.

The character moves to the center of his tile first, then moves to several other tiles, from center to center. Then stops at the center of the destination tile, and doesnt reaaaally go where I clicked.

Or even imagine that after he goes to the destination tile, he moves a bit OFF the center of the tile, and goes to the position I clickd.

To me, that sounds a little: human movement > cyborg moment > human movement.
And just feels a little odd. So I would like to hear some advice regarding both the movement issue and the collision detection issue.

It sounds like your tiles are really large. How big are the tiles compared to the character?

When you specify a movement by clicking on the map, the game knows the absolute starting coordinate (P1) and the absolute ending coordinate (P2).

Suppose your map is a grid, then the game knows that P1 is in cell C1, and P2 is in cell C2. The game then use pathfinding to get a path from C1 to C2. Let's say the path is C1 - C3 - C4 - C2. When the game executes the movement for the character, the game does this:

1) Move the character to the closest point in C3
2) Once the character is in C3, move it toward the closest point in C4
3) Once the character is in C4, move it toward P2

This way, when the character passes through an intermediate cell, the character would not always try to get to the center of the cell.

If you want more math you could also do this:

1) Move the character toward the closet point in C4 via a point in the border between C1 and C3 where the combined distance is minimized
2) Once the character is in C3, move it toward the P2 via a point in C4 that minimizes the combined distance.
3) Once the character is in C4, move it toward P2.

What really confuses me is the concept of mixing tile movement and pixel movement.

I mean, should I allow the characters a free movement and actually use TILE MOVEMENT, I mean, movement directly from the center of a tile to the center of another tile, using both systems at the same time, free pixel movement, and tile movement.

Im having a hard time explaining this.

Every game I see has either free movement, or movement bounded to tiles, I havent seen a mix of both, so is that actually viable? Seems so weird for me to use both systems, and keep in mind that this was my idea lol, I had this idea, but cant really see it working, dont know why.

Quote:

Original post by arthurviolence What really confuses me is the concept of mixing tile movement and pixel movement. I mean, should I allow the characters a free movement and actually use TILE MOVEMENT, I mean, movement directly from the center of a tile to the center of another tile, using both systems at the same time, free pixel movement, and tile movement.

Heh, I'm trying to wrap my brain around this concept as well with my game. It's definitely possible. The only issue I found is storing the delta positions between tiles. Should this be stored within the gamestate itself or in a separate interpolation object?

E.g. your tiles:

+---+---+---+|0,0|1,0|2,0||A  |B  |   |+---+---+---+|0,1|1,1|2,1||   |   |   |+---+---+---+

Now if each tile is 100 pixels wide/tall then when a character moves from one to another it will move at a certain rate. If this rate is 50 pixels/second then it takes 2 seconds to move from tile A to tile B.

Is your game a turn-based game at heart?

If it is then a character will always be squarly on top of a given tile. However animation/feedback may show them moving smoothly from one tile to another.

In my engine, the character will always be squarly in the center of any given tile within the gamestate. However, if they're moving from tile A to tile B then I know the time (in ms) they started moving and the velocity (i.e. number of pixels crossed per second). From that I can interpolate and draw a smooth walking transition. Being turn-based whenever a character takes their turn, I know that all other characters are squarly in the center of their tiles. Calculations are easier.

That's one way to do it. I'm interested as well in hearing how others might approach this.

I take a similiar approach to yours regarding the movement from one tile to another.
Now take in consideration that my game is an action rpg, and the character can be moved freely with the keyboard.

Player presses the left and up keys, now the character is no longer centered in the tile.

And that movement is free, so the character can end up in any point of any tile, not necessarily at the center point.

Now take in consideration a different situation:

The player mouse clicks in a given map position.

The character will find a path to that point, but he will walk from the center of one tile to the center of the next adjacent tile.

See the problem? Everytime I want to take a path from tile to tile while map clicking, my character will have to, first, move to the center of the current tile, and THEN move to the next tile.

My problem is making that combination of systems to work together.

I have to make pathfinding work, so I use tiles, and tile to tile movement, but I dont want my players to be bound to use ONLY tile movement.

Are you trying to create a system that functionally behaves the same as Starcraft?

There is definitely some kind of tiling system (an underlying grid) but units appear to smoothly move between tiles and destination clicking works seemlessly. I think the tiling system allows for easier path-finding, collision, and simplified positioning algorithms as opposed to a pure per-pixel positioning.

How this is implemented I don't know.

I have never played starcraft, so I wouldnt know, but the system you described is exactly what Im trying to do.

Facilitating path finding and collision detection with ground and map items is indeed what led me to this system, but Im having a hard time with the concept.

I consider "Tile-based systems" a sub-type of what I like to call "Node-based systems". Each tile is a node.

I would consider a system where each node (tile) knows of what actors it contains. As an actor moves from node to node they remove themselves from invalid nodes, and add themselves to new nodes.

Then you do collision detection on a node-by-node basis. This also means you can easily consider inter and intra tile path detection as different processes.

e.g
tile(6, 4) contains ann
tile(3, 2) contains bob, player
tile(3, 3) contains player

You therefore know where each actor is, and that the player is currently on the borders between tile(3, 2) and tile(3, 3). With these three actors you need only check to see if bob and player are colliding.

You could have the players be in the tile they are moving to next. But to show the movement you determine how long it takes for the character to move there, then for the fraction of the time it takes to move there position the character based on the percent of when they should be there.

So graphical position would be (startX+movementX) * percentThere, (startY+movementY) * percentThere. Where percentThere is: Current Time from start of movement(Change in Time from start) Divided By time it takes to move from Start to End, and movementX(Y): Is how far you are traveling(IE 100 pixels along X).

This will work fine as long as you don't have acceleration, and may have rounding errors over a long period of time(depending on other logic). It also gets rid of the problem of slowdowns/speedups of your timing code(IE: different computer systems). And allows you to pretty comfortably map to a tile system(especially if you make the calculation part(of this post) of the display logic only, and have tile movement/collision game logic side be purely tile based).

Another note worth mentioning is that you can have a character actually take up 4/8/whatever square tiles if you wanted to, Which means you can more readily combine the apparent benefits of a pixel based collision system(irregular shapes), with that of a tile system(easy to logically map).

________

Also not the best way to do this, just very easy to explain and doesn't require anything very complex(aside from coupling game/display logic).

Re: arthurviolence

Quote:

The character will find a path to that point, but he will walk from the center of one tile to the center of the next adjacent tile. See the problem? Everytime I want to take a path from tile to tile while map clicking, my character will have to, first, move to the center of the current tile, and THEN move to the next tile.