Let's build A Better Village

[BigWeather]

Taking a cue from the "Let's play" series of posts on the Codex I'd like to start a "Let's build" series.

JarlFrank's excellent "A question of scale" thread (http://www.rpgcodex.net/phpBB/viewtopic.php?t=22457) really booted me in the arse to try and start this effort.

A theme that emerged in the thread was that a large-scale (world, continent, nation) dictated at least some use of procedural content. The issue was how do you make it varied enough to be interesting and not devolve into geomorph village generation and endless fetch quests? Section8 and OldSchoolKamikaze advocated narrowing the scale.

Section8 posted

"I don't agree that there's any right size for a game, though I think developers ought to be more wary of simply shooting for an "epic" landscape. Ultimately, it's going to end up feeling pretty sparse.

Story/sandbox has little to do with it. I think you could make a very effective sandbox using very few "sets" to use a movie analogy. Dynamism is the key. If you had a single village, but allowed that village to be flooded, set fire to, over-run, snowed under, etc. then you've got something that could potentially house more interesting dynamic siutations and events than a whole buttload of towns that exist and never change.

Of course, it would be even better to expand that into a world filled with detailed procedural villages. And I don't see why more RPGs don't go for that route. It's a lot easier to define the rules of what a village should look like compared to a "dungeon"."

Section8 hits on a very important thing here (and I echoed it later in my own response on that thread). It's natural when thinking about RPGs to think BIG. But doing so can often lead to breadth but no depth (outside of the main quest). The true benefit of sandbox mechanics comes from depth. And like in many other things in life, it's better to nail something then apply it to a larger scale than it is to try to get the large scale from the get go. Designing set pieces that are dynamic and deep and then applying them (with variations) to a larger scale is the way to go, I think.

Sooooo, let's build A Better Village.

Purpose
I'm envisioning this as a friendly collaboration, though each participant is doing their own work. It is not a competition, though, as a) I'm too cheap to offer prizes and b) it's not a go-off-and-work-for-a-year-and-post-your-EXE-at-the-end. Whether you choose to set up a site with your work, host side forums, post in this thread, whatever, is up to you. But I'd like to see people dividing up their efforts into deliverables that can be shown to the others (and Codex at large) incrementally. Doing so may lead to other participants going "Wow, that's cool -- let me try and build on that!" or what-have-you. The point is at the end we end up with everyone having built a better village based not only on their own vision (though obviously the participant is the final say) but inspired and guided by the thoughts and excitement of others (participants and not-participants alike).

Rules
These can be broken, and are more a set of expectations and hopefully will help focus the efforts of the participants.

Story
I'm sure most everyone in the Codex recognizes the importance of story to RPGs and respect the authors we have with us. For this Let's build, however, the focus is on how rich an environment can be built without story. Any real product that used any of these ideas would obviously allow for story to be woven into it, drive it, and be driven by it.

Mechanics
Participants' work need only have a rules / stat system in place such that is needed to illustrate the concepts they are trying to implement. If the participant wishes to explore the consequences of a murder in town a insta-kill key is perfectly acceptable. They don't need to model to-hit, weapon damage, etc.

Existing world state
The world state (or, more precisely, village state) at the beginning of the game can be arrived at in any way you see fit. The purpose of this Let's build is not to build a better soil deformation algorithm or village growth simulation.

