Closed GoogleCodeExporter closed 9 years ago
Thanks for the report.
Good point, it should be clearer how that button works, and what circumstances
it can be used. In general I think that we should make it clearer to the
players how "fleeing a fight" works. The current implementation is never
explained.
The way to flee is currently:
1. Engage in combat.
2. Longclick some (empty) position beside yourself.
3. Notice how the "Attack" button now changes to a "Move" button.
4. If you have enough AP, you can move instead of attacking.
5. If you are in a position where no monsters are directly beside you, you can
click "End combat".
6. Combat ends. You have fled the fight without dying.
I'm thinking that we either implement an in-game help system that explains
this, or we place some character in the world that talks about how to do this.
Either way, we will have to think hard about how to teach this to the players
in a way that it still doesn't feel like a lecture or too much text to read.
Or we make a "Flee" button that automatically picks an empty spot, moves, and
ends the combat. Picking "the right" spot to move to could be tricky though.
Suggestions are ofcourse welcome on how we proceed with ways to explain the
combat system to the player.
Thanks again for the report.
Original comment by oskar.wi...@gmail.com
on 22 Nov 2010 at 8:25
I support the flee button. Here some thoughts to pick "the right" spot.
Here is an situation:
################
#####2MM2#######
####211123######
###3M1PM########
##43211123456789
####2MM22M#567##
######33###66###
###########7####
P - Player M - Monster # - Tree 1-9 - Moves to reach a field
IMO there are 3 possibilities:
1) Escape to the nearest field without adjacent monsters
################
##### MM #######
#### ..X######
### M PM########
##
#### MM M# ##
###### ### ###
########### ####
You would end up at the X, what is (in this case) a really bad position. (But
it is most of the time a good choice anyway)
2) Escape to the nearest exit-field until you are on a field without adjacent
monsters
################
##### MM #######
#### ######
### M PM########
## ....
#### MM M#X ##
###### ### ###
###########E####
You would end up at the X with 2 additional Moves. (E is the nearest exit-field)
3) Escape to a field without adjacent monsters, while keeping the sum of the
monster-attacks at a minimum.
################
##### MM #######
####. ######
###.M.PM########
##X
#### MM M# ##
###### ### ###
########### ####
You would end up at the X and would have been taken 3 times damage. (You could
also consider the strength of a monster.)
All 3 solutions should be found in O(n). Tell me if you need a hint how to do
it.
As you can manually flee, every solution mentioned above should work. I would
prefer (2) perhaps improved by considering (3) if there is more than one
possible route. This would be perfect. ;-)
Original comment by SamuelPl...@gmail.com
on 24 Nov 2010 at 6:36
Good idea SamuelPlentz, and nicely illustrated. The method is similar to some
pathfinding algorithms I've seen before. Could be very neat.
One thing to consider though is that when making "clever" choices for the user,
the most clever choice might not seem so clever to the player. The player could
have a different opinion on what the best move could be, or not grasp what the
(proven) best move would be. Some users are stubborn :) "the damn game moved
me into more monsters and got me killed when I wanted to flee!"
But I really like your idea about using a pathfinder to select the best fleeing
tile. I have a feeling that we will need to implement a pathfinder one day
anyway, so why not use it for several purposes.
On a side note, the most common case for fleeing is probably a trivial case
anyway, where the fleeing tile doesn't matter that much, just one step away
from the monster.
I'll see if I get time to implement it. If not, you are always welcome to give
it a shot :)
Thanks again for the great summary.
Original comment by oskar.wi...@gmail.com
on 24 Nov 2010 at 9:02
cite: "the damn game moved me into more monsters and got me killed when I
wanted to flee!"
I also thought of this users, but using the last described algorithm would be
very nice to look at. (at the most of the time)
Original comment by SamuelPl...@gmail.com
on 25 Nov 2010 at 1:10
I played now a while and tried the "flee enemy" method. It doesn't work as I
would expect. Sometimes I have enough AP and I tap on an empty space for
seconds but nothing happens. When I release the tap, I make a normal attack.
Sometimes it seems easier to fight on and hope, that there is enough meat left.
I thought some time about the possibilities to prematurely end a battle in an
intuitive way. A "Flee" button could indeed be suicide in an enemy infested
area. If there is a "End Battle" button, why not use it in an intuitive way?
Instead of long-clicking someware just click on "End Battle". If there are
enough AP left, I can click on any place which seams fine to me and I move
there. To less AP and I get an accourding message. This way the game would be
self-explanatory.
Original comment by erwr...@gmail.com
on 26 Nov 2010 at 9:23
Long clicking does work fine here.
But I think fleeing should be improved somehow.
Original comment by SamuelPl...@gmail.com
on 26 Nov 2010 at 9:35
Maybe a "Flee" button and after clicking it:
- if you don't have enough AP - a message "Not enough AP, try next turn"
- if enough AP - a message "Where?" and you have to pick a free tile (or point
a direction). Maybe even some formula to get % chance of fleeing? Based for
example on yours and monsters lvl, some additional skill etc...
Original comment by rafal.wa...@gmail.com
on 3 Dec 2010 at 10:27
Good idea.
Also the flee percentage. I think a formula is not needed, just use a fixed
value around 80% success rate. This would prevent hit and run. (Issue 30)
Original comment by SamuelPl...@gmail.com
on 4 Dec 2010 at 7:35
This is now implemented. The way that it is done is that the "End combat"
button is now replaced by a "Flee" button. Clicking it will give the message
"You can now flee combat by clicking in the direction you want to move", and
you can singletap to move.
The old way of longtapping a location also works. If you want to be sure what
exact tile you end up on, longtapping could be more effective since it doesn't
use up your AP to just mark a location.
I also implemented a flee fail chance (or risk rather). There is now a 20%
chance that movement while in combat will fail. This applies to both movement
while fleeing with the flee button and moving with longtapping.
Thank you for the good suggestions!
Original comment by oskar.wi...@gmail.com
on 8 Dec 2010 at 8:13
I like the new flee button.
If I chose to flee but after fleeing one field want to attack the monster with
the remaining 4 AP, then I have to longclick it to attack. This is not very
intuitive. (especially for new players) I propose to not disable the attack
button and if I click on attack and there is no enemy selected, autoselect one
randomly.
So the flee mode would only change what happens when I click on the screen.
(either attack or flee)
Original comment by SamuelPl...@gmail.com
on 10 Dec 2010 at 7:46
Good point. However I think the most common use-case of fleeing is that the
player wants to flee the fight completely rather than do the advanced
move+attack action. Especially for new players I think. I like that we have the
ability to do the advanced actions, but I think we should focus on the most
common use-case. If that is the case, then keeping the fleeing action between
turns is probably the most intuitive thing to do for new players. Maybe a
setting? :)
Original comment by oskar.wi...@gmail.com
on 12 Dec 2010 at 10:31
I have the following motivation:
If I start fleeing with my 10 AP and I get to a field where monsters are still
around, then I have 4 AP and I am not able to:
a) move
b) attack, (because I am a noob and don't know the unintuitive long click)
All I can do is clicking "end turn".
IMO my suggestion is the best way out of this.
IMO it shouldn't be a setting.
Original comment by SamuelPl...@gmail.com
on 12 Dec 2010 at 2:53
Original comment by oskar.wi...@gmail.com
on 20 Dec 2010 at 9:11
Original issue reported on code.google.com by
erwr...@gmail.com
on 20 Nov 2010 at 7:37