Manageing NPCs out of the screen

Started by
14 comments, last by darkbard 20 years, 7 months ago
People tried ot hack SETI too, they would fake the amount of CPU time they has spent or send back doctored results. As a result SETI had to use more redundant computations to verify the hackers.

-ddn
Advertisement
quote:Original post by Timkin
You''re asking for a world of torment and heartache here... it would be far too easy for someone to write a hacked AI NPC that destroyed the gameplay experience for your players. You might think that this wouldn''t happen, but trust me, there are people out there whose only happiness comes from the misery of others.

SETI is different in that it works in isolation from the main server, except to update it with the results of its work. It doesn''t need to communicate back to the server in real time and the results don''t affect the data sent out to other clients. Your game, on the other hand, would be different. Your AI clients would perform actions that would affect the game world and thus the data sent to other AI and players. This is very open to corruption.

Timkin



Do you think there is a way to avoid the hacker problem?? Maybe using special controls on client application or using particular ways of comunication.
Its pretty much impossible to prevent hacked clients if your perform game logic in the clients. No matter what safeguards you put in your client, a hacker could just dissassemble the client to see how it works then either get around the protection mechanisms, or replicate them. I wrote a small article on this type of thing at http://members.shaw.ca/optikal/MMORPGSecurity/MMORPGSecurity.html
I''ll read this article, it should be interesting.
Do you think my system could work if I run the clients that manage NPC on other "secure" servers??

In this way there won''t be problems with hackers (I hope!), and I could exploit many servers to manage NPC''s AI, without makeing the main server to run slower ...
Yes. For example, John Laird and his team implement Quake bots using their SOAR planning language. Each bot resides on an external machine (because they EAT memory and CPU cycles) and communicates with the game server via a LAN.

You wouldn''t need to go to this extent, however you could reasonably design a multi box system.

box 1-comms: handles communications between clients and the server box;
box 2-server: defines the game stats and handles collision detection, world physics, game loop (timing), etc;
box 3-AI: handles all NPC decision processes

This is just a very rough sketch of how you might break up your game server. There are plenty of good models out there. Do some net research to learn more!

Cheers,

Timkin
quote:Original post by Timkin
There are plenty of good models out there. Do some net research to learn more!


Do you know where I can find them??

This topic is closed to new replies.

Advertisement