I'm using gestouch and it works great, but I cannot quite get it working as needed. I have two touch areas on screen - sprites. The first area controls rotation and zoom/scale of a 3D earth. The second controls panning of a small object. I can pan both areas at the same time, using two hands, but if I am touching anywhere in the second area I'm not able to pinch zoom to scale the 3d earth. If I release my finger in the second area then the zoom gesture works fine.
This is for multiple people though... so really need full gesture support in multiple areas.
Related
AS3 - Detect WHERE a collision occurred and ROTATE everything AFTER the collision point of the object by 90 degrees
DISCLAIMER
The following explanation probably makes no sense, so have a look at http://raphaelhennessy.com/misc/Explanation.png for more information
Essentially, I'm making a game where a lazer shines onto the screen and you have a mirror somewhere on the screen you can drag around. There is also a globe somewhere on the screen. The aim of the game is to direct the light, using the mirror, into the globe. Then, an animation plays of the globe filling with light and you progress to the next level.
After time, the levels get somewhat harder and new obstacles and challenges are introduced.
My problem is this; I got the lazer, mirror & globe all on the stage working fine except that I can't figure out how to programmatically make the lazer 'bounce' off the mirror.
Thanks in advance,
-Raph
I figured out how to do this. If you are interested you can find the code at raphaelhennessy.com/misc/LightStage.zip
I have the following scenario: player is in the middle of the screen and never moves from those coordinates. If I click with the mouse on the far right of the screen, the A* script kicks in and moves the background the player is on according with its own walkable/not walkable criteria, so for example if there is an obstacle in between the center of the screen where the player always is in the far right of the screen, the background correctly moves in the opposite direction And when needed moves around the obstacle, so you have the illusion of player walking, but instead only the background moves.
my problem is that I don't know how to rotate my player to simulate that he is following the path that the actual background is making. For example, in the beginning, the player is facing down. If I click on the right side of the screen, the player should face right. When an obstacle is present, the player should face the direction of the path around the obstacle and so on
but again technically my player never moves, so I don't know what coordinates should I have the atan2 use. In my mind I thought that the player should rotate toward the center of the next best hop in the array of best path created during the A* script, but for some reason I can't figure out the correct coordinates y and x for the atan2 command
I bet this is a simple thing I overlooked, but apparently my mind is in shutdown mode, so I can use a new fresh perspective :-)
thanks!
First, do not code in brain shutdown mode, this can save you lots of brainhurt time.
You don't need atan2() in this scenario, since your player is technically on a grid instead of on the screen. Give the player internal coordinates on the grid that will be updated as the player walks around the world, and use them in your A* script. The A* script generates a sequence of tiles the player should walk, thus you derive player's facing from current and next tile, for example, if the next tile to walk is adjacent upwards, you make the player face up and continue moving.
I am starting to get a grasp of the HTML canvas and I wanted to know if it is encouraged to use optimization techniques. In games for example, is it encouraged to use bounding boxes and only redraw the portion of the screen that needs redrawing, or do people just blindly redraw everything. I ask this b/c I am creating a new engine for canvas and imposing bounding boxes complicates things greatly (ie. the user no longer has the freedom to quickly draw things to the stage).
Absolutely, it's almost always better to draw only what has changed on the screen at any one time. Attempting to draw everything causes unnecessary rasterisation of the images being drawn into one output image, when it's not even going to change on the screen.
In a small game I made a year ago, I was drawing a 2D array of tiles on the screen and getting around 15 frames per second. When I changed it to draw only the tiles visible on the screen, it was an amazing improvement. It will improve in this circumstance too.
I'm new to programming games, so I'll make it short and sweet:
Is there any standard practice for Flash/AS3 for organizing sets of game Sprites, especially related to movement. For Example, if I am moving left, and then down, there should be a fill in animation...if we want that fill-in animation, do we need to create an animation for every permutation of all 8 directions our character can move? Also, if we want to have dynamic shadows for our 2d sprites, do we have to draw a light source for every one of those 8 directions for all 8 directions?
No, there is no practice like that.
However, here are some tips from my personal experience:
fill-ins:
if your sprite is small, just don't do any
other - SOME filling - for example, just from one direction to the one near it, and whenever the sprite rotates more than just on direction, play the fill-ins in a row
if you want to make ALL fill-ins, that would be a lot of work, I would say too much for something as small as a fill-in between two directions - better spend the time for something else
light sources:
again, matters HOW visible this sprite will be - if it is something very small, just mirror and / or don't make any lighting at all
other - I am used to always make one sprite (fully redrawn, or just light redrawn - does not mater) - for all directions - it adds a nice touch to visible things like player sprite that are always going to be on the screen
I'm not sure if this question fits properly, but I'm wondering in tile-based games, does the tiles 'shift' when the player is moving (and the player stays in the same place) or does the player move instead (and instead the tiles stay in the same place)?
Visually or in the model?
Visually, there’s usually some code that keeps the player fixed in the middle of the screen while the tiles scroll under him, with the tiles stopping and the player moving to the edge of the screen when the end of the map is reached. Typically this implies some sort of camera that knows how to follow the player, and perhaps changes its behavior depending on which direction the player is facing, and can also be locked for special effects and cutscenes.
In the model, it makes no sense to update the positions of all the tiles and every single object relative to the player, when you could instead just move the player.
Well, the specifics of how you want to draw it are up to you. Some tile-based games show the player fixed in the center of the screen -- in that case, your function to draw the character sprite always centers the character, while the function to draw the background would take an offset.
Others might give the player a pixel offset as well, either to show movement or to give "edges" to a map, not allowing the player to see what lies beyond.
How you implement it in your game is really up to you -- there's no "right" way to draw your sprites.
The tiles do. Unless there's no more to scroll in a certain direction, then the character moves. It's better to have as much as possible that's static cached together rather than move all the tiles individually.
The player moves, and the camera moves. The tiles are drawn shifted by the camera's position so that the world appears to scroll while the player stays roughly centered on screen. The camera follows the player, but usually a little loosely. (For example, you'll notice that you can walk a bit towards the edge of the screen before it starts scrolling in Super Mario Brothers.)