See, even then you're just making compromises to have a subpar system to make up for a feature BYOND should support natively.

The difference between the drag selection and, say, clicking an attack button is you only press the attack button once while the drag selection is a continuous string of inputs. When you swing a sword or shoot a gun you're only telling the server one thing and then the server reacts. With the drag selection you're constantly telling the server new information while it's reacting to your input, any slight hitch becomes much more apparent.

It's just something which needs to be handled on the client's side.

Forum_account wrote:

That's what happens for everything. Clicking and dragging a box is a sequence of actions with the server reacting to input. Fighting an enemy is a sequence of actions with the server reacting to input. There's no difference.

There is a major difference I don't think you are seeing. It's a matter of single input vs continuous input. When you do something like swing a sword you send one command to the server and you're done with it. There is an immediate cause and effect, you push a button and something happens.

Sliding around a selection box on the other hand requires a constant stream of information being sent to and from the server. Each tick requires the server to process the player's input then send the player the necessary feedback. Any time there is a slight hitch in the information stream it's instantly noticeable and instantly irritating.

Making the selection box client-side would effectively change it from a continuous input to a single input. Rather than having to send and receive information every tick the player would only be sending relevant information such as what coordinates a selection box starts at and where it ends at.

Okay, nevermind. You are choosing to ignore what I'm saying.

It would make sense if you at least attempted to understand it, but everyone knows how you operate so I'll try to break it down for you.



While playing a video game with other people you're using what's called a game client. This game client displays the interface, plays music, and even captures button presses. In one particular game there might be a button which causes your knight character to swing his sword. We'll call that the sword button.

Whenever you press the sword button your game client sends the message "I wanna swing my sword!" to the game server. The game server is what takes the message, figures out what's supposed to happen next, then sends the results back to your game client. Each time you press the sword button your game client takes your input, sends it to the game server, then the game server sends back what happens next. It's a direct cause and effect, you press a button then something happens.

Sometimes you just want to swing your sword once, when that happens you can pretty much just press the sword button and forget about what happens next. There might be a tiny delay between when you press the button and when your character swings his sword, but it's small enough and only happens for a split second so there's a good chance you may never notice it. Other times you might want to swing your sword really fast. You'll mash down on that button over and over, causing your character to swing his sword wildly. While you're rapidly pressing the sword button there might be a delay here and there, but since you don't have machine-like precision with your button presses there's no break in rhythm. Many of your button presses might have been too soon, your character wasn't ready to swing his sword again so your input was ignored. Other times there was a slight delay from when you swung your sword and when you pressed the sword button again. Either way, your inputs were just erratic enough to leave any latency issues completely unnoticed.

This method of pressing the sword button and causing an immediate reaction, we'll call that single input.



Now there's this other game, rather than playing as a knight with a sword you're playing as a space man with a laser blaster. Whenever you click something your space man shoots a big red laser beam at it. While you're holding down click the laser beam continuously shoots out in a line, following your cursor. As you move your cursor around the beam follows with pixel-perfect precision.

While it's slightly more complicated than the previous example, the basic idea is the same. You click your mouse, your game client tells the game server you want to shoot a laser, since you can't build the laser on your side the game server makes a laser for you then sends it your way. Every time you move your mouse around your game client communicates with the game server and your laser beam's position is updated.

We'll call this other method continuous input, it relies on constant updating.



Now it might not seem like much, but there's a world of difference between the two. In a perfect world you're going to be going at 100% speed 100% of the time, but in the real world connections are unreliable and they tend to dip randomly. Maybe there's some faulty wiring somewhere and your game client fails to hear from the game server for slightly longer than usual. With the single input command you're swinging your sword at whatever irregular pace, the lag is easily disguised and can be ignored. With continuous input you have a constant stream of instant feedback. While moving around your cursor and updating the laser beam, any small hiccup is noticed immediately. If the laser is moving at along 20 pixels per tick then suddenly jumps 40 pixels you can quite plainly see you experienced a small lag spike.

