Jump to content
The Dark Mod Forums

Advanced RIT usage


Obsttorte

Recommended Posts

Hi,

 

I want to make a little bit more advanced usage of the RIT system in my next map.

I will explain a simple scenario so you can understand what I'm looking for.

 

Think of a room with three benches e.g.. Imagine a guard patroulling enter the room. He chooses one of the three benches, sit down for a while and than continues his patrol. Getting this to work isn't the problem, but what happens if a second guard enters the room while the first one is still sitting there.

 

If he is using the same pathways he would also randomly select on of the three seeting possibilities and sit down there. What can happen now is, that he chooses the same bench as his predecessor. This will most certainly end up with the guard sitting in the other one or just sitting somewhere near the bench in the air.

 

So a more proper behaviour would be that he is just choosing from one of the other benches that are not yet used.

The question is, how one could accomplish this.

 

My first guess would be to set the probability spawnarg on the chosen bench to zero. If the guard then stands up and goes away, the spawnarg could be deleted so the bench is free to use again.

 

I'm not a hundret percend sure how the waypoint system works, but as the AI are bound to a route via the target spawnarg, I could imagine that if they reach there target path_corner or whatever, they just get the target spawnarg of it as new target. So by reading out these one could manipulate the path as described above.

 

Would that work? And how could I find out when an AI is entering/leaving a room?

 

Thanks in advice and sorry for the long post ;) .

FM's: Builder Roads, Old Habits, Old Habits Rebuild

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Link to comment
Share on other sites

The simplest way to solve this is to create a RIT network for each AI, and make sure the path_corners where they sit are not on top of each other.

 

That way you can accommodate having up to 3 AI sitting side-by-side on the same bench.

 

I can see trying to do this with one network, and manipulating the target spawnargs depending on how many AI are in the room simultaneously, very quickly becoming a management nightmare.

Link to comment
Share on other sites

Doing an individual network for all the guards is not very feasable. One of the big advantages of RITs is the ability to drop multiple AI into the same network.

 

What you can do is to diminish the possibility of same chair selection.

 

Make the overall sit scenario low probability. Say 20% chance guy sits in this room. Then give multiple possibilities for the sitting: if you sit, sit on chair A, B, C or D. If you have sofas in the room one sofa could have multiple sitting positions. Reducing AI amount in the network helps too.

 

Also check if it even IS a problem. In my tests, the AI would often sit next to the other AI so that theyre not overlapping.

 

So don't worry about it. It is all about probabilities and while you cannot make it impossible, you can reduce to probabilities to a level only a very lucky player will see the silly scenario.

Clipper

-The mapper's best friend.

Link to comment
Share on other sites

Yes, you did and yes I did. I think I uploaded it somewhere, posted and then forgot about it. You can examine the Phrase Book mission for details how to set it up. Check the wiki first, though, for basics. All the guards in the manor use the same RIT network. Also the noble in the manor uses his very own RIT network.

Clipper

-The mapper's best friend.

Link to comment
Share on other sites

If you would have to make many path points for every room so that the chance that the ai will not choose the same path, then you can even just make its own path network for each ai. Because:

  • work amount is the same or even more
  • possibility for choosing the same path point for more than one ai still is not zero
  • players get confused if there are too many path points and cant predict the ai movement in some way which isnt good for gameplay

"Einen giftigen Trank aus Kräutern und Wurzeln für die närrischen Städter wollen wir brauen." - Text aus einem verlassenen Heidenlager

Link to comment
Share on other sites

 

If you would have to make many path points for every room so that the chance that the ai will not choose the same path, then you can even just make its own path network for each ai. Because:

  • work amount is the same or even more

Incorrect. You make a path_corner, path_sit (or anim) and a path_wait. You set them target each other appropriately. You clone these three path entity combos and place each of them on the target objects. Then you do what it says on the RIT wiki article (make the path wait that target all of the three path combos.) And then you make all the final path_waits on each three-combo thingies to point to the exit-path node. This takes 1 minute per ROOM (after you have decided which objects have the possibility of being interacted with and how).

 

But I grant you that that with non-optimal work flow it will take more time. But obviously mapper should learn the most efficient way to do things.

 

possibility for choosing the same path point for more than one ai still is not zero

True. But depending conditions the likeliness of player being around when something strange happens, is very low. But you are right, it is not zero. Do note that the probability for more serious bugs and problems is also non-zero.

 

players get confused if there are too many path points and cant predict the ai movement in some way which isnt good for gameplay

 

Or they may love it when the AI is fresh and does Random Interesting Things (RITs). I did not get negative feedback for phrase book. People loved it. PB used extensively the stuff you mention here. Go investigate the map. Once you know how the RITs work, you realize that setting up a basic network is really easy, efficient and most importantly... FUN.

 

Doing separate network for every AI is non-optimal, since you will get a zillion of nodes per room. Not feasable. Not clever. You can really easily make mistakes that make the networks spill over each other and so forth.

 

The RITs strength lies in the ability to use one network for multiple AI. That's the main idea. You are a lazy mapper and all you need to do is to prepare the basic network and you get the paths for multiple guards in a single strike. Plus the guards walking this network will be more interesting than your standard patrol guards.

 

Some important characters could have their RIT networks (just like in PB), but is not a good idea for every AI doing basic things.

Clipper

-The mapper's best friend.

Link to comment
Share on other sites

