Flatfingers wrote: ↑Tue Jul 25, 2017 3:15 pm
I'm imagining the "project" as the core concept for all NPC AI. Some particular features might actually be implemented using unique code systems -- a 3D, field-aware variant of A* for pathfinding, perhaps -- but
conceptually it feels satisfying to me to think of every namable decision-making operation for NPCs as a "project."
The nice thing about this approach is that it offers a simple but powerful way to address what I believe will be the single most important (i.e., fun) aspect of NPC AI in LT: delegation. And that's done by saying that a Project is composed of Tasks (atomic actions performed by activating a game verb) and Goals (a detectable game-state condition). (There'll also need to be a way to specify resource inputs and outputs, and probably a simple way to specify conditionals, but those aren't what's important to this conversation.)
Following this structure, the AI for NPCs in LT is defined as "whatever allows an NPC to decide how to satisfy the Goal(s) of a Project."
And one of those tools is delegation, which will be the AI system with which an NPC 1) breaks down a Goal into smaller Goals and/or Tasks, and 2) assigns all of those decomposed Goals and/or Tasks to some or all of the NPCs under this NPC's direct factional management. Note that any delegated work more complex than a single Task can be treated as a Project, which itself can be decomposed or delegated. (Note also that the NPC itself counts as "managed" for the purposes of delegation -- a solo NPC will break down a Project's Goals until they're all atomic-level Tasks, and assign all of those Tasks to itself.)
As each Task is completed, its result is rolled up to the owner of the Project that included that Task or the Goal from which that Task was delegated. Eventually the satisfaction conditions of the Goal of the top-level Project are either satisfied, in which case the output resources are awarded, or the Goal's satisfaction conditions are failed or flagged as unsatisfiable, in which case any penalties associated with the failure of the Project's Goal are imposed.
Something I read today reminded me of this.
Apparently there's this thing called
Plasma, which is a proposed mechanism for enforcing trusted contracts using Ethereum, which seems to be a kind of competitor technology to Bitcoin. I won't pretend to understand more than every other word in this stuff. ("Merkle proofs?" And the "Nakamoto Consensus" sounds like the title of a spy thriller.)
But this part -- this sounded weirdly familiar:
This construction is achieved by composing smart contracts on the main blockchain using fraud proofs whereby state transitions can be enforced on a parent blockchain. We compose blockchains into a tree hierarchy, and treat each as an individual branch blockchain with enforced blockchain history and MapReducable computation committed into merkle proofs. By framing one's ledger entry into a child blockchain which is enforced by the parent chain, one can enable incredible scale with minimized trust (presuming root blockchain availability and correctness).
Solving for overall satisfaction by trusted decomposition into individually solvable transactions sounds like recursive projects to me. And fraud proofs sure sound like state-based project satisfaction conditions. And the idea of projects as systemically-enforced contracts seems like an idea someone
might have described 13 years ago for strangers playing together in an MMORPG.
Bearing in mind that all analogies are imperfect, am I the only one seeing some interesting conceptual similarities here regarding technical solutions for enabling trustable productive contracts?