Quote:Original post by joe1024
I`d rather let each client handle game logic, if possible.

Well, conceivably, if you wanted to ignore security concerns, you could have each client handle the player logic (i.e. each client is the authorotative source for where the player is).

However, having the server simulate everything isn't completely about security. It also can make your life a little easier for certain things:

World logic like Mob AI has to be centrally driven. Otherwise 2 clients could very easily report 2 different positions and behaviors for a given mob. In that case you can't resolve which represents the "true" game state; your clients then de-sync, and the game ends. Similar consistency problems exist for things like: loot pickup, item trading, etc.

That aside, even with the clients being authoritative over their respective users, you still need to store all that information on the server. 1,000 clients can't do P2P information transfer without latency death and isn't convenient anyway because of NATs and firewalls. So you'll at least need to re-architect enough so that clients report data to the server and then also query the server for other user information.

In other words, you'll probably need to re-architect to the point where only the local user is authoritative to the client and the server is storing the full world-state. At that point, the only game logic the client is in charge of is it's local user. Once you're at that point you're not really saving much refactoring time by having the client simulate the player and meanwhile you're opening yourself up to that one user who's going to ruin the game for everyone else.

-me

Realistically - what are the chances that of those 1000-2000 people there will be somebody willing to loose time creating troubles ?
This is not going to have publicity of WoW or Everquest. I`d dare to say, that getting 1000 subscribers will be almost unreachable goal. Plus, it would have to be actual competent hacker to be able to dissasemble the game code and bypass any security checks.
And even if he would manage to change his stats (or whatever), the server would still have to validate the changes to store them. There would be double checks to make sure, that unrealistic advancements aren`t approved.
And good luck getting to my server and changing the data there. Seems pretty absurd for an indie MMO to get such an attention.

Either way, if it`s true that there aren`t any PvP libraries (with authentication through central server), then I have to let the server handle everything, thus go the "zone" route and forget everything I said above.

Quote:Original post by joe1024
Considering the low number of players in question (~700 at any time, up to 2000 max), would it be extremely risky to let clients handle game logic ? I mean, how many hackers is my game going to attract ? Those few could be handled manually (by IP/user name), probably.

I`d rather let each client handle game logic, if possible.

Experience with Eternal Lands: A game with only 200 concurrent players (at the time of a small imbalance) can screw up the entire economy. Now, imagine what could happen if, instead of exploiting a small server bug, they could inject packets and mess with the server itself. Even at the current max 867 players ever online, and everything controlled server side, moderation is spread among roughly 25 people to keep from getting swamped. I can only imagine that cracks would become commonplace on a game with a small-medium user base and client-side logic. It doesn't necessarily mean changing stats, but can affect combat, and cause 'jittering' or teleporting, etc, to give other advantages.

Quote:Original post by wodinoneeye
3km visibility (radius or diameter??) is a substantial part of the world (16x16) and you might consider having the Client permanently cache to disk and better keeping it entirely in memory (as its getting cheaper...). It could still be streamed (initially anyway) but caching the parts that dont change (terrain mesh/textures/models, prop objects...) would free up bandwidth (parts that change could be delta patched along with the more dynamic bits that are constantly updated). Once the player had been in all parts of the world, then the static parts would no longer have to be streamed (and there may be substantially more dynamic parts which WILL require that bandwidth).

Yeah, the radius of 3 km is substantial part of the 16x16km area, but those 16x16 were just an example. It could be 64x64 or 128x128, since it`s generated procedurally in gfx SW and populated with vegetation automatically. The engine really doesn`t care and since I`d be rendering only nearby players (using LOD/billboards), the landscape renderer takes care of itself without the aid of the server.
Obviously, the 3D data (landscape/textures/characters) wouldn`t be streamed from server but from HDD. I hope there`s no problem (editing terrain landscape/textures by players) with that. Or is there ?

Quote:Original post by KulSeran
The point is that the logic doesn't belong anywhere where random chance can cause something to happen to you.
The point is that, no "one" hacker doesn't mean anything, but people are greedy, and when they find out about little tricks you
can do without effort you will see everyone "hacking".

I admit that I hoped that situation has changed in this regard during last few years and that the initial troubles were overcome (by others). I haven`t watched MMO area for last few years and hoped for similar advances that are in SP area, technology-wise.
But it seems this is a conceptual issue, so there`s no way around this.
Oh, well ...

Quote:Original post by KulSeran
Since you are intent on keeping your current engine, you would probably be best served by getting a copy of some freeware MMO type engine, and either ripping out the code you need (prolly not going to work well) or using their code base
as a learning tool to show you what code you need to write into your game.

That was plan C, originally. Now it`s plan A.
But wait, with so many engines out there, it seems weird there aren`t equivalent amount of MMO engines. Sure, I`ll have to search thoroughly.

