Server-side sprite position verification

[Shaun Dreclin]

Image for reference:

The walls are made up of pieces like this:

 

So I'm wanting users to be able to place posters (like the red thing) and other items on the walls of the room.

I've already got it where I can add the posters into the room file and have them render in the proper position, I'm just a bit stumped on actually placing the item and having it's position be verified (as in, on a valid wall)

I feel like I should look at the top left and bottom right corners of the poster, and check behind those points to see if there is a wall. If both corners have wall behind them, it's a valid position. Just don't really know how to do that with pixi, is there some way to look at a pixel and find all the sprites in that pixel? (clicking through transparancy and stuff)

 

Then after all that, I need to verify the request again on the server side, to make sure the person didn't just modify their client to get past the client side verification. But the server doesn't have pixi on it haha so it can't really look for sprites

[ivan.popelyshev]

Veryfying pixels is a very bad idea. You have to write a model which will be completely independent from pixi and work both on client and server. 

[xerver]

Separate your data from your rendering. Don't think in terms of sprites and pixels, think in terms of entities and objects.

On the client, those entities and objects just happen to have sprite counterparts, but on the server they don't. You game, and the engine that runs it doesn't include pixi at all. Your client code then translate game data and objects into renderable things.

[Shaun Dreclin]

So the question becomes how do I compare the requested xy position to the wall data?

{
    "tile": [],
    "item": [],
    "wall": [{ "id": "wall_1", "z": 0 }, { "id": "wall_1", "z": 4 }, { "id": "wall_1", "z": 8 }, { "id": "wall_1", "z": 12 }],
    "witm": [{ "id": "poster", "x": -50, "y": 60 }],
    "user": []
}

That's the JSON for the tile containing the poster, you can see the four wall objects

[Fricken Hamster]

Server should run the same authentication as client.

Off the top of my head, here is how I would do it.

For the purposes of each wall, assuming only rectangles for both wall and sprite, you can think of it as a 2d plane and there are no lopsided posters.
First, extract the projected position value of the top left of the poster on the wall it is being placed on, which can be done with some simple trigonometry. Then you can just check that one rectangle is within the other. Steps can be projected the same way, and check to see the poster is not colliding with any steps on the same plane.

Though if it were me, since there are obstacles like that, I would treat the wall as a grid of W x H of whatever placement unit I choose. Then I can just store open cells in a data structure as opposed to allowing pixel placement.

 

[ivan.popelyshev]

That's not related to PIXI at all. And that's some serious problem, I can consult you on that only for $$.

[Shaun Dreclin]

Yeah I did consider doing cells rather than pixels, that's why verifying items on the floor is so much simpler. Just have to look at a target tile and decide if it's good to accept an item. Though I kind of like the idea of having totally free placement, from a user perspective. Do you think it would be a good idea for the server to calculate all the different planes of valid wall space for posters, add those planes to the room object itself, and send that to the client? Then the client will check if the poster is inside a specified plane, send that request to the server, and the server will also verify it and send back a success or failure for that request.

I guess my problem then becomes I suck at math haha, "simple" trigonometry isn't so simple for me. Time to read some books

----

Ivan, that's kind of an inappropriate response. I came here to an open forum to discuss my game dev issues, not to hire an employee. If you're going to say "I'll help you for money", just don't respond at all.

[xerver]

Using x/y is fine, but your still trying to think in terms of pixels. Pretend that the game "world" has x/y coords that in no way actually mean anything in pixels, but instead mean something in terms of actual distance. For example, each increment of x is 1 meter or whatever you prefer. Physics engines use this tranlation all the time, your game engine would be similar.

The only part of your code that even considers pixels is the client where it takes the world coord, and translates that to screen space (pixels); and does the translation back the other way as well when comunicating back to the server.

----

I would expect that the map is loaded from the server, it contains all the data necessary for the user to interact with it (properties of walls, whether a poster can be placed, etc.) When the user places a poster you ensure it is valid on the client, and if so do the placement immediately. You then translate the screen space coords into your game world coords and tell the server a user placed the poster. The server will evaluate if that is a valid placement, and if so send back a confirmation. If it is invalid (for whatever reason) then it doesn't place the poster on the server, and sends a response to the client saying it shouldn't allow it either. Upon that negative response the client removes the poster, potentially informing the user why in particular cases.

In this way the server is authoritative about the world,  but the client can make decision it *thinks* will be OK before talking to the server. This is often referred to as "prediction and reconciliation". It is a pretty board topic, but hopeful that helps a bit?

[Fricken Hamster]

Simple way to translate the coordinates for your example is to notice that each wall is just a sheared rectangle.
You can take the x value as is. Figure out the angle the corners of the wall makes, getting a slope value and then multiplying it by the x to get a y offset. Then you can just add the y of the real world coordinate to the offset and then you get a translated y value on the wall.

[Shaun Dreclin]

@xerver

Everything is already based on isometric x/y coordinates, each floor tile and stack of walls has their own position (the walls actually occupy the spaces behind the top tiles in the room). The posters need pixel offsets stored in them though, because there are no actual Z coordinates, just visual offset amounts. each increment of Z is -y by 8 pixels from the origin point of that tile. The posters work by saying draw the poster at the origin point of this tile, then offset it by so many pixels to put it into the right space visually. On the server side, the poster only exists at that origin point and the offsets are just properties stored about them.

I'm not really sure what I would do to convert my existing system into "game world" coordinates. A pixel is the smallest possible unit, so what would be the benefit of making the server not think of pixels when it comes to display offsets?

I get the second part of that though, that's the kind of system I've set up where the server knows everything about the room, sends it to the client, and the client only displays it. It's just the specifics I'm stumbling over, because completely free placement is allowed I can't just store a list of valid positions unless I stored every single possible point. Doing that seems impractical (although it would work!) so I need some sort of way to calculate on the server side say if a client says "Add a poster at position x,y with display offset (-2, 50)" - I can easily check that the given x,y contains a valid wall, but I don't know how to check if say giving it offset (-2, 50) would make the poster render up in the empty area above the room.

----

@Fricken Hamster

Your post there actually makes a lot of sense to me. I think for that to work I'd need to store a list of all the wall planes server-side, right? That way I would be able to compare the plane of the poster to the plane of the wall, and make sure A was inside B

----

Another option I considered is to simply not verify the display offsets server-side at all, since the server can't "see" the room. If the client is told to render a poster and it's an invalid position, it will just ignore the command and not render it. So if somebody modified their client to place it somewhere invalid, they might see it but nobody else would, defeating the purpose of modding the client in the first place.

[Fricken Hamster]

It would probably be a good idea to have the walls server-side nomatter what you do.

Say if client put poster A on wall B, you would send that client put A on B at translated location C. You shouldn't need to do translations on the server, since the server is fine knowing only a regular rectangle and the x y position of the poster on it.

Validating on the client will probably work fine for this case in a vacuum, but is almost always a bad idea.
One possible complication I can think of is that a client can send a bunch of crazy values, really high values, negative values, long floating points.  As the project becomes more and more complicated, it is more likely and bad data like that causes hard to trackdown errors.

[Shaun Dreclin]

So if I did proper server side verification, after the room is read from the data file, the server would build up a series of plain rectangles and store the posters like that. After it's been sent to the client, then it gets translated into the skewed versions. That's probably the best way for me to go about it.

And yeah that is a pretty good point. What if I did some form of minimal validation? If it's not an integer, if the value isn't within like -500 to +500, deny the client's request. Otherwise accept it regardless of if it makes sense to the server or not. That would stop people from putting in any kind of possibly damaging data