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

Post

Week of June 22, 2014

#1
Sunday, June 22, 2014

Here we go...final week :geek: Once again I'm scattered all over the place, and am doing a lot of various polishing work. But today I'm actually most excited about the continuation of the zone tech, so I just want to talk about that quickly and get back to work ;)

Tech: Polygonization of Zone Boundaries

I mentioned yesterday that we can automatically create meshes for zones by using their field functions in the same way that we create procedural meshes for other objects in the game. Today I implemented it! I now have zone meshes that allow me to see the exact shape and location of zone boundaries. I still don't have the shader for them implemented yet (the boundary mesh should begin to fade out as you approach it), nor have I figured out how to texture it to make a convincing LOD representation of zones.

But it's definitely a step in the right direction :)

Tech: Toroidal Zones for Planetary Rings

Today I finally leveraged my arbitrarily-shaped zone tech to implement dynamically-loading planetary rings! It's simple enough with the new zone tech: all I had to do is implement a new field function for toroidal fields. Using a single torus and some scaling, I can get exactly the kind of shape that you would expect for a planetary ring.

The best part? Well...everything else just works, since the engine automatically uses the field function to compute membership and to populate it with dynamic content. When I approach the ring, I see asteroids being generated in the exact shape of the ring. It's just awesome :clap:
“Whether you think you can, or you think you can't--you're right.” ~ Henry Ford
Post

Re: Week of June 22, 2014

#2
Monday, June 23, 2014

Really so close to seeing an economy with production. I believe I can get it in time. I believe!! :D

Content: Production Processes and Non-Trading Economy Nodes

I'm still working to get production tasks into the AI's brain, but, in doing so, have encountered a moderate conceptual issue. I saw it coming a long time ago and knew I would hit it eventually, and now the time has come to deal with it.

The high-level AI thinks in terms of continuous processes (called projects, which are based on the atomic units of action in the LT universe - tasks). It thinks in terms of inputs and outputs. Inputs and outputs are always bound to an economy node - some object that constitutes part of the in-game economy. The economy node is the location at which a resource is produced or consumed. An economy node, until now, has also been assumed to have a trade market, so that acquiring a resource at a given node is simply a matter of posting a buy order, and selling a resource at a given node is simply a matter of posting a sell order. The simplicity and elegance of that has worked very well for us so far :)

This model holds up well for a number of tasks. Mining, trading, piracy, etc. But there are some tasks that don't quite make sense with this model. Most notably, a ship with a tech lab or production lab (ye olde 'secret science vessel' :lol: ). A ship is not an economic node that supports trading. Goods produced at an on-board production lab must then be transported to a market if they are to be sold. Similarly, goods consumed at an on-board production lab must be acquired from somewhere else. These are both consequences of the fact that a ship does not have a market.

The problem brings us to an important question: how do we resolve tasks that consume or produce at non-economic nodes? Interestingly, this question is so general yet far-reaching that it has profound implications for a number of in-game behaviors. It's equivalent to a lot of other questions that I've asked before (specifically concerning transportation of produced and consumed goods).

I believe I've got the answer and I'm working on the code at the moment. I'm hoping this will be the last step before production becomes a true part of the LT economy, but I'll need a bit more time before we'll know :geek:

Polish: Engine Trail Optimization

After a quick profiling run, I was surprised to find that updating and keeping track of the new engine trails was taking a rather absurd chunk of the frame time. After digging back into the code, I realized...well, I must have written that code quite some time ago :oops: Now I think I see why I removed trails. That code is slow. Probably because I used a dynamically-allocating and non-contiguous data structure (a deque) where a simple, contiguous circular buffer would have been fine :oops: Newbie mistake. But I fixed it :geek:

---

PS ~ I know, I know..those dev log times :shock: I'm trying to get a handle on them! But you know how that goes :roll:
“Whether you think you can, or you think you can't--you're right.” ~ Henry Ford
Post

Re: Week of June 22, 2014

#3
Tuesday, June 24, 2014

Massive day, once again in the zone and it couldn't have come at a better time :) I spent all day this time on the economy, AI projects / tasks, and life. I'm determined to see production happening.

Wrapping Tasks with Buying & Selling Tasks

As per yesterday's challenge, today I implemented a solution to allow the AI to understand how to travel to acquire task inputs as well as to sell outputs. IMO it is quite an elegant solution :geek: I implemented one task called 'BuyAnd,' as well as one called 'AndSell' - the former basically takes a task, then wraps it with another task that ensures that the inner task always has the necessary inputs available (by traveling to an economy node at which it can acquire the input resource(s)). The latter wraps a task and automatically locates an economy node at which to sell the output(s) after the inner task completes. In this way, we maintain the same, elegant task architecture! All the beauty of the original architecture still applies - tasks are extremely easy to understand, execute, and even execute in a coarse way (LOD simulation :cool:). Yet, we can now support tasks that have 'unbound' inputs and outputs (for example, producing or researching aboard a ship).

