That sparked some interesting exchanges. So I thought I'd give it its own thread to keep that discussion focused and let the Announcements thread be more announcy.
It's a question about extensibility.JoshParnell wrote:Projects are organized into hard categories because there is a one-to-one mapping between a type of project, a major gameplay mechanic, and an AI implementation of a task. So you can't create a new type of project, because that would require creating a new game mechanic as well as implementing the AI for it. E.g., "Farming" is not a project that we can create because there is no way to cultivate crops in LT at the moment, nor does the AI understand that concept It is certainly possible to customize the parameters of a project to your liking, as well as to create groups of projects that work together as a composite to achieve a complex goal. Still, at the end of the day everything needs to be broken down into existing units of gameplay
But I'm curious what you had in mind in terms of 'free-form' project?
In my Player Contracts design from way back when, I also defined a specific, hardcoded set of contract types. So I'm certainly not criticizing how you're thinking of projects.
While similar, though, I do think there's an important difference between these contract and project systems: where projects are keyed to specific gameplay mechanics, my contracts were keyed to satisfaction conditions.
The difference -- if I'm understanding correctly -- is that defining a project basically tells you how to do something. When you take or assign a Mining project, a character must use the "mine" action.
A contract tells you what to do, but doesn't (in principle) tell you how you have to do it. That's because what defines a contract is the specific set of terminating conditions. As long as you meet those conditions, you successfully fulfill the contract's terms; it doesn't care how you got there.
That's the principle; in practice there are still some connections between certain terminating conditions and a very small set of verbs that allow that condition to be satisfied. A Marriage contract, for example, can't be satisfied in many ways other than a "propose" verb. That said, the contract system itself doesn't require a 1:1 mapping between satisfaction conditions (of which there can be several) and a single verb or mechanic, even if there are some contracts that work that way.
To my mind, systems that tell characters "what" to do, rather than "how" to do it, open up gameplay to greater creativity. That's how I was imagining projects might work, and why I wanted to ask whether they were being thought of as hard-coded categories that you would have to write new code to extend, or if they were going to be types of high-level goals that could be built dynamically. I enjoy creative play, so the create-your-own-project-types idea seems like it would not be out of place in Limit Theory as described to us so far.
Creativity is, of course, a double-edged sword. Characters will do some very funny things if your systems are loose enough to let them get "creative." But that's less harmful in a single-player game, I'd say.
And note that I'm being careful to say "character," not "human player." Wouldn't it be interesting to see how creative NPCs could be in figuring out different -- and sometimes unexpected -- ways to complete a project?
I find this interesting both in itself as gameplay design, and also as a very nice demonstration of a distinction that David Keirsey drew between the two types of introverted Rational temperaments.JoshParnell wrote:I don't see a use case for being able to define a sequence of high-level operations to be performed by the same unit. IMO it makes more sense for every unit to be allocated 'atomically' to a particular high-level task, and to create multi-stage operations, we use multiple units allocated to different projects.
He described both INTJs and INTPs as gifted at arranging things to accomplish a strategic purpose. But how they arrange things differs: INTJs prefer entailment, organizing actions sequentially for maximum advantage and defining contingencies; INTPs think instead in terms of multi-dimensional relationships among nodes, organizing systems into models of maximum consistency and coherence.
So -- in terms of Limit Theory projects, for some defining a "project" means being able to specify a sequence of actions, while for others (of whom I'm one) it would be more enjoyable to be able to organize projects as collections of related behaviors whose sequence doesn't need to be spelled out.
Assuming the current definition of project, I'd be very interested in better understanding this "multi-stage operation" idea. Is that about organizing sub-projects into a higher-level project? (Which is pretty much what I'm interested in, if it's a thing I can define.) If so, does it support sequencing, or is it more about defining connecting conditions?
Which seems to answer part of the question -- sequential orders don't have to be a project. So that's nice.JoshParnell wrote:Yes, absolutely. But I consider this different from a project allocation - it is not a continuous high-level task, just a traditional series of commands. Definitely still something you can doThymineC wrote:I hope we can still serially chain relatively low-level actions, though, as in Command Stacking. This would be necessary if, as Flatfingers proposes, I wasn't able to maintain instantaneous communication with my subordinates, or if I wanted them to pull off some complex task without me having to constantly monitor them.
Other thoughts on this question of projects and gameplay verbs are welcome!