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

Post

Week of March 9, 2014

#1
Sunday, March 9, 2014

Ok! Finally a bit of a recession in devloggery today, as I'm trying to get the implementation caught up with all of these crazy theoretical ideas of late :)

One thing that I'm still trying to figure out is multi-faction, cooperative projects for mutual benefit. Essentially, the stuff a government would usually handle - infrastructure, protection of the general region, etc. I'm not convinced that one big overseeing entity is the right way to handle that, so I'd like to come up with a way to achieve similar effects without invoking government (and frankly, I just don't want to go quite that far with the simulation).

Coming back to the idea of Kickstarter projects, again, I couldn't help but think "wow, this is really a brilliant concept." Give money to fund a project that you believe will be beneficial to you in some way, not just financially. What if similar things existed in LT? What if we had the usual 'corporations,' which were dedicated to setting up a profitable business and creating value for their interested parties, but then we also had non-profit entities providing services like region-wide policing, development of infrastructure like new warp nodes, development of awesome new space sim games, etc :lol: How could that work? Could it? I'd like to think so. Most of the factions in a given area should be interested, at least to some extent, with keeping their area of operations safe. So shouldn't they want to pitch in to help pay for a local police force? Same goes for factions that have a lot of transportation processes. They should be interested in maintaining an efficient warp node infrastructure, and possibley creating new and faster connections to other systems.

Time will tell how that concept develops, but for now we must move ahead with processes. Looking for another big day of implementation :geek:

PS ~ It has come to my attention that the short-lived 'header style' of dev logs (introduced recently) seems to have disappeared. I am currently trying to figure out where it went :think:

PPS ~ Fun fact. I usually have to retry at least 3 times to spell 'corporation.' Coorporation, corpodation, cordporation, cooporation...corporation! Yes! Got it :ghost:
“Whether you think you can, or you think you can't--you're right.” ~ Henry Ford
Post

Re: Week of March 9, 2014

#2
Monday, March 10, 2014

Today I started to realize that the process model of which I've been speaking is really a demand-based concept. It says, "find a demand, then build a process (supply) to fulfill it." But I don't think I've been thinking enough in terms of demand up to this point. In particular, demand in the 'initial' economy is something that's virtually non-existent. I think I've been looking at it all a bit too narrowly, trying to generate reallyyy basic seeds of life with naught but a few transfer / research / production units. It's awfully hard to get things started from such a narrow starting point, especially when no demand exists.

For this reason, I think it makes more sense to set up a 'small' initial economy when a region is first generated. Generate a few small companies (depending on the population density), generate a colonized planet with some needs, etc. This way, we don't have so much of a chicken-and-egg problem in terms of getting things started. The chicken and egg just..exist. Through historical simulation, we can still smooth out incongruities as well as grow (or shrink :shock:, if they're unlucky) the initial population.

So, with all this talk of needing sources of demand, time to start thinking about planets? Yes, I believe so :think: But even more than that, it may be time to start thinking about 'basic' demands that can support the initial economy. Food? Energy? Clothing? ...Artifacts and alien organisms? :lol: We (or at least I) haven't talked about these kinds of basic commodities until his point, largely because they didn't seem to play much of a role in gameplay. But commodities, more than anything, can play a role in stimulating the economy...and that's going to be important.

Still looking for that big day of implementation as I try to fit all of these pieces together...sadly, it wasn't today as I've still got a few too many questions outstanding. But soon...:geek:
“Whether you think you can, or you think you can't--you're right.” ~ Henry Ford
Post

Re: Week of March 9, 2014

#3
Tuesday, March 11, 2014

All about implementation today...just what the doctor ordered ;)

I'm getting pretty deep into labor and contracts as I begin to think about how NPCs and factions allocate resources toward a particular process. At first I was thinking about personnel or machinery as a kind of 'startup cost' of a process, but now I'm thinking more clearly: just think of 'labor' as an input to the process. The difference? You have flexibility in where you get that labor. It can come from a contract, it could come from an allocation of existing personnel to a given task, or it could come from machinery (in the case of a job that can be performed without a person). I'm definitely falling into the swing of thinking in terms of processes, and it's only getting better and better :D Process trees make so much sense for high-level, planning trees make so much sense for low-level...seems like we've got it all covered!

