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.


Comment viewing options

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

How would Dawn of Light fare in a general deathmatch-style multiplayer context, for a game written with OpenTK? My current project would ideally in future be multiplayer-based, but hardly in a "massive" way - more like a maximum of 4-8 players.

The thing I least look forward to coding is the network stuff, so unless DoL would it be too unwieldy on such a small scale, my interest is piqued.

Dinberg's picture

Well, the type of game here is one where there is one server, and many other clients that connect to that server. The server stays up, even if no ones playing - its like the client is a window to an already existing world, which will keep running regardless of whether the client is there.

DoLs code is also vast; sorry I didnt mention that earlier ^^. But the networking behind it is relatively straightforward, and thats the bit I was getting at really, looking at how it handled the networking and how this runs alongside server logic. Its just one of the few web examples I know of which has been developed to such a stage, so it makes quite a good toy to poke around in.

But a deathmatch game sounds like something more like quake in playstyle. Games like this usually have one of the players hosting the the game and others join, so although there is effectively a 'server' the logic is a tad different. I dont really have any experience in that sort of area I'm afraid XD

However, I've seen savage - - has clients that connect to a server among a large list. Although similar to the MMO style of servers, servers only have a cap of 30 or so often, and players can host their own. It sort of basically has no game running until players join, at which point the deathmatch begins for the next 30 minutes or so. Players can leave if they so wish, and others may join, but the feel is much more like a deathmatch than a roleplaying game or similar. Savage is quite neat actually, and they made the first one free so its worth checking out =D

You could in theory work your games multiplayer code like this, but this style has a key feature over client 2 client communication - A server machine that all clients communicate through. Ultimately, the server decides what each client says/does, the client merely requests actions from it - like movement, 'I want to shoot', 'I pickup this key' etc. The server then acts based on these requests, for example checking the distance of the player to the key, or what the player is facing when he pulls the trigger.

But as I say, I'm afraid I can't offer you much more information for a 'deathmatch' type game, I just havnt poked around in that territory before ^^. I'm sure this method of communication can work though for games like this, with just a little more efficiency to reduce lag. If you want to add me on msn and have any questions though I'll gladly assist - but be warned I have 2 weeks remaining until my exams are over, so I'm not around much right now due to a deprivation of free time. But, if I bump into you, I'll give you all the information I know!

Oh btw, have you thought much about reducing latency in communication? It's quite a key area, but I assume because you are playing with friends connection times wont be much of an issue as you will all be fairly local.


Inertia's picture

[Packet hacking]
Please forgive my ignorance, but what is the difference between an IP Packet created through C by Winsock and C# by System.Net? My understanding is that (unless you use a NetworkStream which adds abstraction possibilities like serialization instead of writing byte-per-byte) the datagram of the packet is always a byte[]. If you intercept the packet between sender and receiver, you cannot tell whether it was created with Winsock or System.Net. So all security related problems apply for both. .Net might actually be the better environment to write network applications, since System.Security.Cryptography is only one using clause away and exceptions are redefining the meaning of "awesomeness" when it comes to network errors.

[Memory hacking]
Again, please forgive my ignorance as I haven't given this too much thought yet due to this conclusion: The GC is very happy to move objects around to use memory blocks more efficiently. Trainers do work by overwriting a specific location in memory (for example the player's hitpoints) so no matter if the game decides to decrement the hitpoints from 100 to 80, the next time the trainer's process gets it's share of cycles it will simply write the value 100 back. How would you do that for a relocating memory address? Mind I have no idea how to do that for an unmanaged application (observe memallocs?), but it should be significantly harder to do this with the GC.

To do a trainer for a managed game I'd rather try to disassemble the program, pop a new form at startup with trainer options and do all trainer-related value writing inside the game itself. Build and done.

the Fiddler's picture

[Packet hacking]
The BCL provides both high-level and low-level networking functionality. Even some specific APIs are a little braindead, on the whole it's quite flexible. Never encountered performance issues either, but then again I've never attempted anything large-scale.

The cryptography API can encrypt packets, but the issue comes before that:

[Memory hacking]
No need to poke memory addresses in .Net. The malevolent user can use System.Reflection to modify everything. Sure, you could try to obfuscate the code, but this doesn't work all that well against a dedicated attack.

Dinberg's picture

