GameMaker NPC object good practice

[cpate]

Hi all! I'm quite new to this so I appreciate all feedback.

I'm currently trying to figure out how to best approach having numerous NPCs with varying importance (more important -> more features), different dialogue, etc.
I had originally thought to create one generic NPC object and create ini files to set the name, sprite, dialogue options, etc., for each NPC. But now I'm considering having different NPC objects depending on their function (merchant vs bystander). Which still leaves me with the option of creating ini files for each instance of merchant or bystander.
The reason I want to have this information stored externally (as opposed to in the Creation Code of each instance) is because if I find it more adaptable and simpler to change. Is this recommended?

Essentially what I'm asking is the following:
1. What are good practices in terms of organization and performance for creating numerous (>100) NPCs? External storage and generic objects, one object per NPC, etc.
2. Assuming external storage is the way to go, are ini files recommended?

Thanks!

 

[Jordan Robinson]

I think it depends what information you are trying to store, but personally I feel it would be easier and more adaptable to use the parenting system to have a basic NPC and then children of that object can add extra variables if required

ini files are great for small amounts of information, like storing a few settings etc so it depends just how much information you are trying to save and load from them.

 

[cpate]

I see, so for the generic NPCs I'll probably approach it that way. However, some NPCs I have will have a lot of conditional dialogue and a complex story behind them, but may be functionally simple (all they do is talk). For those I felt I should store their information in files, so that when I create the instance it automatically fills in the variables without me having to manually do it in GMS. What do you think?

 

[Taddio]

Yeah, and the thing with .ini is that it's easy for the end-user to just open it and mess around with the values, thus making your Sword of a Thousand Truths worth -1 gold at the shop. So wouldn't recommend for shopkeeper data.

Definately separate shopkeepers from "real" NPCs, tho, it's going to be way easier. You could use a parent for the common behavior if you wanted to make ot really cool.
Personally, I would just make my own branching dialog system, but there's a bunch of them on the marketplace if you want to go that road. Dialogs you could just store in an .ini if you really wanted to, but I'm guessing some simple hacks with arrays would be sufficient in your case.
You are probably going to place NPC manually in the room editor anyway, so the simplest way is to store their specific messages in the room editor. To me, it's the best way if you're not looking for philosophical complex dialog branching, but it will work well if you need a Zelda/Pokemon level of intelligence from your NPCs

 

[cpate]

Yeah you're both probably right, I'll stick to doing it internally. Thanks!