If you want to create your own village via procedural generation, geomorphs, simulation of the 100 years before the game begins, or what-not, feel free. But it's not the point of this exercise. Also understand that early drops of participant's code may not have a village in place yet, but rather just a collection of NPCs the PC can interact with (mine'll be this way). Also the definition of a village is very loose. It could be a collection of Cro-Mags in a cave. It could be survivors of a shpwreck newly established on an island. It could be Oxford in the 13th century.

The key point is that there is an established collection of NPCs that have formed a community and are considered to be in a stable and entirely self-sustained state. Meaning that there is no dependence on outside materials / food / etc. Though the self-sustained state could be maintained once the game begins and no effort to model a simple economy attempted participants may find modeling a simple economy opens up for some very interesting gameplay.

The village can have factions at the start that could lead to problems as the game progresses. Note that these factions can be statically defined and their hatred of each other built in -- but there can be no post-initial world state scripting of their actions through story and what-not. The behavior of the faction should be driven by the game mechanics themselves ("if two npcs hate each other alot and can get away with fighting, they will").

The village is surrounded by wilderness. The wilderness can be a forest, a barren wasteland, whatever. It is another source of conflict once the game begins and is an opportunity for those that want to add in some more dungeon aspects the opportunity to do so. Note that just like the village the wilderness can be seeded with monsters that can have existing communities / hatred / etc. themselves.

Graphics
Graphics whores (mercifully few on the Codex) shouldn't expect much. There are no graphical requirements for this Let's build. Graphics may be required for some concepts that the participants want to explore, and that's fine. But nobody's work should be judged on the graphics (or lack thereof). Text, ASCII, Tile-based, Iso, 3D, entirely static bitmap menu screens -- all is fine, so long as it is what you need to explore your ideas.

Be aware that using non-public domain assets comes with a risk to the participant that the owner of those assets is not happy with their use. Each participant should go to lengths to secure their assets, whether through creating them, having them created, using public domain assets, or securing the rights to the assets of others'.

Sound
Not required, except in cases where the participant needs it to illustrate a concept.

It's intended for a game!
Never forget that we're exploring ways to make more dynamic RPG setting for modern systems. While a participant could implement the smartest NPCs and use neural networks they should ask "Does this serve the gameplay?" "Will I take up too many cycles to make this feasible for a game implementation?" and, most importantly for the overarching goal -- "Will this scale in the future?"

Executeable
I think a PC version is the most desired, and the participant should try to make it as self-contained as possible and provide links to any frameworks, etc. needed that can't be bundled. For other platforms participants will want to document with screenshots and text what they did for those who can't run it.

Time-frame
None. I know some of the potential participants have their own projects or (gasp!) jobs. Hobby programming can't become a job. That's a lot of the reason why I'd like to see incremental updates to everyones' villages. Some may come late to the game either having not found this Let's build or (hopefully) having been insprited by it. Some will leave early. It's all good. Any work anyone does that serves as a spark to getting RPGs to a better place is good.

Ownership
Both participants and the community at large must know that anything they contribute idea-wise becomes public domain. The implementation (code, assets -- provided they own them, any names), however, is still the participant's. But the ideas, the concepts will (hopefully) be lifted into other villages and improved, tweaked, what-have-you. This is a collaborative effort to make deeper dynamic RPG settings. If you have an idea, an algorithm, whatever that you are concerned about giving up -- don't give it up.

Expectations
I may end up being the only participant. That's OK. So long as the community is involved and ideas are traded and evolved and we end up in a better place RPG setting-wise it's all good.

When a participant updates their village I expect them to post on this thread. Point to where it is, explain what has changed since the previous release, explain what concepts have been explored and what feedback would be helpful. Also discuss future applications / evolutions / consequences of the changes.

Feedback is expected to be constructive. When commenting step back and consider what the participant is trying to illustrate. As noted above don't take personal exception to graphics, etc. Be nice. =)

 

[JarlFrank]

Sounds interesting. I can't do any programming, though [except for writing little programs that say "hello!" to you when you open the exe file], but maybe I could draw some pics of the city I have in mind or do something with some graphic program. Whatever.

I like the idea, and as I have many RPG ideas in my mind it would be well worth trying it out. [And maybe get the attention of some people who know how to develop a game... heh].

Don't expect much more than text from me, though, and maybe a few sketches.

But first one question before I start with conceptualizing my city. Would you prefer me to think about a city set in my 19th century steampunk/fantasy setting Witherheath, or one in my low-magic dark fantasy setting Iridia? The choice is yours!

 

[cardtrick]

I'm potentially interested in this. I've been screwing around with engines lately . . . I suspect this will be more work than I'm able to put in at the moment, though. I do hope you get some participants though!

 

[BigWeather]

Sounds interesting. I can't do any programming, though [except for writing little programs that say "hello!" to you when you open the exe file], but maybe I could draw some pics of the city I have in mind or do something with some graphic program. Whatever.

Not being able to program is fine. Discussion of ideas is important and pics / sketches could be helpful in getting participants inspirted. If anyone is a decent tile artist I know there's always a need for more tilesets. Bear in mind though, that it is ultimately the participants that determine what they want to implement guided by their collaboration to some extent.

The purpose isn't to build a specific setting, but rather using the constraints defined by a self-sustainable isolated village how much gameplay can we get out of sandbox coding with no story or scripts.

I like the idea, and as I have many RPG ideas in my mind it would be well worth trying it out. [And maybe get the attention of some people who know how to develop a game... heh].

Don't expect much more than text from me, though, and maybe a few sketches.

But first one question before I start with conceptualizing my city. Would you prefer me to think about a city set in my 19th century steampunk/fantasy setting Witherheath, or one in my low-magic dark fantasy setting Iridia? The choice is yours!

As said above, as far as getting specific RPG settings implemented that's probably more a follow-on to this than the immediate goal. (Though, I think a separate Let's create series of threads for interesting settings / storylines would be really, really neat).

I think the end point of participants' villages will be an environment the player can walk through and effect and in turn be affected. The dynamics in play would not only give a potential future RPG based on the mechanics more depth, but in turn could also affect a story that the RPG would have.