"In the North" uses multiple RIT networks, not a single large network. I found several cases where my AI were colliding with each other when using the same network, so I opted to copy/paste a working network, assign a new AI to it, then personalize it for that AI. Also, ItN employs a shift change at one point, where each shifting AI's network must be tinkered with real-time to get them to go do something different. In the case of multiple AI using the same network, that could easily become a major headache.

 

So I would say that if you have a large band of AI all responsible for doing roughly the same thing and covering the same ground, and you don't plan to change the overall pattern over the course of the game, and you accept an occasional collision here and there, a single RIT network will work well, and will reduce the amount of work you need to do to lay it out and test it.

 

But if you plan to incorporate a shift change, or add some individuality per AI--even for patrolling guards--then you should consider multiple RITs.

 

How you lay out your RITs, and the number you choose to use, depends on what behavior you want the player to see, and how much work you're willing to do (or have the time to do).

Link to comment
Share on other sites

How you lay out your RITs, and the number you choose to use, depends on what behavior you want the player to see, and how much work you're willing to do (or have the time to do).

 

Exactly! Like in the wiki article, there are several different RIT network topologies (guard, roaming, servant, insert-your-own, etc). The mapper has plenty of design decisions to do, based on what behavior they want.

Clipper

-The mapper's best friend.

Link to comment
Share on other sites

  • 1 year later...

Not that I have experience implementing a RIT network but just from what has been described above it seems simple and logical that for a path node branching to many choices should have some mechanism with an extra flag bit that basically says, "_occupied". So when a new AI comes to a decision tree and has to pick, for example, 1 of 4 paths, if 2 of the paths are flagged as "_occupied" then he'll have fewer decisions and won't set himself on a collision course with another AI whether sitting/standing/anim, etc.

 

If there were an "_occupied" flag for a path it could be set to 0,1,2.

 

0 -not occupied

1 -occupied

2 -ignore the occupied state (could also be the default, or a value of -1 depending on implementation difficulty)

 

Is there currently no state check like this in the path_wait?

 

(reading through the RIT wiki now)

Edited by Lux
Link to comment
Share on other sites

It is, but the setup that RJF suggested is a bit complicated, with targets adding and removing one another's targets. I do like the idea of a simple "occupied" flag that'd be applied to a path choice if you set a spawnarg. Not sure how easy it would be to implement though. I imagine it'd be easy enough to get the pathing code to check a flag when choosing a path, and to set it after making the choice, but when would you turn it off? Or to put it another way, how would the game know how many nodes a given flag covered? You wouldn't always want it to stretch as far as the next branching node.

 

Am I overcomplicating it? Perhaps it could just be the path sit or path anim or whatever that held the flag, not an entire branch of the newtwork. The when it comes to choosing a path, an AI could look ahead and not enter on any path that's blocked by an "occupied" path target. You'd no doubt end up with AI queueing behind certain branch points where all the paths are occupied. Hmm

Link to comment
Share on other sites

I guess I was confusing 2 things. A user setting and a computed value. On the user side they could set it to use the state check or not.

 

On the AI side if it were enabled by the mapper, the AI state machine would set the flag upon deciding on the path the AI takes. When the AI reached the next decision point, the previous/current path would be cleared and the next would get set.

 

So I should think there would only need to be 2 value fields instituted, one for a path id (unless one already exists) and one for the occupied flag. Then some mechanism to clear/alter it at the next decision check.

 

I don't know what dependencies there would be, if any, that would need to be addressed. It would seem from my outside perspective that the system could operate without any dependencies.

 

The only case I can think of that may cause conflicts would be when/if you wanted 2/more AI (for realism) to follow the same path. I suppose the occupied state clear could be set to some arbitrary distance after the initial decision which would give the AI physical space to maneuver, so they wouldn't get in the circle situation. That seems a bit complicated though.

 

If you wanted 2/more AI to do something together you could always use conventional methods.

Link to comment
Share on other sites

Join the conversation

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

Guest
Reply to this topic...

×   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.

  • Recent Status Updates

    • Ansome

      Finally got my PC back from the shop after my SSD got corrupted a week ago and damaged my motherboard. Scary stuff, but thank goodness it happened right after two months of FM development instead of wiping all my work before I could release it. New SSD, repaired Motherboard and BIOS, and we're ready to start working on my second FM with some added version control in the cloud just to be safe!
      · 1 reply
    • Petike the Taffer  »  DeTeEff

      I've updated the articles for your FMs and your author category at the wiki. Your newer nickname (DeTeEff) now comes first, and the one in parentheses is your older nickname (Fieldmedic). Just to avoid confusing people who played your FMs years ago and remember your older nickname. I've added a wiki article for your latest FM, Who Watches the Watcher?, as part of my current updating efforts. Unless I overlooked something, you have five different FMs so far.
      · 0 replies
    • Petike the Taffer

      I've finally managed to log in to The Dark Mod Wiki. I'm back in the saddle and before the holidays start in full, I'll be adding a few new FM articles and doing other updates. Written in Stone is already done.
      · 4 replies
    • nbohr1more

      TDM 15th Anniversary Contest is now active! Please declare your participation: https://forums.thedarkmod.com/index.php?/topic/22413-the-dark-mod-15th-anniversary-contest-entry-thread/
       
      · 0 replies
    • JackFarmer

      @TheUnbeholden
      You cannot receive PMs. Could you please be so kind and check your mailbox if it is full (or maybe you switched off the function)?
      · 1 reply
×
×
  • Create New...