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

Post

Week of April 6, 2014

#1
Sunday, April 6, 2014

Got it. Maybe a bit radical this one, but highly elegant. Depending on implementation, perhaps even highly futuristic! Not so far from what my own conception of the future would be. This solution was strongly implied by my initial discussion of the crew mechanic, but has not been formalized until today.

Low vs. High Detail: Separating Labor and Thought

The fundamental trick that we will play here to solve everything is that we will treat living entities as being split into two categories: high level-of-detail and low level-of-detail. Low-LOD entities are those that will be performing labor, while high-LOD entities are those that are performing thought and management. As I will explain, this split not only solves our problems, but it also has a number of positive ramifications. In many ways, this split will very naturally mirror the split that already exists in the game between objects (instantiated, full-detail) and items (low-detail, abstract information only). All-around, to me it's the most natural thing ever and I should have seen it from the beginning :oops:

To explain how this will work, consider LT to be like a multiplayer RTS. Were that the case, you would have a concept of your units, as well as a concept of the other players. You might use your resources to build new units, which can fight, mine, spread creep, etc :P Are your units alive? Sure. But your control over them is direct. You tell them to move, they move. You tell them to attack, they attack. They do so because they are 'low-detail' living entities. They might do some pathfinding and obstacle avoidance, they might try to dodge enemy fire, they may even try to automatically use abilities and weaponry as effectively as possible. But are they going to go rogue? No. Do you pretty much know how they're going to behave? Yep.

Now look at the other players. Similarly to you, they have units. They have resources. Can you control them directly? No. But might you be able to work with them to accomplish something? Sure. You say "hey, I'll pay you 1000 gold to make sure I get from A to B safely." If they accept, you don't know exactly what they'll do. You can't grab their units and control them as you can your own, yet you know that the other player is going to work to protect you. You see their units escorting you. You know that if a threat presents itself, they will respond appropriately to deal with it. They are a high-detail entity, making their own choices and managing their own units, and when you work with them, you are working on a goal-oriented (equivalently, job-oriented) basis, unlike when you work with your own units, wherein you are working on an action-oriented basis.

This is exactly the distinction that we will make in LT. We will view the world as being inhabited by low-detail personnel - let's call them, for the sake of the devlog, workers, and high-detail personnel - let's call them players. Your ship is staffed with workers. You have workers in your research lab, grinding out new technologies. Workers may control your turrets. But when you accept a mission, it is coming from a fellow player. If you want precise control over your fleet, you hire/buy workers. If you want someone else to help you make something happen, but you don't want to acquire and control the assets yourself, you hire other players (aka NPCs, despite the confusing terminology :D ).

Exactly how it should have been all along, right? :)

The True Nature of Workers

The exact nature of workers is, in my mind, an open question. I have no desire to get into ethical issues with my game design decisions, but being able to throw around and generally send workers to their deaths when and how you please does beg the question "are they human?" Part of the point of a worker is that, once under your control, it does as you desire. It does not have a high-level thinking process that would allow it to reject your orders in favor of some other course of action. What if we considered the low-LOD lifeforms to all be advanced robots / androids / whatever? Maybe even partial clones? You see, we could get creative here to help explain and further characterize the thinker-worker separation :think:

To me, it doesn't even seem like a stretch that, in the distant future, the ratio of 'humans' to artificial laborors would be quite low. As we become better and better at creating machines that perform a specific role more capably than our own bodies allow us to, it seems perfectly natural that the place of the human would be more and more as the place of a thinker, managing large amounts of non-thinking workers that are actually carrying out the labor.

Obviously, one of the nice things that would come with artificial workers is that we can safely consider trading them as goods (with one-time costs), without any kind of moral dilemma :roll: "Hey did you see those Combat Pilot XLZ-600 droids on sale at Gartson? They're so cheap right now!" "Yeah man, I got a few of those myself. They're crazy good pilots, but sometimes a little overly-aggressive..." Indeed, we could think of workers as having attributes just like other items! And not even just raw capability, but perhaps 'personality' attributes as well. I won't even delve too deeply here, as the possibilities might make one's head explode :shock:

Performance Impact: That's a Lot of Activity!

By treating personnel at two different levels of detail, it almost goes without saying that we relieve ourselves of a lot of the computational cost of AI. But I'll say it anyway, since it's important :) Management is the most expensive part of the AI, because it requires advanced analysis of the local economy, consideration of asset allocation and the value of various tasks, etc. It's much more computational than, say, plotting a course for Alderaan (and even doing that ain't like dusting crops, boy.) By allowing a many-to-one mapping between workers and players, we create a universe that's capable of supporting vastly more large-scale activity!!