I'm hoping that in the future we'll be able to talk about RPGs we'd like to make and look back at Let's build threads (like you can imagine a Let's build A Realistic Terrain Generator) and say "I've got this great story, set in a low-magic dark fantasy setting. I really liked BigWeather's faction system and would love to use something like Section8's flood and fire dynamics and apply CardTrick's economy simulation while I'm at it."

Ideally at some point the participants will identify the parts of their villages that really worked and make a library with an API that specific RPG implementations could consume. Or they may decide to end it with the Let's build but they've still had an impact -- they proved through implementation of ideas what is feasible. I hope that those participants that came up with innovative techniques get some measure of recognition too. There are things that we can do today that haven't been done because of the focus on bloom and whatnot. Let's find them.

As for Whitherheath or Iridia, both sound really neat. But I've got to manage expectations here -- this is again more an exploration of subsystems and mechanics, adding tools to our toolbelt. It isn't meant to create the most awesome village setting- or story-wise but rather explore subsystems that could be, with later work with authors / artists / content creators, turned into exactly what I think your aiming for.

For instance, my first code drop will probably be a let down. It's not even a village yet, and is a smallish area with the PC and six NPCs and two types of objects. It uses a public domain prototype tileset that is definitely not what I imagine most Codex would consider "RPG-ish" (yes, in time I'll replace it or commission a tileset to be created).

But it's got a mechanic that's never been done, to my knowledge, in a RPG (prove me wrong, though!). It's an idea I've been thinking about for about two months and it was astonishingly easy to get done in the six hours I've spent so far. So why wasn't it ever done? Because I think the idea is so orthogonal to the way we think about computers in general and computer-controlled entities specifically that I think it slipped under the radar.

I'm really excited by it, and moreso about what it could mean when other subsystems are implemented. I'm excited by the prospect of fleshing it out as I add an actual village, with a simple economy, with a night/day cycle (if it serves the gameplay), etc. And at the end it'll be a village and because of the individual mechanics some neat things may come out that we haven't seen before.

Will it be a compelling game? As a sandbox, sure I hope. As a setting? No way. That's up to the artists to apply in the RPGs that spring forth using the mechanics we'll be implementing. Some participants (especially if provided with assets) may choose to create or apply really neat settings like the ones you propose and tailor their mechanics to it (remember, though -- no story and scripting allowed for now! =)) but it's up to them entirely.

 

[BigWeather]

I'm potentially interested in this. I've been screwing around with engines lately . . . I suspect this will be more work than I'm able to put in at the moment, though. I do hope you get some participants though!

That's cool, I think feedback is important as well for those that do participate. And you may find that you're inspired by someone else's village and say "I really think you need something like X" and prototype that, and once seen that person puts it in their village.

At the end of the day if I'm the only participant that's fine. It's just that we spend lots of time talking about great ideas as far as dynamic mechanics but don't take the next step and try to implement it. With implementations (more prototypes, really) we can identify what works and what doesn't (in the context of not crippling a game's performance or gameplay ideals) and have a common vocabulary that the people actually building a real RPG can use.

 

[Mayday]

If you guys need an advanced graphics engine, esenthel.com releases his tomorrow.

 

[JarlFrank]

That idea sounds pretty neat indeed. So we're going to think about systems and general city builds which could work well in an RPG, completely with a way to design NPC schedules and an internal economy?

I'm in, just let me think out some stuff and refine my ideas.

 

[John Yossarian]

I'll give a try too. Off to work now (yeah, on a sunday), later I'll post something if I think it's worthwhile.

 

[Section8]

Very cool idea, hope it inspires some tangible results.

It's not really what you're after, but back in the day Morrowind really got me thinking about procedural generation (funnily enough). For all the praise of the lavishly detailed world with table settings, bookshelves, baskets and what not - there's not a single aspect of a typical Morrowind household that couldn't be easily generated procedurally.

Setting a table has very distinct rules; A bookshelf is a finite space that would be easy to fill with a script, most rooms (even in the real world) have logical ways to be arranged; etc. I think procedural world creation would really be incredibly simple, even at Morrowind's level of detail with countless junk items. Once you have the basics, there are ways to give a bit of personality to each dwelling - what's on the plates or the bookshelf is arguably more defining than the furniture itself.

But anyway, I'll post some thoughts more in line with the actual goal tomorrow.

 

[Lemunde]

As someone who's working on a game with a lot of procedural generation I'll chime in on this. First of all let me give you an idea of what I'm working on. It's a 2D top-down space sim/shooter. What that means is the game basically goes from the player walking around inside planetary installations with a machine gun to commanding crewed capital ships in interstellar space and everything in between.

