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

Post

Week of March 16, 2014

#1
Sunday, March 16, 2014

Yikes! New record on devlog lateness...but it goes hand-in-hand with a new record on staying up late ;) I really have to stop falling asleep accidentally :| But, with the amount of productivity yesterday, it's hard to feel guilty about it :D So let's go...

Capability as Space (and Value) Allocation

I talked a bit about capability yesterday. I'm finally starting to see the light when it comes to what this actually means and how it fits into other systems. I've been thinking of capability as being produced by objects. Transfer unit has transference, etc etc. Well, that's close, but it's missing something.

Here's the truth: capability is created by allocating some portion of an object's total mass & value towards it! Yes. This makes so much sense. What does it mean? Well, a ship has some total volume. You can choose to devote that volume to cargo storage, or to a tech lab, or to a production facility, etc. Do not think of capability as just coming from an object, but think of it as coming from space itself.

This has some fundamental ramifications that I am still exploring, but I believe the most immediate are the disappearance of research & production units. Instead we see these capabilities arise by allocating volume for tech labs and production labs. From a practical standpoint, this doesn't have too much difference - except that you now definitely have to make a choice between capabilities when it comes to how you're going to use your ship. One cubic meter of research lab is one less cubic meter of cargo space (err, even though cargo is mass-based... :P ).

Very elegant.

Zone Theory

But if you thought that was an exciting breakthrough, just wait. It wasn't the best part of today. No sir, today I finally began to understand in-system space for what it is: a structured, connected graph of 'zones,' not some random homogeneous stretch of space. A 'zone' is just a point of interest, but it is useful to think of zones as objects. A system might have an asteroid field zone, perhaps a planet zone, etc. Zones can be dynamically-created. Creating a big space station in the middle of what was previously just empty space (e.g. unzoned space) creates a zone.

Zoning is more than just a naming convention, though. It's a conceptually-clear way to think about space. Zones can have names, zones can have intrinsic value, zones can have security ratings, and zones can have...owners! Yes. Now we're getting interesting. How do you own space? Well, by force. Zones are considered to be 'owned' by whoever has the strongest presence there. How is that presence measured? To be determined. Could be military force, but I'm thinking more along the lines of the total value of permanent structures. Set up the biggest space station in an asteroid field and it's considered to be controlled by you.

Wars are no longer just random clashes that happen willy-nilly. They're careful and calculated attempts to take control of zones. Zones have 'intrinsic value' related to them insofar as they are 'springs' of natural resource. Asteroid field zones have a certain capacity to sustain mining operations. Planet zones have a certain capacity to sustain surface drilling, farming, etc. Gas zones - perhaps gas extraction? The point is, every zone is like a little spring of potential wealth. Control of a zone is control of wealth. Under this model, it is easy for the player to understand that - but it's even easier for the AI, and that's really the big win here. We have reduced the problem of the AI's understanding of expansion & territorial conflict to the understanding of zone control. Much, much simpler. Furthermore, problems like how to build a transportation network are reduced (it becomes the problem of how to connect a graph of zones), and questions like what is the purpose of a patrol are answered (the owner of the zone should set up patrols proportional to how 'contested' the zone is, e.g., how desirable it is to enemies).

Keep in mind that zones are not some kind of restrictive entity - you can still fly through free space.

I love structure, and for me this is really the step that systems needed to be more structurally-coherent!

Them March Dev Logs...

A bit crazy, don't you think? :geek:

Let's see what we can cook up for tomorrow... :wave:
“Whether you think you can, or you think you can't--you're right.” ~ Henry Ford
Post

Re: Week of March 16, 2014

#2
Monday, March 17, 2014

Hmmm...no breakthroughs today :think:

Task-Network Management

One of the final steps in understanding the highest level of AI and completing task networks is understanding the goal of a task network and how it influences the creation of the network's structure. Everything is pretty easy once we have the structure of the tasks determined, but that's really the key to everything. How does a CEO structure a corporation? How does a commander structure a fleet? How does an individual structure their life? How does a governor structure planetary operations? Clearly there are a lot of different contexts to think about here. But in each case, the answer is that we're trying to maximize some quantity. In the case of a company, it's the quantity associated with the company's mission statement (profit, territorial control, etc). In the case of a fleet...some balance of offensive & defensive capability? In the case of an individual, 'happiness,' which is a function of the individual's personality traits.

