Return to “Suggestions”

Post

Project Types

#1
Following the publication of Development Update #16, I asked in the Announcements forum about the new "projects" categories.

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.
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 :ghost: 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?
It's a question about extensibility.

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?
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.
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.

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?
JoshParnell wrote:
ThymineC 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.
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 do :)
Which seems to answer part of the question -- sequential orders don't have to be a project. So that's nice. :)

Other thoughts on this question of projects and gameplay verbs are welcome!
Post

Re: Project Types

#2
Nice write-up. :thumbup:
Flatfingers wrote: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.
As an INTJ I expect I like sequential stuff better, but the system I designed for projects before Josh introduced the idea supports both highly sequential and highly parallel ways of specifying projects. This is because it's based on ViTheory, which is a dataflow language. Dataflow languages tend to allow for high levels of concurrency, but you can make them behave more sequentially in areas if you like (it's the opposite to procedural languages, I guess, in which things are naturally sequential but with special effort you can make things behave concurrently).

The diagram below clarifies this:
Image
Post

Re: Project Types

#3
The more nodal you make that system, the better the odds might be of seeing it realized. ;)

Actually, I'm wondering now how Cornflakes's "pipeline" might integrate with projects.

If projects remain as Josh is thinking of them -- basically atomic goals with a 1:1 relationship with core gameplay actions -- while "superprojects" can be defined that combine projects, then there'll need to be some kind of glue that connects projects within a superproject. Maybe Cornflakes can tell us whether the current iteration of his pipeline ideas support parallelism...?

But this is where I'll wonder again whether there's a close enough relationship between Josh's "projects" and his "contracts" to get some synergistic effects between them. Do projects have termination conditions (including both "success if all these positive conditions are met" and "failure if any of these negative conditions is met" flavors)?

...

Meanwhile, to summarize my wall-of-text above, what I'm really wondering about for projects are the long-term support effects of defining them so that adding a new kind of project means Josh has to add new code. I'm thinking a number of headaches go away if any of that could be pushed out to modders.

That said, I definitely appreciate that there's a bottom level of in-game functionality for which extension is always going to require access to the game's source code. It may be that the actions keyed to projects need to stay at that level.

If characters can create what I've called superprojects, which contain an arbitrary number and types of projects, then that probably addresses my interest.
Post

Re: Project Types

#4
Flatfingers wrote: Actually, I'm wondering now how Cornflakes's "pipeline" might integrate with projects.

If projects remain as Josh is thinking of them -- basically atomic goals with a 1:1 relationship with core gameplay actions -- while "superprojects" can be defined that combine projects, then there'll need to be some kind of glue that connects projects within a superproject. Maybe Cornflakes can tell us whether the current iteration of his pipeline ideas support parallelism...?

i dont see any reason why they should not be able to parralise :think:
they are just a standing order for "take this stuff from this bunch of stations and move it to that bunch of stations"
they could run with as many "threads" as you have freighters (or storage units within those freighters)
Post

Re: Project Types

#5
Interesting discussion. I've been all over the map with respect to this stuff because, at it's heart, it's a model whose development has been driven by the development of the macro AI.

Thinking about it from the macro AI's perspective, it is, of course, ideal to have only atomic projects, because it reduces the complexity of reasoning. This is something that I wrote up in a dev log a while back where I basically realized the 'purpose' of money in the market - that it glues together atomic projects to create emergent chains of more complex behavior. But it does so without any of the additional reasoning complexity of multi-stage operations.

Concerning Sequential Projects

To me, this concept is not as logical as it seems. From the AI's perspective, why would it create a project to "mine, then patrol, then repeat" when that increases the complexity of reasoning, while at the same time making it more difficult to 'specialize' units to that project (now we need to create ships with an emphasis on transference power AND attack power). It is much simpler to have two projects, 'mine' + 'patrol', as we can now reason easily about each and it becomes easier to specialize units to these projects (we need ships with high transference, and we need another set of ships with high attack). Remember that projects are all about continuous action - e.g., repeated tasks. Keep in mind that a classic RTS command such as "move here," "attack that guy," is not a project, it's just a task. All units have a task stack, so chained actions are still completely viable. But chained projects? IMO this is not sensible.

Concerning Goal-Based Projects

I think this is more of an interesting discussion that we can have, because, as Flat says, specifying a goal instead of a project can yield more flexibility.

