Gamedevlog: TileMap Part 3c
Tags: android, vrgame, devlog, tilemap
Published: 2020-10-25 20:29:54

# Determining where the player leaves the tile
To continue where I left off last time I found the following formula on [wikipedia](https://en.wikipedia.org/wiki/Line%E2%80%93line_intersection), which can be used to determine where two lines cross, I used this to determine where the players trajectory and the edge of the tile cross and therefore the point that the player leaves the tile.

![line line  intersect formula](https://dev-to-uploads.s3.amazonaws.com/i/k6iwk77hnsj0vkenzd4h.PNG)

As I plan on using this in multiple places I created a function which takes the start and end points of two lines and returns the position that the two lines intersect. 

![line line intersect function](https://dev-to-uploads.s3.amazonaws.com/i/0zvy2l4wtevlqvjcnpms.PNG)

### Some future improvements (TODOs)
I know some people do not like putting TODOs in comments but for me it is a great way of keeping in the flow of coding without forgetting some of the smaller things which I can see will need tidying up or fixing. 

As can be seen in the comments above, this function does not check if the lines are parallel, there would be a division by zero if they were, which would crash the application, but as the function is only called to get the intersection point after checking that the two lines intersect, I shall add a TODO in the comments to remind me that there should be a check in for 0.0 value divisor.

Also in the comments I have put a TODO to remind me that for this function it would make more sense to create a 2D version of <code>Position3Float</code> and use that instead of <code>Position3Float</code>.

# Calculating where the player ends up on the tile map
This is where things got complicated, so far I have only catered for the player moving up, down, left or right and not diagonally in any direction. 

The general flow of processing the player movement goes like this:
### Setup
![Setup code](https://dev-to-uploads.s3.amazonaws.com/i/0t4ne07m2v30re6ehq65.PNG)

Hopefully the comments explain what each variable here is for, some additional things to note are:
1. <code>distanceTravelled</code> must be set to anything except 0.0f otherwise the next loop will never be entered.
2. <code>endPosition</code> is used to make up the returned position, setting it to the start position means if anything goes wrong the player will not move at all.

### Checking if the player is still moving and has distance left to travel
![Main loop](https://dev-to-uploads.s3.amazonaws.com/i/2trhh589rjfdn3ypbnhp.PNG)

This loop repeats while the player can still move and is still moving.

### Calculating where the player would like to move to
![calculating travel position](https://dev-to-uploads.s3.amazonaws.com/i/qj5zs2qz5oxlxk9p2fwn.PNG)

This takes the remaining distance and applies the fluidity of the current tile to work out how far the player will travel along this tile, it then multiplies the distance by the normalised direction vector and adds it to the start position to calculate where the player would end up.

### Does this take the player to a new tile?
![Changing tile code](https://dev-to-uploads.s3.amazonaws.com/i/ckbk1ymoix1ar65im1rr.PNG)

This code is similar to the existing code for checking for tile changes.  

### Finalise where the player moves to on this tile
![Where the player moves when statement](https://dev-to-uploads.s3.amazonaws.com/i/h75janmw10qj615iux2n.PNG)

This is performed in a big when statement to allow each direction to be separate, at the minute, because I have not coded the diagonal transitions yet, the process is similar for each direction:
1. Calculate where the players trajectory intersects the edge of the tile.
2. Calculate the index of the tile the player is moving to.
3. If the tile the player is moving to has a non 0.0 fluidity value then the <code>endPosition</code> will be where the player intersects the tile edge - the tile size to wrap around to the opposite side of the tile like we did in the previous code.
The <code>currentTile</code> is also updated as the player has now transitioned to this new tile.
4. Otherwise the <code>endPosition</code> will be where the player intersects the tile edge.

This does give a slight overlap between one tile and the next, e.g. any point at the edge of one tile is also technically on the edge of another tile as well.
Whether this is of any consequence remains to be seen.

### Update the distances traveled and remaining
![Updating distances](https://dev-to-uploads.s3.amazonaws.com/i/ke3gfmwunc2uqt3a58fc.PNG)

One thing that may be confusing is how <code>endPoint</code> and <code>intersectionPoint</code> differ, if the player is on the same tile then they both have the same value, when the player enters a new tile the <code>endPoint</code> is where the player entered the new tile and the <code>intersectionPoint</code> is where they left the old tile.

# Updating the <code>TileMap</code> after applying the player movement
If the tile which the player is on has changed, the center tile is updated to be the new tile and all other tiles are reset based on this new center tile.
Then all the tile offsets are reset as before.

# Conclusions
This update took me a while to get motivated to start but once I did it came together quite nicely.
I should now be able to create a complete level which the player can move around consistently. 

The code at this point of the project can be found [here](https://github.com/longevity-software/AndroidVrGameDemo/releases/tag/B1.14).

Stay Safe and Happy Coding.
Until next time,
Graham