Return to “[Archived] Daily Dev Logs, 2012 - 2015”

Post

Week of May 25, 2014

#1
Sunday, May 25, 2014

Yes yes yes, but not quite, but still yes :)

So, so close...can we have it before the update? Can we have working, top-level AI, metaprojects, and missions? CAN WE??? Yes. I really think so. But I need more hours. Send me all your hours!! :D

Sorry, no, I'm not prepared to discuss it tonight. Implementation took longer than expected, but it's all coming to a close. Give me another day :geek:

(No seriously, if you've got any time to spare, please send it to me :roll: :lol: )

:wave: :geek:

PS ~ Yes, the first time I posted this log I did it under last week...derp... :roll: :oops:
“Whether you think you can, or you think you can't--you're right.” ~ Henry Ford
Post

Re: Week of May 25, 2014

#2
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 :roll: ), 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...?") :lol:

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 :geek:

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

---

:wave:
“Whether you think you can, or you think you can't--you're right.” ~ Henry Ford
Post

Re: Week of May 25, 2014

#3
Tuesday, May 27, 2014

All over the place today...which is exactly and precisely where I need to be at this point in time :D

Mission Rewards as Products of Simple Constraints

Today I finally implemented the concept of the property constraints about which I've been speaking. When speaking about generalized market orders previously, I noted that the most general way to place an order is by specifying a function that takes an item and produces a number, which indicates how much I'm willing to pay for that particular item.

For mission valuation, we will do the same, except with data. The question is, what's the format for that function? My answer to it is a product of simple components. Some components can be thought of as binary constraints, while others can be thought of as windowed linear functions. Let me explain :geek:

Going back to yesterday's examples, posting a reward for the destruction of Faction X's assets is quite simple. It consists of only one property constraint: a binary constraint requiring that the property 'faction' is equal to 'Faction X.' If that's the case, the constraint evaluates to 1.0 (meaning the whole reward is achieved). If not, the constraint evaluates to 0.0 (because we're not going to pay you for destroying Faction Y's assets).

With numeric properties, I will allow a slightly more sophisticated constraint, which amounts to a linear window. For a numeric constraint, you will specify a minimal value, a maximal value, and the low and high reward multipliers at those endpoints. The constraint will evaluate to a linear interpolation of low-high when the property remains within the minimal-maximal window, otherwise it will evaluate to 0. For example. Suppose I want to offer a reward for escorting my own ships. I'll leave it general because I don't really care which ship you escort, I just want to protect some of my assets. That being said, I'm willing to pay more for escorting ships with a low 'security' value. So I set a constraint that says I will pay 1.5x the base reward value at 0.0 security, and 0.5x the base reward value at 1.0 security (we will assume that 'security' is a property which can be evaluated to give a general measure of how 'safe' an asset is, and it ranges from 0 to 1). That means I'll pay you more per unit time to escort a ship that's in clear danger (flying through dangerous space / without any other escorts). To determine the final reward, the game will simply interpolate between the endpoints. Of course, if you don't need any fanciness, it's easy to set the low and high multipliers to the same value, which means, as long as the property is in range, a constant reward is obtained.

Now, if we have multiple constraints, the final reward multiplier is just the product. For example, if I want you to destroy Faction X's assets, but I also want to only target ships of a certain size, I will set a constraint 'faction' == 'Faction X,' as well as a constraint 'size >= 10 (1.0), size <= 20 (2.0),' meaning I'll pay you the base price for ships of size 10, and I'll pay you double for taking out ships of size 20. I'd pay you 1.5x for ships of size 15, etc. I won't pay you anything for destroying a ship of size 5, 25, or 100 :D Make sense? ;) But the final result is a product, meaning the data is still worthless if the faction is not Faction X (because in that case, the first constraint evaluates to 0, so the product is always 0).

The Units of Mission Reward

Consider that, as per the scalable mission theory given yesterday, all 'rewards' are specified in terms of scalable units. "5 credits per unit value of enemy asset destroyed," for example. "6 credits per unit time of friendly asset escorted." What we're getting at here is that the base reward of a mission is actually specified in terms of the value of a property!! In other words, an escort mission would always be rewarded in terms of 'duration' of the escort log. A destruction mission would be rewarded in terms of the 'value' of the asset destroyed. You see, these are actually just properties!

So today I implement the notion that the mission reward is measured in terms of credits per X, where X is any numeric property of the given data.

It's important to note that this means the constraints above are best thought of as percentage bonuses / reductions. If I'm offering a 100% bonus for ships of size 20, as per above, then what I'm actually offering is, for example, 10 credits per unit value destroyed instead of 5 credits per unit value destroyed. So I'm not just offering more reward for killing big ships, I'm offering a better reward rate ;)

I know that might sound a bit complicated...but in practice, it's dead simple. I will just need to find ways to convey it simply and intuitively with the interface :)

Getting the AI to Understand Mission Rewards

Up next, before AI players are able to run missions, we need to implement the other side of the coin. We have AI players that are capable of formulating their metaproject-related desires and posting them up on the mission board. But what we don't have yet is a way for an AI player to realize that a certain project contributes to the fulfillment of a mission (hence, has added value through the mission board).

This should be the final step before we see a working mission-giving and mission-running AI in LT! Hope to have this done before the update ;)

---

The mission work is great, but I also need to attend to the thousand other loose ends that have been left hanging before the update!! :crazy: Where should I go next... :shock: Tune in tomorrow to find out...

