a way to make player move only along 2 axis'
by rennie moffat · in Torque Game Builder · 03/16/2010 (2:18 pm) · 7 replies
I am building a game where my player moves only along x or y. however, x and y are tilted, so they are at say roughly 4 o'clock and 7 o'clock.
The system which controls player movement is made of of tiles. When one is selected the player moves there, however I must make any tile that is not along the adjusted x or y axis that the player is currently on negligible.
I am trying to figure out how to best compare player position and tile position. I did this fine and built a system that worked great for perfect, up down, 0, 90, 180, 270 degree scenarios but for this i have to count for an offset. So whether the offset I rely on is set angle, or something else, I am not sure yet.
I guess what I really need to know is to how to calculate an angle. I did not see a vetorCompare that would accommodate that. So in other words, if my player position is XY and selected tiles position lines up along the desired angle then he can move there, otherwise not.
If anyone knows what I am talking about and has discovered an easy way to do this I would be very happy to hear about it.
Thanks!
Ren
The system which controls player movement is made of of tiles. When one is selected the player moves there, however I must make any tile that is not along the adjusted x or y axis that the player is currently on negligible.
I am trying to figure out how to best compare player position and tile position. I did this fine and built a system that worked great for perfect, up down, 0, 90, 180, 270 degree scenarios but for this i have to count for an offset. So whether the offset I rely on is set angle, or something else, I am not sure yet.
I guess what I really need to know is to how to calculate an angle. I did not see a vetorCompare that would accommodate that. So in other words, if my player position is XY and selected tiles position lines up along the desired angle then he can move there, otherwise not.
If anyone knows what I am talking about and has discovered an easy way to do this I would be very happy to hear about it.
Thanks!
Ren
About the author
My thanks to Garage Games and the Garage Games Community combined with owned determination I got one game up, Temple Racer and I am looking to build more interesting, fun games for the mass market of the iOS app store.
#2
but i was just thinking that if there is some way.. say player is at (30, 40). I know the angle that he can travel along. if a tile is selected and it lines up with the desired angle say 24 degrees then he can move.
i have figured each tile will be offset 5 units left, 12 units down etc, so i have the lines all made up, the angle the position of each tile is done. now i just need to make sure the computer understands that the player can only move along a line he is already on, left, right, up, down while all other tiles are are obsolete. The trick is that the axis' are not your standard x y axis'.
03/16/2010 (2:42 pm)
hmm. thanksbut i was just thinking that if there is some way.. say player is at (30, 40). I know the angle that he can travel along. if a tile is selected and it lines up with the desired angle say 24 degrees then he can move.
i have figured each tile will be offset 5 units left, 12 units down etc, so i have the lines all made up, the angle the position of each tile is done. now i just need to make sure the computer understands that the player can only move along a line he is already on, left, right, up, down while all other tiles are are obsolete. The trick is that the axis' are not your standard x y axis'.
#3
either way, I think I will have to consider walls too. as a tile may be inline with the player, but on the other side of the wall. The problem is, with collisions, the player will be taken off his mark (center spot on the tile).
03/16/2010 (3:18 pm)
I have one way I know I could do it, just make a grid so that each line up and down left and right (on the offset axis) is assigned a letter, so each tile will be A1 thru to Z30. if player is on A5 he can go anywhere, minus a wall on A and anywhere along 5. either way, I think I will have to consider walls too. as a tile may be inline with the player, but on the other side of the wall. The problem is, with collisions, the player will be taken off his mark (center spot on the tile).
#4
Let's add dynamic fields to all of the sprites: "row" and "col". If you are building the game in TGB, set these values on each sprite.
When the user clicks, check the "row" and "col" value of the sprite clicked on. If it matches the $playerRow or $playerCol, move the player to the sprite's location. Make sure to update $playerRow and $playerCol to the values stored in the sprite's "row" and "col".
If there are walls in-between and you refuse to do a full-up model, you'll need to do a line-segment pick between the player and the clicked-on sprite. You can check the list of sprites returned to see if any are walls.
03/17/2010 (12:04 am)
Let's store the player's position in global variables: $playerRow and $playerCol. I'll assume your player starts at <0,0> and so I'll set $playerRow and $playerCol equal to 0. You can do this in your primary .cs file.Let's add dynamic fields to all of the sprites: "row" and "col". If you are building the game in TGB, set these values on each sprite.
When the user clicks, check the "row" and "col" value of the sprite clicked on. If it matches the $playerRow or $playerCol, move the player to the sprite's location. Make sure to update $playerRow and $playerCol to the values stored in the sprite's "row" and "col".
If there are walls in-between and you refuse to do a full-up model, you'll need to do a line-segment pick between the player and the clicked-on sprite. You can check the list of sprites returned to see if any are walls.
#5
Anyhow, thanks!
03/17/2010 (5:43 am)
hmm very interesting. I will try this. It was essentially what i was thinking but I did not think to use the dynamic field variables. I am a little rusty there and will have to study and I am unsure what you mean by primary .cs file. If each tile has its own behavior I could just set everything thru there, minus the dynamic fields I would think.Anyhow, thanks!
#6
03/17/2010 (6:10 am)
Just to be clear, a dynamic field... how is it different from a behaviorField?
#7
A dynamic field is attached to the sprite. A behavior field is attached to a behavior which is attached to a sprite.
You could write a behavior which has a "row" and "col" field, has "onMouseUp" implemented, and does the same check against $playerRow and $playerCol that I described above.
I usually have a "<MYNAME>.cs" file (like Labyrinth.cs) which I keep my state in. If you've not written any scripts, just behaviors, you can throw these global variables in game.cs.
03/17/2010 (1:46 pm)
If you click on a sprite in TGB and go to the "Edit" panel, scroll to the bottom. You can add dynamic fields there. Name the fields "row" and "col" and type in values in the second column.A dynamic field is attached to the sprite. A behavior field is attached to a behavior which is attached to a sprite.
You could write a behavior which has a "row" and "col" field, has "onMouseUp" implemented, and does the same check against $playerRow and $playerCol that I described above.
I usually have a "<MYNAME>.cs" file (like Labyrinth.cs) which I keep my state in. If you've not written any scripts, just behaviors, you can throw these global variables in game.cs.
Associate William Lee Sims
Machine Code Games
First, you write code which model's the game's behavior. It's all of the game play, object locations, and actions that can be taken in a game. Imagine it as the whole game, just without any interface (graphics or otherwise), it's just a lot of variables and functions that change the variables. In here, your player "moves" along the X-axis or Y-axis only because your functions check that the move is valid and then updates the player's position in the model's variables.
Second, you write your view. You write code that looks at the model and creates sprites, particles, animations, etc. In this case, you'd know that your player needs to move from, say, "0 0" to "0 5" and you'd convert that to your rotated coordinates on the screen and move the player appropriately.
Finally, you write a control. This takes the click on the screen, converts it back to the plain X-Y coordinates. This could be easily accomplished by assigning variables to the sprites for it's X-Y location. Then, when the player clicks on the sprite, you take that variable and pass it to the model.
The model will then check that this is a valid move. The easiest thing to do next is update your model (to say that the the player is at the new location) and then call a function which updates your view (to move your player to the new position).