Persistent Characters and MMORPG Network Architectures

#41 What TheMartian said is what I would have said. My background is in enterprise level, multi-tier systems. That's what you're building and you need to think about it from that direction. Why not have an architecture like:

client -> game server -> app server -> db server

Each part knows what it's responsible for. Each part is well defined. I know most would combine the game and app server, it's up to you. I just prefer that one further level of distinction. So, in Torque terms you have:

client (TGE/SE/2D) -> game server (TGE/SE/2D) -> app server (your choice) -> db server (your choice)

This lets Torque do what it does best and reduces the need for heavy source modification.

BTW, I really do have to aggree: if you can do it in a stored procedure, DO IT! The performance gain is astounding. I've seen 2000% gains or more in performance for some very complicated processes, even some on the order of 20 minutes (app code) down to 5 seconds (stored procedure).

#42 I think when all is said and done the person making the decision on what to use will go with what they know or have used in the past. If its already a Windows shop, more than likely they will use Windows and vice versa for UNIX/Linux. In these days of clustering and Oracle RAC. You can have 50 vanilla PC boxes running Oracle and not worry (too much) about losing one. Keeping those 50 boxes up-to-date is another issue though.

I guess the point in all this is that there are lots of options to choose from. Which one is best for you depends on a lot of factors.

I'm thinking if there was one best solution, everyone would be using it!

Steve

#43 I see what everyone's points are on MS vs *nix but the truth of it has to be that one IS better. We see all kinds of benchmarks for video cards, for processors, for ram, for hard drives, etc. Why don't we see them for databases? Why don't we see them for OSes themselves? To steal from a movie, 'there can be only one.' They can't perform EXACTLY the same in all areas, so someone test this crap and let us know what's better. That someone meaning someone like Game Developer magazine or some crap. It'd be nice to throw a million small transactions at each db type on each server platform and see what the results are.

#44 Which reminds me, since we're talking about DB's (kick me in the left eyeball if i'm hijacking the thread again), but why doesn't TGE/TSE have BUILT IN db access? I'd think that DB access is pretty much a necessity in today's world?

#45 Jonathan,

Its the right tool for the right job!

I don't see a real need for TGE/TSE to have built-in DB access for the types of games it does out-of-the-box.

Lets face it, you don't need a database for a basic FPS and GarageGames isn't touting Torque as MMO middleware. The MMO concerns are coming from people who want to adapt Torque for that use.

Steve

#46 Being an engine that, from what I've read so far, is poised to help indie developers get into the game development business, I'd say that it would make sense to start supporting MMO stuff out of box. MMO is the future. Single-player games, IMHO, have numbered days left. I think 10 - 20 years from now, the only single-player games will be ones that were multiplayer but have single-player options as well, instead of the now single-player games that sometimes get multiplayer options later on. But what do I know! ;)

#47 Hmm, I'm not sure everyone that plays video games likes to play an MMO to be honest. I don't think they will die out.

And as you can see from this thread about database access, which should GarageGames choose if they were going to support one?