Here's the thing: goal-based projects already exist :) The way I've designed the economy is such that 'goals' are always explicitly listed on the market. You need a certain amount of a resource? You place a bid on the market (or a contract, depending on what type of goal it is), and the net effect is that, if the price is right, you will drive local NPCs towards fulfillment of that goal (without ever specifying how they get to it). The market is all about goals.

So the next question is, what if we want to assign our own assets to fulfill a goal rather than placing something at the market? Well, currently the AI doesn't think about that, because it wants maximal opportunity for fulfillment. If you want to have the highest chance to fulfill your goal, you should really always post it at the market so that you're getting the help of the whole economy. But it's understandable that a player might not want to do this.

That being said, there's no reason why we can't introduce some kind of 'fulfill goal' project that allows the player to select a goal and assign assets to complete it. Implicitly, this could then create sub-projects towards the completion of the goal. My only fear here is that it's a very powerful tool, perhaps even too powerful. Why wouldn't every player then simply have only one project: "fulfill goal: acquire money," and then assign all assets to that project? That would be equivalent to invoking the AI player routines to play the game for you (or at least to manage your assets for you).

Is it a good idea? Does that detract from the game? You decide :)

Concerning Hierarchical Projects

Finally, about 'super-projects' and 'sub-projects.' Although the AI doesn't ever really need to think in those terms, I agree that it could be convenient for the player to be able to create logical groups of projects ("Cyladon System Operations," consisting of a mining project, a patrol project, and perhaps some production operations as well). It would be particularly nice to be able to see metrics for a group of projects, so that you can see if a certain branch of your empire is performing poorly. It's usually pretty easy to get me on-board with ideas that involve hierarchy :D :monkey:
“Whether you think you can, or you think you can't--you're right.” ~ Henry Ford
Post

Re: Project Types

#6
JoshParnell wrote:Why wouldn't every player then simply have only one project: "fulfill goal: acquire money," and then assign all assets to that project? That would be equivalent to invoking the AI player routines to play the game for you (or at least to manage your assets for you).
How could the game work without such a project?

If you need money to do things ingame but can only assign projects like "mine ore (generic or specific)", you constantly have to manually sell all produce all your assets generate.
Even vanilla X3 is more macro than that and that game isn't very macro at all! =)

One option would be to require a boss NPC for starting a high level project like "make money".
If you hire any old NPC for that you'd never know if all he does is sell all the assets you assign to the project and take off in the fastest ship.
Or maybe he just sells a part of the mined ore to his nephew's factory at a special rebate. Or some get's "stolen".

Players seem to take it for granted that NPC you hire are automatically 100% loyal robots. I think it's time to cure them of this notion. =P

High level macros are a good thing but giving an NPC a lot of control over your assets... gives an NPC a lot of control over your assets.
The dark side of economy are they. Easily they flow, quick to join you in a fight. If once you start down the dark path, forever will it dominate your destiny.
There is no "I" in Tea. That would be gross.
Post

Re: Project Types

#7
Gazz wrote:How could the game work without such a project?

If you need money to do things ingame but can only assign projects like "mine ore (generic or specific)", you constantly have to manually sell all produce all your assets generate.
Even vanilla X3 is more macro than that and that game isn't very macro at all! =)

One option would be to require a boss NPC for starting a high level project like "make money".
If you hire any old NPC for that you'd never know if all he does is sell all the assets you assign to the project and take off in the fastest ship.
Or maybe he just sells a part of the mined ore to his nephew's factory at a special rebate. Or some get's "stolen".

Players seem to take it for granted that NPC you hire are automatically 100% loyal robots. I think it's time to cure them of this notion. =P

High level macros are a good thing but giving an NPC a lot of control over your assets... gives an NPC a lot of control over your assets.
No, you don't manually sell the products - what happens to the products of any given project is part of the project configuration, whether it be storing it or immediately placing it on the market (using a pricing strategy of your choice). This is different from having a project that simply figures out how to make money without your input!

It's still up for debate, but I just want to clarify that the game can certainly still work without that kind of project (and it would still be high-level play) :)
“Whether you think you can, or you think you can't--you're right.” ~ Henry Ford
Post

Re: Project Types

#8
Oh, I get the difference. Just toying with the idea to see if a risk factor can make it workable. =)