Quote:Original post by KulSeran
There are 3 main things that you are going to run into issues with:

No. Actually, there are about 1372 other things. Because if I`m going with the route C (server-side handling), then I have to do everything that books like "Massively Multiplayer Game Development 1,2" describe.
And that`s what I wanted to avoid, in the first place, by using some library that would save me months of low-level coding.

Quote:Original post by KulSeran
I dont think anyone here is trying to say "NOOOOOooo dont do it!" to you. We are just trying to get the point across that there is no "MMO componet" that you can just plug in. There is LOTS of logic behind the scenes that is directly tied to everything else.
You probably can use your 3d engine, and game logic, but you also have to think that everything you have will need some refactoring.

You know, it`s funny, how everyone`s telling you - "Don`t reinvent the wheel", "Just save the time using engines that are out there - just reach out for them". But here, with such a massive issue, as MMO is, now all I hear is "Dude, just write it yourself".
It`s gonna take me 1-2 years until my game is MMO, if I`ll be coding the MMO myself and from the scratch !

Most probably, I`ll end up with completely revamped engine, with several completely overhauled components and many of them completely rewritten.

Which is like coding MMORPG from scratch, only I have a relevant experience - i.e, few finished games on my belt, plus 6 years of DirectX/C++ coding. That`s just plain absurd, IMHO. But if that`s the way to go, well, what can I do ?

EDIT: I`d be grateful if someone would advise what to do to save as much time [recoding] as possible

[Edited by - joe1024 on August 6, 2007 2:19:59 AM]

Quote:You know, it`s funny, how everyone`s telling you - "Don`t reinvent the wheel", "Just save the time using engines that are out there - just reach out for them". But here, with such a massive issue, as MMO is, now all I hear is "Dude, just write it yourself".
It`s gonna take me 1-2 years until my game is MMO, if I`ll be coding the MMO myself and from the scratch !

Most probably, I`ll end up with completely revamped engine, with several completely overhauled components and many of them completely rewritten.

Which is like coding MMORPG from scratch, only I have a relevant experience - i.e, few finished games on my belt, plus 6 years of DirectX/C++ coding. That`s just plain absurd, IMHO. But if that`s the way to go, well, what can I do ?

There are two types of multi-player games. One is the regular online multiplayer, the other is persistent MMO.

It may seem like a minor difference, but it's like talking about mowing a garden, or building city-wide road infrastructure.

When you go persistent world MMO, a whole new world of problems arises you've never even thought of before. In an MO, if client crashes, forgets to save, hacks the client, nothing happens. In MMO setting, if you misplace one single item, or forget a single gold-piece, hell will break loose.

Look at it this way: Your regular single-player game has 1 in 1000 chance of something going wrong during single gameplay session. In MMO, this means, that every game, one player will lose some progress or experience some other problem.

The problems involved have been solved in world of business applications. Unfortunately, their solutions are incredibly complex, and prohibitively expensive, on top of it, they don't scale to real-time use without some incredibly bulky hardware.

If you go through suggestions listed above, you will find a small number of third-party solutions which take care of everything. Unfortunately, they come as all-or-nothing deal. That means, look at them, decide on the one you like, then subject your engine to that.

When it comes to MMO, the entire process is led by technical limitations of server-side. (D2 is only AAA MMO-ish game with client-side logic, and it has been hacked since day one).

As mentioned before, you have approximately 3 options: Turbine, Multiverse or NEL. Look through them, see which is applicable.

An MMO application server is (ideally) a real-time, unreliable massively distributed, ACID-compliant database server. This alone is a hugely complex set of requirements which are only achievable through incredible amount of compromises - and in order to make it work in the first place, corners need to be cut. And the whole implementation is there to make sure everything works.

There is another option. Don't worry about server software. Change existing code to run server-side, then provide a database to take care of everything else. Unfortunately, you'll then need to scale in hardware. You bring in several machines with fail-over hardware, put on distributed database, provide virtualization for your logic (one game per thread). This is perfectly viable - but can you afford the cost of hardware then (at least 4 machines for database cluster, plus 1 machine for every 4-64 players, depends on how much logic you have)?

Multi-player games are challenging. MMO - very difficult.

The reason why companies provide the whole deal is for this very reason - they understand all the real problems you'll face, and give you tools to solve them.

At very least go through the free engines available to see how programming of such server looks and what all is involved. That should give you an estimate on how much work it would take to convert things.

Quote:I admit that I hoped that situation has changed in this regard during last few years and that the initial troubles were overcome (by others). I haven`t watched MMO area for last few years and hoped for similar advances that are in SP area, technology-wise.

Things have changed. But just like you don't download Oracle's database source, and pull out 3 files to include them in your application, you need the whole shebang for it to work. A lot of experience has been gathered, and it's provided as a package deal.