capnjosh

Most RPGs utilize the concept of faction reputation in some way or another. It makes sense, and it’s a valid element to include in its own right. Extending this concept into how creatures and spawn spots relate to their surroundings can introduce a good amount of dynamism in the virtual ecology of an MMO.

You need 2 main mechanics:
1. Every time a spawn spot has some sort of an impact on another spawn spot, you need to record the results of that interaction; or, possibly just have that interaction proportionally change the faction relationship between those two spawn spots’ respective factions (whether those “factions” are actual NPC factions or simply species).
2. You need to ensure that all members of a faction behave toward other factions according to their faction ratings. This includes spawn spots as well as instanced creatures. This part can get rather complex because you want to allow for dynamic, ad-hoc ally groups, both by instanced creatures as well as by spawn spots.

Just imagine a game world in which a player witnesses instanced members of a faction with which he has a higher rating actually join his side in a fight against members of an NPC faction which both he and they have low faction ratings. And then, a patrol of another group of creatures comes along and joins the opposing NPC faction because they have a higher faction rating with them than with both you and the first faction. And over time, the player is actually able to change all that. The thing is, that then you have a world in which all those NPC factions constantly, autonomously change their relative ratings amongst each other. Add in an independent “lust for wealth and resources” as well as a system of “survival is what ultimately counts”, and you just may have a fully-functional virtual ecology.

So, the phenomenally resourceful hacker/gold farmer community is quite the challenge. You’ve tried everything- chat filters, IP filters, email filters, captchas, mass banning of accounts… they always come back and within weeks it’s as if you had never done anything.

Ultimately, you have to go back to basics. What’s the real issue with hackers and exploitive gold farmers? It’s their behavior. They “break” the game, both immersion-wise as well as the economy. So, all you really care about is limiting that bad behavior. Really, you don’t care if they are in the game, even profiting from their activities… as long as their behavior is not beyond that somewhat fuzzy line of “appropriate and reasonable”. So, therein lies the answer. You have to target the behavior. After all, that’s what your GMs are doing when they patrol the servers.

The problem I’ve seen with most attempts at combating exploitive behaviors is that they end up figuratively building a wall. Walls only work when your enemies only walk on the ground and don’t dig under it, don’t utilize airplanes, don’t build ladders, and generally refrain from trying to solve the problem of the wall analytically. Dude, exploitive gold farmers and hackers have within their ranks some of the more intelligent and capable people in the world. In fact, I consider them a worthy adversary and deserving of honest-to-goodness respect.

The only possible “solution” will be in cleverly and aggressively building ever more general solutions to automatically classifying players based purely on their behavior. And this is something we can do. But it takes a lot of determination because it requires a lot of pieces, both technologically as well as inter-personally.

1. You need good hardware. Just go with the most bang for the buck. Focus on memory and lots of pretty fast, physically independent drives.
2. You need clever algorithms. Microsoft has a great start in this area, and it comes free with SQL Server- it’s called SQL Server Analysis Services. The 2008 versions are indeed better than previous ones.
3. You need some good TSQL skillz. This is fundamental. You can try to jump over this, but in the end you can’t get away from it.
4. You need some good organization of database tables as well as some good naming conventions (this is more important than it may initially seem, but you will be doing a lot of data shuffling, and tables and columns that have stupid-obvious names just feel good).
5. You need a good way to centralize large amounts of data. While you can directly query Production servers for the necessary data, extracting it all to a central server allows for a lot more possiblities, and you and your co-developers will learn all kinds of good stuff about your existing systems.
6. You need to have good friends working on the game itself. You will find all kinds of good things that need logging in order to allow for classifying player behavior.
7. You and your co-developers will have to figure out how best to streamline the process of identifying in-game events that need logging and then actually getting that logging set up. It’s never as easy as it first seems. If you can get this down, I guarantee it’s only a matter of time until the world is your oyster.
8. You will need to figure out how to best deliver polished reporting products. Again, Microsoft has done good stuff here, and it comes free with SQL Server. SQL Server Reporting Services will be your friend.

The pretty cool part about working on behavior-based classification systems is that you will really get to know your game well. That, and this stuff is pretty cool indeed.

If at first your server sucks… just throw more memory at it… specifically, get the most bang for the buck and fill up all your RAM slots with the stuff (currently, it’s 4GB sticks).

Seriously.

Insufficient RAM has been the single biggest impediment to my data warehouse development efforts. That, and disk contention (yes, I know the two are related). More RAM means SQL Server has a chance at not even touching a hard disk unless it really really has to. Combine that with the built-in compression of SQL Server 2008, and things can get really fast really quick. Imagine actually reaching that promised land of always being CPU-bound rather than disk IO bound.

As reference points, I had been stuck with a 32-bit server running 3 instances of SQL Server, each of which had 2 GB of statically-allocated RAM, leaving the OS, SSRS, and SSAS with 2GB to fight over. And fight they did, believe you me. Nothing sucks more than the OS paging out all your fundamental SSRS files… right when everyone wants to access them. That’s also about when you hit “process” on some grand new mining model scheme you’ve been working towards for a while. Things don’t go well for the next bit of time.

Another thing- try to have lots and lots of physically independent hard disk [arrays]. The secret is to embrace the inner parallellisation fiend. Lots of RAM and 8 cores allows for that. I’ve cobbled together a new server that has 16GB of RAM and 4 physically independent drive arrays. I cannot emphasize enough how much better that is. We’re talking an order of magnitude, especially when SQL Server gets everything all cached in memory. Soon, I will be getting a total of 32GB for this server, a fibre channel card so I can get some SAN juice, and maybe later some larger local drives (which would be very nice). Incidentally, if you have to use a SAN, make absolutely sure you know what’s physically indepdendent (not logically - that’s not good enough). If you have to share a tray of drives with too many other virtual machines or something, your performance is toast, and you can give up on ever doing the really cool classifier stuff in Analysis Services [so you can nuke all those pesky exploitive gold farmers].