# Assistant conversation TPVAXM - Canonical URL: - Resource IRI: - Type: assistant conversation - Mode: quick ## Transcript ### 1. User tell me about harel's BP quadrotor controller ### 2. Assistant tool calls #### Tool call: `search_text` ```json { "limit": 10, "query": "Harel BP quadrotor controller behavioral programming" } ``` #### Tool call: `list_documents` ```json {} ``` ### 3. Tool result: search_text Exact matches 1. Source: Distributing Scenario-Based Models: A Replicate-and-Project Approach (#D4VB7S), Assaf Marron, Daniel Gritzner, David Harel, Guy Katz, Joel Greenyer, Shlomi Steinberg, p. 2 Context: #D8TLPF Distributing Scenario-Based Models: A Replicate-and-Project Approach #WG2KDF 2 BACKGROUND: SCENARIO-BASED MODELING Matching excerpt #ANRT82: For the remainder of the paper, we focus on a particularly simple variant of scenario-based modeling, called behavioral programming (BP) (Harel et al., 2012b). Despite its simplicity, BP has been successfully used in developing medium scale projects (Harel and Katz, 2014; Harel et al., 2016), and is also known to be particularly amenable to automatic analysis tools (Harel et al., 2015c). These properties render BP a good candidate for demonstrating our approach. The rest of this section is dedicated to demonstrating and formally defining BP. 2. Source: Towards Behavioral Programming in Distributed Architectures (#M5788P), Amir Kantor, Assaf Marron, David Harel, Gera Weiss, Guy Katz, Guy Wiener, p. 27 Context: #GVFU8Q Towards Behavioral Programming in Distributed Architectures1 #QTR76K 3. Application Designs for Dealing with Asynchrony and Different Time Scales #Z5FCGK 3.5. Example 2: Coordinating behaviors with different time scales Matching excerpt #BC76P3: The quadrotor application also shows how behavioral programming can be used in developing hybrid control, i.e., a combination of discrete logic and actuation with the sensing of continuous system variables [36]. In [26] we discuss the application of BP to hybrid control, by using fuzzy logic to translate continuous information into discrete categories that can be refereed to in naturally-programmed scenarios. 3. Source: Towards Behavioral Programming in Distributed Architectures (#M5788P), Amir Kantor, Assaf Marron, David Harel, Gera Weiss, Guy Katz, Guy Wiener, p. 8 Context: #GVFU8Q Towards Behavioral Programming in Distributed Architectures1 #UQH7TV 2. Behavioral Programming in Erlang #GPE58X 2.9. Formal Definitions Matching excerpt #LWS2QC: For completeness of the exposition of BP we include here the formal definition of behavioral programming as transition systems. 4. Source: Towards Behavioral Programming in Distributed Architectures (#M5788P), Amir Kantor, Assaf Marron, David Harel, Gera Weiss, Guy Katz, Guy Wiener, p. 41 Context: #GVFU8Q Towards Behavioral Programming in Distributed Architectures1 #LCVWTC 6. Positioning BP relative to Mainstream Actor and Agent Programming Matching excerpt #ASLM6V: In [32], Alan Kay highlights the naturalness of programming with rules. Behavioral programming is often reminiscent of rule-based systems but it extends the concept by allowing the ability to easily monitor, and react to, entire scenarios without requiring complex state management in the rules. Furthermore, in BP, event-blocking facilitates expressiveness and behavioral composition. 5. Source: Towards Behavioral Programming in Distributed Architectures (#M5788P), Amir Kantor, Assaf Marron, David Harel, Gera Weiss, Guy Katz, Guy Wiener, p. 24 Context: #GVFU8Q Towards Behavioral Programming in Distributed Architectures1 #QTR76K 3. Application Designs for Dealing with Asynchrony and Different Time Scales #Z5FCGK 3.5. Example 2: Coordinating behaviors with different time scales Matching excerpt #KGLCRZ: Subsequently, we have begun to implement a behavioral programming environment written in C that can run directly on a quadrotor, and have shown that the design and the b-threads shown above indeed can stabilize a UAV. In fact, initial versions of this are already flying in our lab. 6. Source: Towards Behavioral Programming in Distributed Architectures (#M5788P), Amir Kantor, Assaf Marron, David Harel, Gera Weiss, Guy Katz, Guy Wiener, p. 1 Context: #GVFU8Q Towards Behavioral Programming in Distributed Architectures1 #5SGDUB 1. Introduction Matching excerpt #RZT5ZT: Behavioral Programming (BP), also termed scenario-based programming , is an approach for the incremental development of reactive systems based on decentralized control and interwoven modules of behavior. A basic tenet of BP is the constant cross-consultation among parallel processes, prior to each system action. In this paper we address the challenge of achieving the implied synchronization in physically distributed environments, avoiding performance degradations that could put into question the viability of BP as a system development approach. Specifically, we show that it is possible to achieve correct and efficient behavioral execution with parallel distributed scenarios that run with hard-to-predict network delays, or are clocked at very different time scales, or wait for external events that cannot be synchronized. 7. Source: Towards Behavioral Programming in Distributed Architectures (#M5788P), Amir Kantor, Assaf Marron, David Harel, Gera Weiss, Guy Katz, Guy Wiener, p. 0 Context: #GVFU8Q Towards Behavioral Programming in Distributed Architectures1 #79EMN3 Abstract Matching excerpt #YCYR5C: As part of expanding the implementation and use of the behavioral programming (BP) approach in a variety of languages and configurations, we tackle some of the challenges associated with applying the approach in a truly distributed, decentralized manner, where different modules run on separate machines. BP supports the development of reactive applications from modules that are aligned with the desired and undesired scenarios of system behaviors as described, say, in a requirements document, in an enhancement request, or a field problem report. A key advantage of this approach is that it facilitates incremental development where loosely coupled modules are added as requirements are introduced, and meaningful prototype execution can be carried out from early stages of development. In BP, each behavioral module (called a behavior thread) takes care of a separate facet of the requirements, thus control is conceptually decentralized. However, as the underlying principles of BP call for constant synchronization of, and “consultation” with, all behavior threads, efficient implementation in a physically distributed environment is a significant challenge on the road to broader acceptance of BP as a viable new way to develop systems. We begin by describing an implementation of BP in Erlang, where the coordination protocol is implemented via message passing. We demonstrate through examples how developing distributed systems in Erlang can benefit from BP advantages of incremental development and alignment of the code modules with the requirements. Next, we propose general BP design patterns (not limited to Erlang) for using BP in distributed applications, showing how to design applications using BP without forcing full synchronization among all threads at each step of the execution. This allows modules to run at different time scales and to wait for external input without stalling the entire system. Finally, we propose ways to alter the execution mechanism of BP so that execution can progress without necessarily waiting for the synchronization of all the threads. The enhanced execution algorithm has the potential of accelerating the distributed execution of behavioral programs. 8. Source: Towards Behavioral Programming in Distributed Architectures (#M5788P), Amir Kantor, Assaf Marron, David Harel, Gera Weiss, Guy Katz, Guy Wiener, p. 18 Context: #GVFU8Q Towards Behavioral Programming in Distributed Architectures1 #QTR76K 3. Application Designs for Dealing with Asynchrony and Different Time Scales #CLFMN2 3.4. Example 1: Synchronizing with an external environment #MRXATE 3.4.1. Game architecture Matching excerpt #LJB78C: We implemented this game in Erlang, using WxErlang as the GUI toolkit, and the bp module as the behavioral programming library. The application consists of the following processes: 9. Source: Towards Behavioral Programming in Distributed Architectures (#M5788P), Amir Kantor, Assaf Marron, David Harel, Gera Weiss, Guy Katz, Guy Wiener, p. 42 Context: #GVFU8Q Towards Behavioral Programming in Distributed Architectures1 #B7CAR2 Acknowledgements Matching excerpt #86HTX9: We thank the anonymous reviewers for valuable comments and suggestions on an earlier version of this paper. These comments have led to a substantial enhancement of the paper. We would like to thank Einat Fuchs, whose lecture about coordination of cockroach locomotion [17] inspired some of the ideas in this paper. We thank Dan Brownstein and Nir Svirsky for their programming work on the MATLAB simulation and the control software of the behaviorally-controlled quadrotor, and Nadav Shechter and Oren Othnay for their work on flying a real quadrotor with BP. 10. Source: Towards Behavioral Programming in Distributed Architectures (#M5788P), Amir Kantor, Assaf Marron, David Harel, Gera Weiss, Guy Katz, Guy Wiener, p. 41 Context: #GVFU8Q Towards Behavioral Programming in Distributed Architectures1 #LCVWTC 6. Positioning BP relative to Mainstream Actor and Agent Programming Matching excerpt #ZGP8UY: BP principles have already been implemented in several environments and languages. It would be interesting to explore the synergy between BP and agent-oriented-specific languages, such as AgentSpeak and Jason [7], 2APL [15], GOAL [29], SIMPA [41], Indigolog [8], JIAC [8], and Axum [1]. Such synergy could emerge from interfacing agents and behavioral programs, from turning b-nodes into agents and using agent programming languages to handle communication between behavioral nodes, or from introducing blocking idioms into agent-oriented languages. Approximate matches 1. Source: Towards Behavioral Programming in Distributed Architectures (#M5788P), Amir Kantor, Assaf Marron, David Harel, Gera Weiss, Guy Katz, Guy Wiener, p. 22 Context: #GVFU8Q Towards Behavioral Programming in Distributed Architectures1 #QTR76K 3. Application Designs for Dealing with Asynchrony and Different Time Scales #Z5FCGK 3.5. Example 2: Coordinating behaviors with different time scales Score: 0.03 Related excerpt #EA8UHB: The model of Bouabdallah et al. is modified, as illustrated in Figure 7. The b-node High-Level Control translates measured differences between actual and desired flight parameters (e.g., orientation, altitude) into four forces (thrust, roll, pitch and yaw — see Figure 6). It consists of four b-threads: one for each of the yaw, pitch and roll axis and one for thrust. Each of these b-threads computes the respective force by applying a standard Proportional Integral 2. Source: Towards Behavioral Programming in Distributed Architectures (#M5788P), Amir Kantor, Assaf Marron, David Harel, Gera Weiss, Guy Katz, Guy Wiener, p. 27 Context: #GVFU8Q Towards Behavioral Programming in Distributed Architectures1 #QTR76K 3. Application Designs for Dealing with Asynchrony and Different Time Scales #Z5FCGK 3.5. Example 2: Coordinating behaviors with different time scales Score: 0.028 Related excerpt #BC76P3: The quadrotor application also shows how behavioral programming can be used in developing hybrid control, i.e., a combination of discrete logic and actuation with the sensing of continuous system variables [36]. In [26] we discuss the application of BP to hybrid control, by using fuzzy logic to translate continuous information into discrete categories that can be refereed to in naturally-programmed scenarios. 3. Source: Towards Behavioral Programming in Distributed Architectures (#M5788P), Amir Kantor, Assaf Marron, David Harel, Gera Weiss, Guy Katz, Guy Wiener, p. 24 Context: #GVFU8Q Towards Behavioral Programming in Distributed Architectures1 #QTR76K 3. Application Designs for Dealing with Asynchrony and Different Time Scales #Z5FCGK 3.5. Example 2: Coordinating behaviors with different time scales Score: 0.028 Related excerpt #KGLCRZ: Subsequently, we have begun to implement a behavioral programming environment written in C that can run directly on a quadrotor, and have shown that the design and the b-threads shown above indeed can stabilize a UAV. In fact, initial versions of this are already flying in our lab. 4. Source: Towards Behavioral Programming in Distributed Architectures (#M5788P), Amir Kantor, Assaf Marron, David Harel, Gera Weiss, Guy Katz, Guy Wiener, p. 22 Context: #GVFU8Q Towards Behavioral Programming in Distributed Architectures1 #QTR76K 3. Application Designs for Dealing with Asynchrony and Different Time Scales #Z5FCGK 3.5. Example 2: Coordinating behaviors with different time scales Score: 0.028 Related excerpt #MMS288: In this section we demonstrate how an application can be composed of behavioral components, namely b-nodes, that operate on different time scales and communicate via events. The example is part of the control software for a quadrotor, a flying vehicle powered by four rotors (see schematic drawing in Figure 6). The behaviorally-programmed piece is responsible for stabilizing the aircraft. It was experimentally tested by plugging behavioral modules written in Java into the comprehensive quadrotor-control simulation model developed by Bouabdallah et al. [9, 10]. This model is based on MATLAB/Simulink and simulates full control of the quadrotor flight including physical aspects. A high-level description of this use-case appeared also in [27]. 5. Source: Towards Behavioral Programming in Distributed Architectures (#M5788P), Amir Kantor, Assaf Marron, David Harel, Gera Weiss, Guy Katz, Guy Wiener, p. 25 Context: #GVFU8Q Towards Behavioral Programming in Distributed Architectures1 #QTR76K 3. Application Designs for Dealing with Asynchrony and Different Time Scales #Z5FCGK 3.5. Example 2: Coordinating behaviors with different time scales Score: 0.026 Related excerpt #KL9BD3: When proceeding on the actual implementation in a flying quadrotor, additional considerations of course emerge in order to meet the real-time constraints. The first and foremost consideration for BP in this regard is having efficient processing at the underlying BP infrastructure, controlling the synchronization of b-threads, collection of their declarations, event selection, and b-thread resumption. One such approach is to turn events into bits and event sets into easily managed bit vectors. Then come the additional real-time considerations of ensuring that the infrastructure and application allow the non-behavioral sensor and actuator processes to interact with the real world at the desired frequency, and that the b-threads of system behavior are efficient and predictable in completing their reactive scenarios before arrival of the next environment-driven event. For example, towards predictability, in our experimentation on the real quadrotor, we initiate the output event at a fixed time frequency, regardless of whether the b-threads have completed their negotiations over the right changes to all RPM values or not. Both the BP infrastructure optimization and more comprehensive design guidelines regarding real time behavioral applications are the subject of future research and are outside of the scope of the present paper. 6. Source: Towards Behavioral Programming in Distributed Architectures (#M5788P), Amir Kantor, Assaf Marron, David Harel, Gera Weiss, Guy Katz, Guy Wiener, p. 24 Context: #GVFU8Q Towards Behavioral Programming in Distributed Architectures1 #QTR76K 3. Application Designs for Dealing with Asynchrony and Different Time Scales #Z5FCGK 3.5. Example 2: Coordinating behaviors with different time scales Score: 0.026 Related excerpt #NDD374: In our simulation, the super-step is orchestrated as follows. A lowest-priority b-thread repeatedly waits for RPM-change events, as described above, and keeps track of all desired rotor RPMs by changing in-memory values by fixed amounts. This b-thread repeatedly requests an output event that contains those values, but due to its low priority, output is triggered only when there are no other events to trigger (i.e., the four force-control b-threads have attained their targets). The output event marks the completion of a super-step. Four inputs (target forces) are then presented again (by a high priority b-thread that polls an external queue), marking the beginning of the next super-step. Throughout, an actuator b-thread waits for output events and transmits the required signals to the rotors. The detailed simulations we carried out show that his behavioral solution indeed stabilizes the quadrotor, as can be seen in Figure 9. 7. Source: Towards Behavioral Programming in Distributed Architectures (#M5788P), Amir Kantor, Assaf Marron, David Harel, Gera Weiss, Guy Katz, Guy Wiener, p. 26 Context: #GVFU8Q Towards Behavioral Programming in Distributed Architectures1 #QTR76K 3. Application Designs for Dealing with Asynchrony and Different Time Scales #Z5FCGK 3.5. Example 2: Coordinating behaviors with different time scales Score: 0.025 Related excerpt #UGV8G9: Summary. In creating composite behavior, the quadrotor application uses very local behaviors, such as controlling roll and pitch, to achieve higher level goals such as maintaining stability. Longer term behaviors, such as traveling between stations in a multi-stop trip, or keeping maintenance and refueling schedules, can be constructed from similar elements. While all these facets can be programmed as compositions of b-threads, gluing them together is easier with an infrastructure that can support multiple time scales. Clearly, a b-thread that controls a multi-stop navigation itinerary can suffice with occasional changing of the required speed and direction, and does not require the constant synchronization and attentiveness of the stabilization modules described above. 8. Source: Towards Behavioral Programming in Distributed Architectures (#M5788P), Amir Kantor, Assaf Marron, David Harel, Gera Weiss, Guy Katz, Guy Wiener, p. 42 Context: #GVFU8Q Towards Behavioral Programming in Distributed Architectures1 #B7CAR2 Acknowledgements Score: 0.023 Related excerpt #86HTX9: We thank the anonymous reviewers for valuable comments and suggestions on an earlier version of this paper. These comments have led to a substantial enhancement of the paper. We would like to thank Einat Fuchs, whose lecture about coordination of cockroach locomotion [17] inspired some of the ideas in this paper. We thank Dan Brownstein and Nir Svirsky for their programming work on the MATLAB simulation and the control software of the behaviorally-controlled quadrotor, and Nadav Shechter and Oren Othnay for their work on flying a real quadrotor with BP. 9. Source: Towards Behavioral Programming in Distributed Architectures (#M5788P), Amir Kantor, Assaf Marron, David Harel, Gera Weiss, Guy Katz, Guy Wiener, p. 24 Context: #GVFU8Q Towards Behavioral Programming in Distributed Architectures1 #QTR76K 3. Application Designs for Dealing with Asynchrony and Different Time Scales #Z5FCGK 3.5. Example 2: Coordinating behaviors with different time scales Score: 0.023 Related excerpt #QJAA25: For example, to increase the pitch (raise the front), the system requests the events of increasing the front rotor’s RPM and decreasing the back rotor’s RPM, while blocking the opposite (complementary) events. Note that desired flight results depend only on the total numbers of events that increase or decrease the controlled value, and the difference between their numbers, while the actual mix of events may vary. Specifically in this example (see Figure 8), in order to allow finer control, the b-threads translate the input force into a sequence of events that affect the rotor speed by smaller increments. Furthermore, to accommodate behaviors that require concurrent actions on multiple rotors, all behaviors entertain a “slack”, in which they allow a small number of undesired events to occur before blocking them completely. In this manner, the ThrustBT can increase the RPM of all rotors equally, one at a time, without interference from b-threads that try to create a difference between certain rotor RPMs. 10. Source: Relaxing Synchronization Constraints in Behavioral Programs (#TDS4H2), Amir Kantor, David Harel, Guy Katz, p. 12 Context: #KBEBVQ Relaxing Synchronization Constraints in Behavioral Programs #97ZMXK 4 Modularity by Eager Execution #WC7Z5Z 4.1 Example: A Modular Design Score: 0.023 Related excerpt #XJFQYS: Using eager execution, this multi-component system can be programmed entirely within the behavioral programming framework, without relying on external means of communication. The threads of each vehicle, v_i , form an independent behavioral module M_i that involves a designated set of events. This results in a strict modular design allowing each vehicle to operate independently of others. A code snippet for the main thread of vehicle v_i is depicted in Fig. 7. If each module has a dedicated processor and event selection is fair, all vehicles are constantly moving — as the coordinator does not wait for vehicle v_i to finish moving and synchronize again before triggering the movement requested by another vehicle. ### 4. Tool result: list_documents FOLDERS - Accounting Algebra & Property Theory - Living Structure, Wholeness & Beauty - Living Structure, Wholeness & Beauty - Procedural Generation & Co-Creation - Roads, Trails & Movement - Scenario-Based & Behavioral Programming - Technology, Scale & Conviviality - Terrain, Hydrology & Erosion - Water Simulation & Rendering Accounting Algebra & Property Theory (4) - #GANFP9 A Fundamental Duality in the Mathematical and Natural Sciences: From Logic to Biology - 2024 | David Ellerman | 53 pp. Micro abstract: Traces an overlooked subset–partition duality—from logic and category theory through entropy and quantum indefiniteness to selectionist and generative mechanisms in biology. - #NBH3BE Algebraic Models for Accounting Systems - 2010 | Derek J. S. Robinson, José García Pérez, Robert A. Nehmer, Salvador Cruz Rambaud | World Scientific | 255 pp. Micro abstract: Develops accounting theory algebraically: balance vectors as modules, transactions as a group, and whole accounting systems as automata with quotients, homomorphisms, and decision algorithms for audit and control. - #7ESDBJ Economics, Accounting, and Property Theory - 1982 | David P. Ellerman | Lexington Books | 110 pp. Micro abstract: Ellerman's vector-accounting monograph: double entry generalized to property vectors ("accounting without valuation"), grounding a property-theoretic account of appropriation, the firm, and goodwill. - #C8FHDZ On implication and negation in partition logic - 2025 | , David Ellerman | Open Journal of Mathematical Sciences | 9 pp. | doi:10.30538/oms2025.0250 Micro abstract: Develops implication as a refinement-sensitive operation on set partitions, showing how relative negation yields local Boolean cores within the non-distributive algebra of partitions. Living Structure, Wholeness & Beauty (9) - #MH5J8D Beautimeter: Harnessing GPT for Assessing Architectural and Urban Beauty Based on the 15 Properties of Living Structure - 2025 | Bin Jiang | AI | 12 pp. | doi:10.3390/ai6040074 Micro abstract: Presents Beautimeter, a GPT-based tool that scores buildings and urban scenes against Christopher Alexander’s 15 properties of living structure to assess their coherence and beauty. - #XW22YY Generative Codes: The Path to Building Welcoming, Beautiful, Sustainable Neighborhoods - 2005 | Brian Hanson, Christopher Alexander, Maggie Moore Alexander, Michael Mehaffy, Randall Schmidt | Center for Environmental Structure | 21 pp. Micro abstract: Argues that living neighborhoods arise from generative codes: ordered, participatory steps that let buildings and public spaces unfold from local people, land, and context. - #SKRF4C Geography as a Science of the Earth’s Surface Founded on the Third View of Space - 2022 | Bin Jiang | Annals of GIS | 14 pp. | doi:10.1080/19475683.2021.1966502 Micro abstract: Recasts geography around an organismic view of space, using scaling and spatial dependence to understand—and deliberately create—places with greater living structure. - #PXG56P Harmony-Seeking Computations: A Science of Non-Classical Dynamics Based on the Progressive Evolution of the Larger Whole - 2009 | Christopher Alexander | Unpublished manuscript | 66 pp. Micro abstract: Proposes harmony-seeking computation as a creative process that repeatedly strengthens latent centers in a configuration while preserving and deepening the larger whole. - #MJKTBB Living Images: A Recursive Approach to Computing the Structural Beauty of Images or the Livingness of Space - 2023 | Bin Jiang, Chris de Rijke | Annals of the American Association of Geographers | 19 pp. | doi:10.1080/24694452.2023.2178376 Micro abstract: Measures an image’s structural beauty by recursively extracting its nested substructures, revealing a compact hierarchy that also captures visual saliency. - #3XSLTA Structural Beauty: A Structure-Based Computational Approach to Quantifying the Beauty of an Image - 2021 | Bin Jiang, Chris de Rijke | Journal of Imaging | 15 pp. | doi:10.3390/jimaging7050078 Micro abstract: Proposes a quantitative measure of structural beauty based on how many substructures an image contains and how strongly they form a hierarchy across scales. - #ZU8GZV Structure-Preserving Transformations - 2002 | Christopher Alexander | The Nature of Order, Book Two: The Process of Creating Life | 4 pp. | doi:10.2307/j.ctv27ftw6c.5 Micro abstract: Explains structure-preserving transformations: incremental changes that extend the centers and relationships already present in a place rather than weakening its wholeness. - #AULNWD The Nature of Poetic Order - 1998 | Richard P. Gabriel | Warren Wilson Alumni Conference, Mount Holyoke | 99 pp. Micro abstract: Gabriel's slide essay relating poetry's formal order to Christopher Alexander's ideas of generative structure, exploring how constraint and pattern produce living order in creative work. - #BYG3BQ Wholeness as a Hierarchical Graph to Capture the Nature of Space - 2015 | Bin Jiang | International Journal of Geographical Information Science | 14 pp. | doi:10.1080/13658816.2015.1038542 Micro abstract: Models spatial wholeness as a hierarchical graph of mutually reinforcing centers, using PageRank and scaling depth to quantify the life of parts and wholes. Procedural Generation & Co-Creation (14) - #ABD2B8 Between Tech and Art: The Vegetation of Horizon Zero Dawn - 2018 | Gilbert Sanders, Guerrilla Games | Game Developers Conference (GDC) 2018 | 87 pp. Micro abstract: A production breakdown of Horizon Zero Dawn’s vegetation pipeline, covering global wind simulation, layered foliage motion, coverage-preserving alpha mipmaps, shading, asset LODs, placement, and cascaded shadows. - #4TH488 Explainable AI for Designers: A Human-Centered Perspective on Mixed-Initiative Co-Creation - 2018 | Antonios Liapis, G. Michael Youngblood, Jichen Zhu, Rafael Bidarra, Sebastian Risi | 2018 IEEE Conference on Computational Intelligence and Games (CIG) | 8 pp. | doi:10.1109/CIG.2018.8490433 Micro abstract: Defines explainable AI for game designers, mapping co-creative systems by their explainability, initiative, and domain overlap so explanations serve concrete design tasks. - #9NQ94D Extracting Physics from Blended Platformer Game Levels - 2020 | Adam Summerville, Anurag Sarkar, Joseph C. Osborn, Sam Snodgrass | Joint Proceedings of the AIIDE 2020 Workshops (CEUR Workshop Proceedings, Vol. 2862) | 7 pp. Micro abstract: Infers playable jump physics from generated platformer levels, including hybrid physics models for levels that blend the geometry and style of multiple games. - #66Q3W3 Ghost of Tsushima: Procedural Grass - 2021 | Eric Wohllaib, Sucker Punch Productions | Game Developers Conference (GDC) 2021 | 55 pp. Micro abstract: Explains Ghost of Tsushima’s compute-driven grass pipeline, from tiled placement and culling to indirect drawing, cubic Bézier blade geometry, variable LOD, wind animation, and material shading. - #QHMFH2 Improved Alpha Testing Using Hashed Sampling - 2019 | Chris Wyman, Morgan McGuire | IEEE Transactions on Visualization and Computer Graphics | 12 pp. | doi:10.1109/TVCG.2017.2739149 Micro abstract: Develops hashed alpha testing, a stable quasi-random thresholding method that preserves distant alpha-mapped foliage and hair while controlling flicker, anisotropy, and interactions with TAA and alpha-to-coverage. - #7GR3AQ Procedural Content Generation through Quality Diversity - 2019 | Ahmed Khalifa, Antonios Liapis, Daniele Gravina, Georgios N. Yannakakis, Julian Togelius | 2019 IEEE Conference on Games (CoG) | 8 pp. | doi:10.1109/CIG.2019.8848053 Micro abstract: Argues for quality-diversity algorithms in procedural generation, producing broad collections of varied, playable content while exposing the design space for exploration and co-creation. - #CQBDX4 Procedural Content Generation via Machine Learning (PCGML) - 2018 | Aaron Isaksen, Adam Summerville, Amy K. Hoover, Andy Nealen, Christoffer Holmgård, Julian Togelius, Matthew Guzdial, Sam Snodgrass | IEEE Transactions on Games | 15 pp. | doi:10.1109/TG.2018.2846639 Micro abstract: Defines and surveys PCGML: generating functional game content directly from models trained on existing examples, with uses spanning creation, completion, repair, critique, and compression. - #EARFEK Procedural Generation of Villages on Arbitrary Terrains - 2012 | Adrien Bernhardt, Adrien Peytavie, Arnaud Emilien, Eric Galin, Marie-Paule Cani | The Visual Computer | 10 pp. | doi:10.1007/s00371-012-0699-7 Micro abstract: Presents a three-stage procedural model that grows terrain-responsive village roads and settlements, partitions land into plausible parcels, and generates slope-adapted buildings with open shape grammars. - #EDURTK Real-Time GPU Tree Generation - 2025 | Bastian Kuth, Carsten Faber, Dominik Baumeister, Max Oberberger, Pirmin Pfeifer, Quirin Meyer, Seyedmasih Tabaei | High-Performance Graphics – Symposium Papers | 10 pp. | doi:10.2312/hpg.20251168 Micro abstract: Introduces a GPU work-graph pipeline that generates, animates, edits, and continuously LODs detailed seasonal trees every frame, replacing gigabytes of baked geometry with kilobytes of parameters. - #GBXEP3 Realistic Modeling and Rendering of Plant Ecosystems - 1998 | Bernd Lintermann, Matt Pharr, Oliver Deussen, Pat Hanrahan, Przemyslaw Prusinkiewicz, Radomír Měch | Proceedings of SIGGRAPH ’98 | 12 pp. | doi:10.1145/280814.280898 Micro abstract: Presents a foundational pipeline for authoring plant ecosystems through terrain design, ecological simulation, procedural plant models, approximate instancing, and efficient rendering of billion-primitive scenes. - #BDBBL6 Real‐time Realistic Rendering and Lighting of Forests - 2012 | Eric Bruneton, Fabrice Neyret | Computer Graphics Forum | 11 pp. | doi:10.1111/j.1467-8659.2012.03016.x Micro abstract: Combines detailed z-field trees with terrain shader-maps to render immense forests in real time, preserving sun, sky, canopy, and ground-lighting effects through seamless, scale-consistent transitions. - #PQ68ZH Responsive Real-Time Grass Rendering for General 3D Scenes - 2017 | Klemens Jahrmann, Michael Wimmer | Proceedings of the 2017 Symposium on Interactive 3D Graphics and Games (I3D ’17) | 10 pp. | doi:10.1145/3023368.3023380 Micro abstract: Renders every grass blade as responsive tessellated geometry on arbitrary 3D surfaces, with per-blade wind, gravity, and collision physics plus aggressive culling that retains dense fields in real time. - #WZ8DHP Runtime Evaluation of Procedural Content Generation in an Endless Runner Game Using Autonomous Agents - 2026 | Rishabh Kar | arXiv | 25 pp. | doi:10.48550/arXiv.2605.01783 Micro abstract: Integrates procedural generation and validation in an endless runner, using aerial and ground agents to detect blocked or unnavigable content before the player reaches it. - #NRBMD5 Towards Friendly Mixed Initiative Procedural Content Generation: Three Pillars of Industry - 2020 | Frederic Fol Leymarie, Gorm Lai, William Latham | Proceedings of the International Conference on the Foundations of Digital Games (FDG '20) | 4 pp. | doi:10.1145/3402942.3402946 Micro abstract: Distills three requirements for industry-friendly co-creative PCG tools: preserve designer control, keep feedback loops short, and fit into existing production pipelines. Roads, Trails & Movement (8) - #G3TBNG A Sequential Two-Step Algorithm for Fast Generation of Vehicle Racing Trajectories - 2016 | J. Christian Gerdes, John Subosits, Nitin R. Kapania | Journal of Dynamic Systems, Measurement, and Control | 12 pp. | doi:10.1115/1.4033311 Micro abstract: Generates near-optimal racing trajectories quickly by alternating between a minimum-time speed profile and a convex path update that reduces curvature. - #B6P8L4 Active walker model for the formation of human and animal trail systems - 1997 | Dirk Helbing, Frank Schweitzer, Joachim Keltsch, Péter Molnár | Physical Review E | 34 pp. | doi:10.1103/physreve.56.2527 Micro abstract: Models trail systems as self-organization: walkers reinforce attractive routes while unused traces fade, producing dendritic ant trails and low-detour pedestrian networks. - #V4TQYB Interactive procedural street modeling - 2008 | Eugene Zhang, Gregory Esch, Guoning Chen, Pascal Müller, Peter Wonka | ACM Transactions on Graphics | 10 pp. | doi:10.1145/1360612.1360702 Micro abstract: Lets designers generate and edit large street networks through tensor fields, combining procedural speed with brush-like global and local control over street patterns. - #UYLTYJ Modelling the Evolution of Human Trail Systems - 1997 | Dirk Helbing, Joachim Keltsch, Péter Molnár | Nature | 11 pp. | doi:10.1038/40353 Micro abstract: Shows how pedestrian trails emerge through feedback between destination-seeking walkers, existing paths, and vegetation recovery, yielding a compromise between directness and shared infrastructure. - #GY93FG Mountain Trail Formation and the Active Walker Model - 2009 | J. P. Hague, S. J. Gilks | International Journal of Modern Physics C | 22 pp. | doi:10.1142/S0129183109014059 Micro abstract: Extends the active-walker model to steep terrain, explaining zigzag mountain trails through slope avoidance, directional persistence, and mutual reinforcement by ascending and descending walkers. - #LXV9AT Principles of Trail Layout and Design - 2019 | California State Parks | California State Parks Trails Handbook | 64 pp. Micro abstract: A field-oriented guide to durable trail design, emphasizing curvilinear alignment, natural drainage, sustainable grades, control points, and close reading of landform and soils. - #XDEFZS Procedural Generation of Roads - 2010 | A. Peytavie, E. Galin, E. Guérin, N. Maréchal | Computer Graphics Forum | 10 pp. | doi:10.1111/j.1467-8659.2009.01612.x Micro abstract: Automatically routes and constructs roads with an anisotropic shortest-path method that weighs slope and obstacles while treating surface segments, bridges, and tunnels consistently. - #ARP5U7 The Topography of Minoan Peak Sanctuaries - 1983 | A. A. D. Peatfield | The Annual of the British School at Athens | 8 pp. | doi:10.1017/s0068245400019729 Micro abstract: Argues that Minoan peak sanctuaries were chosen for visibility and proximity to local settlements, forming a beacon-like sacred network whose contraction tracked settlement abandonment rather than cultic collapse. Scenario-Based & Behavioral Programming (8) - #P2W4J5 Adaptive Behavioral Programming - 2011 | David Harel, Nir Eitan | 8 pp. | doi:10.1109/ictai.2011.109 Micro abstract: Adds reinforcements to live sequence charts and BPJ so scenario-based programs can learn from their environment, specifying goals to pursue and scenarios to avoid, with modular learning decompositions. - #XQ5NKX Challenges in Modeling and Unmodeling Emergence, Rule Composition, and Networked Interactions in Complex Reactive Systems - 2023 | Assaf Marron, David Harel, Guy Frankel, Irun Cohen, Smadar Szekely | 8 pp. | doi:10.5220/0011728900003402 Micro abstract: Position paper on modeling emergence, rule composition, and networked interactions in complex reactive systems, introducing "unmodeling"—explicitly excluding entities and behaviors from model execution. - #D4VB7S Distributing Scenario-Based Models: A Replicate-and-Project Approach - 2017 | Assaf Marron, Daniel Gritzner, David Harel, Guy Katz, Joel Greenyer, Shlomi Steinberg | MODELSWARD 2017 | 16 pp. | doi:10.5220/0006271301820195 Micro abstract: Distributes scenario-based models by replicating the full specification on every component and projecting it per component, mimicking centralized behavior while sharply reducing synchronization. - #CSJARA Enhancing Scenario-Based Modeling Using Large Language Models - 2026 | Assaf Marron, David Harel, Guy Katz, Smadar Szekely | Communications in Computer and Information Science | Springer Nature Switzerland | pp. 43-68 | 26 pp. | doi:10.1007/978-3-031-96841-9_3 Micro abstract: Extended methodology for combining LLM chatbots with scenario-based modeling: iterative generation of stand-alone scenarios checked by analysis and human review, framed as a step toward Wise Computing. - #3JCRAD On Augmenting Scenario-Based Modeling with Generative AI - 2024 | Assaf Marron, David Harel, Guy Katz, Smadar Szekely | MODELSWARD 2024 | 12 pp. | doi:10.5220/0012427100003645 Micro abstract: Outlines a structured method for using generative-AI chatbots in modeling: iteratively generate scenario-based model fragments, then analyze and inspect them to converge on an accurate system model. - #QV3BWZ On tracing reactive systems - 2011 | David Harel, Shahar Maoz | Software & Systems Modeling | 22 pp. | doi:10.1007/s10270-010-0151-2 Micro abstract: Introduces model-based trace visualization and exploration for reactive systems, using scenario-based (LSC) abstractions and the Tracer prototype, demonstrated on a PacMan game. - #TDS4H2 Relaxing Synchronization Constraints in Behavioral Programs - 2013 | Amir Kantor, David Harel, Guy Katz | LPAR 2013 (Logic for Programming, Artificial Intelligence, and Reasoning) | 17 pp. | doi:10.1007/978-3-642-45221-5_25 Micro abstract: Proposes eager execution for behavioral programs: fast b-threads run ahead when synchronization outcomes are predictable, improving performance, modularity, and distributability, shown in a C++ BP framework. - #M5788P Towards Behavioral Programming in Distributed Architectures - 2015 | Amir Kantor, Assaf Marron, David Harel, Gera Weiss, Guy Katz, Guy Wiener | Science of Computer Programming | 58 pp. | doi:10.1016/j.scico.2014.03.003 Micro abstract: Extends behavioral programming to distributed architectures: b-threads as Erlang processes, eager execution to relax synchronization, and modular distributed execution, demonstrated on simulations and a quadrotor. Technology, Scale & Conviviality (2) - #WYH36B The City as Convivial Centre - 1974 | Leopold Kohr | Tract, no. 12 (Gryphon Press) | 18 pp. Micro abstract: Kohr's essay arguing that cities exist for convivial life rather than economic function, and that human-scale size is what lets a city serve as a centre of leisure, culture, and encounter. - #67REFX The Question Concerning Technology - 1977 | Martin Heidegger | The Question Concerning Technology and Other Essays (Harper & Row) | 23 pp. Micro abstract: Heidegger's essay on the essence of technology as Enframing (Gestell), a mode of revealing that reduces the world to standing-reserve, and on art as a possible saving power. Terrain, Hydrology & Erosion (8) - #NV2YRW FastFlow: GPU Acceleration of Flow and Depression Routing for Landscape Simulation - 2024 | Aryamaan Jain, Bernhard Kerbl, Brandon Finley, Guillaume Cordonnier, James Gain | Computer Graphics Forum | 13 pp. | doi:10.1111/cgf.15243 Micro abstract: A GPU framework for routing surface flow through terrain and its depressions fast enough to make erosion, river, lake, and ecosystem simulations interactive. - #2284QZ From features to fingerprints: A general diagnostic framework for anthropogenic geomorphology - 2019 | Damian Evans, Erle C Ellis, Giulia Sofia, Paolo Tarolli, Wenfang Cao | Progress in Physical Geography: Earth and Environment | 34 pp. | doi:10.1177/0309133318825284 Micro abstract: Integrates geomorphology, archaeology, and high-resolution remote sensing into a framework for reading anthropogenic landforms as landscape-scale sociocultural fingerprints. - #96ZMGK Large Scale Terrain Generation from Tectonic Uplift and Fluvial Erosion - 2016 | Adrien Peytavie, Bedrich Benes, Guillaume Cordonnier, Jean Braun, Marie-Paule Cani, Éric Galin, Éric Guérin | Computer Graphics Forum | 11 pp. | doi:10.1111/cgf.12820 Micro abstract: Generates large, controllable mountain terrains by coupling user-painted tectonic uplift with fluvial erosion, then turning the resulting stream graph into detailed landforms. - #K82AS7 Legacy sediment: Definitions and processes of episodically produced anthropogenic sediment - 2013 | L. Allan James | Anthropocene | 11 pp. | doi:10.1016/j.ancene.2013.04.001 Micro abstract: Broadens legacy sediment to episodically produced anthropogenic alluvium and colluvium, and explains its deposition, storage, and remobilization through sediment delivery–transport capacity dynamics. - #DWXKYQ Physically-based analytical erosion for fast terrain generation - 2024 | Boris Gailleton, Guillaume Cordonnier, Petros Tzathas, Philippe Steer | Computer Graphics Forum | 14 pp. | doi:10.1111/cgf.15033 Micro abstract: Turns the stream power law into an interactive terrain tool, replacing thousands of erosion time steps with analytical solutions and a direct control for landscape age. - #MTDKDE Priority-Flood: An Optimal Depression-Filling and Watershed-Labeling Algorithm for Digital Elevation Models - 2014 | Clarence Lehman, David Mulla, Richard Barnes | Computers & Geosciences | 17 pp. | doi:10.1016/j.cageo.2013.04.024 Micro abstract: Introduces Priority-Flood, a simple, optimal algorithm that removes drainage-blocking depressions from elevation models and can also derive watersheds and flow directions. - #AK7NGE Procedural Riverscapes - 2019 | A. Peytavie, B. Benes, E. Galin, E. Guérin, J. Gain, T. Dupont, Y. Cortial | Computer Graphics Forum | 12 pp. | doi:10.1111/cgf.13814 Micro abstract: Builds editable, animated riverscapes from bare terrain by carving hydrologically plausible channels and blending real-time procedural water primitives instead of simulating fluids. - #DMTA8Y Terrain Generation Using Procedural Models Based on Hydrology - 2013 | Adrien Peytavie, Bedřich Beneš, Jean-David Génevaux, Éric Galin, Éric Guérin | ACM Transactions on Graphics | 10 pp. | doi:10.1145/2461912.2461996 Micro abstract: Generates controllable, multiscale terrain from a sketched drainage network, representing rivers and landforms as an editable hierarchy of continuous procedural primitives. Water Simulation & Rendering (12) - #RBS5K6 A Layered Particle-Based Fluid Model for Real-Time Rendering of Water - 2010 | Daniel Scherzer, Florian Bagar, Michael Wimmer | Computer Graphics Forum | 7 pp. | doi:10.1111/j.1467-8659.2010.01734.x Micro abstract: Renders particle-based water and volumetric foam in real time using perspective-aware surface smoothing, physically guided foam formation, and layered depth compositing. - #C4AY2M A Survey of Ocean Simulation and Rendering Techniques in Computer Graphics - 2011 | B. Crespin, D. Ghazanfarpour, E. Darles, J.-C. Gonzato | Computer Graphics Forum | 17 pp. | doi:10.1111/j.1467-8659.2010.01828.x Micro abstract: Surveys ocean graphics from spectral deep-water models to near-shore fluid simulation, then covers the foam, spray, and light transport needed for convincing rendering. - #WZMZGY Advected river textures - 2009 | Dirk Arnold, Stephen Brooks, Tim Burrell | Computer Animation and Virtual Worlds | 11 pp. | doi:10.1002/cav.288 Micro abstract: Combines a 2D Navier–Stokes solver, hydrostatic pressure columns, and advected procedural textures to render detailed, terrain-responsive rivers at real-time frame rates. - #92XRH7 Lagrangian Texture Advection: Preserving both Spectrum and Velocity Field - 2011 | Qizhi Yu, E. Bruneton, F. Neyret, N. Holzschuch | IEEE Transactions on Visualization and Computer Graphics | 13 pp. | doi:10.1109/tvcg.2010.263 Micro abstract: Advects fluid textures with deformable particle grids, preserving both the input texture’s visual spectrum and exact motion along the velocity field without cumulative stretching. - #8SERGP Real-time Breaking Waves for Shallow Water Simulations - 2007 | Markus Gross, Matthias Müller-Fischer, Nils Thürey, Simon Schirm | 15th Pacific Conference on Computer Graphics and Applications (Pacific Graphics 2007) | 8 pp. | doi:10.1109/PG.2007.33 Micro abstract: Adds real-time overturning waves to shallow-water heightfields by detecting steep fronts and spawning connected particle sheets that collapse into splashes and foam. - #CWC7H9 Real-time Rendering of Enhanced Shallow Water Fluid Simulations - 2013 | Antonio Susín, Jesús Ojeda | Computers & Graphics | 9 pp. Micro abstract: Builds a real-time rendering pipeline for shallow-water simulations, adding fine surface detail, advected foam, photon-based caustics, and screen-space reflection and refraction. - #MVUJ8Z Real-time Rendering of River Networks - 2010 | Quintijn Hendrickx, Rafael Bidarra, Ruben M. Smelik | Proceedings of the ACM SIGGRAPH Symposium on Interactive 3D Graphics and Games | 1 pp. Micro abstract: Renders branching river networks efficiently with quadratic Bézier curves, GPU distance fields, and streaming normal maps instead of dense geometry or particle simulation. - #5MGCZ5 Real-time River Representation by Dynamic Control of Data on Waves - 2008 | Makoto Kosugi, Nobuhiko Mukai, Yasuhiro Kato | 4 pp. | doi:10.3169/itej.62.2063 Micro abstract: Dynamically switches river-wave models by viewing distance, preserving nearby reflection and wave detail while retaining wind-driven motion across the full landscape. - #XDESU9 Scalable real‐time animation of rivers - 2009 | Eric Bruneton, Fabrice Neyret, Nicolas Holzschuch, Qizhi Yu | Computer Graphics Forum | 11 pp. | doi:10.1111/j.1467-8659.2009.01363.x Micro abstract: Animates rivers across vast terrains by computing steady flow locally and advecting fine surface detail only where visible, at a screen-space sampling density. - #869NHK Very Fast Real-Time Ocean Wave Foam Rendering Using Halftoning - 2011 | Ian Parberry, Jennifer R. Alford, Mary Yingst | Proceedings of the 6th International North American Conference on Intelligent Games and Simulation (GAMEON-NA) | 7 pp. Micro abstract: Uses a spectrally controlled halftone mask to make texture-based ocean foam dissipate as clumped bubbles that pop, rather than merely fading transparently. - #A2QB8L Water Flow in Portal 2 - 2010 | Alex Vlachos | ACM SIGGRAPH 2010 Course: Advances in Real-Time Rendering in 3D Graphics and Games | 54 pp. Micro abstract: Explains Portal 2’s production-friendly water shader: artist-painted flow maps advect layered normal maps, while offsets and noise suppress repetition and pulsing on limited hardware. - #PBM2TC Water surface wavelets - 2018 | Chris Wojtan, Matthias Müller-Fischer, Miles Macklin, Nuttapong Chentanez, Stefan Jeschke, Tomáš Skřivan | ACM Transactions on Graphics | 13 pp. | doi:10.1145/3197517.3201336 Micro abstract: Represents water waves as spatially varying directional amplitudes, enabling vast interactive simulations with fine detail, moving obstacles, solid coupling, and direct artistic control. ### 5. Assistant tool calls #### Tool call: `get_document` ```json { "id": "M5788P" } ``` ### 6. Tool result: get_document DOCUMENT #M5788P Title: Towards Behavioral Programming in Distributed Architectures Outline: - 1 #GVFU8Q Towards Behavioral Programming in Distributed Architectures1 - 1.1 #79EMN3 Abstract - 1.2 #5SGDUB 1. Introduction - 1.3 #UQH7TV 2. Behavioral Programming in Erlang - 1.3.1 #XF6B7P 2.1. Intent - 1.3.2 #BQTMNY 2.2. Motivation - 1.3.3 #A33ZUE 2.3. Applicability - 1.3.4 #USGF24 2.4. Structure - 1.3.5 #RZ46JZ 2.5. Participants - 1.3.6 #ARBNEY 2.6. Collaboration - 1.3.7 #EZVXKT 2.7. Code structure - 1.3.8 #5FDNGL 2.8. A simple example - 1.3.9 #GPE58X 2.9. Formal Definitions - 1.3.9.1 #SKTV48 2.9.1. B-Threads - 1.3.9.2 #RAU5LM 2.9.2. Behavioral Programs - 1.3.10 #6SYY3E 2.10. Visualization - 1.3.11 #CW2E4J 2.11. Consequences - 1.3.12 #MZ2RLD 2.12. Example: Coordinated sequential processing - 1.3.13 #RQD43J 2.13. Known uses and related design patterns - 1.4 #QTR76K 3. Application Designs for Dealing with Asynchrony and Different Time Scales - 1.4.1 #37FB3F 3.1. How short is your zero time? - 1.4.2 #BE7ZJF 3.2. Handling external events - 1.4.3 #BU6VQL 3.3. Accommodating behaviors at different time scales - 1.4.4 #CLFMN2 3.4. Example 1: Synchronizing with an external environment - 1.4.4.1 #MRXATE 3.4.1. Game architecture - 1.4.4.2 #VZ34LB 3.4.2. Game behaviors - 1.4.5 #Z5FCGK 3.5. Example 2: Coordinating behaviors with different time scales - 1.4.6 #G485QR 3.6. Example 3: Incremental development of a multi-agent application - 1.4.6.1 #88GREA 3.6.1. Vehicle motion - 1.4.6.2 #LG3ZE2 3.6.2. Enabling external communication - 1.4.6.3 #JGN5SS 3.6.3. Adding an advisor agent - 1.5 #BTKBDM 4. Relaxing Synchronization Constraints through Eager Execution - 1.5.1 #GN2TSH 4.1. Relaxing Synchronization Constraints - 1.5.2 #GW8WUH 4.2. Relaxing Synchronization using Static Information - 1.5.2.1 #C7NH78 4.2.1. Example: External Input using Static Information - 1.5.2.2 #KBLKH3 4.2.2. Modularity using Static Information - 1.5.3 #8S8MSX 4.3. Relaxing Synchronization using Dynamic Information - 1.5.3.1 #ZURZ84 4.3.1. Example: Optimization using Dynamic Information - 1.5.3.2 #BSW49N 4.3.2. Automated Graph Spanning - 1.6 #ZBXP46 5. Comparing B-Nodes and Eager Execution - 1.7 #LCVWTC 6. Positioning BP relative to Mainstream Actor and Agent Programming - 1.8 #FDWQZB 7. Conclusion and Future Work - 1.9 #B7CAR2 Acknowledgements - 1.10 #AXBDZB References - 1.11 #V3LTNK Appendix A. Example: Coordinated sequential processing - 1.12 #7AJHYP Appendix B. Eager Execution Formalized - 1.12.1 #ABGXU2 Corollary 1. - 1.12.2 #W2BNZQ Lemma 2. - 1.13 #9XXUP6 Appendix C. Nondeterministic Threads - 1.13.1 #Q8L7S4 Appendix C.1. Eager Execution of Programs with Nondeterministic Threads - 1.13.1.1 #VEWL58 Appendix C.1.1. Relaxing Synchronization using Static Information - 1.13.1.2 #JZUXEB Appendix C.1.2. Relaxing Synchronization using Dynamic Information - 1.13.2 #N4572C Appendix C.2. Eager Execution Formalized for Nondeterministic Threads - 1.14 #L77LJ3 Appendix D. Modularity Formalized - 1.15 #TQXT4D Appendix E. The Distributed Execution Mechanism - 1.15.1 #Z8LGTU Appendix E.1. Distributed Execution Formalized - 1.15.2 #UN2PUF Appendix E.2. Further Relaxing the Distributed Execution Mechanism ### 7. Assistant tool calls #### Tool call: `read` ```json { "blocks": [ "Z5FCGK" ], "expand": true } ``` ### 8. Tool result: read DOCUMENT #M5788P Towards Behavioral Programming in Distributed Architectures SECTION #Z5FCGK 3.5. Example 2: Coordinating behaviors with different time scales EXCERPT #MMS288 p. 22 In this section we demonstrate how an application can be composed of behavioral components, namely b-nodes, that operate on different time scales and communicate via events. The example is part of the control software for a quadrotor, a flying vehicle powered by four rotors (see schematic drawing in Figure 6). The behaviorally-programmed piece is responsible for stabilizing the aircraft. It was experimentally tested by plugging behavioral modules written in Java into the comprehensive quadrotor-control simulation model developed by Bouabdallah et al. [9, 10]. This model is based on MATLAB/Simulink and simulates full control of the quadrotor flight including physical aspects. A high-level description of this use-case appeared also in [27]. EXCERPT #EA8UHB p. 22 The model of Bouabdallah et al. is modified, as illustrated in Figure 7. The b-node High-Level Control translates measured differences between actual and desired flight parameters (e.g., orientation, altitude) into four forces (thrust, roll, pitch and yaw — see Figure 6). It consists of four b-threads: one for each of the yaw, pitch and roll axis and one for thrust. Each of these b-threads computes the respective force by applying a standard Proportional Integral EXCERPT #KF8EPB p. 22 EXCERPT #TNHY92 p. 23 \text{Thrust} = T_F + T_R + T_B + T_L \text{Pitch} = T_F - T_B \text{Roll} = T_R - T_L \text{Yaw} = \lambda(T_F - T_R + T_B - T_L) Figure 6: A schematic view of a quadrotor showing four rotors labeled Front, Right, Back, and Left. Thrust is the sum of all rotor thrusts. Pitch is the difference between front and back thrust. Roll is the difference between right and left thrust. Yaw is proportional to the sum of the products of rotor speed and its distance from the center of gravity. EXCERPT #7Z5BUD p. 23 Figure 6: A schematic view of a quadrotor. Four rotors are mounted rigidly in a single plane and control is achieved only by varying their speeds. The designation of rotor labels is arbitrary, and the rotational forces of roll, pitch, and yaw are defined relative to them. The thrusts generated by the rotors are denoted by T_F, T_R, T_B and T_L , for the front, right, back, and left rotors, respectively. The relationships between these thrusts and the forces are indicated as the four formulas appearing in the figure near each force. The coefficient \lambda marks the ratio between the vertical thrust of a rotor and the rotational (yaw) force that the rotor generates (neighboring rotors rotate in opposite directions to balance the yaw force when all rotate at the same RPM). EXCERPT #DHCDY2 p. 23 graph TD RPMs["RPMs R thrust , R pitch , R roll , R yaw "] --> Simulation["A simulation of quadrotor, sensor, and actuator dynamics"] Simulation --> Errors["Errors Δ thrust , Δ pitch , Δ roll , Δ yaw "] Errors --> HLC["High-Level Control Low frequency b-node"] HLC --> Forces["Forces F thrust , F pitch , F roll , F yaw "] Forces --> FRPMs["Forces to RPMs High frequency b-node"] FRPMs --> RPMs Figure 7: Block diagram for the quadrotor example. The diagram shows a feedback loop between a simulation, a high-level control block, and a forces-to-RPMs block. The simulation block receives RPMs and outputs errors. The high-level control block receives errors and outputs forces. The forces-to-RPMs block receives forces and outputs RPMs. EXCERPT #62X957 p. 23 Figure 7: Block diagram for the quadrotor example. A controller for the quadrotor is composed of two behavioral components. The first, High-Level Control, takes the differences between actual and desired thrust, pitch, roll and yaw and dynamically translates them into the forces that have to be applied in order to correct the displacements. The second component, Forces to RPMs, translates these forces into the rotor speeds (RPMs) that will generate them. The behavioral program that we developed for this paper consists of the two b-nodes on the bottom, their interaction with the environment, and the communication between them. EXCERPT #D6VEPX p. 23 EXCERPT #VMQDX6 p. 24 Derivative control based on the differences between measurements and desired value, as obtained, e.g, from the remote control or as dictated by a higher level navigation algorithm. EXCERPT #25GC3U p. 24 The b-node ‘Forces to RPMs’ operates at a higher frequency than the ‘High-Level Control’. This component receives the four desired forces as external input events and translates them into rotor RPMs, via a fast coordinated sequence of events, where different b-threads balance the competing needs. For illustration, the reader may compare the action of our b-thread with the way sound-mixing is where a sound engineer deals with competing goals, such as balancing the guitar and the piano, and controlling overall volume by small adjustments of the available controls (without attempting to solve complex mathematical equations). EXCERPT #QTACSX p. 24 In the ‘Forces to RPMs’ b-node, each of the four forces is independently interpreted by a dedicated b-thread as a target, and is translated to desired changes to RPM of the various rotors. The b-threads attempt to attain their targets by requesting events that represent (small) increases or decreases of individual rotor RPM towards the target and, blocking events that work away from it, as shown in Figure 8. The composite behavioral execution mechanism interlaces the execution of all b-threads, transforming their possibly-conflicting requests into integrated control. EXCERPT #QJAA25 p. 24 For example, to increase the pitch (raise the front), the system requests the events of increasing the front rotor’s RPM and decreasing the back rotor’s RPM, while blocking the opposite (complementary) events. Note that desired flight results depend only on the total numbers of events that increase or decrease the controlled value, and the difference between their numbers, while the actual mix of events may vary. Specifically in this example (see Figure 8), in order to allow finer control, the b-threads translate the input force into a sequence of events that affect the rotor speed by smaller increments. Furthermore, to accommodate behaviors that require concurrent actions on multiple rotors, all behaviors entertain a “slack”, in which they allow a small number of undesired events to occur before blocking them completely. In this manner, the ThrustBT can increase the RPM of all rotors equally, one at a time, without interference from b-threads that try to create a difference between certain rotor RPMs. EXCERPT #NDD374 p. 24 In our simulation, the super-step is orchestrated as follows. A lowest-priority b-thread repeatedly waits for RPM-change events, as described above, and keeps track of all desired rotor RPMs by changing in-memory values by fixed amounts. This b-thread repeatedly requests an output event that contains those values, but due to its low priority, output is triggered only when there are no other events to trigger (i.e., the four force-control b-threads have attained their targets). The output event marks the completion of a super-step. Four inputs (target forces) are then presented again (by a high priority b-thread that polls an external queue), marking the beginning of the next super-step. Throughout, an actuator b-thread waits for output events and transmits the required signals to the rotors. The detailed simulations we carried out show that his behavioral solution indeed stabilizes the quadrotor, as can be seen in Figure 9. EXCERPT #KGLCRZ p. 24 Subsequently, we have begun to implement a behavioral programming environment written in C that can run directly on a quadrotor, and have shown that the design and the b-threads shown above indeed can stabilize a UAV. In fact, initial versions of this are already flying in our lab. EXCERPT #NMANGR p. 24 EXCERPT #CNED42 p. 25 graph LR start((start)) -- CMD(delta) --> S1 subgraph States S1([delta > SLACK decr_with_no_slack req=NEG_EVENTS block=POS_EVENTS]) S2([0 ≤ delta < SLACK decr_with_slack req=NEG_EVENTS]) S3([delta < -SLACK incr_with_no_slack req=POS_EVENTS block=NEG_EVENTS]) S4([-SLACK < delta ≤ 0 incr_with_slack req=POS_EVENTS]) end S1 -- "POS_EVENTS : delta := delta + 1" --> S2 S2 -- "NEG_EVENTS : delta := delta - 1" --> S1 S3 -- "POS_EVENTS : delta := delta + 1" --> S4 S4 -- "NEG_EVENTS : delta := delta - 1" --> S3 S1 --> output S2 --> output S3 --> output S4 --> output output --> start Figure 8: A statechart template for yawBT, pitchBT, rollBT, and thrustBT b-threads. The diagram shows a 'start' state leading to a 'CMD(delta)' event. This event branches into four states based on the value of delta relative to SLACK. The top row handles positive delta: 'delta > SLACK' leads to a state requesting POS_EVENTS and blocking NEG_EVENTS, while '0 <= delta < SLACK' leads to a state requesting NEG_EVENTS. The bottom row handles negative delta: 'delta < -SLACK' leads to a state requesting POS_EVENTS and blocking NEG_EVENTS, while '-SLACK < delta <= 0' leads to a state requesting POS_EVENTS. Transitions between these states are labeled with 'POS_EVENTS : delta := delta + 1' and 'NEG_EVENTS : delta := delta - 1'. All four states eventually lead to an 'output' event, which then loops back to the 'start' state. EXCERPT #U53GYL p. 25 Figure 8: A template for the yawBT , pitchBT , rollBT , and thrustBT b-threads, written in a parametric manner. Each b-thread is instantiated with different values of the parameters: CMD(delta) indicates a command to change the force that this b-thread is responsible for (i.e. CMD is ChangeYaw for yawBT , ChangePitch for pitchBT , etc.). POS_EVENTS and NEG_EVENTS are the events that increase and decrease, respectively, this force. For example for pitch (and thus for pitchBT ), POS_EVENTS is {FrontRPMAdd, BackRPMSub} . SLACK defines a range close to the b-thread's target where the b-thread allows the occurrence of events that conflict with its goal to allow for other b-threads to work towards their goals. We use statechart-like notations to allow for a compact and readable diagram. The initial state is start where the b-thread waits for a CMD(delta) event. It then transitions into one of the four other states depending on the sign of the change in force and whether it is within the slack value or not, as marked on the arrows going into the states. If the desired change in force is positive, and its absolute value is larger than SLACK then the b-thread requests the positive events and blocks the negative events. If the desired change is negative, the b-thread requests the events that decrease the force, and blocks the ones that increase it. If the absolute value of delta is smaller than SLACK the same events are requested, but no events are blocked. Once an event occurs, regardless of the state, the transitions on the container state show that the value of delta is modified according to the event, and the b-thread transitions into a new state according to the new conditions. When no events are requested by any of these b-threads an output event requested by another b-thread (not shown) is triggered transferring the actual RPM speeds to actuator b-threads, and all four b-threads in this diagram transition back to their initial state, waiting for the next command. The remaining POS_EVENTS are {RightRPMAdd, LeftRPMSub} for rollBT , {FrontRPMAdd, BackRPMAdd, RightRPMSub, LeftRPMSub} for yawBT , and {FrontRPMAdd, RightRPMAdd, BackRPMAdd, LeftRPMAdd} for the thrustBT . The NEG_EVENTS are the complementary ones. EXCERPT #KL9BD3 p. 25 When proceeding on the actual implementation in a flying quadrotor, additional considerations of course emerge in order to meet the real-time constraints. The first and foremost consideration for BP in this regard is having efficient processing at the underlying BP infrastructure, controlling the synchronization of b-threads, collection of their declarations, event selection, and b-thread resumption. One such approach is to turn events into bits and event sets into easily managed bit vectors. Then come the additional real-time considerations of ensuring that the infrastructure and application allow the non-behavioral sensor and actuator processes to interact with the real world at the desired frequency, and that the b-threads of system behavior are efficient and predictable in completing their reactive scenarios before arrival of the next environment-driven event. For example, towards predictability, in our experimentation on the real quadrotor, we initiate the output event at a fixed time frequency, regardless of whether the b-threads have completed their negotiations over the right changes to all RPM values or not. Both the BP infrastructure optimization and more comprehensive design guidelines regarding real time behavioral applications are the subject of future research and are outside of the scope of the present paper. EXCERPT #KSASBJ p. 25 EXCERPT #SW3L5S p. 26 Figure 9: A 3D plot showing the simulated spatial path of a quadrotor in a coordinate system with X, Y, and Z axes. The Z-axis is vertical, ranging from -1 to 1. The X and Y axes are horizontal, ranging from -1.5 to 1.5. A red line represents the path, starting at the origin, moving up and around in a loop, and then returning towards the origin. Below the 3D plot are three small subplots showing time-series data for roll, pitch, and yaw angles, each with a yellow line on a black background. EXCERPT #YFT4S5 p. 26 Figure 9: Simulated spatial path of the quadrotor, and plots of roll, pitch and yaw during the first 20 seconds of a behaviorally-controlled flight, as generated by the MATLAB model and tools of Bouabdallah et al. [9, 10]. EXCERPT #UGV8G9 p. 26 Summary. In creating composite behavior, the quadrotor application uses very local behaviors, such as controlling roll and pitch, to achieve higher level goals such as maintaining stability. Longer term behaviors, such as traveling between stations in a multi-stop trip, or keeping maintenance and refueling schedules, can be constructed from similar elements. While all these facets can be programmed as compositions of b-threads, gluing them together is easier with an infrastructure that can support multiple time scales. Clearly, a b-thread that controls a multi-stop navigation itinerary can suffice with occasional changing of the required speed and direction, and does not require the constant synchronization and attentiveness of the stabilization modules described above. EXCERPT #QEVT6P p. 26 EXCERPT #BC76P3 p. 27 The quadrotor application also shows how behavioral programming can be used in developing hybrid control, i.e., a combination of discrete logic and actuation with the sensing of continuous system variables [36]. In [26] we discuss the application of BP to hybrid control, by using fuzzy logic to translate continuous information into discrete categories that can be refereed to in naturally-programmed scenarios. ### 9. Assistant Harel and colleagues’ **BP quadrotor controller** is a demonstration that **behavioral programming (BP)** can coordinate continuous, real-time control using modular scenario-like processes called **b-threads**. ### Architecture The controller has two feedback layers: 1. **High-Level Control — slower loop** Sensor errors in altitude/thrust, pitch, roll, and yaw are handled by four separate b-threads. Each applies conventional PID-style control to compute the desired forces for its axis (#EA8UHB, #VMQDX6). 2. **Forces-to-RPMs — faster loop** Four further b-threads—`thrustBT`, `pitchBT`, `rollBT`, and `yawBT`—translate those desired forces into small rotor-speed changes (#25GC3U, #QTACSX). Rather than directly solving a motor-mixing equation, each b-thread: - **requests** RPM-change events that advance its objective; - **blocks** events that strongly oppose it; - observes the event selected by the BP engine; and - updates its remaining error. For example, increasing pitch means requesting an increase in the front rotor’s RPM or a decrease in the back rotor’s RPM, while potentially blocking the reverse changes (#QJAA25). ### How competing controls compose The interesting part is that all four control objectives operate on the same motors. BP resolves this by interleaving their requested events. A configurable **slack region** prevents a b-thread near its target from blocking every temporarily undesirable adjustment. This lets, for example, thrust raise all four rotor speeds while pitch and roll preserve the necessary differences between them (#U53GYL). A low-priority b-thread accumulates the selected incremental changes. When the force-control threads have no higher-priority adjustment left to request, an output event sends the resulting four RPM values to the actuators; this completes one control “super-step” (#NDD374). ### Why it matters The experiment shows three things: - local, independently written behaviors can compose into aircraft stabilization; - BP can coordinate modules operating at different time scales; - discrete event negotiation can participate in a hybrid continuous-control system (#UGV8G9, #BC76P3). It was tested first using Java BP modules connected to a MATLAB/Simulink quadrotor model (#MMS288). The authors later implemented a C runtime on an actual quadrotor and reported successful stabilization and laboratory flights (#KGLCRZ). The main caveat is **hard real-time predictability**: event synchronization and negotiation must finish before the next actuator deadline. On the physical vehicle, they therefore emitted RPM outputs at a fixed frequency even if negotiation had not fully converged, and suggested bit-vector event representations to reduce runtime overhead (#KL9BD3). Thus, it is best understood as a compelling modular-control prototype rather than a fully developed replacement for conventional flight-control architectures. ### 10. User I'm interested in behavioral programming. I have my own sketches on co-routine-based behavioral programming in C++ and stuff like that. I'm interested in thinking about behavioral thread composition for a computer game where you have different vehicles. Probably also there will be different simulated critters and stuff like that. ### 11. Assistant tool calls #### Tool call: `search_text` ```json { "limit": 10, "query": "coroutine behavioral programming C++ vehicles critters game" } ``` #### Tool call: `search_text` ```json { "limit": 10, "query": "vehicle behavioral threads game simulation agents composition" } ``` #### Tool call: `list_notes` ```json {} ``` ### 12. Tool result: search_text Exact matches 1. Source: Distributing Scenario-Based Models: A Replicate-and-Project Approach (#D4VB7S), Assaf Marron, Daniel Gritzner, David Harel, Guy Katz, Joel Greenyer, Shlomi Steinberg, p. 3 Context: #D8TLPF Distributing Scenario-Based Models: A Replicate-and-Project Approach #WG2KDF 2 BACKGROUND: SCENARIO-BASED MODELING Matching excerpt #4X2KSF: The BP definitions above are abstract, and make it easier to reason about behavioral models. However, for practical purposes, the BP modeling principles have been integrated into a variety of high-level languages such as Java, C++, Erlang and Javascript (see the BP website at http://www.b-prog.org/ ). These frameworks allow engineers to integrate reactive scenarios into their favorite programming or modeling environments. Further, the same principles as underly BP, play a significant role in several popular modeling frameworks such as publish-subscribe architectures (Eugster et al., 2003) and supervisory control (Ramadge and Wonham, 1987). 2. Source: Towards Behavioral Programming in Distributed Architectures (#M5788P), Amir Kantor, Assaf Marron, David Harel, Gera Weiss, Guy Katz, Guy Wiener, p. 18 Context: #GVFU8Q Towards Behavioral Programming in Distributed Architectures1 #QTR76K 3. Application Designs for Dealing with Asynchrony and Different Time Scales #CLFMN2 3.4. Example 1: Synchronizing with an external environment #MRXATE 3.4.1. Game architecture Matching excerpt #LJB78C: We implemented this game in Erlang, using WxErlang as the GUI toolkit, and the bp module as the behavioral programming library. The application consists of the following processes: 3. Source: Towards Behavioral Programming in Distributed Architectures (#M5788P), Amir Kantor, Assaf Marron, David Harel, Gera Weiss, Guy Katz, Guy Wiener, p. 24 Context: #GVFU8Q Towards Behavioral Programming in Distributed Architectures1 #QTR76K 3. Application Designs for Dealing with Asynchrony and Different Time Scales #Z5FCGK 3.5. Example 2: Coordinating behaviors with different time scales Matching excerpt #KGLCRZ: Subsequently, we have begun to implement a behavioral programming environment written in C that can run directly on a quadrotor, and have shown that the design and the b-threads shown above indeed can stabilize a UAV. In fact, initial versions of this are already flying in our lab. 4. Source: Towards Behavioral Programming in Distributed Architectures (#M5788P), Amir Kantor, Assaf Marron, David Harel, Gera Weiss, Guy Katz, Guy Wiener, p. 41 Context: #GVFU8Q Towards Behavioral Programming in Distributed Architectures1 #LCVWTC 6. Positioning BP relative to Mainstream Actor and Agent Programming Matching excerpt #ASLM6V: In [32], Alan Kay highlights the naturalness of programming with rules. Behavioral programming is often reminiscent of rule-based systems but it extends the concept by allowing the ability to easily monitor, and react to, entire scenarios without requiring complex state management in the rules. Furthermore, in BP, event-blocking facilitates expressiveness and behavioral composition. 5. Source: Towards Behavioral Programming in Distributed Architectures (#M5788P), Amir Kantor, Assaf Marron, David Harel, Gera Weiss, Guy Katz, Guy Wiener, p. 28 Context: #GVFU8Q Towards Behavioral Programming in Distributed Architectures1 #QTR76K 3. Application Designs for Dealing with Asynchrony and Different Time Scales #G485QR 3.6. Example 3: Incremental development of a multi-agent application #JGN5SS 3.6.3. Adding an advisor agent Matching excerpt #S6XUMZ: We are now ready to add advisors that will monitor and try to affect the movement of several vehicles. For example, the following behaviors first report when a vehicle crosses a line, and later ask vehicles positioned at the line to stall if there are more than N vehicles north of the line. The first advisor b-thread, monitor_line , deals only with behavioral events. It waits for any vehicle position event, and requests an event, internal to the advisor, that will eventually lead to inter-agent messages. 6. Source: Towards Behavioral Programming in Distributed Architectures (#M5788P), Amir Kantor, Assaf Marron, David Harel, Gera Weiss, Guy Katz, Guy Wiener, p. 15 Context: #GVFU8Q Towards Behavioral Programming in Distributed Architectures1 #QTR76K 3. Application Designs for Dealing with Asynchrony and Different Time Scales #BE7ZJF 3.2. Handling external events Matching excerpt #QSEJNZ: This solution is implemented by the BP infrastructure, assuming only that the application complies with simple rules, without application-specific programming. Specifically, we propose that behavioral program execution be divided into cycles, called super-steps , and external events are introduced only at the beginning of a super-step. The philosophy is that all internal events in the body of a super-step are perceived as happening in the same physical time unit but they are nevertheless ordered; i.e., there is a sequence of events (not associated with meaningful time-stamps) between the beginning and end of each super-step (c.f. hybrid time-set [37]). Thus, they are viewed as all taking place in zero time. 7. Source: Relaxing Synchronization Constraints in Behavioral Programs (#TDS4H2), Amir Kantor, David Harel, Guy Katz, p. 2 Context: #KBEBVQ Relaxing Synchronization Constraints in Behavioral Programs #YZJE2D 2 Behavioral Programming Matching excerpt #7WKGLC: Various implementations of reactive systems as behavioral programs have been carried out, using frameworks built on top of high-level programming languages such as Java, Erlang and Blockly; see [10] and references therein. These frameworks allow the user to use the full flexibility offered by the underlying programming language in writing threads. In this paper, we demonstrate our techniques using a BP framework in C ++ , termed BPC [1]. 8. Source: Relaxing Synchronization Constraints in Behavioral Programs (#TDS4H2), Amir Kantor, David Harel, Guy Katz, p. 12 Context: #KBEBVQ Relaxing Synchronization Constraints in Behavioral Programs #97ZMXK 4 Modularity by Eager Execution #WC7Z5Z 4.1 Example: A Modular Design Matching excerpt #XJFQYS: Using eager execution, this multi-component system can be programmed entirely within the behavioral programming framework, without relying on external means of communication. The threads of each vehicle, v_i , form an independent behavioral module M_i that involves a designated set of events. This results in a strict modular design allowing each vehicle to operate independently of others. A code snippet for the main thread of vehicle v_i is depicted in Fig. 7. If each module has a dedicated processor and event selection is fair, all vehicles are constantly moving — as the coordinator does not wait for vehicle v_i to finish moving and synchronize again before triggering the movement requested by another vehicle. 9. Source: Relaxing Synchronization Constraints in Behavioral Programs (#TDS4H2), Amir Kantor, David Harel, Guy Katz, p. 0 Context: #KBEBVQ Relaxing Synchronization Constraints in Behavioral Programs Matching excerpt #9H9YU2: Abstract. In behavioral programming , a program consists of separate modules called behavior threads , each representing a part of the system's allowed, necessary or forbidden behavior. An execution of the program is a series of synchronizations between these threads, where at each synchronization point an event is selected to be carried out. As a result, the execution speed is dictated by the slowest thread. We propose an eager execution mechanism for such programs, which builds upon the realization that it is often possible to predict the outcome of a synchronization point even without waiting for slower threads to synchronize. This allows faster threads to continue running uninterrupted, whereas slower ones catch up at a later time. Consequently, eager execution brings about increased system performance, better support for the modular design of programs, and the ability to distribute programs across several machines. It also allows to apply behavioral programming to a variety of problems that were previously outside its scope. We illustrate the method by concrete examples, implemented in a behavioral programming framework in C ++ . 10. Source: Relaxing Synchronization Constraints in Behavioral Programs (#TDS4H2), Amir Kantor, David Harel, Guy Katz, p. 0 Context: #KBEBVQ Relaxing Synchronization Constraints in Behavioral Programs Matching excerpt #LKAPEV: Keywords: behavioral programming; synchronization; eager execution; modular design; distributed design. Approximate matches 1. Source: Distributing Scenario-Based Models: A Replicate-and-Project Approach (#D4VB7S), Assaf Marron, Daniel Gritzner, David Harel, Guy Katz, Joel Greenyer, Shlomi Steinberg, p. 8 Context: #D8TLPF Distributing Scenario-Based Models: A Replicate-and-Project Approach #QYXPCQ 5 EXAMPLE AND EVALUATION Score: 0.024 Related excerpt #3XFLDD: Our example is a slightly richer scenario, coded as a behavioral program written in C++. The four drones (labeled Drone0 through Drone3) participate in “a green wave”, starting with Drone0. After the i=0 ; 2. Source: Towards Behavioral Programming in Distributed Architectures (#M5788P), Amir Kantor, Assaf Marron, David Harel, Gera Weiss, Guy Katz, Guy Wiener, p. 28 Context: #GVFU8Q Towards Behavioral Programming in Distributed Architectures1 #QTR76K 3. Application Designs for Dealing with Asynchrony and Different Time Scales #G485QR 3.6. Example 3: Incremental development of a multi-agent application #LG3ZE2 3.6.2. Enabling external communication Score: 0.03 Related excerpt #G2UHNR: The behaviors listed above will cause the vehicle to move towards its goal uninterrupted. We would like to allow an external coordinator agent to affect this movement, but, unlike the game and quadrotor examples, here there is no natural super-step breakpoint within the internal events where the external environment can intervene. To modify the vehicle software for creating such a breakpoint we add two b-threads. One counts N_1 advancement steps of the vehicle and then sends an external event containing the current position of the vehicle to an external process. 3. Source: Towards Behavioral Programming in Distributed Architectures (#M5788P), Amir Kantor, Assaf Marron, David Harel, Gera Weiss, Guy Katz, Guy Wiener, p. 18 Context: #GVFU8Q Towards Behavioral Programming in Distributed Architectures1 #QTR76K 3. Application Designs for Dealing with Asynchrony and Different Time Scales #CLFMN2 3.4. Example 1: Synchronizing with an external environment Score: 0.025 Related excerpt #TL9MNY: To demonstrate how a behavioral program handles external events, we describe the architecture and implementation of a modest computer game. Specifically, we decompose the game into separate, independently programmed behaviors (all in a single b-node), and show how external events are introduced at the end of super-steps. 4. Source: Towards Behavioral Programming in Distributed Architectures (#M5788P), Amir Kantor, Assaf Marron, David Harel, Gera Weiss, Guy Katz, Guy Wiener, p. 28 Context: #GVFU8Q Towards Behavioral Programming in Distributed Architectures1 #QTR76K 3. Application Designs for Dealing with Asynchrony and Different Time Scales #G485QR 3.6. Example 3: Incremental development of a multi-agent application #JGN5SS 3.6.3. Adding an advisor agent Score: 0.024 Related excerpt #S6XUMZ: We are now ready to add advisors that will monitor and try to affect the movement of several vehicles. For example, the following behaviors first report when a vehicle crosses a line, and later ask vehicles positioned at the line to stall if there are more than N vehicles north of the line. The first advisor b-thread, monitor_line , deals only with behavioral events. It waits for any vehicle position event, and requests an event, internal to the advisor, that will eventually lead to inter-agent messages. 5. Source: Towards Behavioral Programming in Distributed Architectures (#M5788P), Amir Kantor, Assaf Marron, David Harel, Gera Weiss, Guy Katz, Guy Wiener, p. 28 Context: #GVFU8Q Towards Behavioral Programming in Distributed Architectures1 #QTR76K 3. Application Designs for Dealing with Asynchrony and Different Time Scales #G485QR 3.6. Example 3: Incremental development of a multi-agent application #LG3ZE2 3.6.2. Enabling external communication Score: 0.023 Related excerpt #Q9938K: To demonstrate a possible external command, we assume that advisors may warn the vehicle, upon arriving at a certain line in its northward path, that there are too many vehicles beyond that line. To allow the vehicle to react, we add a new b-thread to the vehicle b-node. If the vehicle crossed the line, it calls the hold function. 6. Source: Relaxing Synchronization Constraints in Behavioral Programs (#TDS4H2), Amir Kantor, David Harel, Guy Katz, p. 12 Context: #KBEBVQ Relaxing Synchronization Constraints in Behavioral Programs #97ZMXK 4 Modularity by Eager Execution #WC7Z5Z 4.1 Example: A Modular Design Score: 0.029 Related excerpt #XJFQYS: Using eager execution, this multi-component system can be programmed entirely within the behavioral programming framework, without relying on external means of communication. The threads of each vehicle, v_i , form an independent behavioral module M_i that involves a designated set of events. This results in a strict modular design allowing each vehicle to operate independently of others. A code snippet for the main thread of vehicle v_i is depicted in Fig. 7. If each module has a dedicated processor and event selection is fair, all vehicles are constantly moving — as the coordinator does not wait for vehicle v_i to finish moving and synchronize again before triggering the movement requested by another vehicle. 7. Source: Relaxing Synchronization Constraints in Behavioral Programs (#TDS4H2), Amir Kantor, David Harel, Guy Katz, p. 12 Context: #KBEBVQ Relaxing Synchronization Constraints in Behavioral Programs #97ZMXK 4 Modularity by Eager Execution #WC7Z5Z 4.1 Example: A Modular Design Score: 0.027 Related excerpt #CEAKBY: We implement the traveling vehicles example from [11, Section 7]. The example includes several vehicles, each operating as an autonomous component traveling on pre-given cyclic route along an (x, y) grid; in each given time unit during the run, each vehicle can travel north, east, south or west. We assume that all vehicles travel at identical speeds, i.e., cover one unit of distance per time unit. 8. Source: Relaxing Synchronization Constraints in Behavioral Programs (#TDS4H2), Amir Kantor, David Harel, Guy Katz, p. 12 Context: #KBEBVQ Relaxing Synchronization Constraints in Behavioral Programs #97ZMXK 4 Modularity by Eager Execution #WC7Z5Z 4.1 Example: A Modular Design Score: 0.025 Related excerpt #UPJHJT: Eager execution allows a light-weight solution if communication between the vehicles is required — e.g., for collision prevention. Each vehicle can be accompanied by an adviser thread that keeps track of other vehicles. Whenever its vehicle is dangerously close to another, the adviser blocks movement in the dangerous direction (for simplicity, deadlocks are ignored). As the modular design remains strict, adding the adviser threads does not impede the vehicles' ability to move independently. 9. Source: Relaxing Synchronization Constraints in Behavioral Programs (#TDS4H2), Amir Kantor, David Harel, Guy Katz, p. 2 Context: #KBEBVQ Relaxing Synchronization Constraints in Behavioral Programs #YZJE2D 2 Behavioral Programming #KWNH5E 2.1 Behavioral Programming Formalized Score: 0.023 Related excerpt #ZPB38G: While behavioral programming is geared toward natural and intuitive development using programming languages, its underlying infrastructure can be conveniently class Dispenser : public BThread { void entryPoint() { while ( true ) { bSync( none, {CoinInserted}, none ); bSync( none, {ProductChosen}, {CoinInserted} ); bSync( {ProvideProduct}, none, {CoinInserted} ); } } }; 10. Source: Relaxing Synchronization Constraints in Behavioral Programs (#TDS4H2), Amir Kantor, David Harel, Guy Katz, p. 12 Context: #KBEBVQ Relaxing Synchronization Constraints in Behavioral Programs #97ZMXK 4 Modularity by Eager Execution #WC7Z5Z 4.1 Example: A Modular Design Score: 0.022 Related excerpt #A25NFW: while ( true ) { Vector requestedEvents; if ( destinationIsNorth() ) requestedEvents.append( #iMoveNorth ); if ( destinationIsSouth() ) requestedEvents.append( #iMoveSouth ); if ( destinationIsEast() ) requestedEvents.append( #iMoveEast ); if ( destinationIsWest() ) requestedEvents.append( #iMoveWest ); bSync( requestedEvents, none, none ); adjustPositionByLastEvent(); } ### 13. Tool result: search_text Exact matches 1. Source: Procedural Content Generation through Quality Diversity (#7GR3AQ), Ahmed Khalifa, Antonios Liapis, Daniele Gravina, Georgios N. Yannakakis, Julian Togelius, p. 6 Context: #DZ9GFC Procedural Content Generation through Quality Diversity #W6TBRK IV. CASES OF QUALITY DIVERSITY IN PCG #FT7DW7 J. Discussion Matching excerpt #QNJLDU: especially important for agents playing in collaborative games, as we might need a group of agents that are different from each other and at the same time compatible. For instance, MAP-Elites was used to generate a diverse set of high quality agents [48] that play the game Hanabi (Antoine Bauza, 2010). Another use for high-quality diverse agents is for testing generated content with different play styles [49]. This can help debug the game to see if the current content is experienced in a similar manner as intended. 2. Source: Towards Behavioral Programming in Distributed Architectures (#M5788P), Amir Kantor, Assaf Marron, David Harel, Gera Weiss, Guy Katz, Guy Wiener, p. 53 Context: #GVFU8Q Towards Behavioral Programming in Distributed Architectures1 #TQXT4D Appendix E. The Distributed Execution Mechanism Matching excerpt #6GD6WM: In order to have behavioral modules executed in a decentralized manner on different machines, we distribute the coordinator, so that each machine runs its own coordinator agent . These agents serve as the coordinators for their local threads, i.e., threads running on the local machine, but have no direct access to threads on other machines. Instead, they can communicate with other agents. 3. Source: Towards Behavioral Programming in Distributed Architectures (#M5788P), Amir Kantor, Assaf Marron, David Harel, Gera Weiss, Guy Katz, Guy Wiener, p. 28 Context: #GVFU8Q Towards Behavioral Programming in Distributed Architectures1 #QTR76K 3. Application Designs for Dealing with Asynchrony and Different Time Scales #G485QR 3.6. Example 3: Incremental development of a multi-agent application #LG3ZE2 3.6.2. Enabling external communication Matching excerpt #G2UHNR: The behaviors listed above will cause the vehicle to move towards its goal uninterrupted. We would like to allow an external coordinator agent to affect this movement, but, unlike the game and quadrotor examples, here there is no natural super-step breakpoint within the internal events where the external environment can intervene. To modify the vehicle software for creating such a breakpoint we add two b-threads. One counts N_1 advancement steps of the vehicle and then sends an external event containing the current position of the vehicle to an external process. 4. Source: Towards Behavioral Programming in Distributed Architectures (#M5788P), Amir Kantor, Assaf Marron, David Harel, Gera Weiss, Guy Katz, Guy Wiener, p. 27 Context: #GVFU8Q Towards Behavioral Programming in Distributed Architectures1 #QTR76K 3. Application Designs for Dealing with Asynchrony and Different Time Scales #G485QR 3.6. Example 3: Incremental development of a multi-agent application Matching excerpt #JL2FWF: We present the development of a multi-agent application, where agents include vehicles traveling in open terrain and advisors affecting the vehicles. First, we list the behaviors that are responsible for the movement of a vehicle. To each vehicle we then add behaviors that allow it to interact with external systems. Finally, again incrementally, we program the vehicle agents to react to an advisor agent responsible for directing particular aspects of the vehicles' travel. The communication between the vehicles and the advisor uses the architecture for external events described in Section 3.2. This small example can be readily extended to make it easily possible to add agents (vehicles, advisors), as well as new kinds of interactions among existing agents (inter-vehicle or inter-advisor). 5. Source: Towards Behavioral Programming in Distributed Architectures (#M5788P), Amir Kantor, Assaf Marron, David Harel, Gera Weiss, Guy Katz, Guy Wiener, p. 22 Context: #GVFU8Q Towards Behavioral Programming in Distributed Architectures1 #QTR76K 3. Application Designs for Dealing with Asynchrony and Different Time Scales #Z5FCGK 3.5. Example 2: Coordinating behaviors with different time scales Matching excerpt #MMS288: In this section we demonstrate how an application can be composed of behavioral components, namely b-nodes, that operate on different time scales and communicate via events. The example is part of the control software for a quadrotor, a flying vehicle powered by four rotors (see schematic drawing in Figure 6). The behaviorally-programmed piece is responsible for stabilizing the aircraft. It was experimentally tested by plugging behavioral modules written in Java into the comprehensive quadrotor-control simulation model developed by Bouabdallah et al. [9, 10]. This model is based on MATLAB/Simulink and simulates full control of the quadrotor flight including physical aspects. A high-level description of this use-case appeared also in [27]. 6. Source: Towards Behavioral Programming in Distributed Architectures (#M5788P), Amir Kantor, Assaf Marron, David Harel, Gera Weiss, Guy Katz, Guy Wiener, p. 56 Context: #GVFU8Q Towards Behavioral Programming in Distributed Architectures1 #TQXT4D Appendix E. The Distributed Execution Mechanism #Z8LGTU Appendix E.1. Distributed Execution Formalized Matching excerpt #SCRPND: Observe that each coordinator agent uses information regarding the transition functions (lines 8 and 14) and synchronization requests (line 18) of all the threads in the system — both threads that run locally on that agent, and threads that run on other agents. This information is given prior to the run, in the form of the state graphs of all the threads in the system. 7. Source: Towards Behavioral Programming in Distributed Architectures (#M5788P), Amir Kantor, Assaf Marron, David Harel, Gera Weiss, Guy Katz, Guy Wiener, p. 49 Context: #GVFU8Q Towards Behavioral Programming in Distributed Architectures1 #9XXUP6 Appendix C. Nondeterministic Threads Matching excerpt #E7XLPY: The semantics of behavioral programs with nondeterministic threads are naturally defined as follows. Let P = \{BT^1, \dots, BT^n\} be a behavioral program, possibly with nondeterministic threads. We construct a labeled transition system LTS(P) = \langle Q, q_0, \delta \rangle , where 8. Source: Towards Behavioral Programming in Distributed Architectures (#M5788P), Amir Kantor, Assaf Marron, David Harel, Gera Weiss, Guy Katz, Guy Wiener, p. 41 Context: #GVFU8Q Towards Behavioral Programming in Distributed Architectures1 #LCVWTC 6. Positioning BP relative to Mainstream Actor and Agent Programming Matching excerpt #ZGP8UY: BP principles have already been implemented in several environments and languages. It would be interesting to explore the synergy between BP and agent-oriented-specific languages, such as AgentSpeak and Jason [7], 2APL [15], GOAL [29], SIMPA [41], Indigolog [8], JIAC [8], and Axum [1]. Such synergy could emerge from interfacing agents and behavioral programs, from turning b-nodes into agents and using agent programming languages to handle communication between behavioral nodes, or from introducing blocking idioms into agent-oriented languages. 9. Source: Relaxing Synchronization Constraints in Behavioral Programs (#TDS4H2), Amir Kantor, David Harel, Guy Katz, p. 12 Context: #KBEBVQ Relaxing Synchronization Constraints in Behavioral Programs #97ZMXK 4 Modularity by Eager Execution #WC7Z5Z 4.1 Example: A Modular Design Matching excerpt #XJFQYS: Using eager execution, this multi-component system can be programmed entirely within the behavioral programming framework, without relying on external means of communication. The threads of each vehicle, v_i , form an independent behavioral module M_i that involves a designated set of events. This results in a strict modular design allowing each vehicle to operate independently of others. A code snippet for the main thread of vehicle v_i is depicted in Fig. 7. If each module has a dedicated processor and event selection is fair, all vehicles are constantly moving — as the coordinator does not wait for vehicle v_i to finish moving and synchronize again before triggering the movement requested by another vehicle. 10. Source: Runtime Evaluation of Procedural Content Generation in an Endless Runner Game Using Autonomous Agents (#WZ8DHP), Rishabh Kar, p. 3 Context: #MDEACB Runtime Evaluation of Procedural Content Generation in an Endless Runner Game Using Autonomous Agents #E3MLLW 2 Background and Related Work #LMEKZ5 2.4 Evaluation Mechanisms for Procedural Content Matching excerpt #R76CML: For this project, the focus is on runtime evaluation using automated agents. The reason for this is that the game content is created dynamically while the player is moving, so the evaluation also needs to happen during execution. The agents move ahead of the player and check whether the generated path remains technically playable. This makes the evaluation mechanism part of the game loop rather than a separate post-processing step. Approximate matches 1. Source: Towards Behavioral Programming in Distributed Architectures (#M5788P), Amir Kantor, Assaf Marron, David Harel, Gera Weiss, Guy Katz, Guy Wiener, p. 27 Context: #GVFU8Q Towards Behavioral Programming in Distributed Architectures1 #QTR76K 3. Application Designs for Dealing with Asynchrony and Different Time Scales #G485QR 3.6. Example 3: Incremental development of a multi-agent application Score: 0.03 Related excerpt #JL2FWF: We present the development of a multi-agent application, where agents include vehicles traveling in open terrain and advisors affecting the vehicles. First, we list the behaviors that are responsible for the movement of a vehicle. To each vehicle we then add behaviors that allow it to interact with external systems. Finally, again incrementally, we program the vehicle agents to react to an advisor agent responsible for directing particular aspects of the vehicles' travel. The communication between the vehicles and the advisor uses the architecture for external events described in Section 3.2. This small example can be readily extended to make it easily possible to add agents (vehicles, advisors), as well as new kinds of interactions among existing agents (inter-vehicle or inter-advisor). 2. Source: Towards Behavioral Programming in Distributed Architectures (#M5788P), Amir Kantor, Assaf Marron, David Harel, Gera Weiss, Guy Katz, Guy Wiener, p. 28 Context: #GVFU8Q Towards Behavioral Programming in Distributed Architectures1 #QTR76K 3. Application Designs for Dealing with Asynchrony and Different Time Scales #G485QR 3.6. Example 3: Incremental development of a multi-agent application #LG3ZE2 3.6.2. Enabling external communication Score: 0.029 Related excerpt #G2UHNR: The behaviors listed above will cause the vehicle to move towards its goal uninterrupted. We would like to allow an external coordinator agent to affect this movement, but, unlike the game and quadrotor examples, here there is no natural super-step breakpoint within the internal events where the external environment can intervene. To modify the vehicle software for creating such a breakpoint we add two b-threads. One counts N_1 advancement steps of the vehicle and then sends an external event containing the current position of the vehicle to an external process. 3. Source: Towards Behavioral Programming in Distributed Architectures (#M5788P), Amir Kantor, Assaf Marron, David Harel, Gera Weiss, Guy Katz, Guy Wiener, p. 28 Context: #GVFU8Q Towards Behavioral Programming in Distributed Architectures1 #QTR76K 3. Application Designs for Dealing with Asynchrony and Different Time Scales #G485QR 3.6. Example 3: Incremental development of a multi-agent application #JGN5SS 3.6.3. Adding an advisor agent Score: 0.028 Related excerpt #S6XUMZ: We are now ready to add advisors that will monitor and try to affect the movement of several vehicles. For example, the following behaviors first report when a vehicle crosses a line, and later ask vehicles positioned at the line to stall if there are more than N vehicles north of the line. The first advisor b-thread, monitor_line , deals only with behavioral events. It waits for any vehicle position event, and requests an event, internal to the advisor, that will eventually lead to inter-agent messages. 4. Source: Towards Behavioral Programming in Distributed Architectures (#M5788P), Amir Kantor, Assaf Marron, David Harel, Gera Weiss, Guy Katz, Guy Wiener, p. 26 Context: #GVFU8Q Towards Behavioral Programming in Distributed Architectures1 #QTR76K 3. Application Designs for Dealing with Asynchrony and Different Time Scales #Z5FCGK 3.5. Example 2: Coordinating behaviors with different time scales Score: 0.025 Related excerpt #UGV8G9: Summary. In creating composite behavior, the quadrotor application uses very local behaviors, such as controlling roll and pitch, to achieve higher level goals such as maintaining stability. Longer term behaviors, such as traveling between stations in a multi-stop trip, or keeping maintenance and refueling schedules, can be constructed from similar elements. While all these facets can be programmed as compositions of b-threads, gluing them together is easier with an infrastructure that can support multiple time scales. Clearly, a b-thread that controls a multi-stop navigation itinerary can suffice with occasional changing of the required speed and direction, and does not require the constant synchronization and attentiveness of the stabilization modules described above. 5. Source: Towards Behavioral Programming in Distributed Architectures (#M5788P), Amir Kantor, Assaf Marron, David Harel, Gera Weiss, Guy Katz, Guy Wiener, p. 18 Context: #GVFU8Q Towards Behavioral Programming in Distributed Architectures1 #QTR76K 3. Application Designs for Dealing with Asynchrony and Different Time Scales #CLFMN2 3.4. Example 1: Synchronizing with an external environment Score: 0.024 Related excerpt #TL9MNY: To demonstrate how a behavioral program handles external events, we describe the architecture and implementation of a modest computer game. Specifically, we decompose the game into separate, independently programmed behaviors (all in a single b-node), and show how external events are introduced at the end of super-steps. 6. Source: Towards Behavioral Programming in Distributed Architectures (#M5788P), Amir Kantor, Assaf Marron, David Harel, Gera Weiss, Guy Katz, Guy Wiener, p. 22 Context: #GVFU8Q Towards Behavioral Programming in Distributed Architectures1 #QTR76K 3. Application Designs for Dealing with Asynchrony and Different Time Scales #CLFMN2 3.4. Example 1: Synchronizing with an external environment #VZ34LB 3.4.2. Game behaviors Score: 0.022 Related excerpt #LDVN2Y: For simplicity, this example is implemented in a single b-node. In a richer game, components like the rocket and the pad could be programmed in separate b-nodes. Nevertheless, note that some of the game rules do require synchrony between different behaviors with regard to time ticks, and this was readily implemented in the single b-node setup. 7. Source: Towards Behavioral Programming in Distributed Architectures (#M5788P), Amir Kantor, Assaf Marron, David Harel, Gera Weiss, Guy Katz, Guy Wiener, p. 22 Context: #GVFU8Q Towards Behavioral Programming in Distributed Architectures1 #QTR76K 3. Application Designs for Dealing with Asynchrony and Different Time Scales #Z5FCGK 3.5. Example 2: Coordinating behaviors with different time scales Score: 0.021 Related excerpt #MMS288: In this section we demonstrate how an application can be composed of behavioral components, namely b-nodes, that operate on different time scales and communicate via events. The example is part of the control software for a quadrotor, a flying vehicle powered by four rotors (see schematic drawing in Figure 6). The behaviorally-programmed piece is responsible for stabilizing the aircraft. It was experimentally tested by plugging behavioral modules written in Java into the comprehensive quadrotor-control simulation model developed by Bouabdallah et al. [9, 10]. This model is based on MATLAB/Simulink and simulates full control of the quadrotor flight including physical aspects. A high-level description of this use-case appeared also in [27]. 8. Source: Relaxing Synchronization Constraints in Behavioral Programs (#TDS4H2), Amir Kantor, David Harel, Guy Katz, p. 12 Context: #KBEBVQ Relaxing Synchronization Constraints in Behavioral Programs #97ZMXK 4 Modularity by Eager Execution #WC7Z5Z 4.1 Example: A Modular Design Score: 0.029 Related excerpt #XJFQYS: Using eager execution, this multi-component system can be programmed entirely within the behavioral programming framework, without relying on external means of communication. The threads of each vehicle, v_i , form an independent behavioral module M_i that involves a designated set of events. This results in a strict modular design allowing each vehicle to operate independently of others. A code snippet for the main thread of vehicle v_i is depicted in Fig. 7. If each module has a dedicated processor and event selection is fair, all vehicles are constantly moving — as the coordinator does not wait for vehicle v_i to finish moving and synchronize again before triggering the movement requested by another vehicle. 9. Source: Relaxing Synchronization Constraints in Behavioral Programs (#TDS4H2), Amir Kantor, David Harel, Guy Katz, p. 12 Context: #KBEBVQ Relaxing Synchronization Constraints in Behavioral Programs #97ZMXK 4 Modularity by Eager Execution #WC7Z5Z 4.1 Example: A Modular Design Score: 0.026 Related excerpt #UPJHJT: Eager execution allows a light-weight solution if communication between the vehicles is required — e.g., for collision prevention. Each vehicle can be accompanied by an adviser thread that keeps track of other vehicles. Whenever its vehicle is dangerously close to another, the adviser blocks movement in the dangerous direction (for simplicity, deadlocks are ignored). As the modular design remains strict, adding the adviser threads does not impede the vehicles' ability to move independently. 10. Source: Runtime Evaluation of Procedural Content Generation in an Endless Runner Game Using Autonomous Agents (#WZ8DHP), Rishabh Kar, p. 6 Context: #MDEACB Runtime Evaluation of Procedural Content Generation in an Endless Runner Game Using Autonomous Agents #GL8ZA2 4 Design, Methodology, and Implementation #A85PVT 4.1 System Architecture Score: 0.02 Related excerpt #C9BNCY: The evaluation side of the architecture is implemented through autonomous agents. The aerial agent moves ahead of the player and scans the generated corridor from above, while the ground agent validates the same region through the runtime navigation surface. Both agents are supported by ray casting, volumetric physics checks, and obstacle-layer filtering. When a blocked or unsolvable section is detected, the relevant data is forwarded to the blockage reporting subsystem. ### 14. Tool result: list_notes RESEARCH NOTES #QLR9JX PDF import batch: all 5 imported and validated Published: 2026-07-24T18:21:24Z Mentions: #67REFX, #7ESDBJ, #8C28Q3, #AULNWD, #BEVDM5, #F6P4LS, #NBH3BE, #WYH36B, #Z2YATG All five PDFs are now imported and validated. Economics, Accounting, and Property Theory (#7ESDBJ, source #8C28Q3) and Algebraic Models for Accounting Systems (#NBH3BE, source #F6P4LS) were resumed from the preserved Datalab outputs in runs #Z2YATG and #BEVDM5 after fixing Quadlog large-transaction performance, atomic PDF metadata writes, and retry idempotence. Seven orphan graphs created by timed-out Economics retries were removed after backup. Search and embeddings were rebuilt successfully with zero embedding errors. The three earlier imports remain #WYH36B, #67REFX, and #AULNWD. #CSFA49 Drainage-aligned coordinates as a river-rendering parameterization Published: 2026-07-14T17:20:28Z Mentions: #KNWKGF, #M78ELM, #QGGCCR, #W32P5Z, #YTDJGS A coordinate transform that approximately straightens major rivers could double as a flow-aligned shader/UV parameterization. Treat one coordinate as downstream arc length and the other as signed cross-channel distance. This would simplify streaming normal/foam textures, procedural displacement, bank masks, width profiles, anisotropic highlights, and river-specific LOD. Existing river rendering supports the idea: arc length along a Bézier river is used for streaming texture coordinates (#M78ELM), distance to the curve defines river boundaries (#QGGCCR), and junctions blend coordinates from overlapping branches (#KNWKGF). Texture advection is otherwise difficult because a texture must move like a carpet around a curved track with spatially varying direction and speed (#W32P5Z). The transform would be a rendering parameterization, not a replacement for velocity simulation; junction singularities, distortion, and inverse-map/Jacobian handling remain important. Coarse 3D displacement is compatible with a 2D river animation model (#YTDJGS). #4PF6N6 Cross-corpus inventory of units, quantities, and domain-specific numeric parameters Published: 2026-07-12T03:37:39Z Mentions: #247BPE, #3LSFWC, #GNDKEV, #BEDUYL, #8CNUPW, #8QGM6W, #LUVPJR, #BMKDJR, #N9TEH4, #82HGFN, #43XVF5, #MNZNZU, #J2KKMV, #6N825C, #23W9S2, #XZBXLL, #RTYCL9, #W7JZEK, #9VNYCT, #Z3MXM7, #MSXUGH, #V5XDSY, #76SGWC, #D2C54Y, #XR7Z7G, #754PPX, #9DU2N2, #9AHGRG, #GZJUCV, #AJSDD6, #KAFWZ7, #D33DUB, #8AQDAB, #YVMH2N, #MKYDT2, #M53PTE, #WKY9MT, #EQTM8J, #ED94U3, #LBNKBW, #LUZ5UR, #HS22AT, #JS4LBU, #ZHQFZP, #BPF8Q6, #8ERHN4, #HWVUS7, #VG86AP, #NHQBFC, #WUZ6YE, #A6TZBP, #2RHVZB, #ACDG5B, #54E5UT, #EUX776, #WJSTC2, #JLGV3R, #WV3FXP, #8KBMFE, #BDZQP4, #EKXATA, #NEL8YN, #K7SCA8, #SFWHTE, #2KNSHV, #E6X4P6, #YCESD5, #UG8PZG, #CK2TWF Cross-corpus inventory of notable units, quantities, and parameters. Terrain/erosion: Large-scale uplift/erosion experiments use 50×50 km terrain, uplift 5×10^-4 m/y, erosion coefficient 5.61×10^-7 y^-1, target summit ≈2000 m, and Δt=2.5×10^5 y (#ZHQFZP); stream-power applicability is 10^5–10^7 y and tens–hundreds km (#MSXUGH), commonly m=0.5,n=1 (#EKXATA), with empirical h_max[km]=2.244u/k (#MNZNZU). Thermal erosion often uses 30° talus (#9VNYCT), or varied 6°–54° limits (#6N825C); mountains form around 50 iterations and stabilize in 100–300 (#W7JZEK). Analytical erosion examples use 512² cells, 50 m spacing, t=4.6 My, 460 simulation steps of 10,000 y versus 43 fixed-point steps (#E6X4P6); shrinking cells 50→25→12 m raises simulation iterations 230→460→980 (#EQTM8J). Examples span 200 ky–1.6 My (#LBNKBW), 100/200/300 ky at 30 m spacing (#Z3MXM7), and a 4.6 My mountain at 5/15/25 km scales (#N9TEH4). FastFlow compares Δt=1,000 y explicit to 20,000 y implicit; a 10 My landscape takes 7.2 s vs 0.5 s (#M53PTE), while 10 iterations/0.1 s represent 700 ky on 512² and 100 iterations take 0.7 s (#YVMH2N). Routing runs under 55 ms to 4096² (#BDZQP4), with 5× flow and 34–52× depression-routing speedups at 1024² (#8QGM6W). Real 1 m DEM examples contain 383,918 and 8,445,644 basins (#NEL8YN). Hydrology/rivers: A recurring empirical relation is discharge φ[m³/s]=0.42A^0.69 for drainage area A[m²] (#VG86AP, #HS22AT). Procedural Riverscapes spans a 3×3 km terrain, ≈4 km river, >40,000 primitives, 100 m input DEM pixels, and 10 cm output detail (#ACDG5B); primitives sampled every 50 cm and construction trees generated in ≈15 ms (#YCESD5), rendering >70 fps at 1920×1080 (#GZJUCV). Storage ranges from 22 kB for 50 m to 2.7 MB for ≈4 km; primitives cost 50–90 bytes (#9DU2N2). Compared offline production used 3 cm precision, 4.5M particles, 200M voxels, 20 s output, and 165 total work/simulation hours (#2KNSHV). Priority-Flood tests include 3 m DEMs of 152M and 318M cells (#8ERHN4); a larger benchmark covered 72,500 km² and ≈8×10^9 cells, averaging 16.8% and maxing 37.2% speedup (#XR7Z7G), with up to 37% improvement and one CPU matching six processors (#ED94U3). Water/waves/rendering: Surface Wavelets simulates 4×4 km at 60 fps (#WKY9MT), using 4096 cells per spatial axis (≈1 m spacing; #UG8PZG), 16 directions and usually 1–4 wavenumber samples (#WV3FXP). Despite the coarse grid it resolves 2 cm wavelengths; an equivalent direct heightfield would bottom out at 0.5 m under Nyquist (#BEDUYL). Precomputation gives ≈4.7×, 60→280 fps (#23W9S2); a profile-buffer optimization raised evaluation 1.8→275 fps, reported as 233× (#82HGFN). Four wavenumber groups roughly quadruple cost and reduce 70→20 fps (#9AHGRG). Water viscosity is given as 10^-6 m/s in the dissipation model (#NHQBFC; unit as printed should be checked dimensionally). Breaking-wave tests use 160k–200k grid points at 40–75 fps; simulation consumes 80% of runtime (#RTYCL9). Layered particle water uses 20k–64k particles at 1280×720 and 112 bits/pixel of intermediate buffers (#LUVPJR), with runtime split ≈23.12/24.4/27.43/25.05% across depth, thickness, smoothing, and composition over 6k frames (#754PPX). Advected river textures report 60–120 fps, average 85 (#8KBMFE), illustrate 1.3 m/s flow (#JS4LBU), use a 15° flow-hint cutoff (#BMKDJR), and set particle lifetime 1.5 s plus travel limit 5% of river length (#K7SCA8). Scalable river animation tests 25×25 km at 800×600 with 20 px particle/sprite radius (#EUX776). Halftone foam adds <3% load over five-minute tests (#V5XDSY); surveyed historical ocean methods report ≈20–30 fps on GeForce 2 (#2RHVZB) and ≈100 fps on GeForce 3 (#KAFWZ7). Roads/racing: Procedural road routing discretizes position×orientation as n²×m (#43XVF5); tunnel/bridge masks use 50–300 m lengths on a 300² grid at 10 m spacing, comparing 2728 visited points to 50 stochastic samples (#WJSTC2), and produces paths in <1 s on 100² grids (#JLGV3R). Racing optimization covers a 4.5 km circuit, converges in 4–5 iterations, about 30 s each (#BPF8Q6); experimental laps are 138.6 s versus 139.2 s and a professional 137.7 s, with μ=0.90 and peak 0.9g (#8AQDAB). Each full iteration is 26 s across 1843 timesteps versus hours for nonlinear optimization (#CK2TWF); controller rate is 200 Hz (#3LSFWC). Trails/movement: Mountain-walker footprints use a 10 cm square footprint (#J2KKMV). Simulations use Gmax=200 m^-1, visibility 10 m, 50 footfalls (versus real-world several hundred), weathering 1000 s (versus days), walker speeds 0.5–1.5 m/s, a 25×10 m slope, and 25,000 walkers (#WUZ6YE). Zigzags appear with forbidden angles 25° uphill/10° downhill, weathering 1500 s, and α≳0.45 (#AJSDD6). Stability tests use Δt 0.5/0.25 s and Δx=Δy 5/2.5 cm (#HWVUS7). Biomechanics: a 10° incline may require 60° hip flexibility vs 30° flat; observed ankle max ≈24° (#54E5UT). Field slopes cited around 1:8 and 1:2 (#GNDKEV). Trail design suggests 8–10% for family/senior users where 12–16% may be structurally sustainable (#D33DUB), hillslope:trail grade ratios around 2:1–3:1 (#SFWHTE), and a worked example adds 500 ft to reduce 200 ft rise over 2000 ft from 10% to 8% (#76SGWC). Sudden changes include 5→10% and 7→20% (#247BPE); paired clinometer readings should agree within 1 percentage point (#8CNUPW). Domain-specific abstract quantities: Wholeness case studies use 1,800 Manhattan axial lines and 166,479 Swedish streets, finding power-law exponents around 2+ (#LUZ5UR). Living Images reports recursively defined substructures ≈3% of pixels, ≤2% decomposable, and >3–4 recursive levels (#D2C54Y, #XZBXLL). Head/tail breaks continues while the head is ≤40% (#MKYDT2). Platformer physics uses Castlevania ≈3.7 tiles/s, Mario 10 tiles/s, others ≈5.5, and suggests 4–10 tiles/s as playable (#A6TZBP). #79XGSQ Peak sanctuaries as an inhabited dual of drainage basins Published: 2026-07-12T01:00:47Z Mentions: #25Z8H8, #2QALPN, #A6G5PJ, #BLF82B, #F2VBJL, #GDV37F, #GHEACQ, #JAHVNN, #MZP8G3, #N7XTK3, #QPEZUU, #RBPN5L, #U7AJ7K, #WL3SCW Peatfield’s evidence supports a precise version of the “dual of basins” intuition. Hydrologically, a watershed collects terrain cells toward a common outlet: watersheds are upstream-connected cells associated with an outlet (#WL3SCW), and FastFlow defines a basin by a shared stream-tree root (#A6G5PJ). The terrain-generation paper explicitly constructs a dual graph on the crests between watershed cells (#U7AJ7K). A sanctuary can be modeled as a culturally selected point on or just inside that crest system: not necessarily the highest summit, but the point that most directly overlooks—and is visible from—a particular inhabited plain (#QPEZUU, #N7XTK3). Its relation reverses downstream collection: settlement paths, attention, and offerings converge uphill, while sight, fire, and divine protection project back down (#RBPN5L). The local service regions suggested by Peatfield (#F2VBJL) are therefore analogous to catchments, while intervisible sanctuaries form a second, crest-level network (#GDV37F, #JAHVNN). Formally, assigning each inhabited cell to one shrine would induce a partition analogous to the inverse-image partition of a function (#BLF82B), but raw viewsheds overlap, so without a unique service assignment the better object is a cover, bipartite graph, or weighted field rather than a strict partition. Alexander’s language adds a complementary reading: each shrine is a strong center supported by its surrounding settlements and landscape (#GHEACQ), while dominant sanctuaries create a recursive hierarchy of centers (#25Z8H8). Movement closes the loop: visibility affects trail attraction (#MZP8G3), and slope-constrained walkers generate mountain paths (#2QALPN). This suggests a generative model coupling hydrological basin labels, one-sided viewsheds, accessibility/trail evolution, and shrine-to-shrine intervisibility. #TUCFMG Partition lens across the corpus Published: 2026-07-12T00:29:48Z Mentions: #477DMT, #48RCD2, #964T2S, #A6G5PJ, #BLF82B, #C9XNSJ, #DJQRBX, #FXLSNG, #KAMGFF, #L94DMG, #LNKPPL, #NNC37P, #PUZXXV, #RRJ2BJ, #WL3SCW, #WQW77N, #ZBQE96 Ellerman’s partition logic suggests a useful cross-corpus lens, but only where blocks are mutually exclusive and jointly exhaustive (#ZBQE96). The clearest exact case is hydrological catchments: terrain cells are equivalent when they drain to the same outlet, and watershed labeling assigns one common label to every such equivalence class (#NNC37P, #477DMT). FastFlow similarly defines a basin as cells sharing a stream tree/root (#A6G5PJ) and propagates basin identifiers upstream (#C9XNSJ); saddle crossings then connect or merge basin blocks (#L94DMG), suggesting dynamic coarsening of a catchment partition. Hydrological terrain generation also constructs Voronoi cells and hierarchical watersheds/subwatersheds (#KAMGFF, #WL3SCW), giving nested partitions at multiple scales. Other exact or near-exact corpus examples include planar regions cut by major streets/topographic boundaries (#PUZXXV); recursive figure/ground and connected-pixel segmentation (#FXLSNG); head/tail classes (#WQW77N); MAP-Elites bins that partition behavior/search space (#DJQRBX, #964T2S); fluid particles classified into rendering layers (#48RCD2); and walker populations grouped by entry–destination pair (#RRJ2BJ). Alexanderian centers should not be treated as a partition without qualification because their local symmetries and centers overlap across scales (#LNKPPL). Conceptually, a deterministic map from each terrain cell to its terminal outlet realizes Ellerman’s function-to-partition idea (#BLF82B): catchments are the inverse-image fibers of the outlet map. #8G2LDE Spinoza–Alexander: immanent goodness and composition Published: 2026-07-11T13:08:23Z Mentions: #DPKEES, #G8D7VX, #HTRZHU, #PXG56P, #VWK7B2 Spinoza offers a useful but non-identical analogue to Alexander. Both replace an external blueprint with immanent order: Alexander explicitly denies goal-seeking teleology (#HTRZHU), while Spinoza’s Deus sive Natura acts from its own necessity, not for ends. Alexander’s strengthening of centers within larger wholes (#DPKEES, #G8D7VX) can be compared to Spinoza’s composition of bodies and increase in potentia: a good encounter enables bodies to compose their relations and increases their power of acting, experienced as joy; a bad encounter decomposes relations and produces sadness. The terrace intrusion can thus be described without mere taste as reducing a shared body’s capacities for conversation, play, attention, and repose. Important difference: Spinoza is suspicious of objective beauty and cosmic harmony when these are projections of human imagination, whereas Alexander wants harmony, figural goodness, and beauty to be objective features open to science (#VWK7B2). Their strongest common ground is therefore immanent, relational goodness rather than a literal cosmic desire for beauty. #VZHR9P Boom box on the terrace: an Alexanderian violation test Published: 2026-07-11T11:36:26Z Mentions: #GXVBDU, #XZ4XQ3 Thought experiment: a family quietly inhabits an oak-and-bench setting or Ravello terrace; an intruder plays clipping loud music and scribbles on the columns. The wrongness is relational, not intrinsic to rock music or marker strokes. In another context either could be good. Here they overwrite existing centers—conversation, play, repose, columns, view and acoustic enclosure—without helping the larger whole. This exemplifies Alexander’s SP criterion: a transformation should elaborate existing/latent centers rather than introduce centers that violate or cut across them (#XZ4XQ3), and should improve a larger whole (#GXVBDU). The intrusion is also ethically wrong because it coercively monopolizes a shared sensory field and irreversibly damages a common artifact. The case helps distinguish objective/intersubjective structural badness from mere disliked style: observers could potentially identify loss of affordances, interrupted coordination, distress, damage, and reduced mutual support even without sharing the participants’ musical or decorative preferences. #9RFPBN Religious and axiological reading of harmony-seeking computation Published: 2026-07-11T11:32:51Z Mentions: #8HCCLH, #FDFT8L, #HTRZHU, #VWK7B2 Harmony-seeking computation should be read against Alexander’s explicitly religious late work. The relevant essay is “The Long Path That Leads from the Making of Our World to God” (2007), abridged in First Things as “Making the Garden” (2016). On this reading, harmony is not merely an aesthetic score: making a center-strengthening world is participation in a reality whose deepest order is intrinsically good. The manuscript’s Fact and Value section explicitly rejects value-neutral mechanism as sufficient for understanding cosmic harmony (#8HCCLH) and invokes the older scientific idea of a universe moving toward harmony (#VWK7B2). There is nevertheless a productive tension: Alexander denies that harmony-seeking is teleological or goal-seeking (#HTRZHU), yet describes systems as disposed toward positive space (#FDFT8L) and as progressively healing larger wholes. The best formulation may be immanent rather than blueprint teleology: no predetermined final form, but a directional norm internal to each unfolding situation. “Inner calm” is not static equilibrium but the felt and structural resolution of competing forces into a configuration where centers support rather than violate one another. #RMDR23 Center as spatial-relational formation: apple and ecological niche Published: 2026-07-11T11:26:04Z Mentions: #A4LK2X, #G8D7VX, #PRJ2E8 Alexander’s center is better modeled as a spatial-relational formation than as the material object at its core. An apple is a BFO object, but the apple-center may include or depend on the apple’s boundary, orientation, shadow, surrounding air and light, its relation to the table, and the positive spaces it induces. The apple is therefore the material anchor, focus, or causal bearer of the center, not the whole center. This fits Alexander’s claim that centers are activated by the configuration as a whole (#PRJ2E8), can overlap (#A4LK2X), and have coherence determined through relations with other centers (#G8D7VX). Smith and Varzi’s ecological niche is a useful comparison: a niche is an organism-relative structured surround involving tenant, medium, retainer, and physical/fiat boundaries, rather than merely the tenant or cave. The analogy is limited: a niche is organized as suitable environment for its tenant, whereas an Alexanderian center is a graded spatial unity organized around a focus and supported by surrounding centers. A useful provisional vocabulary is material anchor + spatial halo/field + support relations + context-relative strength. #XE4N77 Alexander’s centers compared with BFO objects Published: 2026-07-11T11:20:45Z Mentions: #A4LK2X, #G8D7VX, #GXVBDU, #KJBJ2D A useful but limited analogy: BFO defines an object as a material entity that manifests causal unity and is maximal relative to the relevant kind of causal unity. Alexander’s centers likewise concern non-arbitrary unity, but they are not equivalent to BFO objects. Alexander permits centers to overlap and nest (#A4LK2X), to be weak or latent (#KJBJ2D), and to include spatial/immaterial configurations such as a square, courtyard, boundary, void, or positive space. In BFO these could fall under different categories—object, fiat object part, object aggregate, site, or spatial region—rather than all under object. BFO primarily asks what kind of entity something is and what grounds its unity; Alexander asks how strongly a configuration functions as a center within a relational field and how transformations strengthen that field (#G8D7VX, #GXVBDU). The promising bridge is therefore not Center = Object, but: BFO supplies distinctions among entity and boundary types, while Alexander supplies graded, relational, multi-scale coherence and transformation. #42YDX9 Alexander (2009), Harmony-Seeking Computations — reading note Published: 2026-07-11T11:14:38Z Mentions: #26RNEY, #5BC6M2, #5F4JYM, #7FFBLT, #9Q3BRS, #GW8NGQ, #NRPMA6, #S3MN33, #S53N2R Alexander’s unpublished 2009 manuscript reframes The Nature of Order as a computational research program. A harmony-seeking computation repeatedly identifies a latent center L within a larger wholeness W, then creates/reconfigures smaller centers N_i so that L becomes stronger and, crucially, helps the larger W become more coherent (#S53N2R, #S3MN33, #5BC6M2, #GW8NGQ). This distinguishes harmony from ordinary emergence: emergence relates parts to the collective they form, whereas harmony adds a third level—the collective must help the still-larger context (#26RNEY, #NRPMA6). Formally the paper offers postulates and the sequence W_1 -> W_2 -> W_3 through SP-transformations, but openly admits that the mathematical description and operationalization of the fifteen transformations remain incomplete (#9Q3BRS, #5F4JYM, #7FFBLT). For procedural generation, its strongest contribution is therefore not an implementable algorithm but a design criterion/update logic: choose each next move by how it strengthens latent structure across scales, rather than merely applying context-free local production rules. The manuscript’s weakness is that identification of centers, measurement of coherence, and empirical objectivity are asserted more than demonstrated; examples function mainly as analogies and existence arguments. #JVRSKS Recommended water renderer for procedural hydrological terrain Published: 2026-07-11T08:23:32Z Mentions: #5NJY7V, #6ELMAT, #EYM9N6, #GU2NEL, #H2E2UR, #QXYWAJ, #X3RVN8, #XVFV3N For a game with precomputed geological erosion and hydrology, the best fit is a stylized data-driven hybrid rather than runtime CFD. Reuse channel topology, banks, flow direction, discharge/drainage area, slope, depth/width, curvature, drops, junctions, obstacles, and distance-to-shore as shader/control fields. This closely matches the input assumed by scalable river animation (#QXYWAJ) and Procedural Riverscapes, which derives per-cell slope, volume, and velocity (#X3RVN8) and selects calm, turbulent, wave, cascade, vortex, and ripple primitives from terrain and flow conditions (#GU2NEL, #5NJY7V). Recommended architecture: one shared water material; rivers use generated flow maps to advect two offset normal/detail layers as in Portal 2 (#6ELMAT, #XVFV3N); lakes use low-speed wind ripples and shoreline masks; ocean uses a few art-directed Gerstner/spectral bands plus shore foam. Generate masks for turbulence/foam from normalized stream power, slope, curvature, constriction, drops, and obstacles; use depth for color/opacity and shallow-ground blending; use local feature primitives only at visually important events such as waterfalls, rapids, confluences, and rocks. Apply screen- or distance-dependent LOD, retaining flow direction and wind at distance while removing displacement and local effects (#H2E2UR, #EYM9N6). #4CB2WQ Water-rendering literature overview Published: 2026-07-11T08:16:55Z Mentions: #3UZ7TP, #4S5XNT, #6ELMAT, #764D8D, #8KBMFE, #AL6YQ9, #BVUXWL, #CZNWCP, #DZCPD6, #EYM9N6, #G3TYUA, #H2E2UR, #KFWVK3, #KHRCTA, #KSH8JS, #MSQQ8G, #PBZNNB, #QGESFA, #RFLQDX, #T9Y2PR, #V5XDSY, #WKY9MT, #XFKY8Q, #XVFV3N, #YJNSYU, #YWWZAM The water-rendering corpus organizes around a recurring hybrid strategy: simulate only the low-frequency/structural behavior needed for motion, then add high-frequency visual detail and optical cues cheaply. The survey separates deep-water parametric/spectral methods from shallow-water fluid methods and identifies foam, spray, and light interaction as separate realism layers (#4S5XNT, #CZNWCP). River methods use coarse or procedural velocity fields plus advected wave textures: Arnold et al. combine 2D Navier–Stokes, hydrostatic pressure columns, and texture advection (#8KBMFE, #T9Y2PR); Yu et al. compute local steady flow and use screen-space sampled wave sprites for huge terrains (#3UZ7TP, #AL6YQ9); their later Lagrangian texture-advection method uses deformable particle grids to preserve both flow and texture spectrum (#DZCPD6, #KSH8JS). Vlachos's Portal 2 production method is the cheapest end of this continuum: artist-authored flow maps distort two normal-map layers, with offsets and noise hiding repetition/pulsing (#6ELMAT, #XVFV3N). Shallow-water work adds effects a height field cannot express: Thürey et al. detect steep fronts and spawn connected-particle sheets for overturning waves, drops, and foam (#KHRCTA, #XFKY8Q); Ojeda and Susín layer FFT/noise normals, advected foam, photon caustics, and screen-space reflection/refraction over a shallow-water simulation (#BVUXWL, #PBZNNB). Scherzer et al. target fully dynamic particle fluids, using screen-space depth/thickness layers, adaptive curvature-flow smoothing, and Weber-number-based volumetric foam (#G3TYUA, #YJNSYU). Surface Wavelets is the strongest large-scale wave paper: it simulates slowly varying amplitudes over space/frequency/direction on a coarse grid, reconstructs detailed waves separately, supports obstacles and artistic control, and runs a 4 km × 4 km scene at 60 fps (#RFLQDX, #764D8D, #WKY9MT); it cannot handle breaking waves or splashes because it is linear (#YWWZAM). Specialized cheap methods include halftone-mask foam dissipation with under 3% overhead (#KFWVK3, #V5XDSY), Bézier-curve river networks with streaming normal maps (#QGESFA, #MSQQ8G), and distance-dependent switching among Stokes, cosine, and bump-mapped wave models (#H2E2UR, #EYM9N6). ### 15. Assistant tool calls #### Tool call: `get_document` ```json { "id": "TDS4H2" } ``` #### Tool call: `read` ```json { "blocks": [ "G485QR", "WC7Z5Z", "BE7ZJF" ], "expand": true } ``` ### 16. Tool result: get_document DOCUMENT #TDS4H2 Title: Relaxing Synchronization Constraints in Behavioral Programs Outline: - 1 #KBEBVQ Relaxing Synchronization Constraints in Behavioral Programs - 1.1 #GJBGMA 1 Introduction - 1.2 #YZJE2D 2 Behavioral Programming - 1.2.1 #KWNH5E 2.1 Behavioral Programming Formalized - 1.3 #WZHJW8 3 The Eager Execution Mechanism - 1.3.1 #EYQQFX 3.1 Static Analysis - 1.3.2 #S38YM5 3.2 Dynamic Analysis - 1.3.3 #D85TR6 3.3 Eager Execution Formalized - 1.4 #97ZMXK 4 Modularity by Eager Execution - 1.4.1 #WC7Z5Z 4.1 Example: A Modular Design - 1.5 #NT2DRQ 5 Related Work - 1.6 #877H7Z 6 Conclusion and Future Work - 1.7 #QPF3PA References - 1.8 #EYT6LY A Proof of Proposition 1 - 1.8.1 #HZTJNN Lemma 2. ### 17. Tool result: read DOCUMENT #M5788P Towards Behavioral Programming in Distributed Architectures SECTION #G485QR 3.6. Example 3: Incremental development of a multi-agent application EXCERPT #U4UEKZ p. 27 In this section we demonstrate how multiple behavioral programs coordinated only by external events can retain much of the incrementality of a single fully synchronized behavioral system, i.e., that functionality can be enhanced by adding b-threads and b-nodes. EXCERPT #JL2FWF p. 27 We present the development of a multi-agent application, where agents include vehicles traveling in open terrain and advisors affecting the vehicles. First, we list the behaviors that are responsible for the movement of a vehicle. To each vehicle we then add behaviors that allow it to interact with external systems. Finally, again incrementally, we program the vehicle agents to react to an advisor agent responsible for directing particular aspects of the vehicles' travel. The communication between the vehicles and the advisor uses the architecture for external events described in Section 3.2. This small example can be readily extended to make it easily possible to add agents (vehicles, advisors), as well as new kinds of interactions among existing agents (inter-vehicle or inter-advisor). SECTION #88GREA 3.6.1. Vehicle motion EXCERPT #GJFFEZ p. 27 For brevity, we list only a minimalistic scenario: moving towards a given goal. The movement is performed by the following processes. A ticker process sends an external tick event every N milliseconds, as in the example of Section 3.4. The b-thread on_tick (not shown) repeatedly waits for this event, samples the current position, say, using a GPS, and broadcasts the position by requesting the event {pos, X, Y} . This event also captures a form of feeding external information into the behavioral system. The behavior head_north repeatedly compares the current position with the location of the goal, and decides whether to request the event of moving north or not. Similar behaviors are responsible for moving south, west and east, all quite obliviously of each other. The is function matches all events of a given record type (all pos records in this case). EXCERPT #MMB7A9 p. 27 head_north() -> {pos, _, Y} = bp:bSync(#rbw{wait=is(pos)}), {_, Y1} = goal(), if Y < Y1 -> bp:bSync(#rbw{request=[north]}), move_north(); % Request granted, move north true -> ok % Don't move north end, head_north(). EXCERPT #T6UWR6 p. 27 SECTION #LG3ZE2 3.6.2. Enabling external communication EXCERPT #G2UHNR p. 28 The behaviors listed above will cause the vehicle to move towards its goal uninterrupted. We would like to allow an external coordinator agent to affect this movement, but, unlike the game and quadrotor examples, here there is no natural super-step breakpoint within the internal events where the external environment can intervene. To modify the vehicle software for creating such a breakpoint we add two b-threads. One counts N_1 advancement steps of the vehicle and then sends an external event containing the current position of the vehicle to an external process. EXCERPT #QMVKDK p. 28 report(S, P, N1) -> {pos, X, Y} = bp:bSync(#rwb{wait=is(pos)}), S ! {pos, P, X, Y}, [bp:bSync(#rwb{wait=is(pos)}) || _ <- seq(1,N1-1)], report(S, P, N). EXCERPT #3GDH7T p. 28 Another b-thread counts N_2 steps and peeks at the communication channel for any external incoming communication. If the channel is empty the process continues. EXCERPT #9DN45K p. 28 listen(N2) -> bp:bSync(#rwb{wait=is(pos)}), receive E -> bp:bSync(#rwb{request=[E]}), after 10 -> ok % Timeout after 10 milliseconds end, [bp:bSync(#rwb{wait=is(pos)}) || _ <- seq(1,N2-1)], listen(N). EXCERPT #Q9938K p. 28 To demonstrate a possible external command, we assume that advisors may warn the vehicle, upon arriving at a certain line in its northward path, that there are too many vehicles beyond that line. To allow the vehicle to react, we add a new b-thread to the vehicle b-node. If the vehicle crossed the line, it calls the hold function. EXCERPT #4W8B83 p. 28 on_warning() -> {warn, T} = bp:bSync(#rwb{wait=is(warn)}), {pos, _, Y} = bp:bSync(#rwb{wait=is(pos)}), if Y >= T -> hold(); true -> on_warning() end. EXCERPT #3C6K95 p. 28 The implementation of hold listed below blocks the movement north, as may be requested by any b-thread, current or future, for 10 steps. The added behavior on_warning represents the policy of the vehicle's reaction to the warn event. It could be easily replaced by other policies, such as blocking the movement north until notified otherwise, or even to move southward. EXCERPT #ETCFV2 p. 28 hold() -> [bp:bSync(#rwb{wait=[tick], block=[north]}) || _ <- seq(1,10)], on_warning(). SECTION #JGN5SS 3.6.3. Adding an advisor agent EXCERPT #S6XUMZ p. 28 We are now ready to add advisors that will monitor and try to affect the movement of several vehicles. For example, the following behaviors first report when a vehicle crosses a line, and later ask vehicles positioned at the line to stall if there are more than N vehicles north of the line. The first advisor b-thread, monitor_line , deals only with behavioral events. It waits for any vehicle position event, and requests an event, internal to the advisor, that will eventually lead to inter-agent messages. EXCERPT #NV2NVY p. 28 EXCERPT #82GY3M p. 29 monitor_line(Y1) -> {pos, P, _, Y} = bp:bSync(#rbw{wait=is(pos)}), if Y >= Y1 -> % Report crossing bp:bSync(#rbw{request=[{cross, P}]}); true -> ok end, monitor_line(Y1). EXCERPT #J3HSSL p. 29 The second behavior listed below mixes behavioral and native communication methods. EXCERPT #GUKAQT p. 29 monitor_crossing(N, Y1, L) -> {cross, P} = bp:bSync(#rbw{wait=P is not in L}), if length(L) >= N -> P ! {warn, Y1}, monitor_crossing(N, Y1, L); true -> monitor_crossing(N, Y1, [P|L]) % Add P to L end. EXCERPT #3XAQWS p. 29 It maintains a list L of vehicles that have crossed the line. Each vehicle is represented by the address of its listening process. When another vehicle crosses (i.e., its address is not in the list), it checks if there are too many vehicles north of the line. If so, it sends an Erlang message to the crossing vehicle. This message is received by the listen behavior in the b-node that controls the vehicle. For brevity, we omit describing the full function of the wait clause. Figure 10 outlines the complete architecture of the vehicles application. EXCERPT #7VC9JF p. 29 graph TD subgraph Advisor ["advisor b-node"] A1[ ] A2[ ] A3[ ] end subgraph Vehicle ["vehicle b-node"] R[report] L[listen] M1[ ] M2[ ] M3[ ] end R -- "send pos every N1 steps" --> L L -- "check for warn every N2 steps" --> Advisor L -.-> |"block move north"| M1 L -.-> M2 L -.-> M3 style M1 fill:none,stroke:none style M2 fill:none,stroke:none style M3 fill:none,stroke:none Diagram of the multi-agent architecture for vehicles. It shows an 'advisor b-node' at the top and a 'vehicle b-node' below it. The advisor b-node contains three small boxes. The vehicle b-node contains a 'report' box, a 'listen' box, and three more boxes labeled 'steps movement behaviors'. A solid arrow labeled 'send pos every N1 steps' points from the 'report' box to the 'listen' box. A solid arrow labeled 'check for warn every N2 steps' points from the 'listen' box to the advisor b-node. A dashed arrow labeled 'block move north' points from the 'listen' box to the 'steps movement behaviors' boxes. EXCERPT #2BPCFS p. 29 Figure 10: Multi-agent architecture for vehicles. The behavior report of each vehicle sends the current position to interested advisors every few steps. The listen behavior checks for a new warning, and may block specific events if it receives one. EXCERPT #FYGKDN p. 29 Summary. In this example we demonstrated the construction of different b-nodes, each comprised of a set of constantly synchronized b-threads. The communication between the b-threads is carried out according to the methodology discussed in Section 3.2. All agents are incrementally programmed to communicate, to interpret each other’s messages and to react as desired by the developer, only by the addition of new, independently programmed b-threads. EXCERPT #WTKJVB p. 29 DOCUMENT #TDS4H2 Relaxing Synchronization Constraints in Behavioral Programs SECTION #WC7Z5Z 4.1 Example: A Modular Design EXCERPT #CEAKBY p. 12 We implement the traveling vehicles example from [11, Section 7]. The example includes several vehicles, each operating as an autonomous component traveling on pre-given cyclic route along an (x, y) grid; in each given time unit during the run, each vehicle can travel north, east, south or west. We assume that all vehicles travel at identical speeds, i.e., cover one unit of distance per time unit. EXCERPT #XJFQYS p. 12 Using eager execution, this multi-component system can be programmed entirely within the behavioral programming framework, without relying on external means of communication. The threads of each vehicle, v_i , form an independent behavioral module M_i that involves a designated set of events. This results in a strict modular design allowing each vehicle to operate independently of others. A code snippet for the main thread of vehicle v_i is depicted in Fig. 7. If each module has a dedicated processor and event selection is fair, all vehicles are constantly moving — as the coordinator does not wait for vehicle v_i to finish moving and synchronize again before triggering the movement requested by another vehicle. EXCERPT #A25NFW p. 12 while ( true ) { Vector requestedEvents; if ( destinationIsNorth() ) requestedEvents.append( #iMoveNorth ); if ( destinationIsSouth() ) requestedEvents.append( #iMoveSouth ); if ( destinationIsEast() ) requestedEvents.append( #iMoveEast ); if ( destinationIsWest() ) requestedEvents.append( #iMoveWest ); bSync( requestedEvents, none, none ); adjustPositionByLastEvent(); } EXCERPT #KT6SJ7 p. 12 Fig. 7: The main method of each vehicle thread. The placeholder ‘#i’ is replaced by the number of the vehicle; for instance, for vehicle v_5 , the events are 5MoveNorth, 5MoveWest, etc. The thread requests moves in all directions that bring it closer to the destination. When the call to bSync returns, one of these moves was selected by the behavioral execution mechanism. The thread then updates its position (by invoking adjustPositionByLastEvent), and proceeds. EXCERPT #UPJHJT p. 12 Eager execution allows a light-weight solution if communication between the vehicles is required — e.g., for collision prevention. Each vehicle can be accompanied by an adviser thread that keeps track of other vehicles. Whenever its vehicle is dangerously close to another, the adviser blocks movement in the dangerous direction (for simplicity, deadlocks are ignored). As the modular design remains strict, adding the adviser threads does not impede the vehicles' ability to move independently. DOCUMENT #M5788P Towards Behavioral Programming in Distributed Architectures SECTION #BE7ZJF 3.2. Handling external events EXCERPT #DN33JE p. 15 The external environment is an essential element in the design of reactive systems. It is the source of the events that the system needs to react to, and is the target of the actions taken by the system. The actual occurrence of events in the environment, e.g., temperature rising, cannot be synchronized with the processing done by the system, and the arrival of such events, e.g., when and how a sensor reading is processed, requires special handling. In our case, for coordinating the synchronized processing of BP with an external environment, we propose a solution based on the super-step approach, as in statecharts [22] (and which is used also in, e.g., LSC execution [21]) and on the logical execution time concept used, e.g., in GIOTTO [28]. EXCERPT #QSEJNZ p. 15 This solution is implemented by the BP infrastructure, assuming only that the application complies with simple rules, without application-specific programming. Specifically, we propose that behavioral program execution be divided into cycles, called super-steps , and external events are introduced only at the beginning of a super-step. The philosophy is that all internal events in the body of a super-step are perceived as happening in the same physical time unit but they are nevertheless ordered; i.e., there is a sequence of events (not associated with meaningful time-stamps) between the beginning and end of each super-step (c.f. hybrid time-set [37]). Thus, they are viewed as all taking place in zero time. EXCERPT #TPZQ8A p. 15 According to this convention, it is sufficient to consider a real-world occurrence of an external event only in relation to when super-steps begin and end; i.e., only external events have meaningful time-stamps. When sampling times need to be equidistant, as is the case when implementing algorithms for certain kinds of real time systems and in control theory, one can program the system such that all super-steps take a constant amount of time, by adding delays (under the assumption that the super-step’s internal events runs fast enough to always complete within the time frame). EXCERPT #VEQBYA p. 15 One initial approach to the implementation of the above philosophy is to have a non-behavioral process handle the external event by dynamically creating a lowest-priority b-thread that will join the next synchronization point and request a corresponding behavioral event. While this approach is general and simple, it may — depending on the implementation platform and language — present performance issues related to the creation of threads and processes. EXCERPT #9T4DYH p. 15 EXCERPT #Z32HVT p. 16 We thus propose the following design: EXCERPT #BTT78R p. 16 • External events are first captured by non-BP processes and are placed in a common queue, using standard programming constructs. • A lowest priority b-thread repeatedly requests a predesignated event, called, say idle , which by convention is never blocked by other b-threads (which can be enforced). Since this event can occur only when there are no other events that are requested and not blocked, its triggering marks the end of a super-step. • A designated b-thread repeatedly waits for the event idle , and then “peeks” at the external event queue using standard programming constructs. This peeking may be slightly delayed, as the queue may be temporarily locked by other processes during an atomic operation. However, this kind of delay is acceptable, since no internal events other than idle can become enabled in the next synchronization point. If no new external event is found, the b-thread proceeds to its next iteration where it waits for another idle event. If an external event is found, the b-thread requests a corresponding behavioral event that represents the external one, and proceeds to its next iteration, waiting again for the idle event. EXCERPT #8VGNMQ p. 16 Actually, the first and third points above can be replaced by allowing a single b-thread to wait for an idle event, and then, wait for external events using standard (non behavioral) language constructs, such as receive in Erlang or wait in Java. This will in fact stall the process and cause the next synchronization point to be delayed until the waiting process also synchronizes, which will happen only after the next external event arrives. It does not stall the system’s operation, however, since by convention no internal events can be triggered between the idle event and the next external event. The three-point design above allows a richer variety of actions in separate b-threads, such as super-step logging, deadlock handling, blocking of external events, and additional peeking at external event queues, while replacing the first two points as suggested may be simpler and more suitable for small applications. EXCERPT #4SXMM6 p. 16 This approach, based on logical execution time, also explains why the BP semantics does not allow for simultaneous triggering of multiple events. On the one hand, allowing only a single event to be triggered at each synchronization point makes it possible for every b-thread to react to the triggered event and change states as needed; e.g., for subsequent requesting, waiting, or blocking events. Debugging and formal analysis of this semantics is much simpler than when simultaneous triggering is allowed. On the other hand, event sequences that do not require such strict sequencing, possibly benefiting from simultaneous event triggering, do not generally suffer from the sequencing, as all the events indeed occur within the same time slot, marked by two time ticks or two other external events. The relaxed synchronization techniques described in Section 4 also assist in enabling the desired parallel execution, when applicable. We should also note that when, for some reason, simultaneous event triggering is desired, it can be partially implemented in application-specific ways by enriching the event objects to represent sets of more primitive events. Finally, if desired, an implementation of BP can easily allow for simultaneous event triggering, for example by triggering all (or some) of the events that were requested and not blocked, notifying all b-threads that requested or waited for any of them, and returning to each of the notified b-threads either the entire set of triggered events or just those relevant to it. EXCERPT #UX27JN p. 16 ### 18. Assistant That sounds like a particularly good use case for behavioral programming. The key design choice is: **don’t put every vehicle and critter into one globally synchronized behavioral program**. Give each entity—or occasionally each tightly coupled group—its own BP coordinator. ## A practical game architecture For each entity, run a local collection of coroutine b-threads: - **goal behavior:** follow route, find food, reach shelter; - **reactive behavior:** evade danger, avoid obstacles; - **social behavior:** follow leader, yield, attack, assist; - **physiological behavior:** hunger, fatigue, fear; - **safety behavior:** prohibit collisions, entering water, impossible turns; - **animation/interaction behavior:** play an animation, emit sound, reserve an object. Each coroutine reaches a synchronization point and declares something like: ```cpp co_await bp.sync({ .request = { MoveToward{target} }, .wait = { Arrived{}, PathFailed{}, ThreatSeen{} }, .block = { EnterTerrain{Terrain::DeepWater} } }); ``` The local scheduler selects an event that is requested and not blocked, then resumes every coroutine waiting for or requesting that event. C++20 coroutines are a natural implementation mechanism because each b-thread’s scenario state remains in ordinary local variables rather than being manually encoded as a state machine. ## Three levels of composition I would separate composition into three scales: ### 1. Within an entity A vehicle might contain: - `FollowRoute` - `MaintainSpeed` - `AvoidCollision` - `YieldAtJunction` - `FindFuel` - `RecoverWhenStuck` These behaviors do not issue motor forces directly. They negotiate over **semantic intents**, such as: ```text Accelerate Brake SteerToward(pathPoint) YieldTo(vehicle) StopAt(location) RequestNewRoute ``` This closely resembles Harel’s vehicle example: independent direction behaviors request moves that approach the destination, while additional advisor behaviors can block dangerous movement (#GJFFEZ, #A25NFW). ### 2. Between entities Inter-entity constraints should usually be represented by a world-level arbitrator or short-lived “advisor” behaviors: - reserve a road segment; - prevent two vehicles entering the same narrow passage; - establish right of way; - coordinate flocking or pack behavior; - reserve food, cover, or an interaction target. Harel’s examples add advisor threads that observe several vehicles and block unsafe movement without rewriting the original movement behavior (#S6XUMZ, #UPJHJT). That incremental composition is likely the most valuable property for your game: traffic rules, fear, weather responses, and creature ecology can be added as separate behavioral modules. ### 3. Between time scales Use BP for relatively low-frequency decisions and conventional systems for continuous execution: - **strategic BP:** migrate, hunt, patrol, refuel; - **tactical BP:** choose target, yield, flee, overtake; - **steering/controller:** produce velocity and orientation; - **physics:** integrate motion and resolve contacts. This is the game analogue of the quadrotor example, where slower behavioral decisions are separated from the faster conversion into actuator commands (#62X957, #UGV8G9). Trying to represent every physics substep as a globally negotiated BP event would probably be expensive and conceptually noisy. ## Tick and super-step model A deterministic game loop could be: 1. Take a read-only world snapshot. 2. Inject observations as external events. 3. Run each entity’s local BP program until it produces an `Intent` or reaches `Idle`. 4. Resolve conflicting world-level intents. 5. Apply accepted commands to navigation, animation, and physics. 6. Feed outcomes back on the next tick. Conceptually: ```text world snapshot ↓ observations ↓ local behavioral super-steps ↓ entity intents ↓ world arbitration/reservations ↓ steering and physics ↓ outcome events ``` This follows Harel’s super-step idea: external events enter at a defined boundary, while an ordered sequence of internal behavioral events is treated as occurring within one logical time unit (#QSEJNZ). It also gives you replayability because event selection can be logged and deterministic. ## One important modification for games Classical BP treats requests largely as sets, with event selection controlled by priority. Game agents often need **graded preference**, not only request/block: ```cpp request(MoveToward(food), weight = hunger); request(MoveToward(shelter), weight = fear); request(ContinuePatrol{}, weight = duty); block(EnterHazard{}) if (!desperate); ``` I would therefore distinguish: - **block** — a hard prohibition; - **request** — an admissible candidate; - **utility/priority** — preference among candidates; - **wait** — an event relevant to the coroutine. Hard blocking should be reserved for genuine invariants. If ordinary preferences are expressed as blocks, independently sensible critter behaviors will frequently deadlock. The smallest convincing prototype would be several vehicles on a road network, with one coroutine each for route following, collision avoidance, yielding, and fuel seeking. Once that works, the same scheduler can drive critters by replacing route and traffic behaviors with hunger, fear, territoriality, and social behaviors. ### 19. User Even without thinking about critters or these kinds of autonomous beings, if you think about something like the camera, the third-party camera that follows the player as the player is riding around in vehicles with different qualities and behaviors, that's really interesting. Also, something like when you're on a motocross doing a jump: you'll have some kind of predictor where the avatar appears to be judging the angle of impact and adjusting to minimize shock. I don't know. I think it is actually quite interesting to think about that, the physics. Maybe not every physics sub-step, but I'm trying to think about it. It's interesting what kind of events we would have. I mean, just the rules of the game, for example: when you ride your motocross into a jump and you're in the air for a little while, it enables the affordance of deploying a hang glider. The hang glider is also, I guess, automatically undeployed on landing, and a bunch of stuff like this. ### 20. Assistant tool calls #### Tool call: `read` ```json { "blocks": [ "VZ34LB", "BU6VQL" ], "expand": true } ``` ### 21. Tool result: read DOCUMENT #M5788P Towards Behavioral Programming in Distributed Architectures SECTION #VZ34LB 3.4.2. Game behaviors EXCERPT #ZFAK5L p. 19 Each behavior matches a single requirement, and is implemented as an Erlang function. The behavior functions are spawned to create the various b-threads. For readability, we tried to keep the code of the functions simple and straightforward. All the events are atoms. Each function fulfills a single role. We deliberately avoided generalizing several similar functions into a single parameterized function, in order not to burden the reader with a non-trivial design. Functions that were similar to ones listed below are omitted, in favor of a textual description. EXCERPT #BMZUPU p. 19 The first behavior reacts to events representing the user’s actions by requesting events representing rocket moves in the desired direction. For example, it translates the event user_left , to left . (In the general case the translation may be more complex, e.g., requesting several events per user command.) EXCERPT #WHKZU4 p. 19 EXCERPT #8UF9HS p. 20 Figure 5: Architecture of the rocket game application. The diagram shows a central 'b-node' box containing a 'queue', 'b-thread_1', ..., 'b-thread_n', and an 'idler'. Outside the box are 'rocket', 'landing pad', 'GUI', and 'ticker'. Solid arrows represent native Erlang messages: 'rocket' to 'landing pad' (labeled 'motion commands'), 'rocket' to 'queue' (labeled 'redraw'), 'GUI' to 'queue' (labeled 'player's actions'), and 'ticker' to 'queue' (labeled 'ticks'). Dashed arrows represent triggering and waiting for behavioral events: from 'queue' to 'b-thread_1' (labeled 'idle'), from 'queue' to 'idler' (labeled 'idle'), from 'b-thread_1' to 'queue' (labeled 'behavioral events'), and from 'idler' to 'queue' (labeled 'behavioral events for player's actions'). EXCERPT #JGQ7C3 p. 20 Figure 5: Architecture of the rocket game application. Solid arrows mark native Erlang messages. Dashed arrows mark triggering and waiting for behavioral events. Boxes are processes. The processes inside the b-node box are b-threads. EXCERPT #A9DGWL p. 20 The following set of behaviors is responsible for actuating the movement of the rocket. The go_left b-thread describes how the rocket is moved to the left. The scenario repeatedly waits for the behavioral event left , and once triggered (i.e., the operation is allowed), it calls the function rocket:left() . Moving right or down are similar. EXCERPT #HRUMK5 p. 20 go_left() -> bp:bSync(#rbw{wait=[left]}), rocket:left(), go_left(). EXCERPT #FYSAF7 p. 20 The on_tick behavior below repeatedly waits for a tick and then requests the event representing the rocket moving down, while also waiting for tick events in order to detect the case where the down event could not be triggered. EXCERPT #XBF6PH p. 20 on_tick() -> bp:bSync(#rbw{wait=[tick]}), bp:bSync(#rbw{request=[down], wait=[tick]}), on_tick(). EXCERPT #ZA9UAB p. 20 In addition to moving the rocket sideways, we also want to allow the player to simulate an exhaust burst that delays the fall, by suspending the movement for one turn. The go_up behavior responds to the up event, and suspends the rocket by blocking its downward movement until the next tick. EXCERPT #LDR3L2 p. 20 go_up() -> bp:bSync(#rbw{wait=[up]}), bp:bSync(#rbw{wait=[tick]}), bp:bSync(#rbw{wait=[tick], block=[down]}), go_up(). EXCERPT #FXZJZN p. 20 EXCERPT #4AS4KT p. 21 We would now like to add some restrictions to the game. The following behavior prevents the rocket from moving beyond the left-hand side of the game board. EXCERPT #CFESGT p. 21 on_left_bound(X) -> % X: rocket's horizontal location if X == 0 -> bp:bSync(#rwb{wait=[right], block=[left]}), on_left_bound(1); true -> case bp:bSync(#rwb{wait=[left, right]}) of left -> on_left_bound(X-1); right -> on_left_bound(X+1) end end. end. EXCERPT #56QM7K p. 21 When the rocket is at the left bound it blocks the left event until the rocket moves right. Otherwise the b-thread tracks the rocket's location based on the left and right events it observes. EXCERPT #2PLGE3 p. 21 The right-hand border is similar, with the 0 coordinate being replaced by some limit M , and changing event names accordingly. Preventing the rocket from moving below the bottom border is done by checking the vertical, rather than horizontal, position of the rocket and blocking the down event when 0 is reached. EXCERPT #QEMY5Q p. 21 To make the game less trivial, we want to prevent the rocket from making too many maneuvers. To this end, we limit its movement to at most one step left or right per turn. It waits for a tick and any move. After a move, other moves are blocked until a tick occurs again. Once a tick occurs, both moves are re-allowed (the blocked events set is empty). EXCERPT #DX95S7 p. 21 block_mult_moves(Block) -> Moves = [user_left, user_right], case bp:bSync(#rwb{wait=[tick|Moves], block=Block}) of user_left -> block_mult_moves(Moves); user_right -> block_mult_moves(Moves); tick -> block_mult_moves([]) end. end. EXCERPT #Q3YCZT p. 21 The behaviors that control the movement of the landing pad are similar to the ones handling the rocket, with one difference: the landing pad is not controlled by the player, but moves at random. After each tick, it requests that the pad be moved in a random direction, or not at all. This behavior is achieved by picking a random element E , that is pad_left , pad_right or an empty list, and calling bp:bSync(#rwb{wait=[tick], request=[E]}) , followed by waiting for a tick if the pad moved before the end of the turn. EXCERPT #CMY9TJ p. 21 Finally, the following behaviors deal with the winning or losing. Note that the detect_win_lose function below keeps track of the entire game board solely by listening out for movement events. This redundancy with the tracking of rocket and landing pad positions in the b-threads rocket and landing_pad might seem wasteful, and one may prefer to encapsulate this functionality. However this design prevents potential race conditions associated to accessing shared resources (see additional discussion of race conditions in Section 6). This choice reflects the preference, in BP, to have b-threads depend as much as possible on events that are meaningful in the overall external behavior of the system, as opposed to requiring specialized inputs from internal components. Nevertheless, it may be fully desirable and appropriate to create such special events, by a central service, and broadcast them for use by all interested b-threads. This can be done for object tracking in our case, and especially, for example, when communicating exact positions that are determined and updated by a GPS. EXCERPT #RVTCFZ p. 21 EXCERPT #G3WL4J p. 22 detect_win_lose(P, X, Y) -> case bp:bSync(#rwb{wait=[pad_left, pad_right, left, right, down]}) of pad_left -> detect_win_lose(P-1, X, Y); pad_right -> detect_win_lose(P+1, X, Y); left -> detect_win_lose(P, X-1, Y); right -> detect_win_lose(P, X+1, Y); down -> Y1 = Y-1, if Y1 == 1 andalso X == P -> bp:bSync(#rwb{request=[win]}); Y1 == 0 -> bp:bSync(#rwb{request=[lose]}); true -> detect_win_lose(P, X, Y1) end end end. EXCERPT #J38JL9 p. 22 Another b-thread (not shown) ends the game by waiting for the win or lose events, and then blocking all movement events indefinitely. The program ends when the user closes the application window. EXCERPT #WGYA95 p. 22 Summary. We have illustrated an application being decomposed into b-threads, using the super-step idea, where external events were triggered as behavioral events after all the internal events of a super-step were completed. The power of BP in handling rich scenarios can be further demonstrated in this example, by replacing the short b-thread implementing the random move of the pad by a lengthy sequence of predetermined right- and left-moves of the landing pad, which represent some covert plan of an adversary played by the computer. EXCERPT #LDVN2Y p. 22 For simplicity, this example is implemented in a single b-node. In a richer game, components like the rocket and the pad could be programmed in separate b-nodes. Nevertheless, note that some of the game rules do require synchrony between different behaviors with regard to time ticks, and this was readily implemented in the single b-node setup. DOCUMENT #M5788P Towards Behavioral Programming in Distributed Architectures SECTION #BU6VQL 3.3. Accommodating behaviors at different time scales EXCERPT #W66B89 p. 17 Many applications that include behaviors of different time-scales can be decomposed as follows. The application is divided into groups of behaviors, with all behaviors in a group being on the same time-scale. If desired, such groups can be further broken down into sub-groups; e.g., by physical components or specific relevant events. Note that the behaviors in each such sub-group are, by definition, of the same time-scale. In the context of BP we call such a group of behaviors a behavior node , or b-node , for short. The work shown here is a continuation and generalization of the InterPlay tool that was designed to allow coordinated execution of multiple LSC and statechart specifications [6]. EXCERPT #8QC38U p. 17 All the b-threads in each b-node run in a synchronized manner, as described in Section 2. In actuality, the b-threads in a b-node may run on multiple cores or, when the time scale allows, on multiple computers, where the execution environment (e.g., native operating system, JVM, Erlang, etc.) facilitates the constant inter-b-thread synchronization implemented in the BP collective-execution mechanism. Here we focus on inter -b-node coordination and not on intra -b-node parallelism. EXCERPT #BR49H5 p. 17 Each event generated by the environment is processed by a designated b-node, as described in Section 3.2. Communication between b-nodes is carried out only through external events, which can be sent and received by all behavioral programs in a consistent and standard way, as follows: EXCERPT #R8NRGQ p. 17 • Send: In each b-node, a designated b-thread waits for certain internal behavioral events, and then transmits a corresponding external event to the desired destination, or broadcasts it to all other b-nodes using some (non BP) protocol. • Receive: Per the design in Section 3.2, for each b-node, a designated non-behavioral process listens to all external events directed at that b-node, and places them in a single queue associated with this receiving b-node. A designated b-thread in this b-node peeks at the queue at the end of each super-step and requests a corresponding behavioral event. B-threads that depend on external events are programmed (behaviorally) to wait for the corresponding behavioral event. EXCERPT #X7KLPF p. 17 Note that the result of an incoming external event could be that some of the b-node’s b-threads decide to block certain events internal to the node, until some specific other external event arrives. This allows one b-node to cause the blocking of events in other b-nodes. Since blocking is central to the incrementality afforded by BP, the ability to propagate event-blocking is an important feature of the proposed decentralized architecture. EXCERPT #XMS7E2 p. 17 This design for communication between behavioral programs reflects several choices that we believe are common and natural in development situations. First, consider a b-node busily working autonomously. When an external event arrives, which is expected to change the behavior of the node, it is acceptable that one or more events of the b-thread’s autonomous behavior be triggered before the new course of action is taken. This form of inertia is commonly observable not only in the physical world and in typical human handling of interrupts (“please just let me finish sending this email, and I’ll be right with you”), but also in the delays tolerated when sensing events or handling interrupts in computer systems. EXCERPT #Y47Z33 p. 17 EXCERPT #YVYFUK p. 18 The second choice is that even a node that wishes to be extremely attentive to external events should not be synchronized with the source of those events, the way, e.g., that b-threads are synchronized within a b-node. Consider a corporation, and a manager-employee analogy for the relationship between two b-nodes. Employees who follow their managers everywhere in order to be ready to respond quickly to new requests may be inefficient and disruptive. Put differently, excessive synchronization between b-nodes can greatly increase the computational overhead in the system. We believe that the proposed design nicely balances the use of autonomous behavioral components with efficiency. In particular, we expect that the delay in reacting to messages will be tolerable in a computer application that is properly decomposed according to behaviors (similarly to the case of a corporation). EXCERPT #GXE6SM p. 18 We believe that this combination of (1) synchrony within a b-node, (2) asynchronous communication between b-nodes, and (3) translation of asynchronous messages and events back into behavioral events in each receiving b-node, allows one to retain the natural and incremental application development offered by BP, while overcoming some of the performance constraints associated with synchronizing many b-threads. ### 22. Assistant tool calls #### Tool call: `write_note` ```json { "block_ids": [ "W66B89", "QSEJNZ", "NDD374", "CMY9TJ" ], "text": "For the game architecture, BP may be most valuable beyond autonomous NPCs: camera behavior, vehicle/avatar coordination, landing anticipation, and transient affordances are cross-cutting reactive scenarios. Decompose by time scale as b-nodes (#W66B89): physics remains continuous; a predictor derives qualitative transition events (AirborneStarted/Ended, ImpactRiskBecameHigh/Low, LandingImminent) with hysteresis; BP negotiates semantic directives; low-level controllers realize camera pose, animation, or bounded vehicle torque. Treat each game tick as a super-step boundary (#QSEJNZ). Distinguish observation events, player-intent events, proposed directives, committed actions, and outcome events. Persistent conditions should use enter/exit events or snapshots rather than repeated pulse events. For camera composition, b-threads can request directives such as frame-player, show-landing-zone, widen-FOV, avoid-occlusion, and stabilize-horizon; accumulate compatible directives during a super-step and use a low-priority CommitCameraPlan event, analogous to the quadrotor RPM output step (#NDD374), then solve the continuous camera pose conventionally. Hang-glider deployment is cleanly decomposed into an input translator requesting DeployGlider, independent eligibility/safety b-threads blocking it when conditions fail, a deployment sequence coordinating vehicle/avatar/glider state, and an auto-stow behavior requesting StowGlider on landing. Prefer semantically meaningful broadcast events over components reading each other's mutable internals, consistent with #CMY9TJ.", "title": "Behavioral programming for camera, vehicle jumps, and transient affordances" } ``` ### 23. Tool result: write_note NOTE SAVED #BQL2KS IRI: https://m.sheaf.less.rest/BQL2KS ### 24. Assistant Yes—this may be a more revealing BP use case than autonomous critters. Camera behavior, vehicle control, avatar animation, and equipment affordances are **cross-cutting scenarios**: each reacts to the same physical situation but contributes a different requirement. The important distinction is between: 1. continuous physical state; 2. meaningful events derived from it; 3. behavioral decisions; 4. continuous controllers that realize those decisions. ## Physics should produce semantic events I would not turn every physics step into a behavioral event. Instead, a predictor or observer watches the continuous simulation and emits **qualitative transitions**: ```text VehicleMounted(motocross) TakeoffDetected AirborneStarted AirtimeBecameLong LandingPredicted(time, point, normal, pitchError, impactSpeed) ImpactRiskBecameHigh LandingImminent GroundContact StableLanding CrashStarted ``` The distinctions matter. `AirborneStarted` is an event; “airborne” is a persistent condition. You can represent that condition either by: - paired `AirborneStarted` / `AirborneEnded` events remembered by b-threads; or - a read-only physics snapshot supplied at the beginning of each game tick. Predictions that fluctuate should be quantized and given hysteresis. Rather than emitting `LandingPredictionUpdated` 120 times per second, emit events such as: ```text PitchErrorBecameNoseHigh PitchErrorEnteredSafeRange ImpactRiskBecameSevere TimeToImpactCrossed(0.5s) ``` That gives the behavioral layer a stable vocabulary. ## Landing anticipation has several separate behaviors The motocross jump could involve independently composed b-threads: - **Landing predictor:** estimates impact time, orientation, and impulse. - **Avatar anticipation:** requests `LookTowardLanding`, `BraceForImpact`, or weight-shift animations. - **Landing assist:** requests bounded forward/backward pitch correction. - **Player-control protection:** blocks automatic corrections that would overpower deliberate input. - **Camera anticipation:** requests visibility of the predicted landing area. - **Crash presentation:** changes camera and animation behavior when safe recovery is no longer plausible. The actual pitch correction should remain a continuous controller. BP selects an intention such as: ```text CorrectNoseDown(strength) CorrectNoseUp(strength) HoldAttitude DisableLandingAssist ``` A conventional controller then converts that into a bounded torque. This also lets the avatar *appear* to judge the landing—head direction, posture, and weight shift can anticipate impact—even if the physical assistance is weak or disabled. That separation would let you tune player agency independently from presentation. ## The camera is itself a behavioral composition A third-person camera has many simultaneous requirements: - keep the player visible; - look ahead in the direction of travel; - show the landing zone; - avoid terrain occlusion; - stabilize the horizon; - widen the field of view at speed; - avoid abrupt angular acceleration; - emphasize long airtime; - recover smoothly after landing; - frame both player and vehicle during mounting or dismounting. These requirements should not each set the camera transform directly. They should request **camera directives**: ```text Frame(Player) Include(PredictedLandingPoint) PreferHeading(VelocityDirection) StabilizeHorizon(weight) SetDistanceRange(min, max) SetFovRange(min, max) AvoidOcclusion(Terrain) LimitAngularAcceleration(value) EnterShotMode(Jump) ``` During one logical tick, camera b-threads can contribute directives. A low-priority `CommitCameraPlan` event then ends the behavioral super-step, and a conventional camera solver finds a pose satisfying the accumulated constraints. This resembles the quadrotor controller’s incremental negotiation followed by one output event (#NDD374). So BP composes the **meaning of the shot**; springs, collision sweeps, and optimization produce the actual camera transform. ## Hang-glider deployment is an affordance scenario The hang glider illustrates a useful BP distinction between **requesting an action** and **making it permissible**. Separate behaviors might be: ### Input translation ```text DeployButtonPressed → request DeployGlider ``` ### Eligibility Block `DeployGlider` unless: ```text player is airborne ∧ sufficient ground clearance ∧ glider is owned ∧ current vehicle permits aerial dismount ∧ player is not already crashing ∧ there is enough space to open it ``` ### Deployment sequence Once `DeployGlider` is selected: ```text LockVehicleInput DetachAvatarFromVehicle TransferMomentum OpenGlider TransferPlayerControl GliderDeployed ``` ### Landing rule ```text GliderDeployed + GroundContact → request StowGlider ``` ### Exceptional rules Other b-threads could independently add: ```text UnderLowCeiling → block DeployGlider ImpactImminent → block DeployGlider EnteredWater → request EmergencyRelease GliderDamaged → block DeployGlider ScriptedSequence → block DeployGlider ``` That is where BP becomes attractive: the input handler does not need to know all the reasons deployment might be forbidden. New restrictions can be introduced by adding b-threads rather than editing a central conditional. ## A useful event taxonomy I would make the event type system distinguish five categories: | Category | Examples | |---|---| | **Observation** | `AirborneStarted`, `GroundContact`, `OcclusionStarted` | | **Player intent** | `DeployPressed`, `BrakePressed`, `CameraResetRequested` | | **Behavioral proposal** | `DeployGlider`, `BraceForImpact`, `EnterJumpShot` | | **Committed action** | `GliderDeploymentAuthorized`, `CameraPlanCommitted` | | **Outcome** | `GliderOpened`, `StableLanding`, `DeploymentFailed` | This prevents a common ambiguity: does `DeployGlider` mean that the player asked, that the behavioral system approved it, or that the animation and entity transition actually completed? ## Likely decomposition I would organize this as several b-nodes operating at different rates: ```text Physics and prediction 60–120 Hz ↓ semantic observations Vehicle/avatar BP 20–60 Hz Camera BP 20–60 Hz Equipment/affordance BP event-driven ↓ committed directives Steering, camera, animation 60–120 Hz ``` That follows the paper’s recommendation to group synchronized behaviors by time scale while communicating asynchronously between groups (#W66B89). Each game tick can serve as a super-step boundary (#QSEJNZ). The deeper principle is: **events should name changes in the gameplay situation, not merely changes in numerical state**. Physics tells you that contact distance crossed zero; the game event says `Landed`. Prediction says the expected impact impulse crossed a threshold; the behavioral event says `HardLandingImminent`. Those semantic events are what make independently written camera, avatar, vehicle, and equipment scenarios composable. I saved this architecture as research note #BQL2KS. ### 25. User I actually find that the non-separation of events and commands in the formulation of behavioral programming is a little bit confusing. ### 26. Assistant tool calls #### Tool call: `read` ```json { "blocks": [ "SKTV48", "RAU5LM", "KWNH5E" ], "expand": true } ``` ### 27. Tool result: read DOCUMENT #M5788P Towards Behavioral Programming in Distributed Architectures SECTION #SKTV48 2.9.1. B-Threads EXCERPT #PBEYQU p. 8 In the following definitions we implicitly assume a given set \Sigma of events . A behavior thread ( b-thread ) BT is defined to be a tuple BT = \langle Q, q_0, \delta, R, B \rangle , where Q is a set of states, q_0 \in Q is an initial state , \delta : Q \times \Sigma \rightarrow Q is a transition function , R : Q \rightarrow \mathcal{P}(\Sigma) assigns to each state a set of requested events , and B : Q \rightarrow \mathcal{P}(\Sigma) assigns to each state a set of blocked events . EXCERPT #TAD8GZ p. 8 EXCERPT #DUW8A7 p. 9 Note that in these definitions, a b-thread's transition rules are given as a deterministic , single valued, function \delta , assigning the next state given a state and an event triggered in that state. A natural variant in which the transitions are nondeterministic , is defined analogously; see Appendix C. Since behavioral programs may contain rich functionality beyond their state transitions, the nondeterministic transitions can be a useful abstraction for describing transitions that are based on auxiliary information. For instance, consider a b-thread currently in state s_1 , waiting for event e_1 which represents a temperature measurement by a sensor. When e_1 is observed, the thread transitions into either state s_2 or s_3 based on the actual value of the measurement. The abstraction of the transition as nondeterministic, is thus a convenience, where the alternatives include distinguishing events with different temperatures as totally different events, or adding guard conditions to the transitions, as is common in other formalisms, such as statecharts [20]. Abstracting transitions as nondeterministic is also useful when a thread chooses the next state at random; say, to create a mix of certain actions. EXCERPT #R32BGQ p. 9 Also note that in the formal definition of a b-thread, there is no need to distinguish between events that are waited-for by the thread, and those that are not. In any of the thread's states, an event that is not waited-for can be captured by a transition that forms a self-loop; i.e., a transition that does not leave the state. DOCUMENT #M5788P Towards Behavioral Programming in Distributed Architectures SECTION #RAU5LM 2.9.2. Behavioral Programs EXCERPT #7MFMHL p. 9 Observe a set \{BT^1, \dots, BT^n\} of b-threads, where n \in \mathbb{N} and each BT^i = \langle Q^i, q_0^i, \delta^i, R^i, B^i \rangle is a distinct b-thread. A behavioral program P comprised of these threads is a deterministic labeled transition system (LTS) [33], defined as follows. P = \langle Q, q_0, \delta \rangle , where Q := Q^1 \times \dots \times Q^n is the set of states, q_0 := \langle q_0^1, \dots, q_0^n \rangle \in Q is the initial state, \delta : Q \times \Sigma \rightarrow 2^Q is a deterministic transition function (i.e., one whose range includes only singletons and the empty set), defined for all q = \langle q^1, \dots, q^n \rangle \in Q and a \in \Sigma , by EXCERPT #2AQFXU p. 9 \delta(\langle q^1, \dots, q^n \rangle, a) := \begin{cases} \{ \langle \delta^1(q^1, a), \dots, \delta^n(q^n, a) \rangle \} & \text{if } a \in E(q) \\ \emptyset & \text{otherwise} \end{cases} EXCERPT #EX4TXE p. 9 Here E(q) = \bigcup_{i=1}^n R^i(q^i) \setminus \bigcup_{i=1}^n B^i(q^i) is the set of enabled events at state q . EXCERPT #YCEFVW p. 9 An execution of the behavioral program P is an execution of the induced LTS. The latter is executed starting from the initial state q_0 . In each state q \in Q , an enabled event a \in \Sigma is selected for triggering if such an event exists (i.e., an event a \in \Sigma for which \delta(q, a) \neq \emptyset ). Then, the system moves to the next state q' \in \delta(q, a) , and the execution continues. Such an execution can be recorded as a possibly infinite sequence of triggered events, called a run . The set of all complete runs is denoted by \mathfrak{L}(P) . It contains either infinite runs, or finite ones that terminate in a state in which no event is enabled, called a terminal state . EXCERPT #C7LPAL p. 9 As noted in subsection 2.1, when multiple events are requested and not blocked, the semantics does not specify which one will be chosen and a variety of techniques can be implemented. Further, in Section 3.2 we discuss why the chosen semantics does not allow the simultaneous triggering of multiple events. EXCERPT #G28F7V p. 9 DOCUMENT #TDS4H2 Relaxing Synchronization Constraints in Behavioral Programs SECTION #KWNH5E 2.1 Behavioral Programming Formalized EXCERPT #ZPB38G p. 2 While behavioral programming is geared toward natural and intuitive development using programming languages, its underlying infrastructure can be conveniently class Dispenser : public BThread { void entryPoint() { while ( true ) { bSync( none, {CoinInserted}, none ); bSync( none, {ProductChosen}, {CoinInserted} ); bSync( {ProvideProduct}, none, {CoinInserted} ); } } }; EXCERPT #WXS7T6 p. 3 Fig. 1: The Dispenser thread. This thread is responsible for dispensing wares, after the user inserts a coin and selects a desired product. The programmer writes behavioral code by overriding the method entryPoint of class BThread . The thread runs in an infinite loop, invoking the synchronization API bSync three times in each iteration: each invocation corresponds to a synchronization point, and includes three sets of events: requested (blue), waited-upon (green) and blocked (red). In the first synchronization point, the thread waits for a coin insertion, signified by a CoinInserted event. In the second, it waits for product selection, signified by a ProductChosen event. Finally, in the third, it dispenses the product, by requesting a ProvideProduct event. Since each call suspends the thread until an event that was requested or waited-for is triggered, one product is dispensed per coin; also, it is impossible to obtain the product without inserting a coin. Observe that the thread also blocks CoinInserted events during its last two synchronization points; otherwise, extra coins inserted before a product is provided could be swallowed by the machine. EXCERPT #7EBPX8 p. 3 while ( true ) { waitForCoinInsertion(); bSync( {CoinInserted}, none, none ); waitForProductSelection(); bSync( {ProductChosen}, none, none ); } EXCERPT #2K6PUU p. 3 Fig. 2: The main method of the KeyPad thread. This thread is an input “sensor” — a thread responsible for receiving inputs from the environment and translating them into BP events. It waits for the user to insert a coin and then requests a CoinInserted event. Then, it waits for the user to select a product, and requests a ProductChosen event. Coin insertions and product selections are inputs coming from the environment, and are abstracted away inside the functions waitForCoinInsertion and waitForProductSelection . The thread translates these inputs into events that are to be processed by other threads. EXCERPT #V238NV p. 3 described and analyzed in terms of transition systems. We present an abstract formalization of behavioral programs and their semantics, similarly to [9, 11]. EXCERPT #HC3GKG p. 3 In the following definitions we implicitly assume a given set \Sigma of events . A behavior thread ( b-thread ) BT is abstractly defined to be a tuple BT = \langle Q, q_0, \delta, R, B \rangle , where Q is a set of states , q_0 \in Q is an initial state , \delta : Q \times \Sigma \rightarrow Q is a transition function , R : Q \rightarrow \mathcal{P}(\Sigma) assigns for each state a set of requested events , and B : Q \rightarrow \mathcal{P}(\Sigma) assigns for each state a set of blocked events . A behavioral program P is defined to be a finite set of b-threads. EXCERPT #RG9E7X p. 3 Note that in the definitions above, a b-thread’s transition rules are given as a deterministic , single valued, function \delta , assigning the next state given a state and an event trigger in that state. A natural variant in which the transitions are nondeterministic is analogously defined; see Appendix II of the supplementary material [2]. The latter is useful for reactive systems, where the next state might also depend on external input. Also note that in the formal definition of a b-thread, there is no need to distinguish between events that are waited-upon by the thread, and those that are not. In any of the thread’s states, an event that is not waited-upon can be captured by a transition that forms a self-loop; i.e., a transition that does not leave the state. EXCERPT #7FT7NC p. 4 while ( true ) { bSync( none, {ProvideProduct}, none ); provideActualProduct(); } EXCERPT #CSWC43 p. 4 Fig. 3: The main method of the ProductSlot thread. This thread is an output “actuator”; it is responsible for translating ProvideProduct events into the dispensing of actual products. Thus, it waits for a ProvideProduct event, and then provides the product by invoking provideActualProduct . EXCERPT #FWYRR4 p. 4 Semantics Let P = \{BT^1, \dots, BT^n\} be a behavioral program, where n \in \mathbb{N} and each BT^i = \langle Q^i, q_0^i, \delta^i, R^i, B^i \rangle is a distinct b-thread. In order to define the semantics of P , we construct a deterministic labeled transition system (LTS) [12] denoted by \text{LTS}(P) , which is defined as follows. \text{LTS}(P) = \langle Q, q_0, \delta \rangle , where Q := Q^1 \times \dots \times Q^n is the set of states, q_0 := \langle q_0^1, \dots, q_0^n \rangle \in Q is the initial state, \delta : Q \times \Sigma \rightarrow 2^Q is a deterministic 1 transition function, defined for all q = \langle q^1, \dots, q^n \rangle \in Q and a \in \Sigma , by EXCERPT #XNNFZY p. 4 \delta(\langle q^1, \dots, q^n \rangle, a) := \begin{cases} \{ \langle \delta^1(q^1, a), \dots, \delta^n(q^n, a) \rangle \} & \text{; if } a \in E(q) \\ \emptyset & \text{; otherwise.} \end{cases} EXCERPT #NYYHYB p. 4 where E(q) = \bigcup_{i=1}^n R^i(q^i) \setminus \bigcup_{i=1}^n B^i(q^i) is the set of enabled events at state q . EXCERPT #S96RYY p. 4 An execution of P is an execution of the induced \text{LTS}(P) . The latter is executed starting from the initial state q_0 . In each state q \in Q , an enabled event a \in \Sigma is selected for triggering if such exists (i.e., an event a \in \Sigma for which \delta(q, a) \neq \emptyset ). Then, the system moves to the next state q' \in \delta(q, a) , and the execution continues. Such an execution can be formally recorded as a possibly infinite sequence of triggered events, called a run . The set of all complete runs is denoted by \mathfrak{L}(P) := \mathfrak{L}(\text{LTS}(P)) . It contains either infinite runs, or finite ones that terminate in a state in which no event is enabled, called a terminal state . ### 28. Assistant tool calls #### Tool call: `write_note` ```json { "block_ids": [ "PBEYQU", "EX4TXE", "YCEFVW", "2K6PUU", "CSWC43" ], "text": "The user's concern that BP conflates events and commands is substantive. Classical BP deliberately uses one alphabet Σ (#PBEYQU): b-threads request and block labels, enabled labels are requested minus blocked (#EX4TXE), and a run is a sequence of selected/triggered labels (#YCEFVW). At the system boundary this makes a label ambiguous: the C++ example has a sensor thread translate an already-occurring physical input into a requested CoinInserted BP event (#2K6PUU), while an actuator waits for selected ProvideProduct and then performs the physical action (#CSWC43). For a game-oriented coroutine BP, use a typed causal vocabulary: (1) Observation/fact—uncontrollable, injected from physics/input, broadcast and never blockable; (2) Proposal/intent—a controllable candidate requested by behaviors; (3) Decision/commitment—the scheduler's selected proposal; (4) Outcome—uncontrollable completion/failure observation from execution; optionally (5) internal coordination signal. Formally partition Σ = Σ_u ⊎ Σ_c. Blocks apply only to Σ_c; external observations in Σ_u first advance interested b-threads, then the scheduler selects controllable proposals. Example: DeployPressed [observation] -> DeployGlider [proposal] -> DeployGliderCommitted [decision] -> GliderOpened or DeploymentFailed [outcome]. This preserves BP composition and trace semantics while making causality and authority explicit.", "title": "Split observations from commands in a game-oriented BP semantics" } ``` ### 29. Tool result: write_note NOTE SAVED #EZBYH4 IRI: https://m.sheaf.less.rest/EZBYH4 ### 30. Assistant Yes. The confusion is real, and it comes from BP deliberately collapsing several causally different things into one formal alphabet $\Sigma$. Formally, every item is simply an “event.” B-threads request and block events; the scheduler selects one requested, unblocked event; and the system’s execution is the resulting event sequence (#PBEYQU, #EX4TXE, #YCEFVW). That is elegant for trace semantics and model checking, but muddy at the boundary of a physical or simulated world. The examples expose the ambiguity: - A sensor receives a physical input and then **requests** `CoinInserted`, although the coin insertion has already happened (#2K6PUU). - An actuator waits for `ProvideProduct` and only afterward performs the physical action (#CSWC43). Thus, one “event” represents an observation of the past, while another represents authorization for a future action. ## A more causally explicit model I would separate at least four categories: | Kind | Meaning | Can be requested? | Can be blocked? | |---|---|---:|---:| | **Observation** | Something has happened in input, physics, or the world | No | No | | **Proposal** | A behavior suggests an action | Yes | Yes | | **Decision** | The scheduler commits to a proposal | Produced by scheduler | No | | **Outcome** | The attempted action completed, failed, or was interrupted | No | No | For example: ```text DeployPressed observation DeployGlider proposal DeployGliderCommitted decision GliderOpened outcome DeploymentFailed(reason) outcome ``` The causal sequence becomes: ```text world/input ↓ observation behavioral reaction ↓ proposals and vetoes scheduler ↓ decision actuator/game system ↓ outcome behavioral reaction ``` ## Why “blocking an event” is especially confusing Suppose physics reports `GroundContact`. A behavior cannot prevent that contact from having happened. It may: - suppress its propagation; - decline to interpret it as a landing; - block a subsequent command; - request a corrective action. But saying that it “blocks `GroundContact`” confuses control over the model with control over reality. Likewise, if the player presses the glider button, another behavior cannot block the button press. It can block the proposed `DeployGlider` command. So this: ```text DeployPressed → propose DeployGlider NearGround → veto DeployGlider ``` is clearer than treating both `DeployPressed` and `DeployGlider` as interchangeable selectable events. ## A typed coroutine API The distinction could appear directly in the C++ API: ```cpp co_await bp.react({ .observe = { AirborneStarted{}, DeployPressed{} }, .propose = { DeployGlider{} }, .veto = { EnterVehicle{} } }); ``` Or more strongly: ```cpp Observation Proposal Decision Outcome Outcome ``` The type system could prevent: - proposing an observation; - vetoing an unavoidable physical fact; - treating a proposal as if it had already executed; - treating a committed command as a successful outcome. ## Formal refinement The event alphabet can be partitioned: $$ \Sigma = \Sigma_u \mathbin{\dot{\cup}} \Sigma_c $$ where: - $\Sigma_u$ contains **uncontrollable observations and outcomes**; - $\Sigma_c$ contains **controllable proposals**. Blocking applies only to $\Sigma_c$. At each game tick: 1. observations from $\Sigma_u$ advance the relevant b-threads; 2. b-threads declare proposals and vetoes over $\Sigma_c$; 3. the scheduler selects one or more admissible proposals; 4. selected proposals become decisions; 5. ordinary game systems execute them and later publish outcomes. This resembles supervisory control more than classical undifferentiated BP, but it preserves the important BP idea: independent behaviors jointly constrain what the system may do. There may also be a fifth category—**internal coordination signals**—for tokens such as `CameraPlanReady` or `LandingSequenceEntered`. Those are neither external facts nor physical commands. Keeping them explicitly internal avoids giving every synchronization token the ontological weight of a world event. For your game, I think this typed causal version is preferable. The original unified “event” model is useful as an abstract trace calculus; it should not dictate the vocabulary of the engine architecture. I saved this distinction in note #EZBYH4.