Wednesday, April 23, 2014
Hoorah! That wasn't so long to wait, was it? And look what spoils devlog savings time has brought us!!
Piracy.
No, seriously! Look at the spoils! Literally!
They weren't obtained legally, but who cares? This is Limit Theory. Some will abide by the law. Others will break it. Such is the nature of good and evil.
Today I implement a piracy task that involves patrolling a zone, hunting down innocent passersby therein, and stealing their goodies to sell elsewhere. How much of that is done? Er...the hunting down part
I still need to implement the cargo drop and scooping up cargo. But this is a lot of new AI content all at once, and I'm very excited to see it happening
Along with this comes new work on the combat AI, which I know everyone has been missing since LTP. It's nice to hear far-off pew pews and explosions once more
Note that piracy is different from warfare (about which I've been dreaming). The primary purpose of piracy is to acquire the dropped cargo (and, presumably, sell it somewhere). The primary purpose of warfare is to do damage to another faction (presumably to reduce their threat, take away territorial control, or just generally be an annoyance).
Starting Risk Management Implementation
Along with piracy comes an interesting new metric today related to projects**: 'losses incurred'! Yep, it's just what it sounds like. If you lose an asset while it's allocated to a project, the losses incurred metric increases by the value of the asset that you lost. This can help both you as well as NPCs to better understand the risk of any given project. Setting up a mining project in a pirate-infested asteroid field is likely to incur significant asset loss.
Today I have just implemented the metric itself, I've not yet created a handling mechanism for the AI. The mechanism I envision, though, is that, if a project starts to become significantly lossy, the AI will attempt to allocate some amount of funding to reduce the risk of the project (by, for example, putting a listing at the local market for dogtags from the offending pirate faction). If, after continued attempts to reduce the risk, the project is still proving to be financially detrimental, the AI will of course abandon it and switch to a new task.
I really look forward to seeing the dynamics of this play out when I finish the implementations. Much like the periodic equilibrium of the market, I expect that this kind of AI behavior will induce periodicity in the activity that we see in any given area. A safe, lucrative task will attract undertakers. Those undertakers will move valuable assets through space in a predictable fashion to perform the task. Other, less-lawful individuals may notice a differential between the security of the space in question and the amount of value being carried therein, and attempt to exploit this differential by setting up piracy operations. Piracy will cause asset loss to the undertakers, which will create a demand for security. Security rises as undertakers fund bounties on pirate factions, and, ultimately, pirate activity may become unprofitable due to high security. Pirates move on to greener fields, demand for security falls over a long period of time, and the cycle starts once more! Sounds an awful lot like the supply / demand cycle, does it not?
Meta-Projects
I've been giving a lot of thought to 'meta-projects' lately (i.e., projects that are set up for the sole purpose of changing the nature of another project). This is probably the one most critical step that I still lack with macro AI. It will govern many important facets of the macro play, including acquisition of new assets, expansion into new territory, competition-driven warfare, and even asset security (as per above). Today I've given some thought to how I want to categorize and approach generation and evaluation of metaprojects. I'm close to starting this final stretch of macro AI, but I'm not quite there yet. Look forward to more on this soon
I Command You to Play Limit Theory!
Interesting tidbit that doesn't really belong anywhere else: you know how I love renaming things, right? Well, the task that NPCs execute to perform high-level management used to be called 'Manage.' Like, they're managing their assets and operations and such. But you know what? I realized the task is actually better described by a different name: 'Play.'
You know, because what they're
really doing is
playing Limit Theory. They're even called
players in the code (just like the human player). Limit Theory contains a task to play Limit Theory. Is that...kind of...meta? Or scary? Or cool? I can't tell. I think it's a bit of all three
(I guess it goes without saying that this task isn't available to the human player!)
---
Alright! I'm already loving the reversion to a reasonable dev log time. I'm also loving macro AI and, just generally, thinking about that broad picture. Last month got me hooked, this month got me digging deeper. This is what LT is all about, folks. Deep dynamicity in a vibrant, procedural universe. Get excited. I am
** Note - I was recently informed that I've been misusing the word 'project,' and that 'operation' is the real word for an ongoing process (which is what I've been talking about). Although I briefly switched my terminology in the engine to reflect the correct usage of the words 'operation' and 'project,' today I have ultimately decided to switch it all back to 'project,' both because I like the ease-of-use of the word, as well as the fact that I would prefer to think of an operation as a specialization of a project, where the terminating condition is null (or "project becomes unprofitable"). This means that, in the project interface, if you set a termination condition for your project, it is a true 'project' as we would call it in the real world. If you set no termination condition, it is actually what we should call an 'operation.' Still, I like the unification of terminology