I think at this point MMO and Indie don't go hand-in-hand. MMO's are a lot of work (from what I've read) and not something an Indie is likely to tackle.

Of course these are my personal opinions based on a little research. I'm not a professional game developer either so take it with a grain of salt.

Steve

#48 Indie teams aren't going to reliably, repeatedly make MMO games. Period. End of story. Many AAA COMMERCIAL studios fail at making MMO's--look at all of them that have been cancelled even with millions in funding.

And as this thread demonstrates, there are hundreds and even thousands of information items that go into the decision regarding which persistence solution you might use--there isn't any way for Torque, for the indie price point that we offer, to make these decisions ahead of time and come even close to pleasing even a small portion of those interested.

Which is why we have the resource system--there are at least 2 strong persistence resources out there using db's, and one persistence solution out that that is even written completely in script. Pick the one that best fits your needs, and go with it!

#49 And there you go, Stephen Zepp could explain it better than I :)

#50 (for context purposes all of my posts really are for indie gamers who think they want to make a mainstream MMO game to compete with the big boys, of course it was already mentioned how unlikley that is, but I offer the opinion none-the-less)

Read my post about why you shouldnt have game servers ie torque talking directly to the DB, its a flawed architecture and it puts an unnecessary load on your game server, it difficult to flow control, its hard to load balance, its hard to do proper caching. sure for a small mom and pop game it works but if you want to play with the big boys you need to learn how to use the big toys correctly.

as for benchmarks, they arent very practical with it comes to RDBMS, all of them have tests that out perform the other. And it doesnt mean much, they are usually lab test that dont apply to real world. although there are some good sites that do perform some good test.

like this one

http://www.tpc.org/tpcc/detail.asp

but its not easy to do fair comparisions databases are a bit more complicated and a bit more complex to configure then a video card polygon test.

for example the tests dont always utilize all the advanced features of each DB. but basically if you dont have the knowledge you cant utilize the power. Lots of great DB developers out there, find one and use them.

I learned a lot about DB's and a lot about the specifics of Oracle and I took advantage of everything I knew to make it happen for my customers. I used some serious tricks of the trade to make it happen and because its specialized it was difficult to use it for everything after the fact(database already designed). But I could these tricks and get Oracle, for example, to outperform all the lab tests and any other DB I had ever used.
(I still havent found a DB to outperform it with my special settings : ) But the others all have there strengths and weaknesses, its understanding what those are that is also lacking in most MMO industry.

but that website is pretty good at reasonably testing the DB's but I certainly would not buy a RDBMS just based on those numbers. Lot more to it then that. You have to look at things like maintainability, pool of available people with knowlegde in it, tools, scalability, cost, hardware platforms (some performance changes drastically when running on one platform over another for some RDBMS's)

there is nothing simple about fully utilizing, designing, and archetecting a persistent world, and on top of that there is no one right answer, there are only guidelines, rules of thumb, and hard earned experience to guide your way.

its a difficult problem, even projects with 50mill to burn get it wrong, maybe because they are too focused on pretty graphics, or how chat is going to work, or how to generate all the content they need but it can be done and some have done a very good job (they arent all bad).

on a side note I agree with J.E. thats the same architecture I was talking about, taking directly from enterprise wide designs from other industries(which have been building and making super large scale high transaction volume databases decades before MMO's came along)

it can be done, just make sure to pay attention to it early on and not right before you ship (dont laugh, long story but ive seen it happen).

#51 And of course I'm sure the reason people are using the direct-to-db route here rather than a multi-tier architecture is cost.

I'm betting if they are well funded they would be using best practices. Or we can hope anyway! :)

Steve

#52 Also, the real question would be then, which db would be best for an indie who can't afford to hire a DBA? Which is best out-of-box or with few modifications that an indie could perform without much effort would be ideal in that situation?

And if GG did put in db support, I'm not saying put in SPECIFIC db support, like SQL Server. I'm saying put in ODBC or ADODB or whatever support, then let others actually get their own specific db to work.

#53 A point about cost. The "app server" could always be a LAMP server and yes, all of it can be on one physical machine, just not recommended for any substantial load. As a side note, I prefer Firebird, the updated, InterBase derivative open-source RDBMS and it's free. Runs on all the platforms Torque does.

So for prototyping, you could do all of this n-tier system work for very low cost.

#54

Quote:I'm saying put in ODBC or ADODB or whatever support, then let others actually get their own specific db to work.

There's a few quick resources out there to do just that, and you only need to add them in. And even if they need to be modified on the code side to get it working (as I had to do to get the ODBC resource to work with Access), it's still easy to do, even for someone who's never touched SQL or ODBC coding before.

I've been using ODBC in TGE and TSE for about two years now, on both Access and MySQL, so the ability is there to use, and about as easily as any other resource posted.

#55 @J.E. Christqau,

Yes, regarding cost, they could use LAMP but that would then lock them into Linux though. :)

Steve

#56 @M-theory