Without any balancing factors a completely generic project like "make money" just doesn't make sense. (for the player)
Gameplay = decisions and if your only decision is to not make any decisions at all, where's the gameplay in that?

How about an intermediate solution?
You hire a management consultant to suggest possible projects to you.
You still have to decide what to do but for a player who is looking mostly for a space shooter, someone to help analyse markets and such could be a godsend. Even if that consultant may turn out not to be very good or creative at it. =)
Even then this consultant may have an agenda based on what he or his friends want. Like suggesting you build a duranium refinery in a sector where his nephew's factory requires large quantities of duranium.
There is no "I" in Tea. That would be gross.
Post

Re: Project Types

#9
I have to say the idea of hiring a project manager for a hierarchical structure based on contract fulfillment really appeals to me. I do however agree that going with something so vague as “make me money” is problematic, and could really detract from gameplay. (Though building up Wayne Enterprises to run itself while I go play Batman with the profits may be an interesting way to play)

Taking from the world of business organization, I think it would be fantastic to have departments in factions large enough to sustain them, each department lead by a department manager who in turn take orders from a chief executive. Departments could be either by system or by function, You could do a matrix structure or network if you think it worth it. I think a network structure would be especially valuable for factions to take on outsourced projects… why build a research division when you can pay to use someone elses?

My own thoughts on this would be to limit the focus of any given department manager. That one player in Update 16 had 12 ships and had made 400k, from what I could tell was as high as the chain of command went. They owned/hired out ships with the presumed goal of making money for themselves. If instead their goal was to meet a quota imposed by a superior who wanted regular shipments of alachite to a neighboring system where it would be turned into Superblue Mk IV Turrets because vertical integration was more cost effective and price stable than market reliance, this is what I am talking about. Taking it one step further, that superior might themselves only be tasked by their own superior with the production of Superblue Mk IV Turrets for the Bubba Gump Deathdealers Wholeshale, and is only sub-contracting local suppliers who can be ditched if cheaper alternatives arise.

Now I agree, this does look suspiciously like a market. However, in the model of departments and sub-projects, because these assets are hired out/owned, a manager has far greater control over resource allocation and has a much more stable, and gives the faction/corporation far greater control over supply chains. I would assume that project managers would be given tasks such as Provide the faction with 7000 of widget A, Research in Direction B, Secure System C, Explore regions D-G, etc. I also imagine that departments could be tailored as to how much of their profits/assets should be re-invested in the department, how much should be put into the faction account, and how much should be taken out of the account to fuel developments.
Image
Challenging your assumptions is good for your health, good for your business, and good for your future. Stay skeptical but never undervalue the importance of a new and unfamiliar perspective.
Imagination Fertilizer
Beauty may not save the world, but it's the only thing that can
Post

Re: Project Types

#10
Moving this here, because it's more relevant in this thread.
Talvieno wrote:In an interface, that could be done with a simple "mine" command:

"Mine from [locationX] and carry contents to [locationY]", with a default of "whatever's best" for both. I'd hope that's how it would work anyway.

What would be more complex is "Mine from [locationX] and carry contents to [locationY], while attacking any [shipTypeA] that come within [DistanceB], if [combatRatingA] is less than [[combatRatingA] / [personalCombatRating]].

Or perhaps "Mine from [locationX] and carry contents to [locationY], while acting as a [patrolShipType] on the journey to (locationX)".

OR, perhaps "Mine from [locationX] and carry contents to [locationY], while sabotaging any ships of [FactionA] that are larger than [MassB] if [cargoFullnessPercentageC] is less than [cargoQuantityD]".

The list could go on for a while, and everything would have a useful situation where the default command just wouldn't cut it quite as well. Commands could potentially get ridiculously complex to the point that the player could feel like they're programming their own AI. The real question is, how complex do we want to go?


Now, I really like the idea of "nodes" you can attach to different jobs...

For instance, you have [Mining] as a node. You select that and add it to your project. Now you have a single node:

- Mining

Then, you click the node, it highlights it, and it makes more nodes come out of the center one:
- <<Mining>>
---- Travel
---- Minerals
---- Subsequent task
---- Mining location
---- Drop location

Completely by accident, you click "Travel". The other node options disappear, and more sprout from "travel":

- <<Mining>>
---- <<Travel>>
-------- Travel task
-------- Return task
-------- Avoid locations
-------- Waypoints

