IB2: Guide for setting up moving props

Any documentation, tutorials, tips and tricks, or examples on how to use the IB2 Toolset

IB2: Guide for setting up moving props

Postby youngneil1 » Thu Aug 25, 2016 5:47 am

IceBlink Engine and Toolset 2: Implementing moving props in your adventure

One of the many new built in functionalities of IceBlink Engine and Toolset 2 is to have props (i.e. graphical tokens that can represent NPC, creatures, objects...) that can change their location, moving around the map in alternating turns with party movement. This allows for lots of new gameplay and world immersion opportunities, ranging from NPC living a full blown daily schedule (e.g. rising early in the morning, working in the fields and then having a drink in their favourite tavern late night), to caravan traders and soldiers commuting on the roads between cities to creatures stalking in the woods and chasing the party across the map should the adventurers dare to get too close to the creatures.

All this can be setup directly in the toolset itself without any further scripting (scripting can provide additional functionalities, but a very, very comprehensive level of functionality - like all the examples above - works completely without scripting).

Getting started
You will want to start by opening the "Unwanted Guests" module in the toolset and then navigate to the props blueprints section in the toolset. Choose a mover blueprint and place an instance of this prop onto the adventure area map for testing. Select that creature instance on the area map and have a look at its properties. You will find a setup of different movers on the brinsby and the wm_try map of the "Unwanted Guests" demo module, too.

Logic events called directly from the prop
First thing to note - before we go into the movement details - is that props can carry with them their own mobile conversation ("conversationWhenOnPartySquar") and mobile encounter ("EncounterWhenOnPartySquare"). This is extremely helpful and replaces a large chunk of trigger functionality. Encounters and conversations just start when the party bumps into the prop (or the prop bumps into the party actually). Furthermore, it can be setup that the prop itself is removed when the attached encounter is won by the party, i.e. the prop (or the group of cretaures it represents) is slain ("DeletePropWhenThisEncounterIsWon").

Properties determining the state of a prop
Also, please note that props can be set to isActive (prop can be interacted with, e.g. cause encounter or conversation), isShown (turn prop invisible) and isMover (use one of the mover types explained below). Additionally, the HasCollision property defines whether the party can move through the prop or not (movers have their collision always set to false, so they can move through each other, see below). Moving props themselves also react to HasCollision correctly and will therefore will not move through or onto static props that have collision set to true. They will also never end their move on squares occupied by other moving props (despite all movers having HasCollision set to false).

Move speed
Furthermore, you can define two chances here for skipping the current movement (turnChanceToMove0Squares) or moving two squares in one movement turn (ChanceToMove2Squares). The later allows props chasing (see details below) the party to eventually catch the fleeing party. I would normally set ChanceToMove2Squares to 0 (unless an enemy hunting creature) and turnChanceToMove0Squares to 50. This way the party moves at double (average) speed of normal civilian NPC movers and can catch up with them easily.

Collision and pathfinding
Please note that all movers by default should have their collision turned to off. This allows them to move through each other and enhances their pathfinding greatly, i.e. it means less prop queues in crowded places and less props stuck without valid path. The engine makes sure that props do not end their moves in each others squares anyhow, granting double (or more) moves to hop over other mobile props in the way or making props temporarily wait until the path is free again. These double, tripple, etc. moves make a prop move very quickly at times from the player's perspective. The more crowded an area is, the more very swift moves you will see. In extreme cases a prop will move 5 or 6 squares in a swipe overtaking all the other props lined up before it. To compensate for this a little and generally to make it easier for players to purposefully catch up with props, it's a good practice to give props of "normal" speed a 50% chance to skip their move (see above already).

The different types of movers
All that being said, I suggest to have a look at the different types of movement that are available from the drop down menu ("MoverType"):

Upfront it's important to note that props of the types post, patrol and random can never leave the area map they are initially placed on. When the party leaves the current area, such props are frozen where they are and will continue their movement from the exact same spot once the party re-enters that map. On the other hand, time driven props (daily, weekly, monthly, yearly) will work across any number of area maps: they can leave or enter into the area map the party is currently on. And when the party enters a new area, the location of time driven props will be set to the most fitting waypoint on this area map (see details below). When time driven props (see below) leave the current area, they will vanish. To distinguish this from a bug, the engine displays a floaty text with the name of the target area, using the inGameAreaName property of class area (you can define this ingame areaname in the toolset, under area properties).

Furthermore, props on neighbouring maps are shown, but they will not move unless the party enters the neighbouring map (to do: behaviour of time driven props in this scenario).

Post: The prop is stationary at the post and will not move in default mode. There's a mode available for all mover types here that is called "isChaser" though (see below for details). When this kicks in e.g. our prop of moverType here will move up to to a certain distance around the post ("PostLocationX","PostLocationY") specified here (and then give up chasing, returning to the post). Could be used e.g. for a stationary guardman.

Random: A random mover will randomly pick its next move target within a distance ("randomMoverRadius") around the central post location("PostLocationX","PostLocationY") and will then move towards that target. Once having reached the current target location, the random moving prop will pick the next random target location within the radius and so forth. Also, after 20 turns a random will switch its target in any event, so they wont get stuck permanently by unluckily picked targets. Random movers are extremely quickly setup: choose the post location and the allowed radius in which the random mover has to stay and you are done. Locally roaming monsters and ambience creatures can be dropped on the map very effectively this way. Like all other mover types, random movers can make use of the isChaser property (see below).

