NPC Configuration

Started by
3 comments, last by TechnoGoth 19 years, 1 month ago
I was wondering what some of you use for keeping track of NPC's in the game. For instance, do you have a generic class cNPC and then define out the NPC's such as this: #define NPC_Yerra 0 #define NPC_OldWoman 1 #define NPC_Sailor 2 cNPC *pNPC = new cNPC("Yerra", NPC_Yerra); pNPCList->Add(pNPC); pNPC = new cNPC("Old Woman", NPC_OldWoman); pNPCList->Add(pNPC); etc... Or do you create a class and base each NPC off of that class? Or do you do something else? Thanks, Chris
Chris ByersMicrosoft DirectX MVP - 2005
Advertisement
You might regret making each NPC a #define later on. I would personally store then in a file, even a simple text one.

I think you could have just a single class for all NPCs. You just need to be able to handle different dialog, maybe from a text file or script for branching dialog.

Then you need an array or dynamic array of all the NPCs, but that is more game specific and Im not sure if it relates to your question.
Sure is a big 'ol world.
I tend to have one single class for all NPCs. If there's a lot of NPC duplication going on (eg. an army of goblins) I separate things out into 2 classes, one for NPC instances and one for NPC types. I also try and stay clear of hard-coded constants and instead use numerical values or string identifiers; this makes it easier for designers to create new NPCs through script, data, or even in the game itself.
Very good points. Interesting that you mention the scripting Kylotan. I'm working on a dialog database that plugs into a generic game engine (but mainly useful for RPG type), the reason I asked the question. I wondered what people are doing and how I could make it seamlessly integrate into their style of code.

I'm building the editor so that you can specify either a string name or an integral designator. Then you can access an NPC's dialog with either of these in the actual game. The reason I'm concerned is because in your game engine you would probably have an ID or Name associated with NPC's that talk, say an NPC that provides a quest. I would imagine that name or ID would be passed into a callback function when the player initiates some action to start a conversation (i.e. click on an NPC). You could then just pass that to the dialog database and let it choose which text you would display next. Does this seem feasible? Is this callback approach how you would do it, or if not, what do you do when the player initiates a conversation with an NPC?

EDIT: Additional info, feel free to provide feedback: The database contains States, which can be set by the database itself or by the game engine. A combination of states I call Required States must be satisfied for the text to be returned. For instance, a state called "Player_Health_Full" must be set to accept a quest, so when the player clicks on the NPC, the database checks that state and determines which line of conversation to follow. The database has two ways of working, free response and canned response. In free response, keywords are tested and NPC dialog is returned, again based on States. In canned response, a conversation with an NPC is kept track of as it occurs and player's available choices (based on States) are returned to the engine. When a NPC dialog text is returned, a callback occurs with user programmed data and information about that NPC, if the programmer sets the callback. It could also set a State internally in the database. "Player_Knows_NPC1_Name" would indicate that the NPC doesn't need to introduce itself again next time. What do you think? I take criticism well, so feel free. I would like to make it the best it can be within reason.

Thanks!
Chris
Chris ByersMicrosoft DirectX MVP - 2005
If you want an idea of how dialog can be organized and accessed in a game take a look at the structure I posted to help some else.
Quote:
For classes I would recomand have the following:
Conversation
TextBox
Actor
Script


Conversation will handle the actual mechanics of running a conversation it will have a list of all actors involved and the current points in their scripts they are at.

TextBox handles all the text rendering, Convestation will call it using a method like:
show(string text)
Which renders the given text to the screen in the text box.

Actor is your npc class it is in no way connected to Conversation or TextBox, it has an istance of script which represents all the dialog that actor can say in the game.

Script hold all the dialog an npc can say, it should be organized in way that makes it easy to for an external class - in this case Conversation - to access the desired dialog in the script and follow along with the script in the correct mannor. You'll probably want some method of storing and accesses dialog based one acts, scenes, and lines for plot specific conversation and a generic catagory organized in a similar way for generic banter. You can and should also consider using a many to one relationship between actors and scripts. Meaning many actors can ues the same script. This will allow you to have generic conversation for groups of npcs without the need for replication.


I personally think that good easy to use tool for setting up and maintaing game dialog using this structure, along with a set of methods to easily access the data with a minium of overhead would be very useful. I would defently use such a tool.

This topic is closed to new replies.

Advertisement