How do you figure if A has met B?

        //declared earlierCharacterDesc *met;CharacterDesc A,B;met = A.Knows;// we do our searchwhile (met){   if (met == &B) return(TRUE);   met = met->Next;}return(FALSE);        

Not really that difficult. Though some optimisations can still be made

-Chris Bennett of Dwarfsoft - Site:"The Philosophers' Stone of Programming Alchemy" - IOL
The future of RPGs - Thanks to all the goblins over in our little Game Design Corner niche
          

Edited by - dwarfsoft on October 30, 2000 11:41:44 PM

"bitch, on your knees"
Thats fiction of course!
Ferrett

www.shogunmod.com
Its your time to choose.

For online games:

Serverside: each NPC has a code.

During game, player will encounter NPCs. When a player learns the name of one of these, he has to manually input the name of that character (in a pop-up box or something).

Clientside: this is where the name that the player typed is stored. Whenever the player sees an NPC walking by and has for example a ''show name'' option running, the name will be displayed when it is stored on client side, otherwise it will not show up.

I have NO clue if this is a possibility as far as programming is concerned, but it would also open up a nice option where players can give descriptions of players when they don''t know their names (which would work wonders for PC interaction).

There could for example be a ''show description'' option running, that would display the description that the player manually put in for a certain character. ''didn''t want to help me out when I was dying''

Plus, a system like this might finally open up a ''disguise'' feature, where if a player disguises himself well enough, his name won''t display to players that have formerly met him etc.

Silvermyst

I''d have to agree more with Silvermyst''s aproach. From a security standpoint, storing the information about NPC on the server is much more secure. Only send info about an NPC to the client when that particular client meets that particular NPC. For NPCs that haven''t been met, simply refer to them by a unique number or code as Silvermyst called it.

The problem with storing NPC info on the client side before they should really have access to it is that, even with encryption, you should always assume that someone out there wil find a way to break it. You can put checksums in, but they aren''t that hard for a competent cracker to find. Even if you put a ckecksum on the checksum and a checksum on that checksum and a checksum on that checksum... (you get the point)it wouldn''t be that hard for someone to find them and disable them. In fact, the more complex you make your access control system the more interesting the challenge will be to a potential cracker (just look at the, proported to be unbreakable, piracy protection in the Bleem Playstation emulator. It was broken in less than a week). Your best bet is simply to give the minimum amount of information to the client and then supply it as it becomes available to the player. Besides, in a MMORPG you''re probably going to be adding new NPCs pretty regularly and NPC names/descriptions aren''t something like textures or geometry that will take a long time to download.

-Daedalus

Niphty - It was supposed to be a fairly simple to follow C++ exampe of pointers and referencing... I thought that people could understand it... Did you really want me to define the

"typedef scruct CharacterDesc_st {...} CharacterDesc, *CharacterDesc_ptr;"?

Null'n'Void - I am glad to see that someone understands the basics

. And NO.. I don't like Hungarian notation

-Chris Bennett of Dwarfsoft - Site:"The Philosophers' Stone of Programming Alchemy" - IOL
The future of RPGs - Thanks to all the goblins over in our little Game Design Corner niche
          

Edited by - dwarfsoft on October 31, 2000 12:58:35 AM