Crimmor the city is laid out in a haphazard manner, much like an actual medieval city. There's no modern grid pattern, its mostly just a jumble of streets that go every which way and are rarely straight. I still get lost, and I built the place!
To ease things I've color coded the extensive set of map points visible on the minimap.
Red: marks safehouses, the guildhall, and the players house, these are
friendly locations where resting is allowed (no resting on the streets
or in some random merchants store!). Red also marks active quest
locations, so your minimap will highlight where you need to go for
quests. The red quest markers are only active while the quest for that
location is open. For locations that have multiple notes, such as a
store that becomes involved in a quest, the quest note takes precedence
so there are not two notes at the same point. (I'm not recoloring a
single note, I use multiple notes and display/hide as appropriate.
Green: these notes indicate a location name, Wight Alley, The Drae, Firesteep Square, Carn Market, etc. These are both for flavor as well as a potential marker to guide players on quests involving locating things ("He hangs out at Carn Market in Purse Ward").
Default color: generic points of interest such as stores.
Blue (may change, the shade I picked looks close to the green) : Dead drops, which function as quest givers. These are only located in the wards of the city you work as a fixer for.
Yellow (may change, looks close to default ingame): area transitions between the sections of the city.
Monday, April 30, 2012
Monday, April 9, 2012
A new feature for my commoner ai
As I was testing various activities for my commoner ai I realized that my "sleeping" commoners would get up and pick another activity at the time period change, meaning they wouldn't be asleep for a normal amount of time. I also realized there was no way for them to go home for the night (only sleep in the same area was allowed). So I've added a new activity and some new functionality that I'm currently working out bugs in. You can now give a "go home and sleep" activity and commoners will find and move to a random door in the area, play the "use" animation, and go script hidden for 9 hours (8+1 for breakfast). At their wake up time they unhide themselves and pick a new activity based on the time. Once that is working, I will add the code to force the activity for a sleep period to all the sleep activity functions, and add a sleep until morning and a sleep until evening function.
The go home and sleep functions will allow builders to have their streets empty out at night (or day if you want vampire commoners :) ). Since these are command to essentially "leave the area", I could see them being used to empty out a tavern at closing time or give a shop hours, with the timely player being able to see these transitions.
Another use case for the commoner ai would be for something like a tavern, have the patrons sit and eat during the day, and get up and dance or play instruments at night, automatically.
edit: it looks like I've solved my problem with npc's sometimes getting stuck at their old waypoint when they pick a new activity. Pesky bug solved! And now my npc's also are "sleeping" properly in their go home and sleep activity, so I can add the sleep period code to the other sleep activities.
The go home and sleep functions will allow builders to have their streets empty out at night (or day if you want vampire commoners :) ). Since these are command to essentially "leave the area", I could see them being used to empty out a tavern at closing time or give a shop hours, with the timely player being able to see these transitions.
Another use case for the commoner ai would be for something like a tavern, have the patrons sit and eat during the day, and get up and dance or play instruments at night, automatically.
edit: it looks like I've solved my problem with npc's sometimes getting stuck at their old waypoint when they pick a new activity. Pesky bug solved! And now my npc's also are "sleeping" properly in their go home and sleep activity, so I can add the sleep period code to the other sleep activities.
Friday, April 6, 2012
What do you want in the commoner ai?
There are still some bugs, mostly in making sure the npcs to play their animation once they reach their waypoints and nailing down some time randomness. But at this point the ai's reached a state where I can start thinking about adding features people think need to be in an initial release. Some ideas I had:
Integration of Apep's dynamic commoners (Apep granting permission required): this allows commoners to automatically dress, get voicesets, names etc. I wouldn't expect permission problems from Apep. I view this as the "neat"-est thing that can be added.
Duplicate waypoint user detection: [edit: added this 7 April, and it worked on the first try! It also fixed the remaining animation bugs, npcs that elected the same wp would result in one getting bumped, and it would be too far from it's wp, so the animation would not play. Added feature and bugfix all in one!]
ensures an npc doesn't try to occupy the same waypoint that another one already is. Not so important for "cheering crowd", but the sitting and bed activities would benefit. Perhaps the most useful add, even if the benefit isn't highly visible except for specific actions.
Kemo sitting/bed support: for those halfling and dwarf commoners. Benefits the sitting/bed activities. I havnt looked at all at Kemo's system, this may turn out to not be doable. I think it should be doable, maybe not in a 1.0 release.
More detection of "appropriateness": npcs already equip their hands appropriately for activities. They could also dress appropriately, for instance making woodcutters wear leather armor.
Also in "appropriate"-ness: there are animations for female and male dance and seperate activity chances for each, but commoners don't currently only adopt the appropriate one (female npcs can currently choose the male dance animation and vice versa). Would people like commoners forced to adopt the "appropriate" animation for their gender? Would they want males being forced into the male dance animation even if the builder assigned 0% to male dance animation, or would re-selection of activity be preferable (that would mean a 50% chance of female dance would result in no males and 50% of females dancing) Or just leave it as is with no gender checks (females can play male dance animation and vice versa).
Holiday detection: allow a builder to use an area heartbeat to have a "holiday" setting, giving builders the ability to use a different set of ipoints for holiday action control (maybe the commoners all dance in the town square) This would be mostly on a builder to define when they wanted one, but a local int such as nIsHolidayToday could be set on an area to support that, and an alternate set of "holiday ipoints" could be included, with a small change to default scripting to look at that for that area variable and change the control ipoints appropriately.
Other, better ideas go below, or do you want to see a beta release first to play around with to see what you want?
Integration of Apep's dynamic commoners (Apep granting permission required): this allows commoners to automatically dress, get voicesets, names etc. I wouldn't expect permission problems from Apep. I view this as the "neat"-est thing that can be added.
Duplicate waypoint user detection: [edit: added this 7 April, and it worked on the first try! It also fixed the remaining animation bugs, npcs that elected the same wp would result in one getting bumped, and it would be too far from it's wp, so the animation would not play. Added feature and bugfix all in one!]
ensures an npc doesn't try to occupy the same waypoint that another one already is. Not so important for "cheering crowd", but the sitting and bed activities would benefit. Perhaps the most useful add, even if the benefit isn't highly visible except for specific actions.
Kemo sitting/bed support: for those halfling and dwarf commoners. Benefits the sitting/bed activities. I havnt looked at all at Kemo's system, this may turn out to not be doable. I think it should be doable, maybe not in a 1.0 release.
More detection of "appropriateness": npcs already equip their hands appropriately for activities. They could also dress appropriately, for instance making woodcutters wear leather armor.
Also in "appropriate"-ness: there are animations for female and male dance and seperate activity chances for each, but commoners don't currently only adopt the appropriate one (female npcs can currently choose the male dance animation and vice versa). Would people like commoners forced to adopt the "appropriate" animation for their gender? Would they want males being forced into the male dance animation even if the builder assigned 0% to male dance animation, or would re-selection of activity be preferable (that would mean a 50% chance of female dance would result in no males and 50% of females dancing) Or just leave it as is with no gender checks (females can play male dance animation and vice versa).
Holiday detection: allow a builder to use an area heartbeat to have a "holiday" setting, giving builders the ability to use a different set of ipoints for holiday action control (maybe the commoners all dance in the town square) This would be mostly on a builder to define when they wanted one, but a local int such as nIsHolidayToday could be set on an area to support that, and an alternate set of "holiday ipoints" could be included, with a small change to default scripting to look at that for that area variable and change the control ipoints appropriately.
Other, better ideas go below, or do you want to see a beta release first to play around with to see what you want?
Sunday, April 1, 2012
More on the commoner ai project
My wintertime funk has pretty much lifted, and so I'm spending much more time in the toolset. While I'm not working on Crimmor per se, I am working on functionality that I view as critical for it, my commoner ai system. It's at the stage of fixing bugs. Here's a link to my original blog post http://kamalpoe.blogspot.com/2011/07/commoner-ai-project.html
How to build with it:
There are premade ipoint placeables for each time period of the day, there are 6 periods, that can be set via script for whatever hours you want. These ipoints are placed in the area, and contain the local variables for the actions, the percentage chance an npc will adopt a given action. The builder sets the chance.
There are premade waypoints for each action. To be placed where the builder wants an action to take place. If you place multiple of the same type, the npc will randomly choose which one to go to.
A heartbeat script: any npc using this system needs to run this heartbeat, but does not need any other customization. No local variables need to be assigned (scripts auto set local variables), no creature tags required.
That's it.
How it works:
The npc heartbeat sets it's initial activity by determining the time, and checking against the ipoint for that time period, selecting an activity based on the percent chance as stored on the ipoint. It also determines a slight offset to the time period that shifts the time period for that npc, so not all npcs will change activity at the same time. The npc then selects a random waypoint tagged for the chosen activity.
The npc moves to the waypoint, and carries out the activity it chose until the heartbeat determines a new time period has been entered. It then selects a new activity based on the ipoint for the new time period and the process starts over.
Activities have predefined scripts to determine them, so a builder does not have to. These are pulled from Uncle FB and Lugaid of the Red Stripes systems. There are approximately 70 activities defined (and more can be added by a builder), covering things like farming, sweeping, working a forge, sitting and drinking, playing the lute, etc.
Scripts automatically ensure the npc is appropriately equipped (and eventually appropriately dressed). An npc that goes from walking around to playing the lute automatically has one generated and equipped, the npc does not need to be pre-equipped. If the npc then decided to be a woodsman, the lute is unequipped and destroyed, and a handaxe is equipped.
Nifty notes:
If you use Apep's dynamic commoner (http://nwvault.ign.com/View.php?view=NWN2PrefabPlaceables.Detail&id=162), like I am, you can have your commoners also automatically randomize their appearance, soundset, name, hair etc. on spawn. Use his included npcs, set the variables you want for his system on the blueprints, and change the blueprints to use my heartbeat. Viola, a town full of customized commoners carrying out randomized actions. Apep's system works, so it's just a matter of getting my ai working. Ideally, town ambiance has never been so easy.
I've also done some preliminary work on random pickpocket results (including failure and being caught) for generic npcs, similar to how Baldur's Gate had it, as a separate script for the OnInventoryDisturbed. That's a separate but related project. Status for that is built but not working. It's on my "would be nice to have" list. When I get that working at some point in the future, I will post a blog on that.
How to build with it:
There are premade ipoint placeables for each time period of the day, there are 6 periods, that can be set via script for whatever hours you want. These ipoints are placed in the area, and contain the local variables for the actions, the percentage chance an npc will adopt a given action. The builder sets the chance.
There are premade waypoints for each action. To be placed where the builder wants an action to take place. If you place multiple of the same type, the npc will randomly choose which one to go to.
A heartbeat script: any npc using this system needs to run this heartbeat, but does not need any other customization. No local variables need to be assigned (scripts auto set local variables), no creature tags required.
That's it.
How it works:
The npc heartbeat sets it's initial activity by determining the time, and checking against the ipoint for that time period, selecting an activity based on the percent chance as stored on the ipoint. It also determines a slight offset to the time period that shifts the time period for that npc, so not all npcs will change activity at the same time. The npc then selects a random waypoint tagged for the chosen activity.
The npc moves to the waypoint, and carries out the activity it chose until the heartbeat determines a new time period has been entered. It then selects a new activity based on the ipoint for the new time period and the process starts over.
Activities have predefined scripts to determine them, so a builder does not have to. These are pulled from Uncle FB and Lugaid of the Red Stripes systems. There are approximately 70 activities defined (and more can be added by a builder), covering things like farming, sweeping, working a forge, sitting and drinking, playing the lute, etc.
Scripts automatically ensure the npc is appropriately equipped (and eventually appropriately dressed). An npc that goes from walking around to playing the lute automatically has one generated and equipped, the npc does not need to be pre-equipped. If the npc then decided to be a woodsman, the lute is unequipped and destroyed, and a handaxe is equipped.
Nifty notes:
If you use Apep's dynamic commoner (http://nwvault.ign.com/View.php?view=NWN2PrefabPlaceables.Detail&id=162), like I am, you can have your commoners also automatically randomize their appearance, soundset, name, hair etc. on spawn. Use his included npcs, set the variables you want for his system on the blueprints, and change the blueprints to use my heartbeat. Viola, a town full of customized commoners carrying out randomized actions. Apep's system works, so it's just a matter of getting my ai working. Ideally, town ambiance has never been so easy.
I've also done some preliminary work on random pickpocket results (including failure and being caught) for generic npcs, similar to how Baldur's Gate had it, as a separate script for the OnInventoryDisturbed. That's a separate but related project. Status for that is built but not working. It's on my "would be nice to have" list. When I get that working at some point in the future, I will post a blog on that.
Subscribe to:
Posts (Atom)