IceBlink Engine and Toolset 2: Implementing moving props in your adventureIntroduction
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. Moving props themselves also react to HasCollision correctly and will nit step onto other moving or static props that have collision.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.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 jump from the players perspective. The more crowded an area is, the more jumps 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. 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, uding the inGameAreaName property of class area (you can define tis ingae areaname in the toolset, under area properties).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 upo to a ceratin 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 () around the central post location() 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 () 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).
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 - I think it's not fully implemented just yet, but once it's in the engine, too, it will make 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 used for signaling an area change of the prop. If the 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 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 day1 both mean day 1 actually. 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): 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. 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.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