But, as it was an accident, you click "travel" again to de-highlight it, returning you to the previous menu:

- <<Mining>>
---- Travel
---- Minerals
---- Subsequent task
---- Mining location
---- Drop location


Then you decide to click "Minerals". The other nodes collapse and disappear, and you're left with:
- <<Mining>>
---- <<Minerals>>
-------- Stone
-------- Metals

Let's say you click "metals". "Stone" disappears, although it would reappear if you clicked "Minerals" again.

- <<Mining>>
---- <<Minerals>>
-------- <<Metals>>
------------ Joshite
------------ Native Gold
------------ Hematite
------------ Tetrahedrite

So, you click "Joshite", and it highlights. Then you click "Hematite", too, because you want both of these minerals. You've reached the end of the options list, so it doesn't expand anymore:

- <<Mining>>
---- <<Minerals>>
-------- <<Metals>>
------------ <<Joshite>>
------------ Native Gold
------------ <<Hematite>>
------------ Tetrahedrite

Following this, you click "minerals" again, and it de-highlights both "minerals" and "metals", which takes you to the top of the list. The "metals", "Joshite", and "Hematite" nodes are still there, because they were selected, but now you have the option to either click the other nodes and continue defining the task...

- <<Mining>>
---- Travel
---- Minerals
-------- Metals
------------ Joshite
------------ Hematite
---- Subsequent task
---- Mining location
---- Drop location

Or simply click "mining" again to de-highlight it, collapsing the node options to as far as they'll go:

- Mining
---- Minerals
-------- Metals
------------ Joshite
------------ Hematite

You're now left with a neat little floaty node system, which is crisp, concise, and easy to understand. You can have as many options as you like, they don't throw themselves at you, and they'll only appear and offer themselves when you actually look for them.


Clicking "Subequent task" would actually allow you to add a second task to the end of this first one, even if it's just to relocate to a specific asteroid field or station if the first asteroid field gets depleted. This solves the problem of sequential tasks. You could also have as much detail as I outlined in the post above, if you wanted, just using nodes. Josh would have a lot of fun setting up a system like that, I think, and it already goes well with the rest of the UI.



It seems simple enough, really. But now I'm going to read the rest of what everybody else said, because I read a couple of the first posts, got excited, and made a post of my own. lol
Have a question? Send me a PM! || I have a Patreon page up for REKT now! || People talking in IRC over the past two hours: Image
Image
Image
Post

Re: Project Types

#11
I swear, I did my best to try to keep these responses short... but there are just so many possibilities to consider!
JoshParnell wrote:Thinking about it from the macro AI's perspective, it is, of course, ideal to have only atomic projects, because it reduces the complexity of reasoning.
I suspect I'm getting hung up on my own professional use of "project."

I'm used to thinking of that word as meaning a collection of sequenced (though sometimes parallel) atomic-level tasks. It's the task that has input (resource) requirements, starting and stopping conditions, and outputs. A project is the next-higher-level management tool that adds structural glue in between individual tasks so that they add up to satisfying a particular business goal.

So, from my perspective, what would make the most sense to me in LT would be to define "tasks" as the atomic-level actions -- Mine, Sell, Buy, Attack, Patrol, and so on -- and then define "projects" as collections of tasks or sub-projects whose inputs and outputs (and starting/stopping conditions) are connected in particular ways. (This may be what has been called a "process.") If I could save project templates, then apply them multiple times as new ships become available, that would be very slick. ("I'm starting up mining operations in this new system... now where's that Mining Project template?")