Something that still evades me a bit is 'speculative demand' (note: I am using this in a different way than the actual definition of that term). It's a bit of a tricky concept when you want to try to supply a demand that is...hmm, how to say it...'created' by your supply. In other words, a demand that doesn't exist until your product comes along. This actually seems like a really common case. Consider: if labor is not available at all in a region, why would an NPC set up a business that hinges on it? That wouldn't make sense, so instead he will try to set up an autonomous operation. But then suppose you and your buddies come along and want a job. Strictly-speaking, there's no concrete demand for labor, simply because there was no supply of it in the first place, which caused the area to evolve in such a way that it could operate without that supply. Looks like you're out of luck :(

But really, this is a phenomenon that would seem to exist in every area of supply/demand - when there exists no supply, how does the initial demand come about? Basically, what one needs is a mechanism for understanding demand that could exist but does not yet due to lack of supply. In some sense, when thinking in terms of supply and demand, one must think of 'demand at the time that my product goes to market,' rather than 'current demand' - understanding that the very existence of your product can significantly change the nature of the demand. One needs a way of understanding the concept of "oh yeah, if your company could provide professional miners, I'd definitely sell these pathetic mining drones off and hire them in a heartbeat." One needs a way of understanding "sure, if you were to develop some new production unit technology, I'd gladly snap it up." But how can you formalize that kind of demand? Remember, in the AI world everything must be precise and formalized. I will need to find a way to formalize that concept :think: Maybe it has something to do with a company setting up a 'sure-fire' solution, but then issuing contracts for speculative 'better' solutions (e.g., in the example above, maybe it will set up a mining operation using only drones, but still issue contracts on the local market for mining labor, making it known that there is a demand for labor even if the operation doesn't actually require it to function). That solution sounds pretty reasonable, actually :geek:

I've also started to think about the different kind of contracts that can be offered for fulfillment of a task. In particular, I'm liking an idea that I had today about exclusive vs. non-exclusive contracts. Consider a traditional job - I would call this an 'exclusive' contract, because the company is relying exclusively on you to perform the task to which it assigns you (that is, the company assumes that you will perform the work given to you). In return, you're given a guarantee that completion of your work will afford you a paycheck. On the other hand, consider a 'non-exclusive' contract - a great example would be a bounty. That contract is going to be gone as soon as someone fulfills it, and everyone that sees the bounty has an equal opportunity to do so. It's much more of a competitive contract, but it also puts no pressure on any one individual. I can see a place for both types in LT. For players that are looking to make some guaranteed cash, a traditional mission approach makes a lot of sense: you're expected to perform a task within certain parameters, and in return, you'll be rewarded, guaranteed. If you prefer a less rigid structure, though, you can always just collect non-exclusive contracts and try to beat out the competition in fulfilling them. From a company's perspective, I'm not totally sure when one would try to issue one type vs. the other, but I'm sure there are some advantages / disadvantages of each to think about.

More answers every day :D
“Whether you think you can, or you think you can't--you're right.” ~ Henry Ford
Post

Re: Week of March 9, 2014

#4
Wednesday, March 12, 2014

Going to have to skimp on the dev log today, as, unfortunately, I just didn't manage to get through much talk-worthy work :|

Process Tree Implementation
I'm still working on process trees and getting the AI to generate them in a similar fashion to how it generates planning trees. Nothing particularly hard here, but it just takes a good bit of time to grind through the process (tee-hee? :D ) First tests will be with very basic mining production chains (phase 1 of LT RTS!)

Flowchart-Like Interface Layouts
On a different note, I'm digging back into interface work a bit, as I want to make a nice way to display and manipulate the process trees. I could do it with the old radial algorithm, or even the newer list one...but I'm thinking it might actually be nice to see a non-recursive graph layout for processes, since we'll probably want to see all of the processes at once. What I mean by that is, it would be nice to have a layout or two that doesn't use scaling, but rather lays a whole graph out on the same level (like a traditional flowchart). We'll see what I come up with :think: (Oh and I swear this work is not at all related to my desire for a structural programming language...I swear... :shifty:)

Let's hope for more excitement tomorrow ;)

PS ~ I'm liking all of these polls in the poll forum! Rather insightful so far :thumbup: (And much easier to keep up with than the suggestions forum these days.... :crazy: )

PPS ~ The fabled 'organized dev log' appears once more! Gasp! Will it stay this time?? Stay tuned to find out :ghost:
“Whether you think you can, or you think you can't--you're right.” ~ Henry Ford
Post

Re: Week of March 9, 2014

#5
Thursday, March 13, 2014
Whoops! Sorry for the late dev log...woke up a bit late due to a long night of coding :think: Hey, you can't blame me for that ;)

Custom Pieces & Icons for Nodal Renderer
Today I worked on changing the way the nodal renderer works to be more flexible. Previously, it used a set number of difference shapes that could be added by UI widgets. Today, I've generalized the system so that I can define any number of custom / new shapes. Rather than the node renderer keeping track internally of the different types of shapes, they are now defined externally, but still grouped and rendered quickly by the node renderer (it's really almost exactly the same as a particle engine!) More importantly, with the way the system works now it's possible to easily define 'icons' that are comprised of a set of shapes. That's was the real goal behind today's changes.