The next big question is concerning 'improvement' of a task network. I referred to this last week as 'metaprocesses.' The idea is that, when you're concerned with achieving some goal, you think not only about ways to maximize achievement of that goal by allocating your resources in a particular way, but also about how you could expand your resources to achieve the goal to an even greater extent. You might call that 'expanding' in the case of a company, 'self-improvement' in the case of an individual, and so on. The question is: when and how do you decide to do so? How much resource do you feed back into the task network for improvement (think: re-investment vs. dividend payout)? What's the optimal trade-off? Mathematically, the answer involves taking the life-expectancy of the entity in consideration into account. But I'd rather not get into that. There's a simpler way to think about it...somewhere out there...I just know it.

I'll find it soon, don't worry :geek:

Seems to be a high variance in dev logs these days...they're either massive revelations or naught but questions and a few steps forward. Odd :think: Definitely feeling like tomorrow is going to be more of the former :cool:
“Whether you think you can, or you think you can't--you're right.” ~ Henry Ford
Post

Re: Week of March 16, 2014

#3
Tuesday, March 18, 2014

Yep, another one of those days :ugeek:

Timelines and Task Networks: Bringing Together Continuous & Discrete

Finally I see how it all fits together. Tasks for modeling continuous change, a 'timeline' of tasks for modeling discrete instances of that change. Timelines are just made up of tasks + terminating conditions for those tasks. For example, 'mine ore until owns 1000 units of Viritium,' then 'transport Viritium to trade hub,' etc.

At the highest level, we can understand a timeline as a flow of resources. It's all about resources. It makes a lot of sense to construct a timeline 'backwards' in an attempt to balance resources, much like a planning tree is constructed backwards from the goal. You think to yourself, "man, it would make me so happy to work for Josh someday." You recognize that doing so would require 1 year of programming experience and 32 pounds of ice cream (??? ... :monkey: ). So you construct a timeline - at the end of it, you've got a task where you're working for me. But at the beginning of that task, the timeline has a balance of -32 pounds of ice cream and -1 year of programming experience, because you have neither of those. From there, you simply work backwards, trying to balance the timeline such that all resources are net positive at all points in time. That's called a valid timeline - one in which you're never operating on negative resources.

I'm extremely excited about this idea, because it's really going to change everything. I feel like it's the final destination in my understanding of AI actions. It's been a long journey - I've been through discrete actions, to continuous processes, and finally landed on sequential hierarchies of continuous processes with termination conditions. Like many of the ideas of late, it just feels right :geek:

Specification and Generalization of Resource and Scope

A few days ago I talked about the engine now understanding the concept of item 'hierarchies' - e.g., that 'pure Viritium' is 'Viritium' which is 'Ore' which is an 'Item.' But that's really just the tip of the iceberg, isn't it?

There's something much deeper lying within that concept. It's the notion of being able to think in terms of generics or specifics. Therein lies something very, very powerful. Consider that hierarchical levels of specificity can provide an elegant way for the AI to reason in broad strokes. When we say, "oh yeah, it makes total sense that you would want to put out an order for Viritium as a whole," what we really mean is that it makes total sense that we can drop the details. Similarly, a faction leader does not think "hey, I can gain an edge over the Pink Mountain Pony Bandits by destroying ship X" (where X is a specific ship). No, he thinks about destroying any asset. Even more generally, he thinks "I can gain an edge by destroying any asset of any enemy." Here we see two degrees of generality - there may be many different ownership scopes that will fit 'any enemy,' and there may be many different assets associated with those scopes.

So, the question becomes - how do you generate tasks and reason in terms of generics? Well, the truth is, this is no different than reasoning in specifics...it just requires that one keeps in mind the idea of 'equivalence' at all times. If a timeline is unbalanced with -50 units of 'damage to enemy,' we must realize that any action involving attacking an enemy, which outputs 'x units of damage to y,' actually also affects this balance, because 'x units of damage to y' is equivalent to 'x units of damage to enemy,' (assuming I attacked an enemy). Similarly, when I am generating suggestions for how to increase or decrease a resource, I must have a mechanism for generating in terms of both specifics as well as generics. It turns out that doing so is remarkably easy, because generic nodes are so sparse compared to specifics. Maintaining an entry in the entity cache for generics is much less memory-intensive than maintaining the entries for specifics!

Optimization of Task Network Selection via 'Opportunity Caching'

Someone very wise recently reminded me that I don't have to share every trade secret of mine in the dev logs. Good idea.

This section redacted for reasons of trade secrecy :cool:

Macro March Madness continues to impress. May the neurons continue to burn! :)
“Whether you think you can, or you think you can't--you're right.” ~ Henry Ford
Post

Re: Week of March 16, 2014

#4
Wednesday, March 19, 2014

As seems to be the trend lately, here we have again a short log following the long one. Such an odd periodicity to this March Madness :think: I wanted to take a bit of a break today since I've been hammering the macro so hard lately - not a long break, just a one-day breather to let the mind flow into other topics before getting back to the big picture :)

