Symbol's picture

OpenTK + C# - MMORPG Game Programming

Are their any tutorials out there for MMORPG programming? Using C# and OpenTK? I really need a tutorial.


Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Dinberg's picture

@ Entropy: DoL is mainly designed as an MMO though. But ask on support as I say and I'll point out the bits you need to look at to figure out how to do multiplayer, because the principles are transferrable :D. I have exams on wednesday, so I'm afraid you may have to wait as long as thursday before I can reply. As for licensing I wouldnt worry - I dont mean you should actually run DoL's code, but just use it as an example for your own design ^^.

Savage is completely unrelated to DoL as a project, I was just using it as a multiplayer example for small player games that use server/client as the basis. Similar to Neverwinter Night servers if you ever played it! Hopefully itll all become clear if you look at how dol handles async connections and manages its clients, aswell as the way packets are structured, incoming packets are handled etc.

@ objarni: I agree they probably are very fast. Perhaps the difference is to do with that the contents of a packet are in some sense predictable, like the packet to login will likely contain the Account name and password in a legible format, but swapped about, such that you could look for possible rearrangements of the characters in various changes of the strings? I would guess deciphering is easier if you have an idea what the message is, but I really have no idea I'm afraid XD.

I found the name of the MMO I referred to - Sword of the New World. Must admit I didnt enjoy it very much, but they made a great fuss about this thing called 'X Trap', which apparently prevents cheating in the game. If it suspects any fiddling, it kills the power to your pc. As you can guess, that seems to make it quite unpopular. It doesnt actually have a wikipedia page (Not in this day and age surely?!) but this google search reveals some of the issues people have with it.
http://www.google.co.uk/search?q=x+trap&ie=utf-8&oe=utf-8&aq=t&rls=org.m...

It's quite a heavy-handed and invasive approach, so I just assume there must be a way of efficiently deciphering messages for the developers to consider it a threat as to warrant such an invasive tool's use for prevention. It appears to be used in a few other MMOs aswell.

triton's picture

@objarni:

I know that at least RuneScape, an MMO game I used to play (and also helped develop a private server for) used some methods to encrypt the packets. I don't remember all the specific details anymore, but I'm pretty sure the server on each new client connected, sent an initial packet using RSA with the seeds for a pseudo-random number generator (ISAAC - http://burtleburtle.net/bob/rand/isaacafa.html). Then because the server and client had the same seeds, the server and the client could encrypt the packets using the random-number generator.

I could be wrong though, don't remember all the details. I searched a bit and found a decent explanation of it here: http://www.moparisthebest.com/smf/index.php?action=printpage%3Btopic=356...

Inertia's picture

Well it's obvious that any security measure can be hacked, the only question is how much time does the security measure cost YOU to implement and how much time does it cost THEM to break it.

Imho post-build steps like obfuscation and packing with .Netz should be enough to scare away most people, Smartassembly claims they additionally protect the application so the source returned by ILDASM will not build unless you do some major clean up.

The only measure I can think of atm that will inevitably force hackers to give up is: Patch often. Every patch will force them to do all steps for breaking security again. Although after the first successful hack they know what to look for, this will get tiresome very quickly.

[Packet Hacking]
Both scenarios described by Dinberg sound to me as if the server fails in it's role and leaves clients too much control over what is a legal move and what isn't. The way I understand Quake III Networking Logic it will delta against last acknowledged state by the client, so even if the client intentionally drops a packet, the server will keep sending the "root spell" until the client acknowledges it.
This is more complicated than described in the link, since it does not cover client prediction and the animation system covering up glitches, but for example the Left 4 Dead network system allows you to play with people from the other side of the globe without any teleportation or other weirdness. The worst I've seen so far was ~400ms latency, and the player moved smoothly although reactions to events were somewhat noticably delayed. Valve's Wiki has some pages related to the network code, however it is not very detailed (probably for security reasons).

[unmanaged cheat detection]
What is the issue with using tools like Punkbuster & Co. for managed applications? I doubt you can add this to Dawn of Light since the game's client is not under your control, but I'd be rather surprised if you cannot get those anti-cheat tools working with .Net games.

Kamujin's picture

I am by no means an expert here, but my sense is that a secure game client is nothing more then dumb terminal to render 3d graphics and capture user input. There are some concessions that can be made to player location and orientation, but these should still be validated server side as well.

triton's picture

@Kamujin:

That is really only the first step. All online games (at least well known) work like that and it doesn't prevent client cheats. For example, aim bots, image analyzer bots, packet bots, etc. This is all easily done with some client-side hooks and code injection, which is hard to prevent.

Dinberg's picture

And as said, the lag issue means calculation of valid movement client side is not as easy as it sounds. Also, if you have a lot of players (perhaps for a big game in the regions of thousands) checking collision pathways for each incoming movement packet maybe every 150-500ms can become very intensive.

For a small game though, which I assume is what the person here aims for, movement wouldn't be so much of an issue. I think the main problem will be things like people using 'auto-aimers' like triton said, or 'Radar' utilities that can show where other players are in the map, giving the cheater an advantage over others.

What I plan to do is make an RTS game via openTK and c#, and thats neat because the lack of player characters means that it removes many of the most likely opportunities for cheating. Fog of War could potentially be an issue, but I'll send create/destroy on objects rather than list all of the objects in the 'Universe' and then let the client itself determine which ones are visible.

This is more complicated than described in the link, since it does not cover client prediction and the animation system covering up glitches, but for example the Left 4 Dead network system allows you to play with people from the other side of the globe without any teleportation or other weirdness.

I refer morely to an example where people induce the lag themselves. Such techniques are often referred to as things like 'window-dragging', but I think this probably is quite an archaic problem because it doesnt appear so much in modern games. However, that could be to do with more advanced network logic being employed, which might not be achievable by a hobbyist, so its worth consideration.

What is the issue with using tools like Punkbuster & Co. for managed applications?

I'm sure you can quite easily, but I don't know what the licensing situation is for some of these measures and I imagine that some might have some sort of royalty added to them, perhaps out of the reach for someone making a game for personal enjoyment as I think the situation is here.

it will delta against last acknowledged state by the client, so even if the client intentionally drops a packet, the server will keep sending the "root spell" until the client acknowledges it.

This is true, and I was trying to make the example a bit simpler than the entire issue. But if the stream remains jeopardized to a sufficient degree the re-sent packets will also be detected as with the first, and they too will not reach the client.

I'm not saying by any means some of these cheats are impossible to fix - what I'm suggesting is that it will require alot of effort and cunning on the programmers part to prevent them from being valid, and that the issue shouldn't be taken lightly. There are ways of combating these problems - in the above, for example, you could check whether the other packets from the client are being replied successfully, and if they are but the speed changing one isn't, then implement a measure accordingly. BUT, all of this adds complexity to the project potentially beyond the scope of someone giving writing an online game a shot for the first time, with little prior experience in networking. It also adds more work to the project, and I'm sure you can agree that issues sometimes turn out to be much more complex than you originally perceived.

Kamujin's picture

@triton

With all due respect, this design is not completely ubiquitous. A number of modern games still allowed a fair number of calculations to be done on the client side, which is why things like clock based movement hacks still find some life.

That said, I think you misunderstood my meaning if you believe that I am suggesting that securing a game is trivial.

The "nothing more" was meant to communicate a limitation to be imposed on the client, not an end to your security planning.

Inertia's picture

I fully agree with Kamujin's assessment that clients should receive only the minimal amount of information they need to faithfully replicate the client's state on the server. For example: If the player cannot see stealthed units or units hidden behind a hill, do not send that unit's information. That should render "radar" or "wallhack" rather useless (i.e. limit those hacks to showing a unit only when it's about to become visible).

