Best way to store NPC and PC in games

Started by
7 comments, last by graveyard filla 19 years, 3 months ago
I am starting to work on a hobby project, that will include NPC an PC characters. At the moment I am working on the design of the classes and the way I would store values. Yes I am working on a MMOG, or MUD type system, but I am expecting to either never finish the project or dump it in the future. Just using it to help develop skills in AI and Networking, then move on to Graphics. The Question I have is. What would be the best way to store the Character data? I was planing on storing the data inside the same class, and if the character had a flag I would seperate it to be either an NPC or PC. Or do I create a base clase and then have seperate classes for PC and NPC Characters.
Mykre - BlogVirtual Realm :- XNA News and Resources from Down Under** For those Interested in an Australian XNA User Group Contact me though my site.
Advertisement
really depends on what you're looking for. if an NPC has hit points, a conversational tidbit, a weapon, and a skill with that weapon, and a PC has hit points, 10 skills, an inventory, equipped weapon/armor, etc, make a base class that has the things in common (in this case hp, weapon skill, equipped weapon) and then derive the rest of what you need from that.

if both the PC and the NPC have exactly the same things in them, then just make one class and set a flag.

it would probably help you to design out exactly what you want as far as character, and then think about the gameplay and how those things come into play. for instance, if you choose to make NPCs and PCs exactly the same other than a flag, and then find out that the NPC never uses some element of that, it may be worth it to design an NPC and then derive a PC from it. if the opposite is true, design it that way. if they both need to have things that the other never uses, then might as well make an abstract base class, and derive them both from it.

hope that helps :)
I would post this question in the "Game Programming" forum. :)

For my part, I'd implement it as a class hierarchy. A base class with all the common properties and two derived classes which implement the methods that differ. Even if all stats are the same, the methods most likely are not.

On the other hand, if you use some kind of model-view-controller pattern and your character class is just the model, then you could use the same class and just write different controllers for both.

------------------------------

There are only 10 kinds of people: those that understand binary and those that don't.

Sorry I thought I would post it here as I am still designing the systems, at the moment I have not decided on a code base, (Thinking of C# or maybe C++, with both choices I will be using managed code).

At the moment All my work is still on paper, just deciding on the class layout before I dig into code.
Mykre - BlogVirtual Realm :- XNA News and Resources from Down Under** For those Interested in an Australian XNA User Group Contact me though my site.
Heres what I did (of course im very component oriented)

Create a base class that will function as both a player and an NPC
such as cEntity. The entity has inventory, limbs (each can hold something),
abilities, etc. If you want you can even derive this from a cObject which
contains information such as weight and various statitual information
relevent to every single object in the game world (so essentialy a buff guy may even be able to carry a midget :)) Then derive from this entity (which btw has controller functions such as MoveLeft, MoveRight, etc. and create a PC class which maps the controller (keyboard, pad, etc.) to the Handler functions of cEntity. Then for the NPC instead of mapping an HID map a small AI to it, which calls these functions. This way, everything in the game world interacts on the same level, simplifying things, and allowing for almost unlimited future enhancements.

EDIT: Structure

  <cObject> // weight, identity, maxholds, etc.    <cEntity> // Every living , or semi living creature      <cPC>  // mapped to input (can be network input)      <cNPC> // mapped to an AI proggy    <cItem> // cost, grouping, etc      <cWearable> // player imp. stats      <cUseable> // scripted change      <cKey> // tested as a key item  <cTrait> // any useable function    <cSkill> // works like an activated key item    <cAbility> // Any useable ability causing change      <cMagick> // Mp consumed      <cTech> // Tp consumed
Quote:Original post by PaulCesar
  <cObject> // weight, identity, maxholds, etc.    <cEntity> // Every living , or semi living creature      <cPC>  // mapped to input (can be network input)      <cNPC> // mapped to an AI proggy    <cItem> // cost, grouping, etc      <cWearable> // player imp. stats      <cUseable> // scripted change      <cKey> // tested as a key item  <cTrait> // any useable function    <cSkill> // works like an activated key item    <cAbility> // Any useable ability causing change      <cMagick> // Mp consumed      <cTech> // Tp consumed


In my opinion your CWearable and CUseable should be interfaces that every class can implement. This way an item could be wearable and useable, the same goes for other properties that have functionality attached.

Also, I'd refine the class hierarchy a bit. For my taste your CObject is too specific for example, but that might be personal preference. :)


------------------------------

There are only 10 kinds of people: those that understand binary and those that don't.

If you write your own virtual machine to handle all game mechanics, you can do a virtual memory dump.

GDNet+. It's only $5 a month. You know you want it.

I would just go with a single Character class and store everything in that. If you need separate behaviours I'd derive subclasses from the base behaviour type, not derive PC and NPC classes. (This would be like the Strategy design pattern.)

Moved to Game Programming; Game Design here on Gamedev.net is for the creative side rather than the software engineering side.
hi,

im working on a 2d MORPG myself. first, i have an "Entity" class. Projectile, Weapon, and Character inherit from this. Player, Npc, and Enemy all inherit from Character. "Enemy" and "Npc" might be bad choices for names, maybe "CombatNpc" and "NonCombatNpc" would have been more appropriate.

anyway, this is just how i do it, and there are other ways. i know of one MMORPG which has a single class which NPC's, players, etc all use, and the class just has a flag which says "im an npc" or "im a player".

keep in mind you are going to want to group your objects somehow. for example, in my game i partition the players and characters by maps. each Map has a list of all Character's on that map. when an event happens to a player and it has to be told to the other players, i broadcast the event to all players who are on that players map. for example, when a player moves, all players on the map are notified of it so they can move it on their simulation. however, not all messages have to be broadcast to everyone on the map. things like guns firing and people talking are sent to people on the same map and within a certain range of the player. anyway, just look out for this ahead of time and design your code so that you can group things togeather. you want to look out for situations like when a player enters a new map and has to be told about items sitting on the floor, players, npcs, etc. if you have all of these grouped togeather, it will be easier and possibly faster to do things like this.
FTA, my 2D futuristic action MMORPG

This topic is closed to new replies.

Advertisement