Patrol: The first mover type that makes use of the waypoints ("wayPointList") of a prop. A patrol mover starts at the first in list waypoint (index 0 in the waypoint list) and from there on moves from waypoint to waypoint in order of the waypoint list. After having reached the end of the list, the patrol mover starts with first waypoint again. A never ending circle.
The waypoints themselves are found in prop properties window, too. You can add and delete them from the props waypointlist. Each waypoint has an x and y location. When you move your mouse pointer over the area in the toolset's area main window you can see the location of each square as x,y coordinates. This way you can easily plan your props patrol route. Additionally waypoints have departureTime and areaName properties - both are only relevant for time driven props (daily, weekly, monthly, yearly), so you can ignore them patrol movers.
Furthermore, waypoints allow to set barkstrings for them (BarkStringsAtWayPoint, BarkStringsOnTheWayToNextWaypoints), short floating texts that will appear with a chance of 10% (checked for every barkstring entry, but a max. of one barkstring is shown per turn) above the prop on the main area map itself. An author can set two different lists of barkstrings for each waypoint, one at the waypoint itself (BarkStringsAtWayPoint) and one for travelling to the next waypoint (BarkStringsOnTheWayToNextWaypoints). Then, there's also a wait duration property: it makes props of mover type "patrol" wait for x rounds on the waypoint before moving on.

Daily: These movers will follow the cycle of their waypoints, too, but they will also adhere to the departureTime property of each waypoint. A reached waypoint will not be left until departure time of that waypoint has come. Also, once the departure time of the waypoint that the prop is headed to has come (even prior to stepping on that waypoint), the prop will change its movement target to the next in line waypoint. This way a long delayed prop might even skip a few waypoints, catching up with its time schedule.

The second important property for determining the course of a time driven prop is the areaName property of a waypoint. It shows on which area the waypoint it belongs to is located. This is used for signaling an area change of the prop. If the next in line waypoint shows a different area name than the one the prop is currently on and the departure time of the current waypoint has come, the prop is automatically transitioned to the new area, right on top of the next in line waypoint. This means that moving props across a number of different maps is as simple as typing different names in the areaName properties of their waypoints.

The departure time expects the following format in its property field: days:hours:minutes. So the three time unit categories are separated by ":". For days any entry between zero and 336 will be accepted (the engine assumes a 12 month, 28 days a month, grouped into four weeks of seven days each, time format). Day 0 and day 1 both mean day 1 actually (ie using 0 or1 in the first place is the same). A daily mover requires the author to enter either 0 or 1 here. Hours range from 0 to 23 and minutes from 0 to 59. Some examples:
0:7:1 means on day one, seven hours in the morning and one minute
1:16:48 means on day one, 16 hours in the afternoon and 48 minutes
For our daily mover here only use 1 or 0 as entry for day. Weekly movers accept 0 to 7 for days, monthly movers will take 0 to 28 and yearly ones 0 to 336.

The type (daily, weekly, monthly, yearly) determines when the mover will start its movement pattern anew, beginning on waypoint 0 in its waypoint list again. Please note that the engine will automatically assign departure time values to first (index 0) and last waypoint (highest index number), overriding anything you entered here: the first waypoint has a departure time that is near the beginning of the interval, i.e. near 0:0:0, the last will have departure time near the end of the interval, i.e. in case of a daily mover near 0:23:59. I use "near" because the exact value depends on the time one step on the current area takes (timePerSquare). Also, please note right now every waypoint of a time driven mover (including first and last) waypoint needs a valid entry in the time format shown above for now. I will eventually add some convenience and error catch functionality here. All this considered I think it's a good practice if you grant the first and last waypoint time values near the beginning and end of the relevant interval (daily: 1:0:1 and 1:23:59, weekly: 1:0:1 and 7:23:59, monthly: 1:0:1 and 28:23:59, yearly: 1:0:1 and 336:23:59).

Also please make departure times increase all the time from waypoint to waypoint and never exceed the length of the interval. I think you will do so intuitively, but I mention it just in case.

Weekly, Monthly and Yearly: These work just like daily above except that their respective intervals before the reset are longer. These can be used for e.g. merchant caravans who need weeks or months to travel from city to city. A market might take place once a week or some bizarre ritual in the woods nearby the remote village is conducted every full moon ;) ...

All moving props (post, random, patrol, time driven) can be set to be chasers (isChaser). A chaser will try to get on the same square that the party is on (temporarily overriding his normal movement plans) but only once it has detected the party. Party detection happens when the party enters the "chaserDetectRangeRadius" around the chaser prop. The chaser prop will then try to catch the party, but only until it reaches its "chaserChaseDuration". It will also stop chasing when the party manages to get a certain distance between itself and the chaser. This distance is called "chaserGiveUpChasingRangeRadius". A chaser that manages to catch the party will trigger its "conversationWhenOnPartySquare" or "encounterWhenOnPartySquare" (should those be setup). When giving up chasing on the other hand, the prop will resume its normal routine again (walk to next waypoint).

Chasers will not cross map borders though, so best design chase situations more towards the middle of a map.
User avatar
Posts: 3605
Joined: Sat Dec 08, 2012 7:51 am

Return to Users Guide and Tutorials

Who is online

Users browsing this forum: No registered users and 1 guest