"Most games run AI in the server or main process, so all of those well-paid, experienced, educated, professional programmers must be complete idiots by your logic?"

Single player games or peer to peer games of course need the AI in the main engine. However, the people who put AI with the main server in a client/server model are making a very costly mistake.

I never said they were idiots. It''s not like professionals don''t make mistakes. In the case of EQ, those people running it are throwing a lot of money away with the model they used. Since they have more money than they know what to do with it doesn''t really matter though.

I didn''t say it''s the only solution. It''s just a significantly better solution.

Ben


IcarusIndie.com [ The Rabbit Hole | The Labyrinth | DevZone | Gang Wars | The Wall | Hosting | Dot Com ]

BTW, I'm the one that mostly re-wrote the EQ UI system and started many of the optimizations of the backend. I have switched jobs since then.

There are two things about patching. Patching content, which usually means updating a database, and patcching code. Having the AI as a separate process allows you to do both without taking down the main servers. It doesn't really matter if the process is on another machine or not for patching purposes. It just gives much more power for AI routines.

You are right that unless it is released, it's still just experimental. We have rrun as many tests as I could think up on our system here and it works great. However, no number of tests makes up for real world testing.

And your right again, not every game should use this model, but many MMP games should. It's a logical design improment of already cutting edge technologies.

I was speaking with a buddy on the SWG team today about scripting stuff and asked about it. SWG is using inline AI as well. But the system is very different from EQs architecture.

Stephen Manchester
Senior Technical Lead
Virtual Media Vision, Inc.
stephen@virtualmediavision.com
(310) 930-7349

EDIT: Woo, I'm the first post on the new page!! ;-)

[edited by - smanches on July 25, 2002 7:37:37 PM]

Yeah steve, I think we met once actually... before your departure.

By EQ backend I'm talking about stuff other than the game server. But I don't want to get myself into trouble, let's just leave it at that. I'm sure you know there is a lot more back there than just the game.

The following anonymous is from me, multipost, sorry


[edited by - fingh on July 25, 2002 7:56:03 PM]

quote:

---

Original post by KalvinB
... However, the people who put AI with the main server in a client/server model are making a very costly mistake.

I never said they were idiots. It''s not like professionals don''t make mistakes. In the case of EQ, those people running it are throwing a lot of money away with the model they used.

---

Care to ammortize for us the amount of money SOE has "lost" on EQ over the last 3+ years?

Yep, professionals make mistakes all the time... but we like to call it experience This statement is like saying Doom should have used 3D models instead of 2D sprites. The game is released, doing phenominally well, and you say they are throwing away money? I disagree.

quote:

---

Since they have more money than they know what to do with it doesn''t really matter though.

---

Don''t know what do do with? Please... It''s called StarWars Galaxies, Planetside, Sovereign, EQ2, EQOA (do I need to continue?)

quote:

---

I didn''t say it''s the only solution. It''s just a significantly better solution.

---

Based on what experience KalvinB? I''d refer you to the last few comments of my previous post... This solution isn''t always better. I''d be willing to say that in most cases it is less than advantageous. The number of IO operations with this model are phenominal. IO is typically more expensive than computation. It doesn''t matter how fast your ethernet is, you are still generating and handling an interrupt every time you send the data one way or the other. Are there cases where a seperate AI server is still beneficial? Sure, but again, not always the case...

A better solution might be a seperate process on the same hardware (assuming multi-processors) accessing shared memory. Not sure how well it would work on Windows, but Unix would treat this model very well.

Ok, I hate it when someone knows how I am and I don't know who they are. ;-p


Identify yourself fingh man.

EDIT: Hi Tim. ;-p What are you working on these days?


[edited by - smanches on July 25, 2002 7:57:46 PM]

I understand on what you mean. I think I know what your talking about since I had those discussions with many people. It's a good thing too, they should help a lot.

Everyone needs to bow their heads to EverQuest for all of the lessons we've learned from SOE/Verant. Some dos, some dont's, some shoulds, some wouldnt's, and lots of basic facts. All of this, expecially the facts, have taught us what we need to do for successful MMP games. Although I have some issues with some of the technical decisions that were made in EQ, I can't argue at all with what I've learned from it. So here's to EQ.

BTW, fingh, my username here is "smanches". I'm not at SOE anymore. :-p LOL, that's funny you put "smanchester".

Back on topic:

Shared memory is a great idea if your architecture is to put the AI precess on the same box, and windows can handle it fine as well, not that you'd use win32 boxes for these servers. I've thought about it alot and especially if you using four or more processors, this is the way to go. This is where the "moeny they don't know what to do with" thing comes in. A startup won't have the money to buy big quads or eightways, not that I think anyone should, so they have to work with single or dual processor machines. The thing we've been talking about.

I'm not saying you can just take a client and put AI routines in it and that's your server. The AI server is very specialized and talkes to the game servers in ver specialized ways. Ways that reduce update times, processor load on the game servers, and network traffic. The servers have to help each other out, not just talk to each other.

This thread should be renamed "Distributed processing in an MMP game environment" since that is really what we are talking about here.

[edited by - smanches on July 25, 2002 8:21:05 PM]

Jeez! This small topic I started a few days back has exploded it seems..

*****
btw - It''s interesting to see real MMP professionals here from games such as EverQuest (etc).

*****
Anyhow, I''ll most likely have at least one AI machine hooked directly to a hub which feeds to my game servers. I''m not going for the huge scale of most MMO games, thus I feel one AI server would be enough.

Well even though this thread doesn''t ''belong'' to me anymore, I still want to say thanks to everyone who''s posted info on the topic at hand.

Regards,
Nate Strandberg

I thank you for starting it. These ideas have been going around and around in my head for a long time now. It''s nice to be able to discuss them with people. It always gives more ideas.

*gasp*
Discussion in a forum thread? Quick, someone lock it...

"This statement is like saying Doom should have used 3D models instead of 2D sprites."

No it''s not. There''s your first absurd analogy for the day.

If Doom had used 3D sprites instead of 2D the end user would have had to spend more money on a better machine. As it was, you just needed 4MB of ram which wasn''t unreasonable at the time. It was still enough to slow down the distribution of the game. I''ve yet to buy a game that requires a GeForce 3.

Putting AI in the game server itself cost the developers money having to invest in higher powered machines. It also costs money in down time when they want to upgrade the AI.

Apples and Oranges.

"Based on what experience KalvinB?"

Let''s try logic. Can you do that? Considering your Doom analogy I''m beginning to doubt that. Or at least you''re not making an effort at it.

smanches:
"I''m not saying you can just take a client and put AI routines in it and that''s your server."

Actually you can and it''s a good start when first trying out the method. It''s just not pretty.

"Ways that reduce update times, processor load on the game servers, and network traffic. The servers have to help each other out, not just talk to each other."

After I initially wrote the NPC client for Tombstone it took a week or two to get it efficient. The server now verifies it doesn''t send the same message to the same connection more than once which saves a great deal of bandwidth and processing time on the server side.

Ben


IcarusIndie.com [ The Rabbit Hole | The Labyrinth | DevZone | Gang Wars | The Wall | Hosting | Dot Com ]