Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (491)
Games in Android Showcase (112)
games submitted by our members
Games in WIP (556)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Writing networking for my game  (Read 1510 times)
0 Members and 1 Guest are viewing this topic.
Offline RegeX

Innocent Bystander




Java games rock!


« Posted 2005-03-12 18:45:23 »

Hey,

I'm writing a MMORPG in Java. So far, I've written a bit of the client, and a bit of the server, and I've run into a few hassles:


  • Player awareness

I'm really having a lot of trouble trying to work out how the server is going to handle informing every client of every NPC/Player's position and any new characters that spawn/login. I'm planning to have 50 or so clients in the game, and I imagine sending a packet to each one purely to inform them that an NPC moved to 51,100 is going to be laggy. Does anyone have any tips they can give me regarding this? It'd much be appreciated. By the way, all of the game is using TPC/IP.


  • Packet encryption

I know a few people who are going to try and cheat at my game (*sniffle*), but I've made the server secure, encrypted packets etc. But I'm lost as to what encryption scheme. I'm currently encrypting using DesEDE with a dynamic key (changing each outgoing packet), and I think this'll sort of murder the server, encrypting so many things so quickly (or trying). I would write my own encryption/descryption methods, but I'm wondering what the most efficient/safest things to do are.

And that about sums up my problems =P.

Thanks,
RegeX.
Offline Herkules

Senior Member




Friendly fire isn't friendly!


« Reply #1 - Posted 2005-03-14 05:27:30 »

Quote

I'm planning to have 50 or so clients in the game, and I imagine sending a packet to each one purely to inform them that an NPC moved to 51,100 is going to be laggy. Does anyone have any tips they can give me regarding this? It'd much be appreciated. By the way, all of the game is using TPC/IP.


FlyingGuns sends position-, speed- and  acceleration-vector and lets every client use that information for extrapolation of motion. The sending client performs the same extrapolation code in parallel and transmits new data only if an error treshold gets to big. For FG, this is all 3D. For just 2D, the error computation is much easier. This way, *no* traffic is created when a player moves along a straight line.

If you motion model does not know acceleration, you can leave that out as well.

TCP is a good choice here, bc. obviously you cannot live with packet loss. In return, proper handling of time (!difficult topic!) makes latency become less critical.

The current implementation in FG has some drawbacks. Doing it right, the server can be another instance reducing traffic by evaluating rel. positions/speeds of object pairs in order to decide to drop or delay further packets.


HARDCODE    --     DRTS/FlyingGuns/JPilot/JXInput  --    skype me: joerg.plewe
Offline aldacron

Senior Member


Medals: 9
Exp: 16 years


Java games rock!


« Reply #2 - Posted 2005-03-15 00:23:00 »

Quote


  • Player awareness

I'm really having a lot of trouble trying to work out how the server is going to handle informing every client of every NPC/Player's position and any new characters that spawn/login. I'm planning to have 50 or so clients in the game, and I imagine sending a packet to each one purely to inform them that an NPC moved to 51,100 is going to be laggy. Does anyone have any tips they can give me regarding this? It'd much be appreciated. By the way, all of the game is using TPC/IP.


First, just to make sure we're clear on terminology - 50 clients does not an MMORPG make. Remember, the first 'M' stands for 'Massively'. When asking for help on message boards, it's always good to use proper terminology. Had you not mentioned that you planned on ~50 clients, I would have assumed you intended to support a few hundred or a few thousand.

Now, to solve the awareness issue. One technique commonly used in multiplayer games is the Sphere of Influence. Each avatar is encapsulated in a sphere and is only 'aware' of other entities within that area. This greatly reduces the number of updates required per client. The size of the sphere depends on the type of game and the game mechanics. In a 2D overhead or isometric game, the sphere (or circle in this case) might extend a few tile rows beyond the client's viewport. In a 3D game, you might extend it to what testing determines an acceptable range - perhaps even to the far clip plane. The density of the world's population could impact the size as well. The goal is to find, through trial and error, a radius that makes sense in the context of your game.

