Actually, thanks to the miracles of math and JavaScript, you can get real-time updates on mouse coordinates. It's an EXTREME pain in the ass, but you can do it. I built a library around it. I'm getting around to releasing it this week, hopefully.
Basically, at client/new, you have to run a bunch of calculations about the client's screen settings and interface elements. Then, using a loop and some hooks, you have to keep track of the interface. From there, you have to nab the mouse coordinates on the client's screen via JavaScript and run some calculations based on the interface to find out where the mouse is located over the map.
How feasible is that for multi-player? Is there a hub for the library yet? I'd like to keep an eye on it.
| |
KetchupKid wrote:
How feasible is that for multi-player? Is there a hub for the library yet? I'd like to keep an eye on it. Uh, I haven't tested it for multi-player yet. I'd really like to though. For single player, it's surprisingly quick. The hub isn't up yet, but like I said, hopefully this week. | |
The JavaScript invokes a call to Topic, this should be as fast as any client-initiated command (a key press, mouse click, etc.). If the JavaScript loop notifies the server of new mouse coordinates every tick it's not really any worse than having a client who presses a key every tick. Since the loops are running in JavaScript they exist on each client so they don't use up the server's resources. This should work find for multiplayer.
| |
Forum_account wrote:
The JavaScript invokes a call to Topic, this should be as fast as any client-initiated command (a key press, mouse click, etc.). If the JavaScript loop notifies the server of new mouse coordinates every tick it's not really any worse than having a client who presses a key every tick. Since the loops are running in JavaScript they exist on each client so they don't use up the server's resources. This should work find for multiplayer. The only thing that may become a problem is the calls to winget() that need to be made to keep track of the interface. | |
Wasn't there a way to detect window resize events in JavaScript? Or was it just for detecting minimize/maximize type of events?
I guess you'd still have problems with winset calls that change the size of the map control, but I would expect these to be much less common. Since it's a code issue (as opposed to a client-side interface issue) it's not as big of a deal. | |
Maximizing and minimizing and movement are not caught by JavaScript.
As for the map, the code already adapts to changing sizes, positions, icon-size, and anything else that could happen to it. It can also account for three additional maps, as well as deliver map, screen, and pixel coordinates of the mouse's location. EDIT: Thinking about it, I think if I do it right, I can actually offload these loops onto the client end using JavaScript. I'll have to do some testing. | |
I have a few procs in my current project which almost completely replicate giving and receiving damage in Link to the past. I fund it very fun and cool.
| |
Bravo1 wrote:
I have a few procs in my current project which almost completely replicate giving and receiving damage in Link to the past. I fund it very fun and cool. As in the collision in the swordplay, or just the heart system? | |
Collision, but I could write up a quick little library on the heart/health system.
my procedures basically draw a hitbox in front of you based on your direction, if any mob is in that hitbox, it calls the damage proc. You can refer back to other variables if you like the ideas of different weapons, damages, weapon reaches, etc. Edit: The damage proc also pushes enemies away from the attacker, depending on their relation to the damaged mob, it also makes their icon flick a damage icon state. currently I just use a simple "flash" icon state where the player turns pure white for a fraction of a second. no sound implemented yet, but they could be easily added. | |
Well, naturally that is what a collision system should do. Though, for it to be perfect, it wouldn't be a box, it would actually model each icon. Which would take forever. The heart system is easy, not a big deal. Anyways, I suppose that would be the best way - though I'd imagine it would still be an emulated projectile.
Maybe I'll work on this system over my winter break - shouldn't be too difficult. Now to read forum_accounts pixel movement... | |
As it turns out, using Pixel_Projectiles as a base, you can modify it to fit with Pixel_Movement and as a result is perfect for projectiles. there's a lot of trial and error involved though.
Sorry f I seem unoriginal but I'm the kind of person who can't really create original things, but I can use former tools and modify them to make them better.... if that makes any sense ._. | |
Bravo1 wrote:
As it turns out, using Pixel_Projectiles as a base, you can modify it to fit with Pixel_Movement and as a result is perfect for projectiles. there's a lot of trial and error involved though. Of course that does! Haha, don't think you're unoriginal. Some of the things I've seen from you I haven't seen on BYOND before, and that's impressive in itself! | |
Some grid-based games feel very grid based. Startropics for NES didn't feel very grid based even though the movement was (or maybe you could move half a tile at a time, I forget). I suspect this too is a consequence of BYOND's low default framerate. For smooth motion people rely on the smooth client-side tile-to-tile transitions. If you manually change an object's pixel_x and pixel_y vars to simulation movement that isn't tile-based then you lose this built-in smooth motion.
It's important to realize that you don't have to use the grid, at least not for everything. BYOND's default movement system is entirely based on the grid but you can create attacks that don't use it. For example, if the player can shoot in your game you don't have to limit shooting to being 4 or 8 directional. As others have mentioned ([link]) you can use the mouse to break out of the grid in some ways.