Of course cities and villages fall into that in between area. As I haven't even finished with the graphics engine or collision mechanism this will be mostly brainstorming but I still have a good idea of what I'm shooting for.

First I'll start with the individual buildings. The exterior of each building is a single bitmap drawn on a layer above the player and NPCs. Think something on the lines of Starcraft except instead of an isometric view it's a purely top down view. Ofcourse there's varying bitmaps for each building type; two or three bar types, several house types, different shops, hotels, corporate buildings, industrial installations, etc..

Each building interior will have a similar amount of presets to choose from. That means I'll have to go in and design by hand a whole lot of presets. I could do this procedurally and I have had some success with that but in the end it just lacks the personal touch a building should have. Besides, given the size and complexity of each building it shouldn't be that much work. It will probably take about as much time as it would doing it in one of those RPG maker programs.

I can extend the randomness in those presets by allowing variations in furniture placements and orientation. That's something I'll have to play around with and there's no telling if I'll be able to get it to work right. One thing that might make things more difficult is when I start adding more floors to different homes but the problems with that are a bit technical and I won't go into it. The last thing I'll do is assign one to three NPCs to that building.

Next I'll move on to the building placement. My engine is designed so that I can rotate objects easily but to keep things from getting too complicated I'll only allow for 90 degree increments. First I'll determine the size of the colony(using the word "village" in a futuristic game just sounds wrong). I may have to make presets for these as well as each size will determine how many big and small buildings there can be. One thing I might try is blocking off a part of the area to allow for things like merging with the terrain, giving the colony a sort of "L" shape.

I'll start with a rectangular area representing the total space the colony will take up and begin placing my large buildings within that area. I'll do a simple check to make sure buildings don't overlap and they're not too close to eachother as I'll want to leave space for the player and NPCs and land vehicles to move through. I'll continue placing them randomly until I either reach the total large buildings possible limit or I go through too many iterations(or tries for the non-programmers here). I'll then do the same thing for the medium and small buildings.

For the medium and small buildings I'll take it a step further and create clusters of buildings before I place them individually. So I may have a 2x6 cluster of small buildings or a medium building with 2 small buildings next to it. Of course I'll have to rotate these so that the doors face outwards and that may be a bit complicated but if I work with presets of clusters it shouldn't be too difficult. The end result SHOULD look like a town with blocks divided by streets.

The last thing I might do is build a wall around the colony which shouldn't be too difficult. There are various techniques I might try to make it look good but I think you get the general idea.

This is what I'm shooting for:

 

[Goliath]

Sounds interesting, but I think you underestimate the work required. Even a "simple" self-contained village requires a lot of non-trivial code, the AI especially. Too make the NPCs act in a sane manner, actually doing jobs, fulfilling needs, finding their way around the village etc. That is not as simple as it sounds.

I will probably try it, because I was looking for something to write in that new programming language I am learning right now anyway, but do not expect results.

 

[BigWeather]

That idea sounds pretty neat indeed. So we're going to think about systems and general city builds which could work well in an RPG, completely with a way to design NPC schedules and an internal economy?

I'm in, just let me think out some stuff and refine my ideas.

Yep, that's more in line with what I was thinking. Rather than designing specific settings instead look at designing and implementing the mechanics that can bring any setting (at least at the village / small community level) alive.

Personally I'm interested in attacking a simple economy (at least a input / output dependency graph -- not so much price fluxuations based on supply and demand and what-not), NPC schedules, and NPC perception of PCs.

Sounds interesting, but I think you underestimate the work required. Even a "simple" self-contained village requires a lot of non-trivial code, the AI especially. Too make the NPCs act in a sane manner, actually doing jobs, fulfilling needs, finding their way around the village etc. That is not as simple as it sounds.

Oh, I know it's a TON of work. And in some ways the key will be in what isn't implemented more than in what is. It'll be easy to fall into the "I've got to have everything simulated correctly" trap and ignore the "but it's still a game and it only has to be good enough to get buy-in from the player" caveat. To me Ultima V with its very simple NPC schedule (three destinations with fixed time to transition between them) and only the suggestion of jobs and a night / day cycle still manages to captivate.

I'll fail at most of what I try, but if I find a nugget or two that spurs further discussion or someone else runs off with and refines then it's a win in my book.




Section8 and Lemunde -- I am most definitely interested in procedural generation. I've taken a stab at the world-level generating continents and based on latitude and elevation applying biomes. I've also taken a stab at dungeon generation for some dabbling in a Rogue-like I was looking at. Also was fascinated with the idea of "blowing up" the tiles in Ultima V -- meaning that I wanted to not have a separate world and town scale, but rather blow each world tile (like a single forest) into a 32x32 tile section (32x32 being the town size, iirc) in a believable continuous terrain. I love problems like those. But yeah, as Section8 mentioned, I wanted to remove procedural generation from this first Let's build but rather focus on the dynamics once play has begun. It's OK to statically place all of the initial state for the purposes of this Let's build, but if you want to do procedural that's cool too. =)

 

