SWEET FANCY MOSES that was a satisfying click.Cornflakes_91 wrote:
Thanks!
SWEET FANCY MOSES that was a satisfying click.Cornflakes_91 wrote:
I think you've got most of the general idea, but I'll explain the actual implementation anyway (and why it is efficient). A blueprint is a pointer to another blueprint (its 'parent' or parent directory in your model), plus a list of attribute operations (you can think of that as a very, very limited script, but really it's better thought of as a 'diff' between the parent blueprint and itself -- an object-attribute-space differential, so-to-speak). This is highly memory efficient, as we require very little memory to make lots and lots of slight variations of an object. If the variation is slight (for example, a delta in just a single attribute), then the memory required for the BP is very, very small (quick mental calculation says ~20 bytes on 32-bit machine, ~32 bytes on 64-bit). "Absolute Original" blueprints (i.e., those that haven't been derived through researching a stem of an existing blueprint or implicitly derived by modifying an object (note that virtual blueprints are not visible to the player, but rather an abstract BP that exists solely to help the AI understand and quantify the nature of an object that's been modified -- by keeping an up-to-date virtual blueprint for the object, we allow the AI to apply the same reasoning to all blueprints when it comes to any type of analysis)) are simply blueprints whose parent field is 'None' and whose attribute operations consist of setting all attributes to their correct values (in other words, they're a diff with a 'null object', so to speak). These are significantly bigger than derived BPs, especially when they are for objects that have a 3D representation (because it is the base BP that actually holds the model). This paradigm of using chains-of-diffs pops up frequently in LT. It's a really, really good way to save memory when we're in procedural land where there's a huge amount of generated content, but where that content often has significant underlying similarities that can be captured in this original + diff + diff + ... manner. Kind of like prime factorizationHyperion wrote:Module instancing is actually proving to be a slightly difficult problem to hash out. Getting a good way to track 10,000 eventual variations on a single blueprint for every single blueprint without making the system cry is probably doable, but is beyond my realm of expertise. Just as a brief outline of my (probably dumb) thoughts, because this isnt really the place for it:
Blueprints are folders, but also instructions coded with the particular Tech stats. Inside the folder is a registry of every unique instance yet made and its stats, each tagged with the owner and where it's used. The owner and usage tags change freely via trade & plunder.
The currently simulated blueprints are known scripts, executed as necessary, changing the stats of the given instance.
Players & NPCs can also execute their own scripts (aftermarket modifications, improved/shoddy construction techniques & materials, overclocking, etc)on a particular instance which also changes the instance stats, but are wholly different from blueprint scripts. Such modifications don't affect the registry serial, but can affect the Human-readable name.
Destroyed instances (or intact but attached to destroyed ships/stations) continue to exist in the registry for potential salvage and reactivation until cleanup.
Temporary instances can also be attached with semi-random stats to permanent debris fields, but disappear as soon as a player is out of range.
Is this efficient? No idea
That seems to be quite well thought out, but I can't help wonder how this will work with the low-fidelity representation of far away regions in the universe :JoshParnell wrote: Technically, to truly be gone from memory, all existing copies of the BP must be destroyed AND all objects built from it, AND the BP must have no surviving children (all BPs that were ever derived from it, if any, have been wiped from existence as well). So it's a very unusual event for a highly-utilized BP to be wiped from memory, since it will often have objects in existence that were built from it, hence carry a reference to it, and will often have child BPs that were derived from it...
Shouldn't we drop old BPs once there are no more instances of them and they have become obsolete by technological advances? Otherwise, traversing the BP-chains for determining the properties of objects might get excessive in very long LT games.JoshParnell wrote: I think you've got most of the general idea, but I'll explain the actual implementation anyway (and why it is efficient). A blueprint is a pointer to another blueprint (its 'parent' or parent directory in your model), plus a list of attribute operations (you can think of that as a very, very limited script, but really it's better thought of as a 'diff' between the parent blueprint and itself -- an object-attribute-space differential, so-to-speak). This is highly memory efficient, as we require very little memory to make lots and lots of slight variations of an object. If the variation is slight (for example, a delta in just a single attribute), then the memory required for the BP is very, very small (quick mental calculation says ~20 bytes on 32-bit machine, ~32 bytes on 64-bit). "Absolute Original" blueprints (i.e., those that haven't been derived through researching a stem of an existing blueprint or implicitly derived by modifying an object (note that virtual blueprints are not visible to the player, but rather an abstract BP that exists solely to help the AI understand and quantify the nature of an object that's been modified -- by keeping an up-to-date virtual blueprint for the object, we allow the AI to apply the same reasoning to all blueprints when it comes to any type of analysis)) are simply blueprints whose parent field is 'None' and whose attribute operations consist of setting all attributes to their correct values (in other words, they're a diff with a 'null object', so to speak). These are significantly bigger than derived BPs, especially when they are for objects that have a 3D representation (because it is the base BP that actually holds the model). This paradigm of using chains-of-diffs pops up frequently in LT. It's a really, really good way to save memory when we're in procedural land where there's a huge amount of generated content, but where that content often has significant underlying similarities that can be captured in this original + diff + diff + ... manner. Kind of like prime factorization
So how come I can't get a simple one line answer to a question about the presence or absence of of immersive speech in Limit Theory? Do we get a Bitching Betty, chatter or anything at all related to this immersive element which can be found in practically every space game now?JoshParnell wrote: Many lines of text.
I don't see how that's going to be possible Victor. That would require someone to be used as voice talent and Josh never hinted about such a thing.Victor Tombs wrote:So how come I can't get a simple one line answer to a question about the presence or absence of of immersive speech in Limit Theory? Do we get a Bitching Betty, chatter or anything at all related to this immersive element which can be found in practically every space game now?JoshParnell wrote: Many lines of text.
Wait. We do have one of the best voices ever, don't we?BFett wrote:I don't see how that's going to be possible Victor. That would require someone to be used as voice talent and Josh never hinted about such a thing.
I..uh..need a tissue that was beautiful. The entire universe is one giant project and the various zones are sub-projects. In a sense, this not only unifies resource mechanics, It quite literally makes it possible to have an intelligent "God" of the universe, tinkering with the universal constants and/or creating/ending various sub-projects.JoshParnell wrote:Dear lord, I think I've just unified field resource regeneration mechanics with project manager capital expenditure mechanics So really, an asteroid/ice/debris/whatever field is a project manager for a sub-component of the 'universal project' -- it gets a steady drip of credits flowing into its wallet, courtesy of the universe, (until said wallet reaches a cap, same as in the auto-manage component of the projects mechanic), and expends credits as it sees fit, depending on the type of field, to bring new resources into the universe. Think of that when you approach an asteroid field in LT...he's actually a high-pay-grade manager!
If I understand this correctly, this is your "first principles" of research, upon there can be nothing of which there is more whicher -- Something that isnt procedural and is actually permanently defined for all universes? If so, this sounds like the target for modders who wish to bring something wholly new into the game, like "blink drive" teleporters or Magic-based weapons."Absolute Original" blueprints (i.e., those that haven't been derived through researching a stem of an existing blueprint or implicitly derived by modifying an object (note that virtual blueprints are not visible to the player, but rather an abstract BP that exists solely to help the AI understand and quantify the nature of an object that's been modified
I see, so these "Field Managers" are intelligently generating objects which maintain resource and value balance in the universe. Essentially, this could be used as an input control to ensure the overall number of objects in the simulation doesn't exceed the CPU's capacity to process them. It might be a wise idea to query cpu usage and framerate to adjust these value inputs into the game, as it would make scaling the game to any CPU easier, I would imagine.For example, a debris field might have a certain rate of 'value replenishment,' meaning once enough time has passed and the field is not at max value capacity, it may spawn an item of value <= its wallet, so to speak, and deduct that value from its wallet. In this way, although we spawn things, we still retain total analytic control over the injection of value into the universe. Doesn't seem too off-track from our motto of real gameplay dynamics, since we already do this with minerals.
First question, I assume that debris fields, while created upon the destruction of ships and stations, their "Wallet" would never replenish, correct? The Field manager may allocate different proportions of the field value to different artificial objects, (whose total value is some % of the objects before their destruction), and that how that value is divided up between salvage ore, artificial objects, data logs, etc. would just be shuffled around for each visit, no?I might, however, apply a nonlinear valuation function to 'artificial' objects in this case, such that it's generally easier for a field to spawn a natural object or a very common (cheap) artificial object, and disproportionately hard to spawn really valuable artificial objects (I'll probably end up making it a power function, and throw the power into the universal constants so that the user can tweak it for a different gameplay experience
This is a thread requesting you to give detailsAhhh what is wrong with me why is this post so long
and how would this behave for mixed-faction debris fields?Hyperion wrote:First question, I assume that debris fields, while created upon the destruction of ships and stations, their "Wallet" would never replenish, correct? The Field manager may allocate different proportions of the field value to different artificial objects, (whose total value is some % of the objects before their destruction), and that how that value is divided up between salvage ore, artificial objects, data logs, etc. would just be shuffled around for each visit, no?I might, however, apply a nonlinear valuation function to 'artificial' objects in this case, such that it's generally easier for a field to spawn a natural object or a very common (cheap) artificial object, and disproportionately hard to spawn really valuable artificial objects (I'll probably end up making it a power function, and throw the power into the universal constants so that the user can tweak it for a different gameplay experience
It was only a matter of time before some form of unified field theory escaped from you, Josh.[color=#BF0000]JoshParnell[/color] wrote:Dear lord, I think I've just unified field resource regeneration mechanics with project manager capital expenditure mechanics
Thinking of fields, and blueprints, in this way reminds me of some earlier conversations we had where I was imagining "projects" as a kind of Universal Converter:[color=#BF0000]JoshParnell[/color] wrote:So really, an asteroid/ice/debris/whatever field is a project manager for a sub-component of the 'universal project' -- it gets a steady drip of credits flowing into its wallet, courtesy of the universe, (until said wallet reaches a cap, same as in the auto-manage component of the projects mechanic), and expends credits as it sees fit, depending on the type of field, to bring new resources into the universe. Think of that when you approach an asteroid field in LT...he's actually a high-pay-grade manager!
ThymineC probably said it best while discussing Cornflakes's "pipelines" concept:Flatfingers wrote:...it's what I was after in my Star Trek Engineering blog post and what Thymine was describing at the start of this thread... so why not apply it to all complex objects, not just ships and stations?
Doing that would make those mechanics consistent, which is valuable for a game that's going to have a lot of complex systems. And I don't think it would be tedious with the kind of automation of production that I suspect Josh is thinking of supporting through "projects." You'd design a prototype object -- with specific internal components -- and then you can build any number of copies of that object, as long as your supply of each required component remains > 0.
In this way of looking at things, the entire universe of the game is composed of:ThymineC wrote:Regarding pipelines as "glue" makes a lot more sense to me.
Ask Josh to imagine projects as nodes and pipelines as the edges between them. That couldn't hurt.
Users browsing this forum: No registered users and 22 guests