When the AI detects that it has chosen to create a project whose task has unbound inputs or outputs, it knows that it must then wrap the task with Buy / Sell in order to create a fully-functional project. The AI still needs to make a decision concerning where to buy and sell, but I actually really like that this question is now separate from the inner task.

From the human player's point-of-view, despite the fact that the project interface still has yet to receive the love that it needs, this will eventually mean that, when the player chooses a task with some unbound inputs / outputs, he will have the ability to select where those inputs / outputs should be bought / sold. Thanks to the generality of the way I implemented it (i.e., wrapping a task with another task), we can even leave the door open for different buying / selling behaviors (instead of Buy and Sell, we can have BuyForBestPrice, SellForBestPrice tasks that automatically locate the best deal within a certain distance). Again, that's thanks to the fact that the actual architecture is agnostic to the details of how resources are bought and sold.

---

Hope I've made a bit of sense today - if not, I apologize :D I'm close to having this whole beastly thing running, but still am not there. Absolutely can't wait for the moment when it all comes together :)

PS ~ Yeah, I'm happy to be working on AI and the economy again. Really happy. :squirrel:
“Whether you think you can, or you think you can't--you're right.” ~ Henry Ford
Post

Re: Week of June 22, 2014

#4
Wednesday, June 25, 2014

Successful Implementation of Buy/Sell Wrappers!

Finally got it! Today, for the first time, I have AIs creating tasks that involve choosing where and how to buy or sell the inputs / outputs of a given task.

As a test, I've changed the mining task to have an unbound output. Previously, I worked around the lack of this tech by making the mining task a 'mine at X and drop off at Y' task. Ideally, though, actions should be as atomic as possible. 'Mine at X' and 'drop off at Y' should be separate tasks, but this wasn't possible before the advances made this week :) Now it is! In order to create a mining project, the AI recognizes that 'mine at X' has an unbound output (meaning an output that's not at a trade node), and wraps the project in a 'sell' task, thereby choosing where to sell the ore.

This structure makes more sense all around, but it actually also has a nice bonus: yep, you guessed it...less code! Smaller, more-atomic tasks means less code in each task and greater reuse.

Alright, I think you all know what time it is now...production time :cool: Let's go!!

A Bit of Fun With Camera Tracking & Effects

Inspired by this thread, I just had to spend an hour or so today playing with some camera motions and post effects for the main menu. I had fun :monkey:

For motion, I am playing with various types of smooth orbit & zoom motions, as well as smooth panning from one object to another. I haven't gotten fancy yet, but I've been thinking that it would be interesting to take into account things like nearby planets or large objects, such that the camera automatically tries to frame a nice shot (Limit Theory aka "pretty wallpaper generator 3000"!) For effects, I just threw together some basic classic camera effects: some vignetting, a bit of noise, a hint of aberration. Looks quite cool :)

Although the primary application of this work is for the main menu, we can also use it for an 'observer mode' wherein you simply watch life go on in a universe instead of taking part in it. I'd be particularly interested in just letting that run on one of my computers at all times, occasionally glancing over to see what's going down in the universe :D
“Whether you think you can, or you think you can't--you're right.” ~ Henry Ford
Post

Re: Week of June 22, 2014

#5
Thursday, June 26, 2014

Honestly it's always my favorite time of the month. Just a blur of code and coffee :)

Content: Production, Minting, and Research Tasks in the Economy

Yep, here it is...what we've been waiting for :) The economy is now identifying and caching opportunities to produce, mint assembly chips, and perform research on blueprints. This means that all of these tasks are now officially exposed to the AI and available for consideration.

Sadly, I still don't have production happening, but the only reason for that is that I don't actually have any chips or blueprints available in the system yet! I'm thinking I will implement a simple generation of basic random blueprints & chips from planetary colonies. As I've said before, colonies are basically my way of injecting or removing resources from the game. Since we can't see the actual internals of a colony, and since they're such a high-level abstraction, it's perfectly OK for us to do things like occasionally generate a random blueprint at a colony (although it should have something to do with the colony type - e.g. agricultural colonies might occasionally spawn a transfer unit blueprint, because we might imagine that transfer units are involved in agriculture. A military colony might naturally spawn weapon or shield blueprints from time to time.

