The Month of the NPC - Roadplan in OP, creature-rewrite branch in repo

The Kickstarter reward fulfillments loom. One of the major ones is backers as NPCs. So a big task awaits us, a task that is (perhaps) the biggest single task for the Cataclysm DDA projects.

We need to kill the NPCs.

Atop the corpse we will build a glorious new revolution free from their madness. But its too big for me to handle it alone. Ill be needing help, so if you want to really help the game moving forward with this most momentous of tasks, let me know. We’re going to be rebuilding them from the ground up, and there’s going to be a lot to cover.

Current Roadplan:

CURSE MY EXTREMELY LOW CODING SKILLS

I wanna help :frowning:

Sounds like a good idea to start over npcs from nothing. They are way too broken atm to be fixed. You will probably have to clear quests also cause they have some npc stuff in them too. I also have no coding skills sadly :s

I’ll gladly help in any way that I can.

I’ve turned out to be pretty good with editing .jsons and faking my way through the deeper stuff where I have examples to work from, but I can’t claim any real serious programming skills.

What we really need is an endless list of things to add to npc’s. So we can tie the devs up indefinitely.

Sadly I can’t program… so ya, can’t really help there. But I’ll ask around see if some other people have experience working with npcs. Might even find some helpful input or an extra set of hands.

The only things I can do is to draw some artwork and add some wicked ideas.
Also, Python coding, but who needs Python?

Well, the first step is basically bookkeeping and requires minimalmal code knowledge. But the information will form the foundation of our plan to move forward. We need a thorough assessment of what NPCs do - at its most basic, this requires looking through the .h file and making a list of every method available for the NPC and what it does. Then we need to get an idea of its dependencies. We will be functionally starting from scratch so this is primarily for understanding.

Then someone needs to do the same thing for monsters, since they are probably going to end up sharing a base class.

So basically, an apprenticeship whereas one needs to understand the concept behind current classes and functions in order to effectively help with the new system. I guess the person that claims this would be jumping on an open cargo wagon for the moving C:DDA train but then, so did the team do with the original Cataclysm game; so an excellent example to be made.
I’ll just do the following: fetch the Whales’ source code, try and understand what he’s been up to; and if I am to succeed, I’ll make a post here.
(only to encourage every other effort coming from the community members, of course)

As mentioned on IRC, I’m happy to help with this, assuming that this will give us a chance to unify monster/NPC/player interfaces into a single base class and otherwise clean up that part of the codebase.

Whatever happens, I wish all of you good luck on your endeavors.

... We need a thorough assessment of what NPCs do - at its most basic, this requires looking through the .h file and making a list of every method available for the NPC and what it does. Then we need to get an idea of its dependencies. We will be functionally starting from scratch so this is primarily for understanding...

And for the help:

The npc.h file found here.

There are also movement rules in npcmove.cpp…

[quote=“vultures, post:12, topic:3188”]

… We need a thorough assessment of what NPCs do - at its most basic, this requires looking through the .h file and making a list of every method available for the NPC and what it does. Then we need to get an idea of its dependencies. We will be functionally starting from scratch so this is primarily for understanding…

And for the help:

The npc.h file found here.

There are also movement rules in npcmove.cpp…[/quote]
That’s the pre-DDA source; the current npc.h is here.
It’s already pretty heavily commented, so this shouldn’t be too difficult.

Okay, finally got internet back at home! I will dive into this tonight and see if I can’t come up with a plan.

FWIW the impression I’m getting of how this will go down (architecturally) is something like this:

[ul][li]Unify monsters/players/npcs under a baseactor class. This class has (more or less) the same interface that the current player/monster classes do.[/li]
[li]Create some kind of actorAI class. Each baseactor has its own actorAI, which, given the state of the gameworld and the baseactor it’s attached to, will come up with that baseactor’s next move.[/li]
[li]The player has its own special actorAI class which, instead of actually being an AI, just proxies all decisions off to incoming keystrokes (i.e. its actorAI is the entire UI of the game)[/li]
[li]Missions/quests, factions, etc etc, which I haven’t really thought about much[/li][/ul]

Let me know how off the mark I am :wink:

I’m not so sure whether monsters/players will end up being merged. Right now there are a bunch of differences between the two, enough so that it might be better just to handle them separately.

I’ll try to pop into the IRC channel this week and volunteer a bit. I took C++ classes for years in high school and college but I’ve never really done anything with it and I’m a bit rusty.

I do know some folks who coded for SS13 for ages who have some idle hands right now. I’ll bug them about maybe joining the project in the mean time.

I came to the realization this morning that we have a bijillion pieces of code that look like:

   int mondex = mon_at(tx, ty);
// If we shot us a monster...
   if (mondex != -1 && ((!missed && i == trajectory.size() - 1) ||
        one_in((5 - int(zombie(mondex).type->size))))) {
    monster &z = zombie(mondex);

    // Blablabla details

    shoot_monster(this, p, z, dam, goodhit, weapon, effects);

   } else if ((!missed || one_in(3)) &&
              (npc_at(tx, ty) != -1 || (u.posx == tx && u.posy == ty)))  {
    // Blabla details
    player *h;
    if (u.posx == tx && u.posy == ty)
     h = &u;
    else
     h = active_npc[npc_at(tx, ty)];
    }

    shoot_player(this, p, h, dam, goodhit);
   }
  }

That should look like:

  creature *target = creature_at(tx, ty);
  if( creature != NULL && /* Other generic tests for hit-ability */ ) {
    // Blabla details
    creature->shoot(/* args denoting severity and effects */);
  }

So I’m definitely on the side of unifying a base class (My suggestion is creature, I don’t like using CS-ish terms, they tend to be very generic and easy to misinterpret) under pc, monster, and NPC.
The open question is what the player-monster-NPC heirarchy looks like, are they all siblings? are NPCs a subclass of monster that knows how to talk and use tools? Are player and NPC siblings under some other subclass that encapsulates tool use, hit location, etc?
Personally I’m for creature -> monster, creature -> person -> NPC, and creature -> person -> player.

Haha, Kevin, I ended up looking at this last night and coming to the exact same conclusion. I decided I was going to pursue:

[tt]Creature --> SimpleCreature
-> ComplexCreature --> NPC
-> Player[/tt]

Which is exactly what you just suggested. So yeah, NPCs and Players would be siblings under the complex creature class.

That’s sorta how we had it in SS13.

Creature – > simplemob --> npc’s
-> mob --> players

example: mobs have internal chemistry, hit locations, and are susceptible to diseases

simplemobs just have HP. both have enough animations and interactions and the proper VARS for people to control both (make me a corgi!), and do simple things like fight interact with objects and die properly, but cool code like transmitting diseases and getting drunk don’t involve the corgi.

be careful about lumping NPC’s into the same creature group as players though, you wouldn’t want them to all starve to death in the first week because whoops hunger/thirst.