Ships & Station Construction via Platemesh Hierarchies

The vultures are circling and it's only a matter of time before the ship and station construction algorithms get ripped to pieces once and for all (err..I mean, in a good way..) :D

Today I worked on what has been my favored angle of attack with respect to procedural model construction for some time. I introduced the platemesh last month, and this month it's time to develop a mechanism for using them coherently. Not surprisingly, my approach is...well, you might say...node-based :D :roll: A hierarchy of connected pieces. It's exciting to think about all the ways we could embed patterns in that hierarchy. Factions having a specific set of pieces that are used to generate their ships and stations, or perhaps even more subtly, factions having specific patterns with which they like to assemble pieces. How best to generate these connected pieces? Still working on it :) But I'm growing very fond of this idea of hierarchical construction. Nodes, connections. Starting to feel like all of life, the universe, and everything can be described in this manner :shock: I'm not going crazy..right? :shifty:

There exist other tidbits of the day here and there, but nothing too worthy of mention. I suppose tomorrow will be another 'big revelation' day if this pattern is to continue :shock: Well, I look forward to whatever it'll be this time... :D

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

Re: Week of March 16, 2014

#5
Thursday, March 20, 2014

Gasp! The cycle is broken, what ever will we do? :cry: I blame it on the interface. If there's one piece of the code that has an unprecedented ability to rise up and steal entire days of my time without me having given it the right to do so, it's that blasted interface. That thing better pay back the debt. Like...when I'm old and sickly, I'm expecting the nodal interface to be paying my bills, taking me to my doctor's appointments, handling my taxes, etc... :roll:

Nodal Interface ("Sucking up Dev Time Since 2013")

It's not even a theoretical problem, really. It's just implementation. Always implementation :think: Implementation of the camera model for the nodal UI has been particularly troublesome. I've written and re-written it about a million times, because it's just so darn hard to get something that works well for all of the different UI contexts, all of the different layouts, etc. Did I finally get it right today? Well...good lord, I really think so :shock: But...you know...I've thought that so many times before :shifty:

Sphere Trees: The Structure of the Entire LT Universe?

What with the recent introduction of zones and such (and continuing the implementation today), I find it interesting that the LT universe is starting to look quite similar at every level of scale. Systems are connected in approximate-spanning-tree-fashion, and can be thought of as spheres. Zones are using the same concept - spheres of influence connected by warp nodes. Even regions are modeled in the same fashion. So if you think about it all together, the LT universe is basically a sphere tree - just a bunch of recursively-clustered and connected spheres. Just something to think about. Rather elegant :)

I really have to get all of my AI theory implemented before the end of the month. There's no choice about it. It just has to be done. But where can I find some extra hours? Anyone know? :D :think:
“Whether you think you can, or you think you can't--you're right.” ~ Henry Ford
Post

Re: Week of March 16, 2014

#6
Friday, March 21, 2014

There we go :cool: Bear with me today as I merge the theory and implementation into one...it may be a rough ride :ghost:

Actors, Managers, and Assets

I already sort of touched on this the other day, but my understanding wasn't clear like today. I spoke of how task networks have a 'manager,' in some sense, in that they have a person who controls the allocation and structure of the network.

Today, I implement and formalize this idea within the engine by implementing the concept of an 'actor.' I don't find this word to be a perfect fit for the concept that I'm describing, but I couldn't think of something better :think: An actor is something that can affect change on the world in a systematic and intentional way. An actor is a person, a faction, a planetary colony (or perhaps a whole planet). Perhaps even more things in the future. An actor has tasks, a manager, and assets. The manager uses the assets to accomplish the actor's tasks. Not to complicate things too much, but note that the manager is not necessarily the owner, hence, not necessarily the one creating the tasks - rather, the manager is the one attempting to carry them out.

This starts to clear up some of that dark, mysterious area of 'automation' and how it might work in the game. Automation entails giving high-level tasks to something. But what is that something? Well, that something would be the manager of a particular actor. Depending on how high-level of automation is desired, you might give the order at a different level. If you want one of your ships to acquire a particular resource, you appoint a 'captain' (manager) to it and give him the task. Note that the 'captain' does not have to be a dedicated role - the captain can also be the pilot, a researcher, etc. The captain is now in charge of the ship 'actor.' The ship is an actor in the sense that it, again, has a set of tasks, a manager, and assets associated with it. If you feel the captain may need some money to carry out this task, then you ought to transfer it to the scope of the ship actor, otherwise he may not be able to carry out the task! Note that the captain / manager of a ship has a relatively narrow ability to create and control task networks. He probably can't set up a production pipeline, because he wouldn't have enough assets to allocate to the corresponding task network! At best, he can assign the other crew members new jobs if he thinks it will help achieve the task. In this sense, the scope of the ship is narrow and has only a small ability for autonomy.

