Open GoogleCodeExporter opened 9 years ago
You can download the source code and compile it on your computer to try it out.
I would really encourage you to try it, so you can test other things as well if
you want. I'll email you more info.
My very brief tests show that example 2 above actually does work with the
current implementation. Example 1 would require a pathfinder to select the
correct movement position. Compare to:
1#
P## C
2..
should the player move to 1 or 2 when clicking C? To determine that, you would
have to find a correct path from P to C.
Original comment by oskar.wi...@gmail.com
on 12 Dec 2010 at 11:19
Perhaps I will try to compile on my own.
My tests show that example 2 does not work. (Crossglen village tavern is the
"#"-building)
P#####
.#####
.#E###
..c.C
It works if I click "c" but it doesn't work if I click "C".
I'm aware of the pathfinder situation. But I more often face a situation where
a single obstacle is in my way (a), or where the other way is not possible. (b)
a)
.
P#..C
b)
########
P##...C
..
IMO the pathfinder would have disadvantages on hold to move. Consider the
following situation: (c)
c1) c2) c3)
# | ## | ##
P..c# | P.Sc | ..PS#c
##### | ##### |.#####.
| | .....
If I hold to move and the display scrolls, then every time I accidentally cross
a border my hero will move in a wrong direction. (P wants to go to S; c is
where the user holds to move)
IMO a direction oriented system would be better here. (As it is now.)
Original comment by SamuelPl...@gmail.com
on 12 Dec 2010 at 3:55
i really like how u move around on the game i would like to keep it that way if
u were to change is it possible to have it as setup the way u like it?
Original comment by breid3...@hotmail.com
on 11 Jan 2011 at 5:54
This would not significantly change the way you move.
It would just reduce the times you get stuck in a tree or fence.
But I agree to you, that it should be optional.
Original comment by SamuelPl...@gmail.com
on 13 Jan 2011 at 11:30
I would like to see more touch-based movement options.
• North, south, east, west (no diagonals, and touch-to-move disabled)
• Swipe-to-move (distance of swipe determines distance of travel,
configurable as "sensitivity")
• An on-screen directional controller pad
Hopefully, these are easy to implement.
Original comment by theGl...@bigfoot.com
on 17 Jan 2011 at 2:39
Nah, the movement controls are just perfect (galaxy s). Only a pathfinder would
be brilliant.
Original comment by michisch...@web.de
on 18 Jan 2011 at 1:42
An optional translucent on screen D-Pad would be awesome IMO. If I get some
free time this weekend I will try to build one and see how it goes, I may need
some help getting the option into the options menu at some point.
While I'm doing this I'll look at refinement options for the movement code and
maybe build out some pathfinder logic where the pathfinder is disabled by press
and hold.
Original comment by divilsp...@gmail.com
on 18 Jan 2011 at 5:43
any word on an upcoming update for this game? been waiting forever
Original comment by jesscahi...@gmail.com
on 18 Jan 2011 at 6:23
@divilsp...@gmail.com:
I already implemented an pathfinder. (See attachment)
But AFAIK Oskar did not yet decide if he should include it or not. (performance
reasons)
IMO both the improved movement code and the pathfinder work very well so far.
@Jfaulkne...@yahoo.com:
Only Oskar knows. AFAIK he is working on content.
I expect an alpha or beta in this or in the next week.
But remember: I dont know anything.
Original comment by SamuelPl...@gmail.com
on 18 Jan 2011 at 9:28
Attachments:
At first glance this looks pretty awesome. Being as you have both pieces
working how you like, have you tried breaking out of the pathfinder on press
and hold? I think this would be a nice balance between performance and
usability. It might also be worth considering a range limitation on the
pathfinder if performance does suffer that badly; though it could always be
masked by having move animation between the tiles and doing the compute during
the animation.
For the sake of my first programming instructor.. "MORE COMMENTS!!!" :-) Even
when the code was 80% comments he wanted more.
Original comment by divilsp...@gmail.com
on 18 Jan 2011 at 9:38
IMO the performance is good.
I tried an earlier version of it with my wildfire and did not have problems at
all. After that I improves the code for even more performance. (I think I
somewhat doubled the speed) Did not experience any difference.
@MORE COMMENTS:
I try to comment by writing readable code. IMO good code doesn't need many
comments.
Just my 2 cents. (And... Oskar did comment rarely too ;-))
Original comment by SamuelPl...@gmail.com
on 18 Jan 2011 at 9:52
pathfinding is the one, A* ?
Original comment by rqpa...@gmail.com
on 3 Feb 2011 at 6:11
As the target can not necessarily be reached I cannot use A* in generally.
Perhaps A* could be adjusted somehow, but IMO you need to visit each
(reachable) field anyway.
Original comment by SamuelPl...@gmail.com
on 3 Feb 2011 at 7:14
Waiting for a review
Original comment by sdeva...@gmail.com
on 10 Feb 2011 at 1:00
What do you mean with: "Waiting for a review"?
Original comment by SamuelPl...@gmail.com
on 10 Feb 2011 at 1:08
It was just a reminder to myself to review the submitted code.
Oskar explained it uses too much memory and will need to be improved before it
is included but it definitely could be a great enhancement.
Original comment by sdeva...@gmail.com
on 10 Feb 2011 at 5:33
Mh I think its not needed anymore, right?
I dont miss it and it looked strange sometimes.
Original comment by SamuelPl...@gmail.com
on 21 Jul 2011 at 8:41
Original issue reported on code.google.com by
SamuelPl...@gmail.com
on 11 Dec 2010 at 2:20