The virtue of this model is that it minimizes complexity as an organization grows in size -- you just apply (or, if it's the first time, build) a project template consisting of a few sub-units connected to efficiently produce a specific output. The downside is that a "project" becomes a lot more complex to reason about for an NPC... but isn't this what executive NPCs already have to do?

Maybe this is just semantics, and the current system basically already does an early version of this?
JoshParnell wrote:Remember that projects are all about continuous action - e.g., repeated tasks. Keep in mind that a classic RTS command such as "move here," "attack that guy," is not a project, it's just a task. All units have a task stack, so chained actions are still completely viable.
This is where I come back to satisficing/terminating conditions.

Let's consider the Mine action. A ship, preferably one that's optimized for mining if one is available, is given this action. It has to break this down into multiple sub-steps: scan space for a reasonably high ore signature; fly to that location; begin mining; stop mining when the cargo hold is full. What does it do after that? Does it know to try to sell the ore in its hold? Is a miner best equipped to do that, or should it tell its controlling executive "my cargo hold is full with X units of Y ore" and let the executive handle placing the ask order? What does the miner do in the meantime with the ore filling its hold? Does it pause and wait for the executive to assign to it a "deliver" action that will cause the miner ship to fly to a storage depot and allow the ore in its hold to be unloaded?

The point to asking these questions is to highlight that although there's obvious value in defining a bottom-level activity, someone, somewhere, has to have some way of chaining atomic activities together to create a sequence of actions that produce either a final outcome (a "project" in the normal use of that term) or a loop (an "operation" as we've been told we should really call it ;)). It seems like there's some value in letting players define these chains. But don't some NPCs have to do this as well, else how can they perform operational and strategic gameplay? And don't all units of a project need defined starting and stopping conditions to know how to chain actions together effectively?