Not at all. Technically, you're right and I shouldn't have said "LAMP". I guess a better way to say it is that the app server could be a AMP server since all the other parts run on other platforms. But in truth, it should only be an "AP" server since the "M" is for MySQL and that should be on another server anyway or a different RDBMS. (I also prefer Python to PHP or Perl but that's just me.)

The actual OS that each part runs on should be irrelevant. Each part communicates with the others in a platform-independant manner so the OS doesn't matter.

#57 @J.E. Christqau,

True, MySQL and Python can be run on both Windows and UNIX/Linux but that again is assuming they want to use those applications. Maybe they want to run SQL Server or use some other Microsoft application or language.

That's all my point was about.

Steve

#58 @M-Theory

I think the reason people use the direct-to-db option is the same reason that people use convenient (but questionable) techniques in any area of computing - they do it because it's the obvious thing to do, and because they haven't done that kind of thing before, they're not in a position to know any better. I hope that doesn't sound pompous - I'm not saying people are stupid, I'm saying that the technical issues involved here are more akin to enterprise-level business applications than they are to games, and so it's quite natural that a game developer (commercial or indie) will not necessarily know better than to do what's most obvious.

Anyway, hardware cost isn't an issue in how you design your server layer(s) - there's no rule that says you must put each server on its own machine. The point is more that you *could* put each server on its own machine, at some future point in time, and thereby gain the benefits of the distributed design. This design approach is completely independent of what operating systems and databases are actually involved.

Well, this is my first post on these vaunted forums, and I kind of feel like I've come in all aggressive! Please forgive me if that's how it seems - I'm a pussycat, really...

#59 @Wayne,

That's a very good point. There is probably a much better way than any of us have described, we just don't know what it is yet. Until I got exposed to the n-tier structure, I thought client/server was the way and huge apps using shared DBs before that. Until I started learning OOD&P, procedural was the way (usually in a horribly monolithic form).

There is so much tech out there right now that it's going to be interesting to see how it all shakes out.

"May you live in interesting times." ;)

#60 @Wayne

Exactly. Even if many teams had the money it would not mean they would build the infrastructure
for an MMO game correctly. In fact there are plenty of examples of large MMO's, highly funded,
that built some pretty poor infrastructures for their games.

Its a knowledge and experience thing, most game developers do not have enterprise system type experience.
Not to poke too hard but ive been on too many teams where the developers had never worked in another industry, games was their first job. well unfortunately game companies do not educate there employees.
Other industries spend a lot of time with on-going training. As a result you get whole game studios that do not know anything about what is a software development process, how to manage time, schedules, or people.

So its not really a surprise that primarily single player, console programmers, and many multi-player programmers do not understand how to design and implement enterprise style scalable and reliable servers
technologies.

They never had to write anything to support 100k current players, or a process that is suppose to run 24/7 or that can fail over to another process if things go wrong. Or to write systems that your going to need to be able to maintain for years to come.(improve, add features, monitor, etc)

Its the primary reason I found, besides inexperienced management, for even the big boys with all the money
to fail miserably. They just had no idea what they were getting into and all the money you can get isnt going to help you overcome that unless you can find the right people.
(side note, then you get into the thing where they dont want to hire people that know more then they do because it threatens their job, have a good war story on that one, gets back to inexperienced management).

people with no enough experience, promoted up the ranks for the wrong reasons. In other industries ive been in the high level people, product managers, lead programmers, etc, all had no less then 20 years experience. In the game industry ive seen 20 year old directors of technology, with almost no experience, no people skills, just friends of the right person.

coming from outside the game industry you just stare in awe.

over the years its been getting better and better I must say. companies are figuring it out, they are hiring quality people from outside the games industry. and frankly it makes sense, if your going to drop 30million on a MMO game you should probably get people that know what they hell they are doing. You can only do so many failures at that level before it sinks in that you need to widen the net for hiring talented people.

and its working, its getting better. most of my examples are slowly getting outdated(but they are based on real events) and its improving. which is something im delighted to see since I really like the game industry
I just think it needs a reality check once in awhile.

sorry to ramble, just been doing it a long time and have lots of war stories from all sorts of MMO projects :)

to summarize, money wont help you make a better game or help you design better systems, people do.
and the quality and knowledge of people you need goes up significantly when taking on a large scale
MMO projects.