Forum_account wrote:

There's the problem - there's no such thing as this constant updating that you're talking about.

Yes there is, have you not been paying attention to this whole conversation? When you do something like drag a selection box around you're doing this constant updating which is completely unnecessary. Stack all that on top of the sort of input lag you're already dealing with and you have a very slow and clunky control interface.

Rather than having the box drawn on the server side it would be much, much more efficient to have the box drawn on the client side while the coordinates are sent to the server once the player has made their selection. It has to be as smooth and quick as selecting a bunch of icons on your desktop.

Lag spikes are noticed with the "other" kind of input too and players ignore them just as easily.

When you're using an input>reaction sort of command it's much harder to notice any sort of lag because of the nature of a command. When you're dragging around a box or moving around a laser beam you have constant feedback of your connection quality. You have a frame of reference to tell whenever the game hitches.

I think the best course of action would be to bug Tom until he makes it a proper feature. It's pretty much the only major hurdle I can think of holding back proper RTS games. I mean, we've already got an isometric mode and tons of other features which cover pretty much everything else.

If Tom wanted to open the doors for a whole new genre of games he'd add drag selection.

The problem with MouseDrag() (and the other mouse procs) is that it doesn't update the mouse's pixel_x and pixel_y within each tile. Another issue is that the DrawBox() proc needs some kind of params argument, allowing you to specify the corners on the pixel level, unless some other method can be made for the actual drawing of the selection box. We already have maptext, so it seems like there should be a native method of drawing directly on the map, using a mouse. This wouldn't just benefit RTS games, but also painting type programs and games.

I would assume MouseDrag() initiates the box selection on the client's side, the client then resizes the box without having the server draw the box for him, then once the client releases his click the final coordinates are sent back to the server and the box is removed from the screen.

The stylization of the box wouldn't have to be too complicated. You would at the bare minimum need a border color and border width. I'm not entirely sure what you'll be capable of so if you want to add a fill color for the box you would also have to add alpha blending so you can see through it.

Couldn't you make some way to draw a pixel-perfect box on the client's side?

Scaling is a much more complex operation, and shouldn't be necessary just to draw a simple box. It would also likely be quite inefficient, and might defeat the purpose of even having it be client-side.

I personally wouldn't use a fill color, because I think that's just way too distracting. My concern is that if the box is tile-based, then it just jumps around as you move it, and I don't like that. I want to have a selection box that moves smoothly, and sticks exactly with the mouse's location. I want it to be as smooth as the selection box you can draw to select multiple icon states in Dream Maker's icon editor.

Now if the selection box is drawn pixel-perfectly, having it be done by the client is even more necessary, since otherwise it would be sending far more messages to the server than it would if it were just tile-based.

Is anything like this even possible to make happen with BYOND? In other languages, selection boxes are a very trivial thing to make.

SuperAntx wrote:

When you do something like drag a selection box around you're doing this constant updating which is completely unnecessary.

You're still assuming the box needs to be pixel-based. It might look nicer but it's not necessary. Even if it is pixel-based, you'd only be sending mouse position updates to the server periodically. Moving the mouse looks like a constant stream of events but it's really a discrete set of events.

For a tile-based selection box it takes 10 events to make a 5x5 box (1 MouseDown, 8 MouseEntereds - 4 over and 4 up, and 1 MouseUp). BYOND can certainly handle this and people won't mind playing an RTS with tile-based selection boxes. People play BYOND games that run at 10 frames per second! If you can make a fun game, you'll be surprised at what types of problems won't bother people.

D4RK3 54B3R wrote:

This is related to the client-side transformation features I brought up a while ago.

You can take any solid color icon and just do a simple scaling transformation to create the rectangle you need for the box selection.

You should already be able to scale icons on the client with the icon.Scale() proc. The "problem" here is that the server has to tell the client where to draw the box.