"more advanced network logic being employed, which might not be achievable by a hobbyist, so its worth consideration."
From my experience with network programming I can only draw the conclusion that the difference here is not hobbyist vs. professional, but rather whether you have shipped a program which is used by people around the world as opposed to testing the program only in LAN or "geographic neighbouring" locations.

"RTS game via openTK and c#"
Not sending unit's status - which are hidden by the fog of war anyway - sounds like a good idea to counter both: bandwidth requirement and map hacks.

"Punkbuster & Co."
Don't get into the "I wouldn't be able to afford it anyway" mood here, talk to them.
However if you cannot even afford some "master server" which is responsible for client login (authentication and banning) and supplying some kind of matchmaking service it might be useless to employ anti-cheating tools. Banning per IP Address is useless (I'm getting an dynamic IP allocated for every internet connection) and banning IP ranges is not a good solution since it will block honest players which use the same ISP.

"But if the stream remains jeopardized to a sufficient degree the re-sent packets will also be detected as with the first, and they too will not reach the client."
In that case drop the client as it is too badly out of sync? What degree of difference is tolerable/acceptable and what isn't? (more than 10% packet loss sure is unacceptable)
Using the 400ms ping case mentioned in my previous post, the player would miss a considerable amount of bullets since the zombies were simply not where he shot at. Dropping that client from the server might have been a good decision, since he couldn't really participate in the game, and he'd most likely be able to find a new game that would provide a better game experience.
Another approach might be observing in which situations the client drops packets.

Dinberg's picture

All fair points, and I agree. It would be interesting to see if someone like PunkBuster would give some sort of hobbyist offer, perhaps its worth checking out.

However if you cannot even afford some "master server" which is responsible for client login (authentication and banning) and supplying some kind of matchmaking service it might be useless to employ anti-cheating tools

It'll definitely be alot harder. But still, you rely on the clients computer to tell you they're cheating in the case of things like PunkBuster, so you could probably use this information on various smaller independent servers.

Banning per IP Address is useless

I realise that, and its a right royal pain! ^^
It's very hard to actually identify a user. Things like mac addresses also can be hard to obtain, but could be more useful as its hardware based. I read up Punkbusters methods, they looked good too. The problem with hardware is you can get the same effect as "banning IP ranges is not a good solution since it will block honest players which use the same ISP", except I imagine on a much smaller scale (maybe only siblings sharing a pc, for example).

Another approach might be observing in which situations the client drops packets.

Thats what I was trying to get at in the speed changing packet case in my last post, but I dont think I made my point clear I'm afraid. This seems a perfectly sound method for the case of when packets are just removed. But then I've just thought if the interceptor also forges its on ack-type reply it could get very dubious, which I hadn't thought of earlier....hmm...

From my experience with network programming I can only draw the conclusion that the difference here is not hobbyist vs. professional, but rather whether you have shipped a program which is used by people around the world as opposed to testing the program only in LAN or "geographic neighbouring" locations

I meant more along the lines of more complex prediction techniques to calculate likely movement in the absence of a player's actual movement being sent, not only server-side but clientside aswell. Then if a client's packets do get held up, the end product still seems to run smoothly as it fills in the blanks and evens out the glitches.

A good thing about the internet is that you meet alot of people all over the world, so testing across long distances isnt too hard because youll usually be able to find someone in America, France, Russia etc - wherever you need really :D

pkuzmenko's picture

Hey guys, I can give few tips:
1. MMO it's scaleability of the world server (500 players per CPU it's maximum!!!) so It's first what you have to think about.
2. It's client which very carefuly care about network protocol (better use seporeted therads for network, render, physics )
3. scaleable internal DB.
4. admin / log system for the server.

My advice is to use Erlang for backend server (ex. open poker ) + add scene graph for 3D - it you what I can describe it deeper.... and for client OpentTK to make crosplatform client (I'm ubuntu user, I like linux)