Gentlemen. We have. Delegation.
To be fair, it's not even that big of an achievement anymore, since I've been able to conceptually simplify it so much. But that's usually how you know you got it right - it doesn't feel like a big deal anymore
Today I introduced a new (and perhaps the final?) concept to the AI engine: resources. I explained yesterday how planning, parallelism, and scheduling all work together. Today I implemented it A resource is a tool that the AI can use in implementing a plan. That's really the key insight behind fast delegation & parallelism: a plan is a schematic of what needs to be done, and although it may contain instructions, it's not necessarily a strict specification of how it needs to be done. Those two things can be separated. That's where resource scheduling comes in! As I explained yesterday, you have some number of resources (subordinates, friends, nearby people that you think could help, or even hypothetical people), and you bind these resources to your plan in order to carry it out more quickly.
I introduced two resources today (along with the actual architecture for resources): self and hypothetical. Self is obviously the most common resource, and will usually be doing a lot of the work But hypothetical is a really interesting one. I think I've mentioned before that posting a contract is equivalent to delegating to a hypothetical person. So an NPC may consider that a "hypothetical" person could handle one of the goal nodes, and if it decides to dispatch the goal to the hypothetical person, then a contract will automatically be created and posted to a nearby planet or station (note: contracts can be posted remotely, for reasons of simplicity). Since all resources are treated identically, the NPC doesn't actually know whether it's dispatching to itself, a friend, the player, or a contract. It just happens automatically
Finally, I implemented the first iteration of a greedy resource scheduling algorithm that dispatches goals to the resources that are most suitable for solving them. I mentioned yesterday that there is a notion of "efficiency" with respect to a resource being able to handle a particular goal, and today I implemented the architecture for it, so that the scheduling algorithm takes into account which resources are best for the job (e.g., heavily-armed people are more likely to be assigned combat-related goals, etc.). However, I have not yet implemented the function for evaluating efficiency, so right now all resources are considered equal. That one's going to take some thought
At any rate, I haven't actually implemented the hypothetical person dispatch yet, so no contracts have been posted but....I expect that to change here in the next few hours
It's going to be one heck of a sprint to the update so...strap yourselves in
EDIT: Also, while randomly browsing an old dev log, look what I found!!! :
Sound familiar? Almost a year ago, this idea of an elegant, unified UI was on the tip of my tongue, but I wasn't good enough to understand exactly what it was, so I failed to implement it. But a year later, guess what we have: the node-based UI. It's good to know that dreams do come trueJoshParnell wrote:Thursday, January 3, 2013
... I had a rush of ideas last night concerning interfaces (not just the strategic interface, but interfaces in general), and started conceiving of some pretty radical notions with respect to interface design. Today, I spent the entire day building a new interface engine, trying to flesh out and concretely realize my ideas. I basically want to make the interface more natural, intuitive, interactive, dynamic, and unified, all at once. Very little is working at this point, and it's going to take a lot to figure out how to make this new approach work. But I think the result could be worth it. I always kind of just assumed that a standard "window-based" approach was the best. But after thinking it through a little bit more, I think we can do better, and build something that feels more like a natural overlay that exposes a dynamic flow of information, rather than a bunch of preset windows.
If I'm successful in re-inventing my UI, it will have a host of implications for other systems. The tactical and strategic interfaces will, more or less, become one. All other interfaces will have to be redesigned, but they should all require less lines of coding, less hard-coded constant numbers, and less endless tweaking to get the layout of everything right. Limit Theory is going to have a huge amount of information that can be both observed as well as manipulated, and I really don't want the game to become a spreadsheet, as a few other space games with large amounts of interactive information have become. I feel like there has to be a way to present that information in a beautiful, simple, and intuitive way that feels more like a game!