Return to “General”

Post

Re: Proof

#138
Hyperion 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 :lol:
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 :geek:

So the key here is to think of a blueprint as a self-recursive object, much like a tree (except that it's really just a backwards-linked-list). As far as who's got them and when we need to delete them, this is of no concern: when a blueprint is lost -- let's say a ship carrying a blueprint that has no other copies in existence1 blows up and RNGesus decides the BP didn't survive, hence is nowhere to be found in the debris -- the refcount goes to zero and it's gone from memory. Reference counting really does work beautifully. Same applies to any temporary instances that might be generated -- as soon as no object is holding a reference to it (because, for example, the debris container whose inventory held the reference to this blueprint died of old-age and vanished from memory), it vanishes. Note that this hypothetical situation of finding a blueprint in a debris field may not even happen, since we try to always have an explanation for things existing rather than just 'generating them.' Then again, fields are natural sources of value within the game as they have a rate of mineral replenishment, so I could explore the concept of extending and generalizing that to different fields having their value source exist in different forms. :think: 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. 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 -- that's what I do with most things related to valuation and value transfer, since they're somewhat 'arbitrary' compared to many of the functions and formulae in the game). An actual original blueprint is both artificial and typically of very high value, so I wouldn't expect to stumble over them often, even if you're a seasoned explorer who's seen a lot of fields.

Dear lord, I think I've just unified field resource regeneration mechanics with project manager capital expenditure mechanics :wtf: 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! :lol:

What am I doing. How did all of this start from your post about module instancing. I must be in the theorycrafting zone right now :monkey:

*opens vim and wanders off further into gameplay theory lala land*

1 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 (who will often have objects in existence that were built from them)...and so on. But that's exactly the behavior one would expect. It all 'just works' in refcounting :) An remember, BPs are very small memory-wise. I won't do the exact calculation, but a single planet's texture takes the same memory as roughly a bajillion blueprints.

Ahhh what is wrong with me why is this post so long :shock: :ghost:
“Whether you think you can, or you think you can't--you're right.” ~ Henry Ford
Post

Re: Proof

#139
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...
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 :angel: :
-Will BPs existing in those far away regions also be reduced to a simplified form :?:
-If the player visits those regions again, will an approximation of the simplified BPs be re-created from the previously simplified BPs :?:
-Are player-owned BPs (or assets in general) excempt from reduction to a low-fidelity representation? If yes, what is the expected impact on performance :?:
Post

Re: Proof

#140
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 :geek:
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.

So, once a BP has gone out of use, the next BP down the chain should have its properties fixed and saved and can then be set as the new root BP.
Post

Re: Proof

#141
JoshParnell wrote: Many lines of text.
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? :angel:
Post

Re: Proof

#142
Victor Tombs wrote:
JoshParnell wrote: Many lines of text.
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? :angel:
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.
Image
Post

Re: Proof

#143
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.
Wait. We do have one of the best voices ever, don't we? :twisted:

Not a female one, though. :shh:
Image
"Playing" is not simply a pastime, it is the primordial basis of imagination and creation. - Hideo Kojima
Post

Re: Proof

#144
JoshParnell wrote:Dear lord, I think I've just unified field resource regeneration mechanics with project manager capital expenditure mechanics :wtf: 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! :lol:
I..uh..need a tissue :shifty: 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. :shock:
"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
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.
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.
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.
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
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?

Second question, how is object value going to be determined on a local level? You said it could be tweaked as a universal constant, but given that objects are valued via supply and demand, would this mean that debris fields are reading local markets to determine what is a low-value common object in that area? I suppose this would really allow for extensive localization for goods, even in debris fields, and would make it far more realistic than "And now I shall generate a Mk II Laser" for any given debris field, anywhere in the universe.

And expanding on the ideas of Localization and Field Managers, would it not make sense to apply this line of thought to distant star systems and Multi-stellar empires for LOD? Essentially the universe would just be a patchwork of "Fields of Value" which have a seed Culture Vector that starts throwing out iterations and recursions and history simulation as you get closer, much in the way a game like Minecraft handles Biomes (But much more complex). These "space biomes" could of course phase out as they are explored so the field manager doesn't accidentally "reallocate" your home system out of existence if you've gone too far away.
Ahhh what is wrong with me why is this post so long :shock: :ghost:
This is a thread requesting you to give details :lol:
Image
Challenging your assumptions is good for your health, good for your business, and good for your future. Stay skeptical but never undervalue the importance of a new and unfamiliar perspective.
Imagination Fertilizer
Beauty may not save the world, but it's the only thing that can
Post

Re: Proof

#147
Hyperion wrote:
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
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?
and how would this behave for mixed-faction debris fields?
Say a battlefield between two factions.
Both have their own tech and thus equipment.

With random shuffling ships of one faction could end up with equipment of the other one.
giving immersion and suspension of disbelief quite a hit.


Or are item types separated into their own sub wallets and individual wrecks have only access to specific wallets?

So the whole debris field has a total value wallet which defines the total worth of the field.

A number of item wallets which determines the types and maximum amount of each type of items (if only one ship with that fancy engine was shot down there you can only recover one of those engines).

[If the field is top-down generated at map generation time an amount of wallets for ship types are also present, for faction-correctness]

And individual wrecks with pointers to the item wallets and maximum recoverable amounts of those (you wont find 5 lasers in a fighter that can only mount 4)


debris fields generated at worldgen (off-camera) would have looser constraints in terms of ship and equipment compositions.
But fields created during gameplay (on-camera) would have pretty harsh constraints on what can spawn where.
("the fighter i shot down near this cruiser wreck had zorblaxian equipment, but the debris contains only andesian gear!" <- this should not happen)


Edit because of sleepy when writing:
When fields get generated during worldgen a couple of ship classes with "nominal equipment" get generated, assigned a worth and from thereon generated along the worth-likelyhood curve.
With every instance of a ship and piece of equipment taking some of the total worth.

For fields generated by gameplay every added ship flatly adds its hull+equip worth to the relevant wallets.
the values can then be used for AI/LOD calculations and maybe for exact item distribution. (Which ship gets how much of which equip)

Woohoo, something interesting \o/
Post

Re: Proof

#148
[color=#BF0000]JoshParnell[/color] wrote:Dear lord, I think I've just unified field resource regeneration mechanics with project manager capital expenditure mechanics :wtf:
It was only a matter of time before some form of unified field theory escaped from you, Josh.

:lol:
[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! :lol:
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:
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.
ThymineC probably said it best while discussing Cornflakes's "pipelines" concept:
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. :thumbup:
In this way of looking at things, the entire universe of the game is composed of:
  • converter nodes (projects that change inputs to outputs in defined ways, some of which are real objects)
  • pipelines between nodes (abstract connectors defining how objects move between nodes)
Fields are thus a project node, but the particular type of project node with "real object" properties (such as location, size, and composition) connected via pipelines to other object-type project nodes in a great galactic web.

Ships would be another instance of "object-type project node": they're projects for converting fuel to movement. ;)

And if you virtualize the ideas of "objects" and "movement," this model also lets you see blueprints as a type of project: they're conversion definitions for how to turn inputs (resources and components) into outputs (components and complex mechanisms).

Result: the "universal project" notion. It probably seems a little goofy until you consider how often "convert X to Y" shows up in a game designed to be a complex dynamic world. When you see "convert X to Y" as an atomic operation, darn near everything in such a game would use converters... so why not generalize the idea of "convert X to Y" as projects, and look for where that conceptual function can be applied consistently?

Certainly there'd be a fair amount of special-casing required to make a notion like this actually work as gameplay. But it keeps looking plausible to me.... :ugeek:
Post

Re: Proof

#150
I'm glad Thymine got a mention. :thumbup: :)

I can't say I'm that concerned about the blueprint discussion but just in case my query gets buried under the avalanche of text walls I would like to refer you to my humble request for information made in one of the less impressive posts above, Josh. :angel:

Dog with a bone and all that. :mrgreen:

Online Now

Users browsing this forum: No registered users and 6 guests

cron