Display posts from previous

Sort by

Didn't manage to get as much work as I would have liked knocked out today, mainly because I got a bit tripped up on this one concept that's giving me some implementation woes...

Adaptive Packed Grid Layout

Here's something very interesting What if we took the grid nodal UI layout and removed the constraint that grid cells all be the same size? What if, for example, we had a fleet interface where we wanted to convey the fact that we have some really big ships and a bunch of small fighters? If we were to view that fleet in an orderly way, wouldn't it make sense to let the big ship nodes take up more space? Of course But how?

Well, what if we tried to automatically pack variable-sized nodes into a grid in an aesthetically-pleasing way? Seems like it could be pretty cool...

Anyway. Turns out it's not that easy of a problem, and it's taken me several hours just to build a half-working implementation. Hrm. Not cool! Maybe just another hour or two This is my first time implementing bin-packing algorithms, so it's understandable that I would get slightly hung-up. Still....

The nice thing about this problem is that it's also directly related to the hardest remaining step that I have in finishing off platemesh texturing. So...solving this will solve both a nice UI problem as well as the platemesh texturing problem!

Nothing like a 2-for-1 special

'Tag-Based' Resource Generalization

Luckily, I did still get some nice theory done today, despite my implementation woes Previously I've spoken about how the engine now supports hierarchical items ('Ore -> Viritium -> Condensed Viritium', etc.) As I am starting to understand how factions will reason about zone control, I am having trouble sticking with this strictly-tree-based model.