How did all this get started? Well, I was wanting to build a market screen so that I could visualize that good old supply and demand...but I realized it would be quite boring since I didn't have icons in the new nodal UI. What good is a marketplace without icons for each item? :ghost: My thoughts exactly. I have an old icon implementation that we saw in LTP...but it just feels..lacking, compared to the nodal UI's standards. That's why I figured I'd go ahead and build a new icon format that is comprised solely of the nodal UI shapes that you've all come to know and love :) I do plan to add a few new shapes later as well, just as icing on the cake.

So! We're now in good shape with respect to nodal UI icons. And as a bonus we get a more flexible nodal UI renderer :thumbup:

Planet Theory
:cool: Well...it's a bit too early to talk about this just yet. I don't want to jump the gun when the theory isn't solidified. But...planets will soon be playing an important role in the LT economy! :D

Hoping for another late night tonight... :geek:
“Whether you think you can, or you think you can't--you're right.” ~ Henry Ford
Post

Re: Week of March 9, 2014

#6
Friday, March 14, 2014

Mysterious and Cryptic Message
Need more time!!! :shifty:

I'm close but I'm not there yet. Just give me a bit more time :geek: Yes. Just a bit more. The flowers are blooming, the squirrels are singing, the birds are chirping, and even the otters are dancing. But I still need just a bit more time.

:think: :monkey:

:wave:

PS ~ Can you tell that I haven't slept in a long time?? :shifty: :ghost:
“Whether you think you can, or you think you can't--you're right.” ~ Henry Ford
Post

Re: Week of March 9, 2014

#7
Saturday, March 15, 2014

There's too much progress and too much thought to log coherently. I won't even try (to log it coherently, that is).

Refining the Task Model: Capability, Requirement, Input, Output

First of all, these processes of which we've been speaking lately are now called 'tasks.' (Has anyone noticed I have a burning love of renaming things?) The conceptual model of tasks has been further refined to the following four elements:

Capability: A measurement of the capabilities that influence an agent's performance of the task. In particular, the rate of a task is assumed to be linear in the total sum of all relevant capabilities of the actors that are assigned to the task. For example, 'transference' is a capability for 'mining.' 'Storage' and 'motion' are both capabilities for transportation jobs. 'Research' is a capability for...research! In every case, you see that the task becomes quicker or more efficient as the capabilities rise.

Requirement: To be thought of like an 'activation' energy. Many processes would require, for example, some motion capability. At the same time, it doesn't necessarily influence the rate of the process.

Input / Output: You already know :)

Item Classes

Sometimes, a flat hierarchy of items just isn't enough. See this topic to understand why. The engine now supports hierarchies of objects, where an object can be treated as a 'subclass' of another object. This allows for the possibility of many different objects to fulfill the role of one.

For example, I might put out a contract on Viritium, but that doesn't mean I need a specific type of Viritium. Maybe there's 'pure viritium,' 'compressed viritium,' 'impure viritium,' etc. Each fulfill the role of Viritium to a certain percentage. Maybe 'pure viritium' has a 2x multiplier, impure viritium has a 0.75, etc.

I'm excited about this. Definitely with respect to different purities of ore, different types of the same material, etc. But there's more to it than just that. Consider if 'deaths' or 'dogtags' are an item. The engine now immediately has a way to understand that 'Joe Billybob' is a subclass of 'The Band of Brothers' faction, so the item 'Joe Billybob Dogtag' can derive from 'Band of Brothers Dogtag,' meaning that a contract can be put out which pays for 'Band of Brothers Dogtags,' and it can be fulfilled by killing any member of that faction. Makes total sense, right?