Skill Increase

Now, we've spoken of skill before in the initial introduction to crew mechanics. Even if the workers are artificial lifeforms, there's no reason to believe that they wouldn't be able to improve based on experience. In fact, if we consider workers as artificial (hence, trading them is morally-acceptable), we open up the door for an entirely new (and a bit strange) profession: training. Imagine setting up large-scale tasks for the sole purpose of training the machines involved, then selling them at a profit once they've acquired a high level of skill. Neat. Strange. Unlike any job you've seen in a traditional game? Probably :shock:

PC-NPC Symmetry, Player-Worker Asymmetry

Under this model, you can see that PC-NPC symmetry is fully-preserved. Players are all equal in their capacities. This is because we have moved the asymmetry into the worker-player split. Players are not equivalent to workers in their capacities. This is a question that was actually brought up when crew mechanics were first introduced: "can the player become a crew member aboard an NPC ship?" A very interesting question. Despite the argument that ensued, my intention had always been 'no,' but one would be hard-pressed to defend that position...until, that is, we introduce the worker-player split. Players do not become crew members for other players, so there is no need to introduce all of the extra game mechanics that it would entail (and thank goodness, because I think we're quite close to feature saturation for LT 1.0 :shock:).

Faction Membership?

Ok, so clearly we now have a concept of belonging to a faction, but that's only as an asset. As a player, you will never belong to another player in the same way that a worker might. So what of faction membership? What of players who want to give their support and be a part of the larger plans of another player? Well, don't worry, the theory is moving along here, but it's not finished yet. Needless to say it will exist. Faction membership is still a concept and still different altogether from being contracted to perform a job or from being owned as an asset. It has not been forgotten! :D

---

Whew. That's quite a bit. Probably lots of other stuff to say that I haven't managed to remember but...I think I covered the basics.

These dev logs are absolutely out of control, eh?? :lol: :shock:

PS ~ What? Did I just ninja 4 weekly summaries? :cool: :ghost:
“Whether you think you can, or you think you can't--you're right.” ~ Henry Ford
Post

Re: Week of April 6, 2014

#2
Monday, April 7, 2014

You know how it goes, after an uber devlog like yesterday, gotta calm down a bit :D Today I didn't sail too deep into those conceptual waters, just docked on the calm shores of implementation. Hoorah! Sanity!

Real Task Implementations

As I mentioned in the video, what was shown in update #15 was actually a sped-up version of the tasks involved (mining and trading). What I didn't mention is that they were also low-LOD versions - basically they were being simulated as they would be simulated if the player weren't in the system. This means that, even if a miner had reached an asteroid, it would not have started using a transfer unit, because in the LOD version of the task, the 'net effect' is basically enacted directly over time (in a probabilistic manner) to simulate the real thing without the computational expense.

Today I worked on implementing the real things, as the next step that I would like to see in the local economy will be the full versions of all of these tasks being carried out. No doubt we will run into performance problems with so many transfer beams buzzing around in the same system, but I'm sure it can be overcome in due time :geek:

Wonder if tomorrow will bring theory or implementation :think: I'll be happy either way! :)
“Whether you think you can, or you think you can't--you're right.” ~ Henry Ford
Post

Re: Week of April 6, 2014

#3
Tuesday, April 8, 2014

Woah! Andddddd there's what happens when you totally ignore part of your work for a day!! Nice!! Turns out it doesn't just go away :crazy: :lol:

Well, what can I say. Basically, no change from yesterday. I'm pushing forwards on implementation but not making immense amounts of progress. It just takes time :think: I'm guessing this means a few more dev logs before we're completely finished :crazy:

However!!! On the good side, I have to say...I am feeling immensely good about the worker / thinker / tool split. It's making so much sense in code, and that's really how you know that a design decision is going to pan out :D (at least, that's how I feel). If it makes sense in code, it makes sense in life :lol:

Ok hopefully see you tomorrow for something more exciting :)
“Whether you think you can, or you think you can't--you're right.” ~ Henry Ford
Post

Re: Week of April 6, 2014

#4
Wednesday, April 9, 2014

Yep! Here we go! :)

Real Mining! ...well, almost.