Contrast that with fleet-level commands. Now we move to a higher level :) Create a fleet by designating a group of ships, then control it by appointing a commander and giving him a task. Now we're starting to operate at a level where very complex stuff can start to happen. A fleet commander has significantly more assets at his disposal than a ship captain. He can create and carry out more complex task networks if necessary, since he has more assets to allocate. Concretely, this may entail creating and assigning ships to different roles during an attack, etc. Note!! There is some subtlety when it comes to autonomy and how the tasks that you give influence it. If you give a fleet commander a 'move' command, you are giving him very little flexibility. He needs to move to the location that you specified...what else could there possibly be to carrying that out? On the other hand, if you him a 'generate income' task, you are implicitly affording him significantly more flexibility, because the task requires thought and sub-tasking to accomplish. In this sense, we have dual hierarchies at work. On the one hand, you increase autonomy by dispatching a task to a broader actor scope. On the other hand, you increase autonomy by dispatching high-level tasks rather than low-level ones. Makes sense :geek:

So, through this mechanism of hierarchical actor command, we have a very nice way of understanding automation at different levels. The level at which you give a task is equal to the level of automation you can expect. If you prefer to have extreme control over your empire, you will want to give commands directly to ship captains, in much the same way that a micro-heavy RTS player will be giving orders to individual units during a battle. If you prefer to have the AI do more of the heavy-lifting for you, you can assign a task at the highest level applicable to you. Assigning a task to your own faction would, for example, yield total autonomous control of your faction. No micromanagement. You understand that the assets associated with an actor are what will be used by the manager to carry out the task, so you (implicitly) understand the limitations of what an actor can and can't do in order to carry out a task that you give (e.g., you know that a ship captain isn't going to touch the inventory of one of your stations, because the scope of the actor he controls does not include it. The same is not true of the station manager, nor is it true of the faction manager. Both of them would have access to the station's inventory).

Very cool that we finally see how automation can fit in :)

Data, Function, Structure?

Ok, strictly-speaking, not an LT-related thought. But as some of you know I'm a bit obsessed these days with the data / function duality. I'm also obsessed with structure. These ideas seem to occupy more and more of my mind, the more time I spend programming. I start to wonder...how many of them are real and distinct concepts? For example, structure - or what you might call relations - the way that data relate to one another...is that a real concept? Is it intrinsic? Or is it an abstract construct that exists only within our minds to help us understand the patterns that emerge when function transforms data?

Then, the even more disturbing and perhaps ultimate question to me: are function and data the same thing? I really don't think so. But at the same time, unification of concepts is pretty much...my purpose in life. What if they're the same thing? Object and operator. Function and data. Entity and action. State and transformation. But how could they be? I don't even know what that would look like :think: If anyone knows the answer to this (along with life, the universe, and everything), please do share :monkey:

Anyway! I swear I'm not going crazy, but just wanted to include those thoughts in there :shifty:
“Whether you think you can, or you think you can't--you're right.” ~ Henry Ford
Post

Re: Week of March 16, 2014

#7
Saturday, March 22, 2014

I gotta be honest folks, I've been up for 22 hours thinking that I can make something impressive happen in one day with respect to tying all these loose ends together...and that's just not going to happen. I just keep thinking 'one more hour!' And another hour flies by, some more code is written, and I still don't know what to say in the dev log :monkey:

So...forgive my brutal honesty, but I'm scattered thin at the moment trying to bring the theory of this month into the visible foreground to once again earn my keep :) Yes, I'm working on the separation of manager / asset / task, yes, I'm working on the implementation of all those different tasks all at once...yes, I'm working on zoning, and no, I haven't forgotten about my promise concerning research :shock: I think it's safe to say that if I were an NPC in Limit Theory, my active task list would have caused your computer to run out of RAM long ago :lol: Pray for my brain :ghost:

Anyway. Let me get some sleep and see if tomorrow's hours can't yield something a little more concrete :think: Bear with me! :geek:
“Whether you think you can, or you think you can't--you're right.” ~ Henry Ford
Post

Re: Week of March 16, 2014

#8
Summary of the Week of March 16, 2014
  • Started on zone theory for large-scale territory dynamics!
  • Implemented 'timelines' for modeling evolution of task networks over time
  • Implemented resource hierarchies (generalization of item hierarchies)
  • Opportunity caching theory for faster AI :monkey:
  • Actor / Manager / Asset conceptual model (to be refined in April... :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