Furthermore, let's go back to that ship we want performing a Mine/Sell loop. What should that ship do if at some point in any of its chained actions it's attacked by a pirate or stopped by a Customs ship or hacked by a rival, etc.? This brings up the other important question of interrupts and blockers. How does a ship that has been assigned an atomic action know what to do when accomplishing that action is blocked for some reason (as when the cargo hold is full or if it can't locate any appropriate ore sources) or interrupted (as when being attacked by a pirate or infected with a computer virus)?

Is the knowledge of how to respond appropriately to every possible interrupt and blocker hard-coded into every NPC? Or is that knowledge something that needs to be defined for every atomic action that might cause an interrupt or blocking condition for some other actor?

The reason I ask is because how this knowledge is defined will affect how groups/sequences of atomic actions -- whatever those are called -- are performed. If actors magically know what to do when interrupted/blocked, then projects (or whatever they're called) can be simple. If however knowing how to respond to things that interrupt or block an atomic action needs to be defined more dynamically, then maybe projects need some way to encode that "if you can no longer do X, do Y" information.
JoshParnell wrote:But chained projects? IMO this is not sensible.
It's probably more likely that a senior character would want to have multiple operations (looping groups of actions) running in parallel.

But I can imagine that there might be some cases where you might want to define "X before Y" chains of high-level groups of actions, especially at the operational level of play. For example, a Production loop pattern can't sensibly do anything useful until its required inputs are supplied by the outputs of a Mining (or Refining) loop pattern.
JoshParnell wrote:[T]here's no reason why we can't introduce some kind of 'fulfill goal' project that allows the player to select a goal and assign assets to complete it. Implicitly, this could then create sub-projects towards the completion of the goal. My only fear here is that it's a very powerful tool, perhaps even too powerful. Why wouldn't every player then simply have only one project: "fulfill goal: acquire money," and then assign all assets to that project? That would be equivalent to invoking the AI player routines to play the game for you (or at least to manage your assets for you).

Is it a good idea? Does that detract from the game? You decide :)
To answer this, I'd need to know whether NPCs would ever create a pattern that's sub-optimal.

If so, then even if some players are OK with delegating an "acquire money" goal to an executive NPC, trading off some inefficiency for simplicity, other players will still prefer to roll up their sleeves and build their own sub-projects to try to opimize the results.

Maybe that's actually a request for operational/strategic-level NPCs to be sub-optimal sometimes. :D
JoshParnell wrote:Although the AI doesn't ever really need to think in those terms, I agree that it could be convenient for the player to be able to create logical groups of projects ("Cyladon System Operations," consisting of a mining project, a patrol project, and perhaps some production operations as well). It would be particularly nice to be able to see metrics for a group of projects, so that you can see if a certain branch of your empire is performing poorly. It's usually pretty easy to get me on-board with ideas that involve hierarchy :D :monkey:
Hierarchies of projects are absolutely what I've been hoping for, up to a top-level strategic superproject.

I imagine CEOs/Admirals/Emperors defining superprojects with a number of connected sub-superprojects. Each of those sub-superprojects would be assigned to a lieutenant who would figure out how to break it down into more specific sub-superprojects. Assessing the effectiveness of the top-level sub-superprojects (i.e., the effectiveness of the NPC running each one) would be what the player would do at that level of gameplay -- the initial high-level breakdown would be the player's to decide; after that, the gameplay would be an ongoing evaluation of the next level down and revision through allocating new goals and replacing unsatisfactory lieutenants.

These lieutenants in turn would assign their own subordinates to the individual sub-projects. These subordinates would generate their own sub-projects, and so on, until the lowest level of management defines a project consisting of atomic tasks, each one of which is allocated to a specific worker. And information about the performance of each task/worker would be flowed back up the chain to be accumulated at each level up until the top-level character gets an overview of all operations.

If that sounds boring to some, bear in mind that I assume no player, unlike our real-world Peter Principle, will ever be forced to rise in any Limit Theory organization to his level of incompetence. :D If the idea of play-by-delegation leaves you cold, you don't have to do that -- just keep flying your ship of choice as a lone wolf, a contractor, or a tactical-level employee.
Post

Re: Project Types

#12
Why wouldn't every player then simply have only one project: "fulfill goal: acquire money," and then assign all assets to that project? That would be equivalent to invoking the AI player routines to play the game for you (or at least to manage your assets for you).
I like this idea, with the caveat that worker-level AIs shouldn't be able to coordinate these operations. You would need a subordinate player-level NPC to do the management for you. This brings up several possibilities for disadvantages, including corruption in-organization (embezzlement, hidden agendas, hostile takeovers, etc) as well as the possibility that the manager takes risks that you wouldn't (sending miners into a mineral-rich but pirate-plagued asteroid field), or simply chooses options to make money that you wouldn't (sending pirates to fight in your name, and getting serious flak from nearby factions for doing so). The manager could also just simply be less intelligent, not fully understanding the rules of the market, selling and buying at sub-optimal points, breaking zone laws, cutting corners, and the like. This shouldn't be too much of a penalty, of course- it should still be a viable alternative to micromanaging your business yourself- but it can provide both a reason to do some management of your own, and even create factional drama for the player to deal with.
Post

Re: Project Types

#13
Periapsis wrote:I like this idea, with the caveat that worker-level AIs shouldn't be able to coordinate these operations. You would need a subordinate player-level NPC to do the management for you.
Absolutely. From personal experience I can say that maybe one in ten "workers" is able and willing to coordinate more than what happens in front of his own nose.

Periapsis wrote: This brings up several possibilities for disadvantages, including corruption in-organization (embezzlement, hidden agendas, hostile takeovers, etc) as well as the possibility that the manager takes risks that you wouldn't (sending miners into a mineral-rich but pirate-plagued asteroid field), or simply chooses options to make money that you wouldn't (sending pirates to fight in your name, and getting serious flak from nearby factions for doing so).
Disadvantages are the cornerstone of balancing. If a game action has 100% positive results there is no reason not to do it... and you have a first order optimal strategy which is the ebola of game balance.
If there are disadvantages the player has to weigh and decide.

That doesn't mean that every boss NPC you hire automatically is your enemy on some level. Some will definitely be loyal to you / your corporation, gain happiness from being good at their jobs, and actually be good at it. The trick would be finding them. Just like in the real world. =)
There is no "I" in Tea. That would be gross.
Post

Re: Project Types

#14
Some thoughts that came to mind when I read this post - and skimmed through some of the comments.

- Since we're going for a more realistic AI, there should be some sort of Manager AI present to keep the workers in-line.

- I view projects as a series of tasks chained together, like Mining - to get the resources, and Manufacturing - to convert the resources into finished products which could be sold for more.

- There should be some sort of Chain of Command, something like Executive - in charge of entire Project, Director - in charge of a Sector, Supervisor - in charge of a group of workers (Miners, Manufacturers, Escorts, ect.), and the Workers. Each one will provide more specific data according to their area of command. This means that for basic information that tells you if the Project is successful or not, you would go to the Executive in charge, while if you want information on a certain sector, you would go to a Director, and so on.

- Executives will distribute all the assets you allocate to them (Ships, Supplies, Money, ect.) evenly throughout each Director, which would then distribute it accordingly to each Supervisor which places a Worker in charge of each ship. If a situation arrives where one group or one sector needs more assets, the executive will redistribute it. For example, a sector that has more piracy will recieve more Fighters to protect the mining ships, and a sector that has more valuables will receive more mining ships.

- The Player's Job is to oversee the entire Project. For instance, lets say the Project is unsuccessful in making money. Why? The player will then look at the Executive's Chart which shows the money made in each Sector. Great! So now the Player has noticed that Sectors D, F, and J are unprofitable. The player digs deeper, looking at the Directors in charge of those Sectors. Now you noticed that Sectors D and F are suffering from high piracy, while Sector J has few freighters to carry the resources mined, leaving a road block between the mining location and the market. This gives the player 2 options. One - The Player can supply the needed assets to continue the Project in the unprofitable Sectors, or Two - Relocate the Directors to a new Sector.

- In regards to relocating entire Sectors of mining ships, escorts, and freighters, there should be some scouting involved. Maybe have a Scouting division who's sole purpose is to find more profitable areas to mine, or whatever task you're doing.

Those are just some of my ideas. I'll have to read through the replies to see some of the other ideas. Enjoy!
Brian makes Art! Check out http://bk-creations.deviantart.com/ for more information! Suggestions are appreciated!

In Josh we trust.
Post

Re: Project Types

#15
Flatfingers wrote:So, from my perspective, what would make the most sense to me in LT would be to define "tasks" as the atomic-level actions -- Mine, Sell, Buy, Attack, Patrol, and so on -- and then define "projects" as collections of tasks or sub-projects whose inputs and outputs (and starting/stopping conditions) are connected in particular ways. (This may be what has been called a "process.") If I could save project templates, then apply them multiple times as new ships become available, that would be very slick. ("I'm starting up mining operations in this new system... now where's that Mining Project template?")

[...]

Furthermore, let's go back to that ship we want performing a Mine/Sell loop. What should that ship do if at some point in any of its chained actions it's attacked by a pirate or stopped by a Customs ship or hacked by a rival, etc.? This brings up the other important question of interrupts and blockers. How does a ship that has been assigned an atomic action know what to do when accomplishing that action is blocked for some reason (as when the cargo hold is full or if it can't locate any appropriate ore sources) or interrupted (as when being attacked by a pirate or infected with a computer virus)?
This is exactly the kind of reasons I wanted to use ViTheory to handle projects. :) The idea of "programming" projects makes sense for the following reasons:
  • After you're done writing a program in ViTheory, you can "compile" it to one of several different types of formats, such as "Resource allocation program", "Fleet template", etc. One of these will be "Project template" - appropriate validation of the program occurs when you try to compile it to a particular format. Those templates will require certain inputs (such as worker NPCs to enact the plan, mining vessels/equipment if mining is involved, etc.), but you can apply the template over and over again in different situations if you have the resources for it.
  • How an agent reacts in the case of blocks and interrupts can be handled based on what you've specified in the project template or for the agent's role behaviour template.
    • If an agent gets blocked or interrupted in a way that isn't covered in the agent's role behaviour template or the project template, they use their "best judgement" - a miner that comes under attack will probably try to escape.
    • If an agent gets blocked or interrupted in a way that is covered in the agent's role behaviour template but not the project template, they behave in accordance with what's specified in their behaviour template.
    • If an agent gets blocked or interrupted in a way that is covered in the project template, they behave in the manner specified within that. This overrides anything in the role behaviour template. You can specifically address potential blocks or interrupts in project templates by performing checks within the code and combining these with if/else cases.
Flatfingers wrote:If so, then even if some players are OK with delegating an "acquire money" goal to an executive NPC, trading off some inefficiency for simplicity, other players will still prefer to roll up their sleeves and build their own sub-projects to try to opimize the results.

Maybe that's actually a request for operational/strategic-level NPCs to be sub-optimal sometimes. :D
Exactly. Specifying a high-level project of "Acquire money" to all of your sub-ordinates should be perfectly viable, but don't be surprised if it doesn't work out as well as you hoped. This is because even if we assume NPCs to be as intelligent as humans, there's still two problems:
  • NPCs at the same level as each other won't necessarily all communicate or cooperate together - it's their job to communicate with you, and you combine the feedback they're giving you to find the optimal way to address a problem.
  • NPCs at a lower level have enough on their hands worrying about the low-level action-oriented details of a plan. They cannot be expected to handle high-level goal-oriented details optimally as well. The idea of delegation is that the CEO, at the head of the project or operation, does not have to spend as much time worrying about implementation details so that he can spend more time thinking at a more strategic level.
If this were as over-powered as Josh seems to think it would be, why don't real-life CEOs tell all their subordinates to "acquire money" and leave it at that?

Online Now

Users browsing this forum: No registered users and 10 guests

cron