You can reduce the number of updates even further by using Herk's suggestion of sending position, velocity, and a direction vector (which you *might* not need in a 2D game, depending upon how you represent velocity). When combined with the Spehre of Influence, the sphere can be used as a trigger of sorts. There are two events that aid in determining who to send updates to and when to send them.

The first event is when an entity enters a client's sphere. This informs the entity that it has a new client to send updates to, and it should immediately send its current position, velocity and direction and add the new client to an internal update list. Each time the entity's state changes (i.e. the entity transitions from walking to standing still) OR its velocity or direction changes, it then walks through the list and sends a new update to each client with the current position, velocity and direction.

It's important that updates be sent when velocity or direction change, as that affects how the client extrapolates the next position. State changes will usually affect the current animation. The position need not be sent each time it changes, because the client is getting that through extrapolation anyway. However, when the server does send the current position during one of the state/velocity/direction changes, the client can use that to verify that it has the entity at the correct position. If the positions don't match (which often occurs due to network latency), then the client should interpolate from the incorrect position (the one the client previously extrapolated - remember the server is always authoratative) to the correct position the server sent in the update. If you didn't interpolate, the player would be seeing the graphical representation of the entities 'teleporting' (or 'jumping' you might call it) from one position to another. The interpolation helps smooth things out so that the entity appears to move to the correct position. The player shouldn't might not even notice that an error occured (though sometimes it's painfully obvious).

The second event that helps manage this system is triggered when an entity leaves a sphere of influence. At that point, the entity removes the affected client from its internal list so that that client no longer receives updates for that particular entity. You will need to send a final update packet, but what that contains depends on how you've constructed your system. If the client is aware of the sphere of influence (and this may or may not be a good idea - again it depends largely on the context of your game), you can send your standard position/velocity/direction packet and let the client determine that the entity is no longer visible. This is more error prone though, as latency might cause the client to miscalculate (this could potentially result in an entity that is visible but cannot be interacted with - aka 'lag ghost'). You might opt instead to send a special packet that informs the client to remove the entity from the scene.

The Sphere of Influence may not be relevant to your game. For example, if your world is divided up into easily manageable zones that are not densely populated then you might opt to use the zones themselves as your area rather than the influence spheres. But I wouldn't advise that unless your zones are really, really small. Whatever technique you use for partitioning, updating only on state changes is a must to reduce bandwidth. Extrapolation allows the client to maintain a reasonably approximate view of the game world, while interpolation helps bring that approximated view to a higher degree of accuracy.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline aldacron

Senior Member


Medals: 9
Exp: 16 years


Java games rock!


« Reply #3 - Posted 2005-03-15 01:16:54 »

Quote


  • Packet encryption

I know a few people who are going to try and cheat at my game (*sniffle*), but I've made the server secure, encrypted packets etc. But I'm lost as to what encryption scheme. I'm currently encrypting using DesEDE with a dynamic key (changing each outgoing packet), and I think this'll sort of murder the server, encrypting so many things so quickly (or trying). I would write my own encryption/descryption methods, but I'm wondering what the most efficient/safest things to do are.


No matter what encryption scheme you use for normal game data, anyone who wants to hack your packets will do so. Take a gander at the emulators and cheat tools out there for UO, EQ, DAOC and whatever else exists. I've followed the development of a DAOC emulator for sometime, and though Mythic changed their encryption scheme a couple of times the emulator team was able to crack it in short order. Account/credit card info is a different story. For that end of the game, you can go with some more heavy duty encryption that mere mortals aren't likely to crack in a lifetime.

Packet Encryption, like CD copy protection, is a barrier against the lazy. My advice is forget about it. Better to spend your time thinking about packet compression schemes (sending as much data in as few bytes as possible). The two primary areas of cheating you need to be concerned with are client side tools and packet hacks - neither of which can be prevented by encryption.

Not long after DAOC was released there were a couple of 'radar' programs available that allowed players to see the position of enemy players who were otherwise out of view. This gives a giant, unfair advantage to radar users. Mythic eventually learned how to detect radar programs and, through a combination of red flag raising at the code level and observation by employees of those so marked, have suspended and/or banned several radar-using accounts.

Programatically, third party tools like the radar program are hard to detect in the general case. One way to handle it is to code the server to look for suspicious activity. What constitutes suspicious activity depends on your game. The problem is that this can become very complex. For example, detecting radar users might involve storing a sampling of a player's position updates over an interval of time, the tracing back through the list of position updates to determine at what point an attacker started on a straight vector toward another player and if the victim was actually visible at the time. If the victim was not visible, increment a counter on the player's account. Once the counter has passed a certain threshold, raise a red flag so that a staff member can then silently observe the player in game. This is just me rambling, but this is the sort of thing you have to deal with to detect third party program use programmatically. And where do you draw the line? Do you try to detect macroers (like those that plagued UO once upon a time)? Radar users? Key bots (something that presses a certain key or a sequence of keys over and over and over without player interaction)? There's no easy answer to this.

Another method of third party tool detection at the code level is to scan the operating system's active processes for known cheat programs. While this can be much simpler and, potentially more accurate, than the general case of detection on the server side, it can also be error prone. It's possible to mistake a legitimate program for a cheat tool, the creators of the cheat tool will most likely be diligent at changing the application's memory signature, window title, or whatever else you used to clue in on it once they discover what you are doing. At best, you would still only be able to raise a red flag and have someone monitor the account. The bad part is that the client would have to send a packet to the server to do so. It wouldn't take much for someone to write a packet sniffer that detects the red flag packet and either discards it or modifies it such that no red flag is raised.

Another form of cheating you need to be on the look out for is packet modification. Unlike detection of third party tools, this is normally much easier to detect in the general case, but it requries a great deal of forethought to do so. First, you need to validate that each packet is the size it should be. You might also want to send a CRC key with each packet to verify integrity (though this, again, is only good against the lazy). Most important of all is that the server needs to strictly validate all data coming from the client. Is it really possible for player X to be running at double the normal speed? Is player Y's hit point value valid? The server knows the game rules, and it knows the game mechanics. With that in mind you should be able to validate every piece of data that comes across the pipe and catch 99.9% of the modified packet values that come through. Usually, when people cheat they do it in a big way. Forget increasing hitpoints by 10, they do it by 1000. 10% speed increase? Bah, try 500%! These will be the majority of cheats you see and will be blatantly obvious. The other 0.1% are the ones that are smart enough to cheat within the bounds of the game mechanics. These are likely impossible to catch in code, and most likely won't give you any reason to red flag them. The best you can hope for with these guys is that they are observed doing something they shouldn't be able to, or make a mistake later on.

Exploiters are another category of cheater, but it's hard to catch them without first knowing what the exploit is. Some of them might get caught in the nets of the third party tool detection, or through packet validation. But the majority will likely be reported by other players.

I hope all of this makes sense to you. Encryption of game data is really a wasted effort for a small scale project, IMO. Big companies like Sony are going to be targetted by every leet script kiddie and his brother, so encryption will discourage a large number of them (though over time the more persistent will figure out the encryption scheme, decode the packets, and make it all available somewhere online in one form or another). If you really, really insist on encrypting  your packets, you might want to roll you own algorithm - either something from scratch or a modified version of an existing one. Any encryption libraries that are publicly available to you are also publicly available to the cheaters. By rolling your own you might get lucky and delay them a few days Smiley
Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

Nickropheliac (15 views)
2014-08-31 22:59:12

TehJavaDev (23 views)
2014-08-28 18:26:30

CopyableCougar4 (32 views)
2014-08-22 19:31:30

atombrot (41 views)
2014-08-19 09:29:53

Tekkerue (40 views)
2014-08-16 06:45:27

Tekkerue (35 views)
2014-08-16 06:22:17

Tekkerue (25 views)
2014-08-16 06:20:21

Tekkerue (37 views)
2014-08-16 06:12:11

Rayexar (72 views)
2014-08-11 02:49:23

BurntPizza (49 views)
2014-08-09 21:09:32
List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06

List of Learning Resources
by SilverTiger
2014-07-31 11:54:12

HotSpot Options
by dleskov
2014-07-08 01:59:08
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!