Monday, May 26, 2014
Yes. Brace yourselves
Missions and Mission Boards
Today I've set up the architecture for missions (the real one this time, not those LTP cheeseball placeholders
), which I've finally decided is the avenue through which I want to handle a lot of the metaproject AI. That's in contrast to, for example, a strict 'data market,' which would implicitly create missions by placing bids on certain data (just as the commodity market implicitly creates trade routes). I've chosen to approach it from a mission standpoint purely in the hopes of making it more engaging for the player. There's just something fun about taking a 'mission,' knowing what your objectives are, getting some feedback when you do something productive (or possibly counterproductive) to those objectives. As a player, I couldn't possibly live without something like that. The truth is, from a logical standpoint, the AI would probably prefer to handle it all through data and use the same mechanisms as it uses to understand the commodity market. That would be the
elegant way...but to me it takes too much fun away.
Now, let me also say that it doesn't necessarily have to be one or the other. I still do intend to have a data market, especially for discovery-related data. To me that almost feels like a
different kind of data than data logs, for example, which are more about
events than
objects. It does make me a bit uncomfortable that I haven't found a way to formalize that distinction (if one does indeed exist), but I haven't given too much thought to that yet. But for
event-related data (such as destroying assets of the enemy faction), missions are what we're doing.
Scalable Missions via Reward Pools
So! Let's talk about how missions work, because it's rather interesting. Every mission has a visible pool of money allocated for the rewards, which determines how much payout can be earned by completing objectives. It's a completely continuous ordeal, not a binary "success or failure." That's a bit of a novel mechanism that you probably don't see in other games - but for the purposes of LT, it makes a lot of sense. Suppose an AI player wants to pay to do damage to his competition. Internally, he's got a wallet allocated specifically for that metaproject, and can't afford to pay infinitely for accomplishment (remember - the money in LT is real! The credits for mission rewards had to come from somewhere
). At the same time, he wants to do as much as he can do with this money. Hence the pooled approached. A player can pump as much or as little money into a mission as he likes, and the results will naturally scale accordingly.
Think of it this way: a mission isn't going to tell you
how many assets of Faction X you need to destroy. It's not going to tell you
how long you need to escort freighter X. It'll simply say what the reward is for each
unit of work. The way that works will vary depending on the goal of the mission, but in general it's pretty easy to understand: 'one unit of enemy asset value destroyed,' for example, or 'one unit of friendly asset value repaired.' 'One unit of time spent escorting a friendly asset.' You get the idea. Now, as long as you keep the mission active in your mission log, the pool will remain visible to you so you can see how much potential reward is left. When the pool is exhausted (keep in mind that it may drain more quickly if the mission rewards are generous and other players are competing to fulfill the mission), you'll simply head off to find a new job. If you're only running the mission at a small scale and the mission owner continues pumping money into it, you'll likely be able to simply continue doing what you're doing as long as you like
Once again, this paradigm works beautifully with the way the rest of the LT activities are set up: it's all about
continuous processes rather than discrete actions. A mission can be performed continuously, so long as the reward pool is continuously replenished (which it will be, unless the AI stops making money or decides to switch focus to a new metaproject). That's good news both for the AI and the player. Not only that, but the pooled architecture allows a neat sort of flexible leveling system. Sure, some jobs are always going to be harder. But if a player posts a really general mission like, for example, 'do damage to Faction X's assets,' it could be equally-applicable for a one-man, one-ship type of player and a multi-million-credit industry player. The former will be looking to pick off little targets like fighters, while the latter may try to take out entire stations or capital ships from Faction X. They will work together to achieve the same goal at different scales, and will automatically be compensated accordingly! It should go without saying that the scale is limited by the pool: that is, if the pool is 10,000 credits and the mission rewards 5 credits per unit damage, you'll be wasting your time trying to take out a station ("hey man, thanks, we really appreciate it, but, uh, you know we can't pay you for all of that...right...?")
Mission Objectives as Generalized Data Specification
It's a good thing that I've already had quite a bit to talk about, because on the flip side, I'm not 100% done with mission objectives yet. As hinted at previously, I will be handling objectives as generalized data. Not only is it an elegant way to track and understand missions, but it allows for mission scope to be naturally scalable! Consider that setting 'destruction log' and 'target == Ship 6710' is a lot more specific than 'destruction log' and 'faction == Cyladonian Mining Co.' The former is a mission to destroy a ship. The latter is mission to destroy
any ship belonging to a certain faction. We could go even further on either end, getting even more general or specific! Yet, to the properties system, they are all the same - there is no explicit concept of scope
The big thing that I have left to solve - which is more of a technical issue than a theoretical one - is handling specification of properties of different types. The ones I mentioned above ('target' and 'faction') are both properties that give back a specific entity, unlike, for example, 'mass,' which gives back a number. These should be treated differently, as we would like to be able to specify ranges for numeric properties, not equality. Just need a bit more technical magic to deal with this nicely
The Month of May
Ok, I want to be honest with you guys. At the beginning of this month, I took a personal day due to some issues in my life. Although it was the only day I actually took off, I'd be lying to myself if I didn't admit that the issues have been adversely affecting my productivity for the greater part of this month.
The reason I want to mention this is because I know many people enjoy reading my daily dev logs. To those who do so and have done so for quite some time, I'd be surprised if you
didn't notice that my logs this month have contained less excitement and less productivity than usual. As much as I've tried to mitigate the influence of my personal life on work, I'm only human and this is just one of the consequences of a one-man dev team. I want to make sure no one gets the sense that I'm losing interest or motivation in LT, because that's not at all the case, nor is it the explanation for this month's weirdness!
The other reason why I want to bring it up is because: it's over!
As of today, I can confidently say that my personal issues are completely dealt with and behind me; my head is 100% back in the game. I'm frustrated that I lost what seems like a fairly substantial amount of productivity during the month of May. But...I'm excited to be back and in better shape than ever! Maybe you can feel the difference with this log
So...did you miss me? I missed you :3
---