Hey great, these real tasks are starting to come together! We have real mining! Uh...well...close to real mining :P I am actually still invoking the 'mine' event directly (which is what transfer units are supposed to do). So there's still no transfer unit involved, but the ships do at least come into mining range, and the math that's used is the same as the real math. Yay!

Now, it gets a little harder. I need to figure out how exactly I want to handle ore respawn. It only took a few minutes of 'real' mining to realize...woah...look at that...the ore is getting exhausted! As you noticed in the videos, I am able to strip-mine a single rock quite quickly. Well, same for NPCs.

This is the part where I realize I should have set the mining task as a zone-based task in the first place. It's too narrow to say "mine at asteroid X," because right now that task will only last for...well, not very long! But "mine at zone X" is a much more reasonable request. It should be able to continue ad-infinitum (remember that zones have a specific rate at which they replenish their natural resources). Despite the fact that I want to keep my Starcraft 2 addiction a secret, I feel compelled to make a reference here that really sums up the 'correct' way of thinking: even if you take a probe / SCV / drone and tell it to 'mine' at a given mineral patch, it will automatically re-distribute itself to any patch in the same 'mineral line' (or...zone!) in order to attain maximal efficiency (or relocate in the event that a patch gets mined out). This is how it should work! :) If I say "mine at this asteroid," my worker should actually perform "mine in this zone," where the zone is the one that contained that asteroid. Yep :thumbup:

But this brings me to a problem. In all honesty, zones should be thought of as containing objects, and systems should be thought of as containing zones. The problem? Well, remember...like...half a year ago when I spoke of 'hierarchical scenegraphs?' Yeah. I still didn't get around to implementing it. But we need it. We really need for zones to have objects associated with them. But I need that hierarchical scenegraph! I'm just going to have to bite the bullet and devote one of these days to doing that. It shouldn't be too 'hard,' but it will definitely take a solid day of implementation work. Still, once we have that, we'll be in really good shape with respect to zone theory :geek:

Shaping the Asteroid Fields

As much as I like ellipsoids, it was a bit too clear in update #15 that the asteroid positioning algorithm is just an ellipsoid with exponential falloff. Kinda ugly. I'm not interested in 'realistic' asteroid field shapes (belts), but I do want something more interesting :)

So today I played a bit with the math for generating asteroid fields to create some cool patterns. Now you can actually see vein-like high-density regions. And I did it without rejection sampling! Which means the math is quite fast still :thumbup: Looks a lot more interesting.

Ok! Let's keep this implementation train rolling ahead! :clap:

PS ~ Super excited we got another RPS article for this month! I really wanted #15 to get noticed. Yayyy!!
“Whether you think you can, or you think you can't--you're right.” ~ Henry Ford
Post

Re: Week of April 6, 2014

#5
Thursday, April 10, 2014

Hmmm, not a particularly interesting day, unfortunately. No coherence really, a bit all over the place :think: I'm missing that March Macro Madness :cry: :lol:

Zone UI

I'm working on a HUD widget for displaying information about the current zone to the player. Already this is a very exciting little widget for me, because it just gives so much more...flavor to space :) Suddenly we are not just in some random place in some random system....we are in the Killydellian Asteroid Field of Sector XYZ! I will also show the 'owner' of the sector, if it has one. This way you will immediately know who controls a zone, or if zone ownership is in conflict, upon entering. Exactly how and why you are able to glean such information when entering a zone will be discussed in the near future :)

Grid Layout

Well, it's not new, but I poured several hours of love into the nodal UI's grid layout today. Making scrolling more robust, making the calculation of volume more precise, and so on. I'm really in love with this layout...as you saw in update #15, it really does a fantastic job of putting a lot of information on the screen in a way that's still structurally interesting (and flexing the muscles of the nodal UI!) :D

I believe we're going to see more of this layout in the future. I want to expand it and perhaps make this the 'uberlayout' of LT. One layout to rule them all, you know :) Imagine having a search box, filtering options, and customizable row / column counts on...everything :shock: Would be pretty great, don't you think?? :)

Ok! Honestly I just need a 36-hour day or so tomorrow and I will feel happy. Just need to push through some of these details so we can start digging into faction play...!! The night is young. But more importantly, the month is young. Let's go :D
“Whether you think you can, or you think you can't--you're right.” ~ Henry Ford
Post

Re: Week of April 6, 2014

#6
Friday, April 11, 2014

Fun times at the market! :)

Hierarchical Market Data History

Although I already had some basic historical market data, what I really need to bring both the market charts as well as the AI behavior to the next level is extensive historical data.

