Problem description:
I'm trying to decide whether to go with tile movement or pixel movement for my project. The issue is I've already coded in a lot of the combat system.
Now, I like how easy it'd be to control movement speed with pixel movement considering I'd like players to have varying speeds based on their agility. I'm having a hard time finding a smooth way to implement a control on movement speed for tile movement. On the other hand, I'm worried that the combat system won't work as fluidly with pixel speed considering how the attack verb uses some get_step procs. I've experimented with it, and there are some "blind spots" in which players seem to not be attacked (mainly regarding diagonals). I'm also not pleased with the choppiness of the smaller pixel steps.
Anyone have any advice?
I don't think it's so much an FPS issue. I think I may have to make adjustments to the animations to fit to the smaller steps.
Regarding the pixel movement, is there a good guide out there on it? | |
I don't really think so. It's fairly new, so you need to look at the reference.
And about the FPS. I'm not kidding. Just try putting world.fps to about 40 and tell me if it helps. | |
No, that's exactly what I put it at. The animations are carrying all the way through each step. :\ It looks rather hokey.
| |
I've managed to get it working semi-smoothly. The pixel movement, that is.
As far as combat, it's a bit buggy. I've swapped... for(var/mob/M in get_step(src, usr.dir)) ...for... for(var/mob/M in obounds(src, usr.dir)) ...just to try it out. I realize their arguments aren't the same, so obviously it's not working as desired. The attacker can attack the person whether he is facing them or not. I understand why this is, but what's the best way to fix this? Also, I have a bit of code that allows the attacker to face the person their attacking automatically if they are targeting, as such: if(client && target && get_step(src,target)==1) Would it be best to swap this out for: if(client && target && bounds_dist(src,target)==16) Or is there a better way of doing this? | |
I use my code to determine what pixels to search depending on the direction.
var x=0, y=0 That's just one unrefined example of doing it. Also, I would advise you swap that out, yes. You may want to change 16 to something higher, though. | |
Ah, I see. Thank you for that. Now what if they are facing NW,SW, etc.? Will I need to specify those?
| |
Nope, that's been accounted for.
If you check it out, you will see that & is used instead of ==. & is a bit-operator for AND. Think of it like a multiple choice circle with NSEW being the choices, the & allows you to circle in more than one option whereas == would force you to pick just one option. (Or think & as if it was saying 'if it contains X, do this'). So, for NE, it would do y += 16 (NORTH & NORTHEAST = NORTH detected) and x += 16 (EAST & NORTHEAST = EAST detected). There's a lot more to this though but that pretty much sums up the snippet shown. | |
Ahhhhh. I remember reading a bit about them in the DM guide, but they didn't get too in-depth. Thank you for the reference. I'm trying to learn all I can right now.
| |
I'd say pixel movement all the way, because tile based movement is too old school :P
Don't use get_step() with pixel movement, though. Use obounds() and the other procs that accompany pixel movement. It's what I do with mine. It's much more accurate.