I'm working with an MMORPG, and I'm starting to wonder something when it comes to movement change. Right now, any user can request movement of 4x (which could be 4, 8, 12, 16, 20) and the default is 16. The client then sends "moverequest, [Xchange], [Ychange]" to the server, and if the server allows it, it sends "move,[Xchange],[Ychange]" with either modified values or the original ones (that is by default).
Now, I've made it so that the client won't ask for a movement change if there is an obstacle in the way (without sensors), and since the beginning, this little request sequence makes a very slight delay in every 16 pixel movement (as it is an incremental movement, not sudden). Should I make it so that the client simply tells the server that he's moving 16 pixels in X or Y right away, or should I keep the request system and make it so that the client starts a request just before his playerobject has reached 16 pixels/stopped moving? The latter part would require me to make some kind of 'rates' variable, depending on your ping to the server (in other words how good your internet is).
What do you guys think? I am definitely capable of pulling off the second idea, but how effective will it really be? What are the odds of someone hacking the game if he can control the move commands all by himself and not through requests?
If you are unfamiliar with the delay that I am talking about between each movement, think of Age of Empires when you play on a laggy server, or runescape when every click takes a short while for the command to actually be executed (like moving somewhere).
Like I thought.. Even my website has people with more ambition.
E-Man: "The lag part you're talking about makes sense, how you need to send alot of information across the net and the delay results from the internet connection.
But the hacking part seems new to me, I can't figure out how that could be hazardous."
Unless the game has hard-to-reach areas that contain bonuses, I doubt a hacker would bother to interfere with the movement of the player - things like score, cash or items would be more important for progression in the game.
Rather make the client tell the server that the player is moving/attacking and show the actions on the client immediately, and ask the server to let the player collect bonuses and do other things that are not time-critical. Delayed movement of the player becomes tiresome..
"Hello, here's a question. By the way, you're site's rubbish." Not the most endearing topic I've ever seen (though Silvernova's post wasn't exactly helpful either).
CodeCannon's said pretty much what I would have. Perhaps concentrating on making sure that the client program can't be changed by the player would help as well.
What can be done to prevent a hacker from changing the client? I'm curious. Would compressing the runtime of MMF programs make it harder to disassemble and change it? Are there ways to encrypt the program?
Yeah!
Encrypting the data sent from the client would work, but what about the key for the encryption? How is it stored? Would a hacker be able to disassemble the program and retrieve it, or is it also encrypted?
Assault Andy Administrator
I make other people create vaporware
Registered 29/07/2002
Points 5686
26th December, 2006 at 17:22:16 -
WillWill - Okay you need to take a fair few variables into mind here. The thing about the mooapi is that it's kinda slow to be honest and there's not that much you can do about it. Sending requests is actually kind of slow, even if you had a really fast server. Both your movement ideas are quite doable, but sort of impractical if the player has to wait long periods of time. I have a suggestion for you that would be fast and provide a minimal amount of security:
Firstly, screw the request idea. It may be secure, but it slows things down and makes the player angry. Use the basic concept of movement, getting the client to tell the server when it's moving, 'simply tell the server that he's moving 16 pixels in x or y'. As long as you have an effective method of dead reckoning programmed into that it should be fine. Now you might ask: But how can I stop hackers from modifying the movement speed?!? Well what you can do is have the server check that the movement is vaild everything it recieves a movement command. That is to say, the client should only be able to move from 0,0 to a position lower or equal to 16,16. The client can't just somehow get from 0,0 to 530,120. Pseudo Code for server:
On receiving a movement message
+ Difference between X position recieved and current x position is <= 16,
(or however your movement system works, eg make sure that xchange <=16)
then do nothing.
otherwise:
boot client from server with "out of sync" message
(or just tell the client to move back to where they were before)
CodeCannon - For hacking an online click game, it is unlikely that the hacker would disasemble the program. It is difficult to do that to click games as they are all compiled by clickteam in a similar way. A much easier alternative would be to ues packet spoofing. This involves recording the messages sent out by your machine, analyzing them, and then modifying them as they are sent. For example I could record 1000 packets of me playing a game, and then I analyze the data I have collected to try and work out which packets are making me move, which are making me talk, etc.
Say while playing I typed the word "HELLO WORLD", I could quite simply then search all the packets for that data, and once found I could note the command used. Then I could built a program that could replicate the packet, change the message and send the packet very fast; effectively creating a simple spamming program.
Using that same information I could try and find things like sending coordinates and item data to modify. Even using basic encryption will slow down the hacker because he will not be able to search for 'hello world' as it will be encryped and show up as garbage.
HOWEVER In short... (and this is addressed to everyone) Do not worry about your game security too much until you actually have a game. I see people spending ages in the design and basic engine stages of their online games, trying to make their game all secure. The thing is you should worry about security when it becomes an issue. People won't hack your game unless it's really popular. Start to worry about the security more when you have a few thousand people playing, not 30.
I hope that answered your questions. Sorry for the late reply.
Just for interest - what dead-reckoning can be used for online platform games? There's a lot of fast movement and action in there - are there any decent ways to co-ordinate the game and to keep the lag of the movement low?
Assault Andy Administrator
I make other people create vaporware
Registered 29/07/2002
Points 5686
7th January, 2007 at 17:54:13 -
Sorry for this late reply, I was away on holidays for a week.
CodeCannon - For platform games you are right, there is a lot of fast movement and action. I remember seeing a mario multiplayer engine. I don't have it anymore because I reformatted and didn't save some of the examples.
But for the basic principles, I think a good method is to send the commands of the movement, and then simulate them on the other machine.
Take this example - Say you had two machines (Client 1 and Client 2), each with a basic platform movement that you created. Both movements are exactly the same. If you press jump on Client 1, you would want the same player to jump on Client 2. Now if you didn't use dead-reckoning, you would probably do something like Send the x and y coordinates of the player every so often. That would be extremely ineffective for obvious reasons. However, since both player's movements are exactly the same, you should know what both jumps look like. In effect, if you want a player to jump on one screen, all you need to do is send the command "jump" and have him jump, instead of sending positions. In pseudo Code:
* If player 1 presses jump
Then
+ Jump on my screen
+ Send command "Jump" to all other players.
* If I recieved the message jump from another player
Then
+ Make that player jump on my screen
Basically, it's just like somebody is yelling at you from across the room, telling you which buttons they want you to press. You can then duplicate this same idea for the rest of the controls: You only need to send the command to start moving right (When the player presses right) and then another command to tell the player to stop (when he is pressing no buttons).
Now this idea would work in theory, however you then quickly run into the problem of lag. . It can't be eliminated and therfore must be dealt with. Take this example into account:
Client 1 sends the command "Start Moving Right".
Client 1 then sends the command "Stop Moving Right" 50 milliseconds later
Due to lag, this message is recieved 80 milliseconds later, instead of 50. This will mean that Client 1 was moving on Client 2's screen for 80 milliseconds, instead of the desired 50, and therfore has moved further. The games are now out of sync. What you have to do is send extra information so that the Client knows where you decided to stop. Pseudo Code:
* If player 1 presses jump
Then
+ Jump on my screen
+ Send command "Jump" to all other players AND send my x and y coordinates.
* If I recieved the message jump from another player
Then
+ Move the player to the recieved coorinates
+ Make that player jump on my screen
Now you will have an engine that will always be in sync. However it will also be extremely choppy, whenever you recieve a message the player will 'snap' to where he received the coordinates. In an engine I made a while ago I do this:
* If player 1 presses jump
Then
+ Jump on my screen
+ Send command "Jump" to all other players AND send my x and y coordinates.
* If I recieved the message jump from another player
+ Player is <= 50 pixels away from the recieved cooridnates
Then
+ Slowly move the player to the recieved coorinates via a custom movement
+ Make that player jump on my screen
* If I recieved the message jump from another player
+ Player is > 50 pixels away from the recieved cooridnates
Then
+ 'Snap' the player to the recieved coorinates
+ Make that player jump on my screen
Now what is happening here:
If the player is less than or equal to 50 pixels away from the coordinates he recieved, then we use a custom movement to 'slide' him to the position he is meant to be in. This can be in the form of something as simple as:
My X is lower than recieved X, X = X + 1.
Then when you finally reach where you are meant to be, execute the movement. If you are more than 50 pixels away, we make the player snap to where he should be. This creates 'visible' lag much like you would see in any action game where a player moves very fast to another location. It is to keep him where he should be. 50 pixels is just a random number, you have to change it until you get a good feel of how often the player should 'snap' depending on your game.
WillWill - Dead reckoning simply means sending and recieving as little data as possible and using intelligent engines\techniques to do so. See above for an example. I think you already knew this, but not the word for it. Google it for some more information. I think you're overcomplicating things a bit with things like "I suppose you could analyze the packets". The Mooapi can't be sped up, but it's still quite fast and useable. You just have to know how to work it properly to get it to do what you want. The only thing is you should send numbers instead of words whenever possible. Eg: Send the number 1 instead of the words "Move Left".
MooClick can only send strings - is there a way to convert the values/strings, so that it only uses 2 characters in a string to hold a number with a range of ~64000, like a 2 byte integer?
Assault Andy Administrator
I make other people create vaporware
Registered 29/07/2002
Points 5686
10th January, 2007 at 02:19:57 -
Well I'm sure you could just use an ascii character object, in which you can convert a number to its equivalent ascii character. If you are using MMF 1.5 there are plenty of objects to do that for you, I'm not so sure about objects to do it for Fusion 2.
Advertisement
Post Reply
Edited by the Author.
. It can't be eliminated and therfore must be dealt with. Take this example into account:
