Jump to content

Next.. Ambient NPC population

Marleys Ghost

1,902 views

Working on two principles K.I.S.S. (keep it simple stupid!) and more for less.

 

I spent a lot of time researching (read playing) certain games that have what I call an ambient NPC population. This is specifically those NPC's that reside in the background and generally have no real or very limited interaction with the player. Two such areas of research <coff> included Assassins Creed and Fable 2. Although both of these games have a far more complex general NPC population than what I am setting out to create, but the "research" was most enjoyable.

 

First Step:

 

Machine Intelligence "Kinda Almost":

 

Machine Intelligence "Kinda Almost", simply gives an illusion that there is intelligence at work but there is not, sort of like, the lights are on but no ones home. There are several subsets to this group but the obvious one is simple animation. Also this can include proximity reaction behaviour, a posh and complicated way of saying when the player is near, stop what you are doing, and do this instead. But that's as far as interaction goes for those NPC's in this group. This simple ambient NPC type could also use lua scripts, loaded with the level and be left to attend to themselves.

 

For example, just two chaps having a chat:

 

blogentry-12-053597000 1283986535_thumb.jpg

 

Having a chat is basically all they do, its simple per character animation's controlled by lua scripts. The purple block volume is the walkable area that would be utilised by more "advanced" ambient NPC's, typically those that move about, particularly those that would use Pre-Loaded and Pre Calculated path routes for this particular level. The purple block volumes are simply required by the application I wrote to generate the route node data for the pathfinding tools I created and have demonstrated here. Not that this is a level just something thrown together for testing but I think I should unarchive some of my GMF format models and put together a small town/Village for testing this, rather than another simple "BlocksVille".

 

There are obvious limitations to consider with this approach to the first tier of the Ambient NPC population for a "busy" town/village. The NPC's need animation's, most come with maybe 15 animation's (if you're lucky). My intention is to surmount this by adding animation's to them, primarily Mo-Caps. This will require a little work but will be the bedrock for the construction of this "tier". There are some very good applications on the market for achieving this. For me I prefer Fragmotion, there is also a free alternative that I also use on occasion called Pacemaker. But don't be fooled though, none of these applications will do it all "for you", you will need to skin the mesh to the correct rig for the plethora of free to use Mo-Caps, or indeed ones that can be purchased. It will all depend on budget and or requirement.

 

This is still only a very basic outline for this "packing" stage, it will still require a lot of work but my goal is to get the impact of it at runtime to an almost negligible effect even when including proximity reaction behaviour.



8 Comments


Recommended Comments

That's a really interesting read MG. A subject that I've only just considered, ambient mobs or mobiles. Reading what you wrote sparked a few ideas on zones and assigning such spawned entities to different movement behaviours within them.

Share this comment


Link to comment
Guest Red Ocktober

Posted

yes... this is something that has, for the most part, been totally ignored by many, yet something that a lot of games will need...

 

good stuff MG... keep it coming...

 

 

--Mike

Share this comment


Link to comment

I wouldn't go so far as to say ignored. Getting to the point where you need these kinds of objects is a pretty big step.

 

My ideal way of working with NPCs would be to drag some form of "Crowd" box into the editor and adding characters, specify number, variation, movement pattern in the box. Not just people but animals too. Chicken runs, birds, cows. That would be a pretty high-level operation, but wouldn't it be a fantastic way of populating such scenes?

 

That would be awesome. Even those people that use Leadwerks for architectural visualisation, putting people in the scene that move about would be pretty handy.

Share this comment


Link to comment
Guest Red Ocktober

Posted

I wouldn't go so far as to say ignored.
i actually would... the reason being is that this is the first thread that i've seen here that even looked at the aspect of adding this sorta realism to a scene from this perspective...

 

i mean, i easily might've missed one... so, if you could point me to it, i'd be interested in seeing what approach was proposed there, but most of the game dev i've seen here so far, that involve characters, centers mainly on the players character, and the antagonist(s) or bad guy(s) character... nowhere have i've even seen mentioned the idea of having incidental characters that appear (or that actualy are interactive) as an added element of realism for a scene...

 

Getting to the point where you need these kinds of objects is a pretty big step.
i might not agree with this assertion either... depending on the type game you're crafting, incidental npcs might start appearing at any point past the initial development cycle... just as you'd consider adding lighting, structures, or any other scenery elements that contribute to the ambience of the surroundings...

 

 

 

--Mike

Share this comment


Link to comment

Good stuff, MG. I can't wait to check out a video with the progress. Screen-shots for AI doesn't do any justice for it.

 

 

Sorry Paul would have got back to you sooner but as you know I am "spring cleaning" the Dev system lol

 

 

Yes a video is always preferable with AI but this is still in its early stages and so far all there would be is the two NPCs running through thier respective animations. But I will certainly use videos in the later dev stages. :D

Share this comment


Link to comment

That's a really interesting read MG. A subject that I've only just considered, ambient mobs or mobiles. Reading what you wrote sparked a few ideas on zones and assigning such spawned entities to different movement behaviours within them.

 

 

Thanks Flex, I always hope some (or any) of my musings help others, I feel this to be an important part to game dev. thus worthy of thinking about. A lot of the ambient life I see in games simply is "smoke and mirrors" .. had the Great Bard been an Indie developer I think he'd have said "All the game world's a stage, And all the NPC men and women merely players. They have their exits and their entrances..." And typically thats what the tier idea is about .. not every NPC will require complex or even medium AI coded ability nor even A* .. I am simply trying to work as though its a film set ... Extras .. walk on parts .. co-stars and stars ... that sort of thing. Still needs better formulation though.

Share this comment


Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Add a comment...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Blog Entries

    • By Josh in Josh's Dev Blog 0
      A new update is available for beta testers.
      Terrain
      The terrain building API is now available and you can begin working with it, This allows you to construct and modify terrains in pure code. Terrain supports up to 256 materials, each with its own albedo, normal, and displacement maps. Collision and raycasting are currently not supported.
      Fast C++ Builds
      Precompiled headers have been integrated into the example project. The Debug build will compile in about 20 seconds the first run, and compile in just 2-3 seconds thereafter. An example class is included which shows how to add files to your game project for optimum compile times. Even if you edit one of your header files, your game will still compile in just a few seconds in debug mode! Integrating precompiled headers into the engine actually brought the size of the static libraries down significantly, so the download is only about 350 MB now.
      Enums Everywhere
      Integer arguments have been replaced with enum values for window styles, entity bounds, and load flags. This is nice because the C++ compiler has some error checking so you don't do something like this:
      LoadTexture("grass.dds", WINDOW_FULLSCREEN); Operators have been added to allow combining enum values as bitwise flags.
      A new LOAD_DUMP_INFO LoadFlags value has been added which will print out information about loaded files (I need this to debug the GLTF loader!).
      Early Spring Cleaning
      Almost all the pre-processor macros have been removed from the Visual Studio project, with just a couple ones left. Overall the headers and project structure have been massively cleaned up.
    • By Josh in Josh's Dev Blog 6
      An often-requested feature for terrain building commands in Leadwerks 5 is being implemented. Here is my script to create a terrain. This creates a 256 x 256 terrain with one terrain point every meter, and a maximum height of +/- 50 meters:
      --Create terrain local terrain = CreateTerrain(world,256,256) terrain:SetScale(256,100,256) Here is what it looks like:

      A single material layer is then added to the terrain.
      --Add a material layer local mtl = LoadMaterial("Materials/Dirt/dirt01.mat") local layerID = terrain:AddLayer(mtl) We don't have to do anything else to make the material appear because by default the entire terrain is set to use the first layer, if a material is available there:

      Next we will raise a few terrain points.
      --Modify terrain height for x=-5,5 do for y=-5,5 do h = (1 - (math.sqrt(x*x + y*y)) / 5) * 20 terrain:SetElevation(127 + x, 127 + y, h) end end And then we will update the normals for that whole section, all at once. Notice that we specify a larger grid for the normals update, because the terrain points next to the ones we modified will have their normals affected by the change in height of the neighboring pixel.
      --Update normals of modified and neighboring points terrain:UpdateNormals(127 - 6, 127 - 6, 13, 13) Now we have a small hill.

      Next let's add another layer and apply it to terrain points that are on the side of the hill we just created:
      --Add another layer mtl = LoadMaterial("Materials/Rough-rockface1.json") rockLayerID = terrain:AddLayer(mtl) --Apply layer to sides of hill for x=-5,5 do for y=-5,5 do slope = terrain:GetSlope(127 + x, 127 + y) alpha = math.min(slope / 15, 1.0) terrain:SetMaterial(rockLayerID, 127 + x, 127 + y, alpha) end end We could improve the appearance by giving it a more gradual change in the rock layer alpha, but it's okay for now.

      This gives you an idea of the basic terrain building API in Leadwerks 5, and it will serve as the foundation for more advanced terrain features. This will be included in the next beta.
    • By Josh in Josh's Dev Blog 1
      Here are some things I did in the last couple days to fix a computer that was basically unusable.
      It seems that Superfetch was rebranded to "SysMain" in an update and automatically re-enabled. If your computer is grinding away either the CPU or disk usage while doing nothing, this is the culprit. Disable it in Windows services.
      The XBox games bar is suspect. I recommend disabling it now that FRAPS supports Vulkan.
      Some features in Visual Studio are making it unusably slow.
      In Project settings > Link > Debugging, set "Generate Debug Info" to "DEBUG:FASTLINK" (in the debug build only) for faster linking.
      Disable these two settings in the general program Options:
      Enable Diagnostic Tools while debugging Show elapsed time PerfTip while debugging
×
×
  • Create New...