PS ~ Really gotta cut back on these devlogs :shock: :shock: :ghost:
“Whether you think you can, or you think you can't--you're right.” ~ Henry Ford
Post

Re: Week of May 25, 2014

#4
Wednesday, May 28, 2014

I trust no one will mind a bit of a short log today considering that I've exhausted both myself and readers the past two days :lol:

Frankly, I'm unimpressed with myself today. I wasn't in as many places as I should have been :( I allowed myself to get sucked into missions again when I should have been branching out to fill the other gaps in this month. Nonetheless, finishing off the mission architecture is a gap that needs filling just as badly as any of the others... :think:

Mission-Running Tasks

The issue that we run into with the 'missionee' side of AI (i.e., the one who takes the missions rather than the one who posts them :lol: ) is that, in theory, we should have a specific type of task associated with every possible mission objective. That's not surprising, and it's actually a problem that goes wayyyyy back in the LT AI history, back when we were thinking in terms of discrete goals and actions, and talking about how goals need to be able to 'suggest' solution actions for the sake of efficiency. Now we're facing the same problem, but in what seems like a more general way. Depending on the way that a mission reward is structured (see yesterday's talk about a product of simple constraints), the solving task may be many tasks, it may be only one task, and, conceivably, there may be no task that can meet the constraints.

Sampling tasks and checking whether they meet the constraints of a given mission isn't a hard idea to come by. It's no different from sampling tasks and checking whether their inputs and outputs create a net profit at the market. But there's a deeper problem: the sampled task space needs to be able to (conceivably) solve any of the constraint combinations that might arise in practice. In other words, for any conceivable mission (or at least, any mission that occurs in practice), there needs to be some AI task that adequately solves it. Does this imply that we need tasks like "hunt assets from Faction X" for specifically solving that kind of constraint? Does it imply that we should have a task "hunt assets that meet constraint XYZ," meaning that we have a task that internally performs sampling to try to find data that can solve the constraint? How do we write a sampling algorithm that can take the constraints of a mission and efficiently produce a list of viable solution tasks? Should we simply limit the mission types to pre-defined sets of constraints and write a solution task for each? Hard problem.

There's an answer out there, but I just need more thought to get to it. And I sure don't have much time left :?

Keep sendin' those hours my way, folks :geek:
“Whether you think you can, or you think you can't--you're right.” ~ Henry Ford
Post

Re: Week of May 25, 2014

#5
Thursday, May 29, 2014

Sorry folks, no time to chat tonight :geek:

I'm pulling hard and it's going to be a close one. No sleep tonight, presumably no sleep tomorrow night either :shock: This is gonna get fun :D

Still a long, long todo list. Those ends are indeed coming together. But the hours are dwindling! Thankfully, there's one thing around here that's not in short supply: coffee :D :monkey:

Wish me luck :squirrel: :wave:
“Whether you think you can, or you think you can't--you're right.” ~ Henry Ford
Post

Re: Week of May 25, 2014

#6
Friday, May 30, 2014

Good lord the code. It's like someone flipped a switch in my brain today and I was finally able to get back into high gear :shock: Problem is, I need a solid 36 hours of high gear work before any update. Sadly I didn't get that yet. I just couldn't see how to do it before today. But I see it now. :monkey:

In order to make the update all that it should be, and to prevent any exhaustion-related deaths, I'm going to push the update back two days :ghost: Why two? Because I can see the finish line, and it's two days away...that's just how it is :geek: I was late getting into insane mode this month, but I'm there now, and the next two days are going to be a blur. A magical, beautiful blur of code.

Thanks for your patience...I love you all! <3

(I'll be posting that on KS comments section soon)

:wave:

(Yeah, so what, I may have taken a 30-minute graphics break today to throw in some gratuitous enhanced color grading. That + new nebulae = 8-) 8-) )
“Whether you think you can, or you think you can't--you're right.” ~ Henry Ford
Post

Re: Week of May 25, 2014

#7
Saturday, May 31, 2014

Stay on target....stayyy on target. Yes, I switched off my targeting computer. I'm OK! Just feeling lucky :geek:

You know what days like this call for: the list!
  • Worked on and fixed system map
  • Integrated switchable orthographic / perspective projection into system map
  • Top-level AI now capable of posting missions for monopolization (attacking competitors)! First ever AI missions being posted!
  • Implemented notification HUD node for displaying player log events
  • AI cache now capable of serving tasks related to basic mission running
  • Implemented data resource output for relevant tasks (AI now understands when tasks yield data)
  • Working on hardpoint HUD nodes
  • Working on basic mission interface + mission log
  • Millions of other things :D
May the code be with us all. It's been a fun 24 hours and it will continue to be a fun ~24 more hours :crazy:
“Whether you think you can, or you think you can't--you're right.” ~ Henry Ford
Post

Re: Week of May 25, 2014

#8
Summary of the Week of May 25, 2014
  • Theory & implementation of scalable missions and reward pools!
  • Implemented mission objectives using the data mechanics
  • Implemented 'constraint product' mechanism for computing mission rewards
  • Achieved first-ever real, AI-posted mission!!
  • Implemented thousands of new UI nodes :lol: missions, HUD, notifications, etc...
  • Implemented some awesome new color grading :cool:
“Whether you think you can, or you think you can't--you're right.” ~ Henry Ford

Online Now

Users browsing this forum: No registered users and 1 guest

cron