This complicates inventories and fulfillment checking a little bit. But I think the price is definitely worth it. The ability of a subclassed item to fulfill the role of a superclass is going to come up in a lot of places and is going to be worth it's weight in gold! :D

Crew Mechanic.

Let's stop lying to ourselves, shall we? We need a crew mechanic. It doesn't have to be fancy. It doesn't have to be complex. But NPCs are intended to be first-class pieces of the game, so let's treat them as such. Introducing: crew quarters, crew taskings. Really, this doesn't add a whole lot of complexity to the game (don't worry!), it just answers a few questions that were already up in the air.

Who's piloting a ship? "The pilot. (Duh?)"
When I buy a new ship, do I have to hire a new pilot? "Of course."
Do I have to pay wages? "Yes. If you hire people."
You mean I have an alternative? "Of course. Robots."
So I can have a completely robotic fleet? "If you like."
Can I research better robots? "Yes."
Can I research better people? "That doesn't make any sense. But people gain skill as they increase in experience."
I have a capital ship with 20 independently-tracking turrets. Who's controlling them? "Someone. You decide. Could be you, could be Elroy McWampratSniper, could be GunneryBot 3000."

NPCs have stats that determine their effectiveness at certain tasks. This is not a new mechanic, it is 'capabilities' (from above) in disguise :cool: Stats are just capabilities. An NPC's 'gunnery' ability is the exact same as a transfer unit's 'transference' capability. They both affect the efficiency of an agent at performing a specific task. In the case of an NPC, the NPC's stats can change over time with practice. This separates NPCs from robots and gives you some trade-offs to think about. On the one hand, with an entire army of robots, you don't have to pay wages. On the other hand, the up-front cost is much, much higher, and the long-term potential remains constant. With an army of people, you pay less up front and have the potential to increase the effectiveness of the fleet over a long period of time - but in the end, you'll end up paying more since you're paying wages. Good gameplay choices to be made by any ruler :)

Tasks and Task Allocation

Let's talk about tasks. Tasks are everywhere in the world, and tasks go hand-in-hand with crew, because crew are the people carrying out those tasks.

For example, you can think of 'control forward turret #1' as a task that's implicitly created by equiping a weapon hardpoint. In fact, in general, it can be useful to think of tasks as being created by objects. Weapons create control tasks, tech labs (oh, hey, did I mention that I renamed research units to tech labs? :oops:) create tasks for research, production labs (heh :oops:) create tasks for production, etc.

That's obviously taking tasks to the micro level - but that's the beauty of it. This works for all levels of scale. Let's move back up and examine factional structure, as we were doing before with processes and process trees. Now we look at a faction as a group of tasks - but where do they come from? Well, that's the neat thing. Some objects are inherently dynamically-tasked in that they allow for dynamic creation and linkage of task networks. A faction is one such example. A faction only creates one (or maybe a few) 'inherent' task(s) - CEO, for example. But the CEO then creates a dynamic task network within the faction.

Task networks actually appear all over the place, which is why this model solves so many problems at once. One immediate example is fleet command. A fleet is a task network in almost exactly the same way as a faction - a fleet has a commander, and that commander creates tasks and assigns members of the fleet to them to build the structure of the fleet. Fleet-based tasks would be along the lines of 'scout,' 'tank,' 'support,' etc. (you might call them 'roles'). Planet? Oh, guess what, same story. A planet is a dynamic task network of 'colonies,' managed by a governor. Same structure as a faction or fleet. Same code. (Planet theory is still embryonic, so don't quote me too hard on that.)

Broad Strokes

I've said it before and I'll say it again: the only way to build something like LT in finite time is to find sweeping simplifications that asymptotically reduce the workload at every corner. Today and yesterday alone I believe I've just hit on about...er, roughly a gazillion such simplifications. At the same time, the game is looking to have more functionality than ever before. That's when you know the system is right - it's simple, clear, but flexible.

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

Re: Week of March 9, 2014

#8
Summary of the Week of March 9, 2014
  • Started thinking about basic demands and planets as the sources of local economy
  • Implemented process trees
  • Implemented piece-based node rendering framework + nodal icons
  • Implemented 'item classes' for item hierarchies
  • Started on crew mechanic theory :D
  • Dynamic task network theory (later called 'management'!)
“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