Confirming a couple of small things ...
A couple of quick questions from a GS newb user but successful App Store developer.
1. How does GS handle things like clicking on, and then dragging an object to a location on the screen then letting it snap to that location? In this case, I'm thinking of a square player piece that needs to be dragged onto a specific board location (an outlined square area) that then snaps to that location to register a move.
2. Can GS handle the same situation as above, but using end containers areas that are not squares? Circles, or even polygons (say like a map of provinces)? [I suppose this could be faked by having an invisible square in the centre of an oddly-shaped region.]
3. Line of sight? Anyone come up with a "simple" working solution to that problem using GS? Can piece A "see" piece B if there is an object that blocks LOS? Or suppose you had a chess board ... some of the squares are black (block LOS). Pieces are in the squares. I know LOS is a difficult problem but has anyone figured it out in GS and willing to share their method?
4. Finally, the simplest one. Clicking on a piece sends a "I'm being used" message to the rest of the game/pieces. How's that accomplished in GS?
I'm asking these because while I'm re-releasing a couple of my apps for the iPad, I am also thinking about developing/tackling a new (board-like) game that might be easier for me to make in GS.
Thanks.
1. How does GS handle things like clicking on, and then dragging an object to a location on the screen then letting it snap to that location? In this case, I'm thinking of a square player piece that needs to be dragged onto a specific board location (an outlined square area) that then snaps to that location to register a move.
2. Can GS handle the same situation as above, but using end containers areas that are not squares? Circles, or even polygons (say like a map of provinces)? [I suppose this could be faked by having an invisible square in the centre of an oddly-shaped region.]
3. Line of sight? Anyone come up with a "simple" working solution to that problem using GS? Can piece A "see" piece B if there is an object that blocks LOS? Or suppose you had a chess board ... some of the squares are black (block LOS). Pieces are in the squares. I know LOS is a difficult problem but has anyone figured it out in GS and willing to share their method?
4. Finally, the simplest one. Clicking on a piece sends a "I'm being used" message to the rest of the game/pieces. How's that accomplished in GS?
I'm asking these because while I'm re-releasing a couple of my apps for the iPad, I am also thinking about developing/tackling a new (board-like) game that might be easier for me to make in GS.
Thanks.
Comments
http://gamesalad.com/game/play/30842
http://gamesalad.com/forums/topic.php?id=5579#post-35139
http://gamesalad.com/forums/topic.php?id=5595
2. Usually, in GS, snap-to is based on X/Y coordinates, proximity to an actor, or on collision with an actor, so you should be able to fake the scenario in a few ways but with GS lacking arrays, you have to get creative if you use the last two methods since multiple actors could be fighting for the right to be snapped-to if they are equidistant from the piece.
http://gamesalad.com/game/play/49127
3. Line of sight would be tricky and possibly induce some performance issues within a GS app. I could see you continually firing off invisible bullets that go from actor A to actor B. These bullets would be set to collide with anything and if overlap/collide, increase a hit counter. Then if it arrives at actor B with no hits, you have a clear path.
Another way would be to use a thin, invisible actor that you can make its endpoints both actors location (center points) by stretching/rotating it to make it connect both actors (see FMG's magnitude demo:
http://gamesalad.com/game/play/31279
it connects floating circular actos with a "string"). Have the "string" actor set to collide with all items like the invisible bullet method. If no overlaps/collides, you are set. This may be less performance impacting than moving bullets. Only problem here is, if it is moved into place, it could detect collisions and if spawned into place, overlaps may not be sensed if I recall. So you would have to grow it from one actor to the next - performance wise it may be a wash compared to the invisible bullet so test.
Some things to play around with. No real path determination/sensing/A* ability other than quirky workarounds like this.
4. Yeah, have a game (not actor) based attribute called "PieceInAction" or such that gets set to "true" or "1" or something by a piece as it is touched. However, before that action is allowed, you of course test to make sure "PieceInAction" is not currently set. Then when the piece is done doing its thing, clear "PieceInAction" to "false" or "0" or something. If using more than Touch1, you may have to add some additional logic.