This one will get a bit tricky. My heart strongly desires to have full, 100% historical data to make things like this possible. Awesome, practical, and beautiful graph right there (thanks to Jörn Huxhorn for drawing my attention to this site in the KS comments section!) That level of historical data + graphs would pretty much be equivalent to having X-ray vision and just being able to pierce right through to understand the local economy in totality.

But, the fact is, in a procedural universe with procedural commodites, procedural traders, and procedural markets...memory can get out of hand very quickly. Even 100 'time units' of basic historical data for a market with 100 goods for sale is close to one megabyte in size. It may not sound like a problem, but 1 mb is huge for any one entity's data (note: graphics data is an exception, but it's also something we can drop fairly quickly when OOS). And when you consider that 100 linear time intervals is not very much (imagine, for example, 100 minutes), well...it's looking to be too much data :think:

So what can we do then? As usual, when we have too much 'stuff' to deal with, we will turn to...hierarchy!

Suppose, instead of just storing a raw list of all trades (too much memory) or a bunch of linear interval data (still too much memory), that we store a few smaller intervals for recent trade data, then some slightly-larger intervals for less-recent trade data, etc. etc. In other words, maybe we have 10 one-minute intervals, which allow us to see the market history at a one-minute resolution for the past 10 minutes. But then the next interval is '10 minutes,' and we have 10 of them again. This means we have a 1-minute resolution for market data that's 10 minutes or young, a 10-minute resolution for market history that's older than the 10 minutes but younger than 100, etc. So on and so forth. With just a few more levels, we can easily cover huge amounts of time!

If we go to the extreme and only use 2 as our exponent instead of 10, we can cover 2^(n-1) minutes of history using only n intervals. 100 seemed pretty small in the linear case, but now it looks like major overkill. At 11 intervals starting with one minute, we now get almost a day. At 21 intervals we get 2 years :D Clearly the scheme should be efficient enough :geek:

Despite the fact that we ultimately lose data, I think this scheme actually makes a lot of sense. In general, you will be more interested in the exact details of recent market activity, and more interested in the coarse averages of the distant past (which is exactly what this scheme gives you).

And...yes, it's already implemented! But I haven't built the chart yet :geek: I sense a bit of graphics Josh fun in the near future (he's been locked up for a bit too long, don't you think?? :monkey: ). I'm also very much looking forward to seeing how the volatility of the Viritium market at Gartson changes as soon as the NPCs start using the historical data :geek:
“Whether you think you can, or you think you can't--you're right.” ~ Henry Ford
Post

Re: Week of April 6, 2014

#7
Saturday, April 12, 2014

Ok, look...I'll confess. I'll just come clean...

I let him out. I let him out all day long :D And I couldn't be happier about it! Graphics Josh did good. He did real good today :monkey: Very fun and productive day :D

Light & Occlusion in UI

Previously the UI style was really strongly biased towards light. If you look at #15, you can see that the UI really feels like a full holographic projection - just a bunch of light. As much as that looks pretty good, I think all aesthetics are more effective when you play with both light and occlusion (blocking of light - basically the opposite!) Today I have improved a lot of the UI style to look cleaner, more readable, and just...prettier! I did so by bringing occlusion and light back into balance. Some parts of the UI shine brightly, while other parts soak up light, implicitly placing emphasis on the light parts. Not only does it just look better, but it also improves readability thanks to the fact that the UI is occluding more of the light from the actual rendered game world.

Very pleased with this work. Doesn't even look like the same UI that was shown in the previous update. Not even close :)

1000s of UI Graphics Tweaks

I'll just break out a list for the rest :geek:
  • Improved node title / subtitle as well as implementation thereof
  • Improved UI noise effects to only influence light and not occlusion
  • Improved rendering of layered UI panels
  • Implemented gamepad support for grid layout scrolling
  • Found & integrated a new font for the UI that is...wow! Blows away all the other fonts I have tried - makes the UI look so crisp!
That monkey does good work. We can't let him get carried away, of course, but it's definitely beneficial to let him out every once in a while, don't you think? :monkey: :ghost:
“Whether you think you can, or you think you can't--you're right.” ~ Henry Ford
Post

Re: Week of April 6, 2014

#8
Summary of the Week of April 6, 2014
  • Solved scope-of-hiring problem via worker / player theory
  • Implemented almost-real AI mining behavior
  • Implemented new asteroid field shaping algorithm
  • Implemented market historical data
  • Huge improvements to UI graphics!
“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 2 guests

cron