[BigWeather]

Prepare to be underwhelmed but, in the interest of getting this started, my first drop is ready.

It can be found at http://www.bigweathergames.com. It is a site I just started for this so go easy on me please. I think I got the executable and all dependencies uploaded or linked from the post, if not let me know.

At the very least you can read about what idea I am messing around with to start my village.

Many, many things I know can be done better but this was just the very first implementation of some of the ideas. I need to work on the input handling, the UI is atrocious, and the tiles, while cute, don't fit long-term with what I want. You'll see. =)

I'll try and upload some pictures to the post for those that don't wish to download a .zip and run the executable. By the way, is there a better way I should be delivering it?

 

[cardtrick]

That is pretty damn cool, man. I already had .Net, and the XNA framework took about 30 seconds to download, so it only took me a couple minutes to get the village up and running. I played around a bit and read your blog post. At this point, I really can't think of anything constructive to say, but I think you've got a great idea here with a lot of potential for interesting gameplay once things get more dynamic. If I think of something thought provoking, I'll post again, but in the meantime I'm looking forward to seeing more from you.

 

[Section8]

Very cool concept, BigWeather. I'm getting Guess Who?/Carmen San Diego vibes where you're essentially putting together an "identikit" of sorts through a process of elimination.

My biggest suggestion would be to treat filters as an array of size n, where n is the number of characteristics - that way, you don't simply have a one dimensional slider for how accurate an eyewitness can be. The way it stands, there's no reason to consider more than one witness - the one with the highest filter value. I'd rather see something like:

NPC 0 spots a thief walking through the red light district, and the most prominent features she notices is that the thief is male, and of diminutive stature.

NPC 1 spots a thief from behind as they dash under a streetlight, and notices that they're of indeterminate gender, but diminutive and wearing a red cape.

Are they one and the same? Maybe that's a level of complexity you don't necessarily want to get into, and even your first drop is something considerably more complex than the standard fare. And maybe the use of colour and coloured lighting is a fairly impractical example...

But if you accounted for facing, rate of movement and so forth, you could get some simpler, more practical results. A character seen from behind while wearing a cape might have their body shape concealed, but long hair would be quite prominent. A character lit from behind would have a very prominent silhouette, while one lit from in front would likely have skin tone or gross facial features taking precedence. A character in profile might have a prominent nose, and so on.

It's considerably more complex again, and arguably not entirely worthwhile, but I like the idea of multiple eye-witness reports.

 

[JarlFrank]

That idea sounds pretty neat indeed. So we're going to think about systems and general city builds which could work well in an RPG, completely with a way to design NPC schedules and an internal economy?

I'm in, just let me think out some stuff and refine my ideas.

Yep, that's more in line with what I was thinking. Rather than designing specific settings instead look at designing and implementing the mechanics that can bring any setting (at least at the village / small community level) alive.

Personally I'm interested in attacking a simple economy (at least a input / output dependency graph -- not so much price fluxuations based on supply and demand and what-not), NPC schedules, and NPC perception of PCs.

Okay, then I got plenty of ideas ready. I'm too lazy to download all the stuff I need to test out your little village prototype, but I guess you haven't implemented too much yet anyways. The stuff I'm proposing might be a bit hard to implement, too, but it's just ideas anyways.

So, let's get on to the economy of the city/town. If it's supposed to be self-supplying, it needs several things. First, several obligatory buildings, like a granary for storing the food. Maybe a smokehouse to conserve meat and fish. Then there need to be several NPCs who take up certain jobs. We need those who fetch the food [peasants, hunters, fishermen] and those who process it [bakers, butchers]. All that can be done by scripting, I guess. A stable self-sustaining economy shouldn't be too hard to build up that way.

Now to NPC schedules. Something I've had in mind for quite some time now, might as well post the whole load of shit here. I was pretty amazed of scripted schedules like in U7 or Gothic, as they tend to make the whole town feel a lot more real, but, well... it's all scripted, and lacks variety. Oblivion's Radiant AI seemed like a good step forward until they crippled it into its current meaningless state. What I have in mind would be a combination of scripting and letting the AI choose schedules. Let's just call it "flexible scripted schedules", for that seems to describe my idea pretty well. Or not, depending on how you see it. Whatever.
Now, for the usual daily schedule we could use simple scripts. Like "Around the morning hours, stand up. Then go to work. Then go home and eat. Then go out and have fun. Then go to sleep". That would be a good framework, and we can change it however we like. Like adding "please your master" into the schedule of a female sex slave. Or "report to the sherriff" for guardsmen at the end of the day.
Now, that's still pretty basic, and, of course, pretty static. But details of this could be set either to variables or given to the AI for choosing. Let me explain what I mean. For example, let's give each NPC a variable for "hunger" and "thirst". When that variable is low, the NPC won't be hungry or thirsty at all. If it's high, he will go and seek out food. If it's too high, he desperately searches for something to eat so he won't starve to death. So we're making the "go home and eat" part of the NPC's schedule not dependent on the time of day anymore, but on the NPC's own "feelings", so to say, in this case hunger and thirst.
But what does the NPC eat? Well, we could add certain preferences to each NPC to make them more unique and give them more personality. How about adding beef and bread to this NPC's favourite foods, and mead to his favourite drinks? He then will prefer those foods and drinks to all others.
But how does he get the food? Now, for that we could let the AI decide. Give a few variables for the decision first, and then let him decide. First the NPC should check if there's any food left in his house. Is there? Well then, we have a meal for today already! Is there not? Let's see how much money the NPC has left. Enough money to buy food? Let's go to the tavern and eat there! Or maybe he'd rather decide to go out and hunt for deer... we could add some more variables to this, and then leave the decision open for the AI. Personality traits would help a lot with this, too.
With such a system we could make the schedules a lot more dynamic and flexible.

That's it for now, I still have some more ideas in my head, gonna post some more later.

 

[rpgcodexusername]

i dont have shader model 1.1 so im anticipating the screenies
EDIT- oh yeah i see them now very good

Jarlfrank - Im creating a game exactly like what bigweather is talking about and the issues you have described are exactly the ones ive had to deal with during the creation of the game.
If you are working at a restaurant you dont go home to eat.. etc.

 

[BigWeather]

Sorry for the long delay in replies -- I'm taking great pains to not mix this project and my day job so won't be able to stay on top of this thread like I do some others. =)

