Closed GoogleCodeExporter closed 9 years ago
Original comment by oskar.wi...@gmail.com
on 20 Nov 2010 at 10:09
Or maybe a doubletap to set waypoint
Original comment by The2ndclory
on 20 Nov 2010 at 1:10
Good idea The2ndclory, that's something that we probably should think about in
a future release. I've made pathfinding implementations for other games, so
that particular part should be no problem. We just need to consider what would
be best for the players, and most intuitive.
Hm, maybe a setting where the player can choose if the game should use
click-to-move or click-to-set-waypoint? Just a thought.
In the meantime, I've made a quick implementation of drag-to-walk, but I need a
second opinion on whether it feels correct or not. I would need someone to
betatest it before we release to Android market. Anyone willing? :)
Original comment by oskar.wi...@gmail.com
on 22 Nov 2010 at 9:09
*Raises hand* me teacher. I've actually tried looking at the code which has
spurred my interest to look into java.
Original comment by The2ndclory
on 22 Nov 2010 at 9:50
Great, I'll prepare an APK right away that you can install and test. Should we
take this discussion to email instead? Please email me at iostr_antr [at]
iostr.com and I'll set you up with what you need to test it.
There's some new quests developed in there as well that aren't completely done
yet and not really ready for publishing to market :)
Original comment by oskar.wi...@gmail.com
on 22 Nov 2010 at 9:58
Tests indicate that the new movement system is working as expected. Much better.
This will be included in the next update. (v0.6.6)
Original comment by oskar.wi...@gmail.com
on 24 Nov 2010 at 9:03
Its better now, but as usually I have some suggestions. ;-)
Consider the following situation:
####m###
# . M
# P#####
# ######
########
P - player
M - point where I click to move (does not work)
m - point where moving works
Currently the player wont move anywhere when tapping "M". I suggest that he
should move to the "." instead. I do NOT want you to implement a path finding
algorithm. (perhaps later when double tapping a field) I just think you should
rework the moving system.
I think currently you are determine the angle and compare it using the
following system:
-22,5° to 22.5° > move east
22.5° to 67.5° > move north east
67.5° to 112.5° > move north
112.5° to 157.5° > move north west
157.5° to 202.5° > move west
202.5° to 247.5° > move south west
247.5° to 292.5° > move south
292.5° to 337.5° > move south east
If this does not work because the field is full I suggest to compare the angle
again to:
-45° to 45° > move east
0° to 90° > move north east
45° to 135° > move north
90° to 180° > move north west
135° to 225° > move west
180° to 270° > move south west
225° to 315° > move south
270° to 360° > move south east
In my example with an angle around 15° the first table says me to go east.
(blocked)
After this the second table has 2 options for me: "east" and "north east".
North east is not blocked so I could go there.
It happens really often that I cannot move because of that...
Original comment by SamuelPl...@gmail.com
on 25 Nov 2010 at 7:52
Very nice idea. I've also noticed that I got stuck on some fence when I wanted
to travel in another direction. This could really help in those cases.
A remark tough, the example you gave actually works
I've done a quick implementation similar to what you suggested, and the
movement really feels much much better.
Thank you again for a great suggestion. I'll put up an updated version of
v0.6.6 shortly.
Original comment by oskar.wi...@gmail.com
on 26 Nov 2010 at 12:54
Works like a charm in 0.6.6b1.
Moving is really fun now.
Original comment by SamuelPl...@gmail.com
on 26 Nov 2010 at 9:31
This is now implemented. Closing this issue. Thanks again for all the good
suggestions!
Original comment by oskar.wi...@gmail.com
on 29 Nov 2010 at 9:36
Original issue reported on code.google.com by
oskar.wi...@gmail.com
on 20 Nov 2010 at 10:09