In a massive-multi-player game, is the NPC AI usually done on server side? The server would do all AI calculations and keep track of every NPC in the map. When a player is within range of an NPC, the server would simply indicate what that NPC is doing at that time and client CPU will show it. Then does this in effect mean that there is no limit to how complex MMORPG AI can get? Since the machine used for server is certainly very powerful and there is enough resources to create as advanced AI as the programmers can make it. I just wanted to check if I understand things correctly. Thank You

I would think that it''s done server side. If it was done client side, then anyone near the same NPC as the client who''s computer is doing the AI calculations has to wait while the AI stuff is sent from client, to server, to other clients. It seems like it would make sense to do it server side, and send it to clients from there. I think that would make a big difference to 56k users, so that point might be worth keeping in mind...

Of course, I''m only an amatuer programmer who uses Tcl rather then a real programming language, and I only have a 20% complete MUD under my belt as far as experience goes...

i''m thinking of the same thing actually.. i''m almost sure that in every game until now have used ai on the server only.. but what if u could releave the server from some cpu load?

the current internet connections are getting better and better and if u could just see at what kind of connection the user has (pingtime/bandwidth) wouldn''t it be good to share the load to the user? if ur thinking of a massive online rpg this would help a lot if there are lots of npc''s(and extensive ones)
however be sure not to share it with 56k6 users etc with bad pingtime/bandwidth

it''s not ez but would help i think...

i''m thinking of the same thing actually.. i''m almost sure that in every game until now have used ai on the server only.. but what if u could releave the server from some cpu load?

the current internet connections are getting better and better and if u could just see at what kind of connection the user has (pingtime/bandwidth) wouldn''t it be good to share the load to the user? if ur thinking of a massive online rpg this would help a lot if there are lots of npc''s(and extensive ones)
however be sure not to share it with 56k6 users etc with bad pingtime/bandwidth

it''s not ez but would help i think...

Yeah, in a perfect Utopia of the Internet the idea of distributed computing makes idealistic sense. I get 5 computers, put them together on a common code base and get my work done quickly and efficiently.

Unfortunately, reality hits you quickly. First, is reliability. You can''t control the computers if they''re not on site. What if you get a good connection then suddenly it hits major packet loss or connection issues. You have to switch overhead to another.

Also, when it comes to games, cheating goes rampant. So, while doing the distributed idea is great, the reality is someone will find a way to abuse it to his or her own end.

If you''re making some program to share with friends, dont'' care about cheating and really don''t care if a computer node goes down from time to time, then it''s a great idea.

But most games today require very high expectations of stability and require a "fair playing field" since they''re multiplayer.

So, the result is most of the work is done in a server farm and the results are published to the end machines for display. =(

R.

Rube, you're right. Seems like server side is the only solution.

Anyway, Thank you all

Edited by - Cameron on December 26, 2001 10:40:50 AM

For any kind of serious project, you will never want to trust the client to do anything for you. If your server is loaded, then consider breaking your world into more managable pieces, e.g. zones. Run each zone as a seperate executable, so that heavy-use zones can run on seperate systems. Using this method, the system has relatively few entities (NPCs/PCs) to keep track of. This is the way that the most popular MMORPGs currently handle this problem.