For example, suppose that zone control is expressed by having a 'deed' to a given zone (the means by which one acquires this deed are up for debate, but let's just say that there exists some concrete manifestation of your control). Suppose, in fact, that I have a 'deed to Silverton Asteroid Field' in the Colorado System. If we start trying to think about how that deed might be understood by an NPC, we immediately run into the same issue that deep-hierarchy-based game engines run into: how do we structure the tree? Should 'deed to Silverton Asteroid Field' derive from 'deed to Asteroid Field in Colorado System,' which derives from 'deed to Asteroid Field'? But what about 'deed in Colorado System'? Do you see the problem? It's the same reason why we prefer composition over inheritance in programming. In reality, my deed is a 'deed to asteroid field,' it's also a 'deed in Colorado System,' and each of those parent types have their own parents.

The point here is that some things cannot be easily understood as a single-inheritance hierarchy. It is perfectly reasonable to believe that some NPCs would have a desire to control any zones in the Colorado system. It is also reasonable to believe that some NPCs would desire to control any asteroid fields. There is no inherent relationship between those two types of zones, and yet, my deed should be able to fulfill either of them in the marketplace!

For this reason, I'm moving to a 'tag-based' mechanism for generalizing resources. It's really just the same thing that we already had - resources can derive from other resources - except that it allows multiple relationships. For some reason, though, it seems to make more sense in my head when I think about these generalized things as 'tags' rather than 'parents.'

This is going to be very important in the near future when we see zone ownership finally happening....soon.........very soon.....

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

Yep I finished the implementation of the adaptive grid interface (which means I now have bin-packing code in the engine). Looks promising, but probably going to take some aesthetic work to make it usable for general-purpose interfaces.

Anyway. That's not what I want to talk about. I want to talk about the monkey. Yeah, you know him well. Graphics Josh came to town Well, kind of a hybrid graphics Josh / interface Josh

Real Market History Interface

Ohhh yeah. It's that time. Let me explain how excited I am about this interface through a series of rhetorical questions

Do we have full-blown candlestick charts with adaptive time scales? We do.
Do we have multiple EMA lines for quick average information? We do.
Do we have MACD for at-a-glance trend analysis? We do.
Do we have volume bars for at-a-glance quantity information? We do.
Is it all easily-available in the same node so we can just kick back and watch the economy? Of course.
Is it all very shiny like the rest of the interface? You're darn right it is!!!

Ok, I'll admit. This trade interface is...how to say it...a bit more powerful than you might need for a game But here's the thing. I spent a lot of time on this whole dynamic economy shebang. So it would kind of be a shame if all we could visualize it with is a handful of little tinkertoy graphs like in update #15. No, this is Limit Theory. We can do better

Once again, let me stress, if you don't give a hoot about EMAs and candlesticks and all that hooplah, you don't have to use this. This is the 'advanced' trade interface.

But let me tell you. 'Trader' has never been such a deep and viable profession!!!

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

It all started with 1,000 cr. I was a humble little thing. Not a single ship to my name, but I had dreams. Big dreams. And I had a thousand credits. Chump change, really. Could probably get me a Konalian ale or two. But I had other plans for those credits.

Born and raised on the Konala Orbital Station, I was no stranger to the markets. Traders and miners alike passed through all day everyday, dealing mainly in Arrenagite. The fields out beyond the Padflag Two Hub were the richest in the region, they said. Fountains of wealth. Ha. I wouldn't know. The rich men of Cyladon called our little system 'the hidden gem,' the Konalian markets a 'treasure trove.' Today was the day that I would find out for myself if they were telling the truth.

No, I hadn't a single gram of Arrenagite to my name. But I had a thousand credits, access to a market terminal, and two hands with which to pray.

The warmth of holographic projections washed over my retinas as the real-time trade data came pouring in. Dots. Lines. Bars. An alien language to some. A clumsily-spoken form of communication to others. The common ground for the Konalian government and the local traders and miners. Dots. Lines. Bars. But to me? Well, let's just say that...my wealth lies on the inside. I could see what they couldn't. And today, today I would show them how this language is meant to be spoken.

I watched for a minute or two, letting the rhythm of the data drum it's way into my mind. Like an elaborate orchestral piece, the market orders danced up and down, back and forth, swinging gently despite occasional bursts of excitement. A chaotic motion to some. But they could not feel the rhythm. They knew nothing of this dance.

I directed my mind to the order entry form. The interface read my thoughts and automatically filled itself out. 100 units @ 10 cr/unit. It asked for confirmation. I confirmed. Farewell, my thousand credits. No doubt my bid was sitting at the bottom of a long list of bids with higher volumes and more generous offers. But they knew nothing of this dance.

An hour and sixty-five trades later, I lifted the glasses from my face. The account screen shimmered and then disappeared. The last remaining text before all went blank: "Account Balance: 108,500 cr."

The rich men hadn't lied. Truly, Cyladon was a fountain of wealth. Sadly for them, that wealth, from this day forth, would find itself flowing to a new master - not to the rich old traders of Cyladon, not to the corrupt government of Konala, and not to the overworked miners of Padflag Two. No, from this day forth, the wealth would be the prize of the one who felt the rhythm. And with that wealth, he would build an empire.

And to think. It all started with 1,000 cr.

---

(Despite the added roleplay elements, this is a true story! Today, working bid/ask interfaces, coupled with the detailed market information, allowed me to daytrade my way to admirable fortunes at the Konala Orbital Station Of course, the fact that I was able to do so points to the NPCs still being quite inadequate at valuing commodities properly. Still, it was certainly a fun and rewarding day )

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

Another full day on the economy. Worth it? I think so. As much as I feel that I'm sinking a scary amount of time and effort into this bad boy, every hour feels like it's bringing me closer to that living universe that I always dreamed of. The more I work with the economy, the more I can't shake the feeling that...it's like...the centerpiece of civilization Is that weird?

Gaussian Price Beliefs

The original paper that inspired much of the LT economics system introduced a scheme wherein AI agents choose prices by sampling a uniform distribution. With the passage of more time and trades, the NPCs continue to narrow this distribution, honing in on the 'true' value of the commodity.

In LT I do something similar. But as of today I propose a new, simpler, distributed model for price beliefs. Rather than every NPC having an individual belief about every commodity (which is obviously a bit memory-intensive, right?), why not have a 'global' belief distribution, from which individual agents then sample a belief. After all, there must be some kind of 'best distribution' of the true commodity value that we can compute based on historical information, right?

If that's the case, how would it look? I think it would look something like a gaussian centered at one of the average trade price EMAs, with a variance that is inversely proportional to the trade volume EMA. Basically, what this would mean is that, on average, agents believe that a commodity's true value is reflected in a historical average, and that the variance in agents' beliefs would be determined by the historical trade volume. If a commodity trades at one unit per year at a given market, there is going to be almost no agreement on the correct price. The variance should be very high because the volume is so low. On the other hand, a commodity that is trading at a cut-throat 1000 units per second no doubt has a razor-thin bid/ask spread and a very-well-defined price. There should be little variance in what agents believe about the price of such a commodity.

Now, no doubt any economist will point out that this model is flawed because the past does not predict the future, etc. A better belief model will also take fundamental analysis (e.g., the current state of things, perhaps including events that might affect price) into consideration, and probably some more advanced technical analysis than just EMAs (historical averages).

But the point is not how the mean is computed. The point is that, for the everyman miner / trader / mercenary, etc. it suffices to globally compute a distribution from which the agent will then sample a price belief. The market dynamics will naturally cause that belief to change over time, ideally getting closer and closer to a price that reflects the true value of the commodity at the given market.

Hmm....there was more for today, but I've already written more than I expected to So I'd rather just get back to it...excuse me

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

Hmmm...I'm in the middle of some very interesting factional warfare theory at the moment I'm starting to understand competition over supply, which, as far as I'm concerned, is not so different from competition over asset control. Both fuel a desire to do damage to the other party (which is, essentially, the root of conflict in the LT universe). But I'm not sure I'm ready to speak of these things yet So for now I will bide my time with a minor log...

Gaussian Price Belief Implementation

I implemented the gaussian price belief theory from yesterday, but was slightly underwhelmed with the results. Although it's a really solid theory, I think the bigger problem is that, ultimately, the economy needs to push down the price of commodities with excess supply, and push up the prices of commodities with excess demand. This seems to be more central to a working economy than the beliefs of any individual agent. So I may have been wrong yesterday when I undermined the computation of the 'mean' of the price distribution. This may well be the true key.

I've yet to come up with an elegant way to compute the mean that takes the supply/demand differential into consideration. The problem is a tricky one: on the one hand, if you use a very short-term average to do so, the price will quickly plummet or skyrocket (since the supply/demand do not have time to adjust and react to the change in trade price). On the other hand, a failure to adjust price beliefs rapidly enough can cause an incorrect belief about the price and substantially sub-optimal trading. It's definitely going to take some thought to nail this one. But when you think about this, it's really...an ultra-deep AI issue that I feel very few SP games would ever even come close to tackling. Considering how the relative supply / lack of supply of a given resource at a given location could affect their plans...I mean...come on, how great is that? This is truly a reactive AI. Very excited to see what kinds of solutions unfold.

Ok, I want to get into 'supply conflict,' but I also don't want to. I feel it may be a bit premature. Give me another day or so to work with this issue and understand how it spawns wars, and I'll get back to you...sound goood?

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

Alright alright, I wanted to continue faction work, but when I woke up last night I had an idea...yes, an idea about the economy...and I just had to try it.

Seriously, I apologize for all the technical / economy-related dev logs lately. I'm just...eh, very excited about it all. And I want to nail it!

Automatic Price Adjustment via Skewed Price Belief Distributions

Yesterday I spoke about how we need a way to adjust the mean of the price beliefs of agents based on supply / demand. If supply greatly exceeds demand, buyers should be able to get a good deal, and, conversely, if demand greatly exceeds supply, sellers should get a good deal. I also mentioned that a belief distribution by itself is not enough to create this effect...

...or is it?

The idea that I had today is, I think, pretty darn elegant. Let's say, instead of fixing the 'mean' of our price belief distribution based on a historical average and using a symmetric distribution...what if we fixed the 'mode' - or most common element - at the historical mean? This would enforce the obvious - that most people believe the historical average to be about right. But this says nothing of the mean of the belief distribution...and in fact, we're going to play some tricks here to cause the price of a commodity to automatically adjust itself based on supply and demand. To do so, we'll used a skewed belief distribution. Alright folks, let's break out some math

Suppose a small percent of sellers are willing to discount their product below the historical average (think: "I just want to get rid of this ore quickly!"). Next, suppose that a larger percent of sellers are going to try to mark up their product above the historical average ("If I could just get a few more pennies...."). Furthermore, suppose the distribution is such that the mean is farther to the 'greedy' side than the mode and median (i.e., skew-right in the case of a seller). Something interesting then happens automatically...

When supply greatly exceeds demand, we find that the small percentage of discount sellers are the ones that take all of the business. Even though they represent only a small percentage of the supply, the demand is much lower than the supply, hence, most buy orders are filled at a price below the historical average, thanks to the discounts. Now notice that, since most orders trade at a price below the historical average, the historical average is automatically driven down. Basically, the non-discount traders say "wow, those discount sellers are getting all the business...I need to be more competitive." The price naturally continues to fall until either we hit the hard floor of production cost, the supply tapers off (because trading this commodity becomes less lucrative), or the demand spikes up (because buying this commodity and using it for something becomes more profitable).

Now, on the other hand, consider if demand greatly exceeds supply. Remember that a good portion of the supply is marked up - in fact, we'll say that tail end is really marked up. If you want to buy the entirety of a commodity's supply at any given market, you're going to be paying a pretty penny for it. You need only check the listings on any EVE station commodity to realize that this is very real behavior. The result? Buyers will continue to consume the supply up until there is none left, or until the price is simply not viable anymore. In either case, they have likely already payed well in excess of the historical average. If, in fact, a large portion of the marked-up supply was bought, then it stands to reason that the historical average will be driven up! Remember, this is because we skewed the distribution, so the mean of the distribution is actually well above the historical average. Buyers are willing to pay extra to get the over-priced supply since there's too much demand, and this is reflected in a natural elevation of the historical average. Once again, we see that the trade price average should continue to move to the point where supply and demand come back into balance. Awesome!

So, can it work? Sounds pretty elegant...right? Well, I've got a working implementation (albeit basic), and the results are actually fascinating. It seems to be doing exactly what I want it to, and has already made the market substantially less volatile and less predictably-periodic. The price belief spread acts as both a 'buffer' that helps reduce volatility, as well as a kind of 'sensor' that helps push the historical average in the direction dictated by the supply/demand ratio. Very cool

Very much looking forward to continuing this work. But seriously...I promise...no more economics tomorrow...

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

Yes. Absolutely. That's the kind of day of which we need more Grinded out some serious hours today on a lot of different fronts. Very excited in general about...uh...everything. Feels like so much is coming together now

Projects and Project Management Interface

Although I originally implemented the concept of 'projects' as an AI-side concept hidden within the management task, I realize now that the whole thing is exactly the kind of representation that we need for a powerful automation interface. We've spoken only minimally of automation in the past, with basically me promising "don't worry, you'll have powerful automation tools so that you don't have to micromanage everything." With the advent of a task-based macro AI, automation has never been more viable! I think it's time to move the concept of a 'project' into the user interface and get some serious empire control going.

What this will mean is that, for high-level empire control, you can create a 'project' based around a task (for example, 'mine at Konallian Asteroid Field.') When you create a project, the game will automatically begin to track a set of metrics, such as 'revenue,' 'expense,' 'cumulative inputs / outputs,' etc. so that you can understand exactly how the project is going. Interestingly, this is something that I've already done to help AI players manage their projects and assess project quality. But hey, it's also exactly the kind of stuff that players will want to be able to see, right? After creating a project, you then allocate assets appropriately - essentially choosing which ships and station modules you want to assign to the task. From there on out...you needn't do a thing! Just check up on the project from time to time to make sure that things are going well, and potentially allocate more assets if you want to expand your operations.

There are some interesting things that we can get into with respect to precise control over projects, such as how you want to supply the inputs (will you want to automatically buy from the local market? Or will you supply the project manually with another project?), what you want to do with the outputs (automatically sell to market? Store a certain % in storage?). The neat thing is that all of this actually begins with the management AI. These are all knobs that the AI needs in order to operate effectively...so naturally, we'll give them to the player as well! Once again, the player / AI symmetry in LT is a concept whose importance just can't be overstated. So much has fallen out of it already, and so much will continue to fall out of it as we push further into these late-game concepts

Implementing Workers

I've got an item class up and running for workers and I'm in the process of making the switch to the player / worker split once and for all. Moral issues aside, I'm pretty much set on workers being commodities like everything else, with no 'special' stuff going on. It just simplifies so much. This was really the original motivation behind the worker scheme - to introduce an easily-understandable manner in which labor (or the potential to produce it) can be bought and traded. More importantly, it can be easily-understood and quantified by both the player and the AI.

Interestingly, we already have a fantastic mechanism for 'producing' workers - planet colonies! You've already seen in the last update that we had a planetary colony operating as black-box production process. In that case it was simply consuming Viritium and...nothing else (not much of a production process eh ). But I spoke a few weeks ago about how we could imagine having different types of planetary colonies that represent different processes - agricultural, industrial, technological, militaristic, etc. Well, it certainly makes sense that, on top of the other commodities produced by these colonies, workers could be produced in the same way!

I'm very interested to explore the possibilities here. Can you imagine, for example, saying "Yeah, those Konalian Researchers are just so bloody smart...I loaded up a research lab with them just the other day and we've already had like 4 big breakthroughs..." Yep, that's right, workers are procedural just like everything else...what did you expect?

Worker Training and Skill Levels

Omitted due to length of devlog - will explain more shortly!

Flight Control Component

Previously, the AI managed flight control (maneuvering towards a destination, avoiding things, staying in formation, etc.) inside of it's 'brain.' But now that we have non-brainy people capable of piloting things, the model doesn't make so much sense anymore. In addition, we have to think about, for example, autopilot! In general, as I have found with the implementation of tasks, it makes more sense to associate control-based data with the entity that is being controlled, rather than the entity that is doing the controlling.

Today I implemented this pattern for ships, such that a ship can be controlled easily by any entity without needing extra state. The upshot of this is that I can finally remove the concept of players as assets, which was the intention all along with the player / worker split. We now have ships that can simply be crewed with workers and then given tasks to execute! Great

Woah. That one kind of got away from me in length Anyway. Definitely going to be looking for a few more days like this one (I'm looking at you, tomorrow!)

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