This point applies to both principles below: what I meant was C# doesnt have the power to check whether or not a process is being interfered with, be it interception of a stream or the writing/reading of addresses. See below why each is an issue. So while if you make your code in another language, you have defences at your disposal to, for example, terminate the application if you suspect interference as many mmo games now do (I've even seen systems before that force a BSOD onto a pc - not very nice at all though because it thought norton antivirus' routine checks was 'interference' and nearly did a few hundred pounds worth of damage to my computer by taking down ALOT of drivers with the power outage) if you make it in C#, its a little less defended. As I've said, If anyone knows how to check if something is being interfered with in C# I'd absolutely love to hear about it.

[Packet Hacking]
Lets say, in a hypothetical scenario, player A and B come face to face in a heated firefight. Player A casts "Glue Feet" on player B - the cast goes through smoothly, and the server woefully roots player B's feet to the floor.

But, player B is cunning and has decided to employ a packet sniffing device. The server sends out the packet to change player B's speed, but the little tool sitting along the wire intercepts the message, checks the packet header, and upon realising the nature of the packet (to reduce B's speed) the little rascal hides the packet from the client.

So, the data stream arrives at player B's client, but there is no speed reduction packet. Player B is therefore immune to the effect of player A's rooting spell, and strolls up to whack him on the head.

But, Player A is also a rascal! As B hits A over the head, A disappears - A has also intercepted his packets and put an intentional delay on their arrival. This causes a horrific latency effect and makes him devilishly hard to pinpoint as he warps around. But the server reads it as just heavy internet traffic, and does nothing to stop A. Likewise, B also gets away because the server sits there thinking "Well, I told him to stop, so he must have done. There must be a different explanation!" *

The packet sniffing is the lesser of the problems though, because you can encrypt the packets to a fairly high degree and also add things like time signatures so that stalled packets can be found out. But, given enough time and patience, any encryption can be broken.

[Memory hacking]
Although a Server can send alot of the statistics to a player - for example what skills are available, what his /her health/mana/items are, etc etc, there will likely be a small part of the character that will rely on client-side statistics. This is most likely to be movement, because to await a response from the server everytime a player moves if you use the directional keys (as opposed to mouse movement, where you click and your player goes there) would be wasteful and could cause a 'laggy' feel in the client's responses to the user's movements.

This means a client can alter their location for example, and might get a way with it. They might also get banned, but its alot more complicated than just calculating the clients maximum speed to a point and checking if his distance jumping is feasible - what about, for instance, lag spikes? If you took this approach, any lagging player's movement packets suddenly wham into the server at once and he appears to have cheated, like in the scenario of stalled packets above - that means a player could get banned while following the rules!

* A and B did eventually settle their differences. Putting their issues aside, they settled, and lived a happy life. The birds and the Bs eventually took their place, and they had many lowercase of their own.

objarni's picture

The packet sniffing is the lesser of the problems though, because you can encrypt the packets to a fairly high degree and also add things like time signatures so that stalled packets can be found out. But, given enough time and patience, any encryption can be broken.

Like ten times the age of the universe..? Public key encryption is not really practically breakable - if you have a technique, I think a lot of internet banking services would be really interested in employing you.

Graveen's picture

Hello, i'm the actual project leader on Dawn of Light.

I understand the server side of Dawn of Light don't use open TK. I'm simply here to point that DoL can be used as a solid framework representing the server side of any game you could develop with OpenTK.

Of course, there are still work to do, but the open source nature of the DoL project can provide example and a basic working server, widely used, and of course mastered: support, documentation (although as not as i 'd like :D).

I silently go back to my lair, letting Dinberg discuss with all of you :)

Sincerely yours,

Dinberg's picture

The packets can be decoded for online games. I personally dont know how nor have ever tried it, but as I understand it is essential for the basis of many MMORPG emulators to be able to communicate to the clients they emulate. Though I've never touched it as I say, so I can't speak from experience!

I was thinking perhaps that packets are encrypted in a less secure way, so that communication can be handled between server and client faster? This is where I'm hazy on knowledge, and don't have much evidence. All I know is that online games these days invest large sums of money on systems to prevent people interfering with packets, so I'm guessing encryption alone wont do the trick.

if you have a technique, - If only ^^

Entropy's picture

Thanks for the advice Dinberg.

Actually, I mentioned "Deathmatch" to give an idea of the scale of the game - in gameplay it's much closer to Savage than Quake, so I'll look into using DoL for a while - even if it's just for early-development use until I leran how it works and narrow the content down unti I'm only using the code I need (if the licence allows that kind of thing).

All long-term speculation, though. LinkSphere is still very much in its infancy, and you never know how far these personal projects will really go...

objarni's picture

I'm not so sure how real-time modern public key encryption algorithms are. At least they are real-time enough to surf the web in a secure way (which I admit does not prove they're fast enough for MMORPGs, but it gives us a hint) without any noticeable slowdown.