CardTrick, thanks for checking it out (and verifying that I didn't deploy it wrongly).

Section8, interesting point. I agree that there needs to be a way of ranking witness' observations so that the one that happens to have the highest filter value (by virtue of being closest, or whatnot) isn't always the "winner".

I'm hoping to tackle this in a couple of ways. There will be filters for other senses, so it's possible that while NPC 0 is positive he saw X person NPC 1 can be positive he heard Y person. Also a NPC's own attributes can affect things. A NPC with poor sight (thus having an additional filter applied) may be closer than a NPC with normal sight and thus have a lower aggregate filter value. I'd also like to consider weighting multiple witnesses seeing the same suspect vs. just one. Also I'd love to eventually get to the point where if a NPC sees a "bad" action and has a favorable opinion of the suspect he may instead suspect another, similar person. And so forth.

The first drop was very, very abstract, mainly to get a feel for the idea in those terms. The next step is to assign values to characteristics. While A could represent "fat" and B "skinny" that's pretty binary... A should rather represent "weight" and while it has the same prominence whether skinny or fat (as it is a rather common distinguishing feature) its value could range from 100 lbs to say 300 lbs for humans. So now the filter value (say 0.7) knocks down the prominence (what the observer sees is anything that after filtering has a prominence greater than or equal to one) but also "fuzzies" the value. Suppose that the suspect is 200 lbs and the normal weight error in worst conditions is +/- 30%. Applying the filter gives the observer an observed range of 200 lbs +/- 21% (with the actual guess randomly determined within that range).

When doing matching we'll not only do the current "did the observer see characteristic X and does this potential suspect have X" as well as "the potential suspect has characteristic Y and it should've been seen, was it?" to eliminate but could also use value as a factor.

As for values, I think there are three basic types. There is binary (what I've got now). You either have leprosy or you don't (oh, ok, there are degrees -- but humor me =)). There is continuous (weight, height, etc.). And there is "type". The third is trickiest. But I want wearing say a puffy shirt to give the "puffy shirt" characteristic to a person (one key goal is to make items impart characteristics on the character while worn / held / whatnot). Shirt is derived from "upper body clothing". Thus, further away you may not see a shirt but rather "he was wearing something on his upper body".

The example of the cloak is very interesting and something I've considered, but in a different context. Consider "puffy" above. It can be a prominent feature of the shirt, heck maybe a 10. But shirt itself may only be a prominence 5 on the grand scheme of things considering weight, height, etc. I'm undecided as to whether shirt has a filter on it that knocks down puffy, or if shirt just automatically limits any prominence to no greater than itself.

Another example would be something like a bag. A bag of jingle bells will filter sight completely but not do much to filter sound.

As for facing, movement, etc. -- a very interesting idea. I've thought of facing in terms of being needed for sight filters as opposed to not being needed for sound or smell. But I hadn't thought of it applying a filter to specific characteristics.

Another issue in addition to prominence is that of permanence. Earlier I had mentioned that perhaps we rank what each observer sees. I'd give an inverse weight to prominence. Meaning, if a person observes a person with a ruby-set ring that is far more specific than seeing just a fat person. Permanence is important too -- ones weight is hard to disguise, to rapidly change. You'd give that a bit more weight than someone wearing a puffy shirt. Meaning, while the puffy shirt is an important detail, you'd be more reluctant to condemn a man that happens to wear a puffy shirt as that is easily faked by the real perpetrator. Hope that is making sense.

That brings to mind another issue -- that of a changing characteristic state. If a NPC sees someone wearing a baker's hat kill someone on a foggy night he may finger the baker. But then he learns that the baker had his hat stolen prior to that night -- certainly changes things. This is clearly off in the future, and it has worrying concerns as you wouldn't want every NPC to have a mental image of every other NPC that they must compare against (since one NPC may know the hat was stolen, another may not) -- makes the head spin, and ultimately may never pay off gameplay-wise.

With all things game programming a lot of this is a question of how far to go. It's a game and as long as it is plausible, if not entirely correct, and serves gameplay but doesn't hiinder performance then we're golden.

Something I've been tossing around is is it worth having NPCs use this technique on each other? I'm concerned that performance could suffer, and really until NPCs get smart enough to decide to steal, or murder, or whatnot is there really a point? If only the PC is observed by NPCs then the problem above of NPCs having separate mental images becomes much, much more manageable.

That leads to another question. If the player character walks across the street, has breakfast, buys a newspaper, yawns, and goes back home must all of that be observed (note -- it could be recorded unfiltered as facts if you were building a game where you needed to be able to prove alibis, etc. and could filter later, after the fact, if the game demanded it)? That could get very slow. It'd hinder the amount of bloom we could display! =) I'm thinking its the "significant" actions that should be recorded -- the ones, positive and negative, most likely to have an impact on others.

Anyhow, I've rambled on long enough about that for now. I'll continue to evolve it and drop more code as soon as I can.

JarlFrank, some very interesting ideas. My thinking on NPC schedules is still rather early and I'm sure I'll often come back to your post as I'm forming them. I like the idea of defined tasks that require a material component(s) like a building, etc. and a person to fill the role.

As for scripting, I'm torn on how much of that I want to do -- I'm thinking a baker's role of "taking flour and producing bread" it could be divided into subtasks (and note, I'm no baker, so I'll probably get this waaay wrong!) like get flour, add water, knead dough, bake, let sit. Each has a location (get flour would be the mill, add water would be the sink, knead dough would be the counter, bake would be the oven, let sit would be the counter) along with a set of animations to do. If any input isn't available (the miller has not flour, the sink is busted, etc.) the baker will signal an issue. Initially there'll be no attempt to solve it, but eventually you could imagine them being smart enough to go to another miller, etc.

Initially I'm thinking the miller always happens to have just enough flour for any bakers, bakers produce just enough bread for everyone, etc. -- so there is no actual tracking of the sacks of lour, loaves of bread, etc. But that makes "going to another miller to get flour" kinda pointless because does he magically have enough for everyone still? So that'll have to change at some point.

Ultima V had the barest of schedules but it worked fine. I like what you've done with "wake up, go to work, eat, work some more, have fun, go to bed". Maybe "have fun" means "go to the pub" and at the pub the NPCs randomly choose what to do. Feasible and the illusion would be really neat. For your example "work" for the guard would have a subtask to report to the sherriff (whose location is at the jail). Unless I'm misunderstanding.

As for motives like "hunger" and "thirst" that'd come later. I'm a bit wary of it, to be honest, mainly for two reasons. Bad memories of The Sims being the first. The second is that I attempted to implement a virtual ecology based on Maslow's Hierarchy of Needs. Even at the lion drinks water, eats zebra, leaves zebra carcass, zebra eats grass, vulture eats zebra carcass level it had some implementation problems and some of the deadlocks / unpredictable states were... problematic. I'm worried about applying it to NPCs with far more complex needs.

While I think concpetually it'd be *really* neat to have people eat when they are hungry and drink when they are thirsty I wonder how much it'd bring in terms of gameplay (since it's certainly not zero-cost). And in reality we are creatures of habit as much as of needs. I'll eat breakfast some mornings not because I'm hungry but because it is morning. Removing that layer of the simulation could give performance gains and give the player a touchstone of familiarity.

That all said, I agree that the NPC should still, when told to eat, do a simple check to be sure there is food and if not, either seek it or flag it for the player to do (first step).

I'd encourage others to try JarlFrank's more detailed schedule / needs simulation. I'll be approaching it as well, but will probably start out a bit more "static" and add to it as benefits gameplay without killing performance, but it's possible I've missed some key ways to make it not crawl.

Slenkar, agreed on the not going home to eat if one works in a restaurant. I'm thinking something like "It's noon, where's some chow?" as opposed to JarlFrank's "I'm hungry, where's some chow?"

Longest post ever? Apologies if so. =/

 

[JarlFrank]

JarlFrank, some very interesting ideas. My thinking on NPC schedules is still rather early and I'm sure I'll often come back to your post as I'm forming them. I like the idea of defined tasks that require a material component(s) like a building, etc. and a person to fill the role.

That's a pretty long post you wrote there. Should take me quite some time to reply to it, heh.

As for scripting, I'm torn on how much of that I want to do -- I'm thinking a baker's role of "taking flour and producing bread" it could be divided into subtasks (and note, I'm no baker, so I'll probably get this waaay wrong!) like get flour, add water, knead dough, bake, let sit. Each has a location (get flour would be the mill, add water would be the sink, knead dough would be the counter, bake would be the oven, let sit would be the counter) along with a set of animations to do. If any input isn't available (the miller has not flour, the sink is busted, etc.) the baker will signal an issue. Initially there'll be no attempt to solve it, but eventually you could imagine them being smart enough to go to another miller, etc.

Initially I'm thinking the miller always happens to have just enough flour for any bakers, bakers produce just enough bread for everyone, etc. -- so there is no actual tracking of the sacks of lour, loaves of bread, etc. But that makes "going to another miller to get flour" kinda pointless because does he magically have enough for everyone still? So that'll have to change at some point.

Yeah, that's basically how I imagine it. You could add some supply/demand layer later, as in "There are three bakers. Each of them needs 3 bags of flour. There is only one miller. He can sell the flour for a high price because of the supply/demand level." That would be pretty interesting, but it's an additional layer of complexity that doesn't have to be implemented yet. In the beginning we could just let the base supplier have an unlimited amount of base resources [in that case the farmer who has unlimited wheat]. The miller then goes to the farmer to take wheat and make flour, while the baker then goes to the miller to take flour and make bread. That would be a good enough economy model for the beginning.

Ultima V had the barest of schedules but it worked fine. I like what you've done with "wake up, go to work, eat, work some more, have fun, go to bed". Maybe "have fun" means "go to the pub" and at the pub the NPCs randomly choose what to do. Feasible and the illusion would be really neat. For your example "work" for the guard would have a subtask to report to the sherriff (whose location is at the jail). Unless I'm misunderstanding.

Yep, that's how I imagined it. There would be a list of basic tasks, while some of those tasks might have special subtasks depending on the NPC. As you said, "work" for a guard has the subtask of reporting to the sherriff after his duty. The "have fun" task should be randomly chosen by the NPC, or by his mood, but NPC personality is something I'll come to later. Mostly it would involve going to the tavern and either gossipping with other NPCs, gambling, drinking, whatever they want. Or just go for a walk in the forest. There are many possibilites.

As for motives like "hunger" and "thirst" that'd come later. I'm a bit wary of it, to be honest, mainly for two reasons. Bad memories of The Sims being the first. The second is that I attempted to implement a virtual ecology based on Maslow's Hierarchy of Needs. Even at the lion drinks water, eats zebra, leaves zebra carcass, zebra eats grass, vulture eats zebra carcass level it had some implementation problems and some of the deadlocks / unpredictable states were... problematic. I'm worried about applying it to NPCs with far more complex needs.

While I think concpetually it'd be *really* neat to have people eat when they are hungry and drink when they are thirsty I wonder how much it'd bring in terms of gameplay (since it's certainly not zero-cost). And in reality we are creatures of habit as much as of needs. I'll eat breakfast some mornings not because I'm hungry but because it is morning. Removing that layer of the simulation could give performance gains and give the player a touchstone of familiarity.

That all said, I agree that the NPC should still, when told to eat, do a simple check to be sure there is food and if not, either seek it or flag it for the player to do (first step).

Yeah, hunger and thirst are something less important and could be a bit screwy to work with. The general "food-times" are also a problem there, would be weird if every NPC ate at a different time. So maybe every NPC could make a check for his hunger/thirst level around lunchtime and mealtime?

Longest post ever? Apologies if so. =/

Pretty long, but a good read anyways. I'll come up with some more ideas later, gotta do some work now anyways.

 

[JarlFrank]

So, is there still something going on with this project or has it died?