Radish Trial 3 Community Basics
Trial of the radishes - trial 3
The trial of the radishes is meant as a guided, self-learning tutorial without step-by-step instructions. Instead it focuses on exploratory learning by actively using the tools to solve increasingly challenging tasks.
>> Trail 3 focuses on communities basics <<.
This article provides some background information and various tips required or helpful to accomplish these objectives.
See forum post for more information about the trials.
Some background Information
In a nutshell: communities define schedules for npc actors. Those schedules can be timed, e.g. different actions in different locations at specific times.
The associated actor will automatically follow the schedule based on the current time and move to the next location and “perform” the action. The time is merely the trigger to change to the next action so the actual duration of the walking to the next point has to be accounted for.
A community is setup as a set of phases and every phase defines multiple actors (and some of their properties, e.g. appearance for this phase). A phase can represent some state of the community, e.g. a “normal” workday schedule. Another phase may be a “lazy-day” schedule. Only one phase for a community can be active at the same time.
Phases are also useful to change specific communities depending on world state changes. Without phases you can only setup static time based routines for communities but if something happens, e.g. based on a dialog choice of the player you can set a new community phase according to the choices. That is not possible with a timetable.
An action of a community actor is defined by selecting an actionpoint which defines possible sequences of some predefined animations and placing it in a specific location.
Radish Quest UI
Radish Quest UI has three main modes: layer mode for editing layers, community mode for working with communities and an additional navigation mesh mode for creating new navmeshes for NPCs (which works only for new hubs and will be covered in a later trial).
Communities cannot be edited or created in radui. They are read-only (indicated by the orange color of the community name and phase, see above) and it’s only possible to visualize and test encoded communities and their phases.
The community mode enables the spawning and despawning of encoded phases. This means you can preview communities in radui exactly like they would appear in the quest if this phase was triggered. However you have to make sure the layer containing the actionpoints referenced by the actors in this phase is also visible - or the community actors will not spawn at all or behave differently as they cannot find the actionpoint they are assigned to.
Actionpoints can be defined (placed and the action animation previewed) in the layer mode of radish quest ui.
Beware: adding or modifying actionpoints in radish quest ui does not make the encoded community use the updated actionpoints. You have to encode the updated layer actionpoints first!
While radish quest ui can be used to interactively preview phases of communities the questgraph editor is used to spawn specific phases of communities according to the quest flow.
Communities can only be defined manually directly in yml files. However the questeditor can parse the definitions and will offer only the defined communities and phases in appropriate community blocks.
Tips Questgraph Editor
- beware of concurrent editing of community yml files and unsaved changes in the editor!
Tips Radish Quest UI (radui)
- specific phases can be spawned or the community can be despawned
- with a minimized radui you can use the normal player to test the community interactions (e.g. non friendly behavior of monsters)
- actionspoints can be defined and previewed in the layermode. the preview uses a standard template, e.g. some woman template for all actionspoints usable for women actors
- layers have to be active for actionpoints to be usable for encoded communities. be aware of this when testing in radui
Tips Quest Definition / Community Definitions
- a community may contain multiple actors and different timed schedules can be setup for actors
- for actors a specific appearance or a set of appearances can be defined in the community definitions. the game will choose a random appearance if a set of appearance is defined
- appearance names can be found in the usedAppearances of the .w2ent files or previewed with Storyboard UI mod in the actor selection mode for that specific template interactively
- use last ap is a setting that defines how the actors are respawned when the player moves too far away (actors get despawned) and returns back: they will either spawn at the action point the actor was using last (true) or a default one (false)
- you can also setup only a subset of actors from the community for a phase so it enables the despawning of parts of the community
- in theory you can put different aspects of quest definitions (e.g. production and questgraph) into the same file. this is strongly discouraged. structure your project so it can scale for more complicated projects: put different types of definitions into different files and use multiple files for the same type, too. name the files accordingly, e.g. different communities in separate files
- look out for indentation errors in your yml definitions if the encoding fails
- there is a (simple) example community definition in the files section
- additional settings can be setup for communities but those will be covered in another trial