I'm not yet ready to deal with first-principles research (i.e., research in which we try to create a new blueprint from scratch rather than iterating on an existing one), so this is my preferred angle of approach for the first pass of seeing a production-enabled economy.

Polish: Node Interface Visibility

Despite it just being a rather small tweak in the interface compositing code, I stumbled upon a really nice effect today that basically puts a subtle shadow behind all interface widgets, which dramatically increases their visibility, especially against backgrounds of similar color. It's now a whole lot easier to read the entire HUD when looking, for example, directly into the sun (for the sake of your retinas I still don't recommend pursuing this activity on a frequent basis :roll: ).

Looks a good deal more polished to me :)

Tech: Dynamic Zone Expansion for All Observers

With the new zone tech, we have a minor issue to be resolved with respect to the AI. Currently, the content of a zone is expanded only around the player (so that it can be rendered). In reality, though, a zone needs to be expanded around any observer. If the AI is trying to hunt for rich asteroids in a field, now that those asteroids are actually part of the dynamically-generated content rather than created during system generation, we actually need to expand the zone a bit around AI ships so that they can locate resources like the player!

I'm working on the tech to do so at the moment. It's non-trivial, but the good news is that we don't need to expand a zone as aggressively for the AI. The AI won't care if content seems to pop in a bit more suddenly :geek:

---

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

Re: Week of June 22, 2014

#6
Friday, June 27, 2014

Ahh! I'm sorry!! I keep wanting to write a dev log but also keep wanting to not lose my momentum (which, today, is considerable) :D

As it often happens with the last few days of the month where I'm in a rush, I present you with the ever-formidable list-format devlog!
  • Wrote shading model for zone boundaries (smooth fade out as camera approaches)
  • Made more breakthroughs with camera model! Feeling better and better every day.
  • New platemesh-based capital ship algorithm :shock: Not perfect, but significantly better than before IMO :D
  • Working on new implementation of colony landing mechanics (could we see planetary landing once more in this update??? Would it be too much to ask for that little miracle? :shock: )
  • Billions of small polish tweaks!!
  • Optimized opportunity caching to make AI & economy run faster
Let's keep going!!
“Whether you think you can, or you think you can't--you're right.” ~ Henry Ford
Post

Re: Week of June 22, 2014

#7
Saturday, June 28, 2014

Yes. Yes. Yes!!! No sleep last night but it was worth it :shock: :) Lots of miscellany today, but only two things that are really on my mind right now:

Zones as Docking Zones

Although I've been speaking lately about dynamic content-generating zones, the tech that the engine uses to detect when objects are in a certain zone is not bound solely to content-generating zones. I've now got the ability to slap a 'zone' component on any object in the game, and the engine will then recognize and treat the object as having a zone associated with it.

Here's the neat thing: we can use zones for anything. Consider docking to be a zone-based activity. To dock you will need to get in range of the object (i.e. 'in the docking zone'), press a button to request landing, and autopilot will take it from there. While this mechanism was already implemented in LTP, it was implemented in a specialized way. We've now got it back, but this time it's using all the good old zone technology that has been developed in the past week. That means docking zones can be significantly more complex than they were before (if we want to allow that).

This logic can apply to stations, carriers, and... :cool: ....

Colonies as Surface-Based, Dockable Objects

I had this idea a few days ago. With the zone tech, it couldn't have come at a better time :) Originally my plan was to have a menu that allows you to select where you want to go on the planet on which you are landed. While gazing fondly at a large planet this month, though, I started to think...wow, wouldn't it be cool if you could see colony nodes on your HUD, then just descend directly to the colony that you want to visit? Then travelling around a planet becomes 'real' travel, because you actually need to go up into space! Feels a lot nicer and more immersive to me :cool: I also just love looking at LT planets from space :geek:

Well, guess what? With docking zones it's all the same! Slap some colonies on the surface of a planet, give them spherical docking zones, and voila. We have colonies on which we can land. Very, very cool :)

I've already got the code for this up and running. No docking / descending animation yet, nor a fade. But that'll come soon :)

---

I'm hoping that I'll be able to bring the planetary surface code back in shape quickly enough to...well...I think you know where this is going :D :squirrel:
“Whether you think you can, or you think you can't--you're right.” ~ Henry Ford
Post

Re: Week of June 22, 2014

#8
Summary of the Week of June 22, 2014
  • Implemented real planetary ring zones using the new zone shaping tech!
  • Implemented buy/sell task wrappers for dealing with economic tasks at non-market nodes
  • Added production, minting, and research to economic caching, effectively exposing these options to the AI
  • Zone tech for docking & colony landing theory
  • Played around with camera effects for 'observer mode' (particularly as applicable to the main menu)
“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