So this topic has come up before but thought I'd create a new topic as in this forum as it is technically a suggestion and it relates to implementation instead of generalities.

My idea:

As asteroids are created they come pregenerated with set commodities/resources. This could be several different types or just a singular type. This information is "hidden" from the player. Upon scanning of the asteroid a result is returned that gives a variation based on percentile of scanning equipment of possible resources contained within. This new information is calculated and then made visible via a "tag", much like ships currently are.

As for the scanners, a single scanner could hold set resources of up to three varieties. For these purposes we will call them Tactical, Environmental, and Astrogation. Tactical gives information on ships: Their fire power, their AI skill level, the type of ship. Astrogation gives information on the system you are in: Asteroid fields, planets, wormhole detection. The better the scanner, the further away you can view via RTS map the current system without having explored it yet (think the black out areas in other RTS's or even freelancer's inability to detect fields or bases until within a set distance). Environmental is for the scanning of asteroids for mining purposes. Every scanner can have one to all three of these things at different ratings. The higher the rating, the more accurate and/or further away the information that can be obtained. For this example we will use a base of 1-100.

Ship A buys a scanner that is Tactical 50, Astrogation 20. - This scanner is not very good at it's job. The ship increases the range of system sensor by only 20%. The tactical information it will display on the AI skill of another ship would be (actual numerical AI skill * (RNG -0.50 to 0.50)) not giving a very good guess.

Ship B buys a scanner that has Tactical 90 - This scanner is excellent at determining the skill of an AI on a ship. (actual numerical AI skill * (RNG -0.10 to 0.10))

Ship C buys a scanner that has Astrogation 50, Environmental 70. This scanner is decent at extending the range of discovering in a system ( a 50% increase). But is only so-so at determining the amount and types of resources in an asteroid for mining. If the ship scanned an asteroid that only had a single resources (actual numerical number of resource * (RNG -0.30 to 0.30)). If an asteroid had more than one resource there comes a chance you could miss the smaller number of resources due to poor scanning. For an asteroid with 100 resource X, 20 resource Y, 75 resource Z you first put resources in decending order (Resource X, Resource Z, Resource Y) then you have an RNG run three times 1-100 that would lead to yielding results like 20, 88, 69 (put output in ascending order) yielding 20, 69, 88. Stack first resource in ordered amount to first RNG ordered number. Because the Environmental scanner is a 70, a result of 1-70 will confirm the existence of the resources. Because the first descending ordered RNG number is 20 resource X is confirmed. Now comes the resolution of the amount (actual numerical number of resource X * (RNG -0.30 to 0.30)). In this mock up Resource X and Resource Z will be confirmed but resource Y will not. (it is a lot like doing critical hits in most RPG's)

Ship D buys a scanner that has Tactical 40, Astrogation 10, Environmental 40. While this scanner, when equipped, can do all three things, it obviously does nothing well.

Similarly, with this static numerical number locked into asteroids when it comes time to mine them (because a drill does not care how many resources a computer thought was there, just what actually IS there) just shooting an asteroid would yield only a small portion of the actual numerical value of resources contained therein. Say 10-20%. The mining "drills" that I assume would take weapon slots would be able to extract a variable amount more. I would also assume that shooting them is fast and easy but yields little. Actual mining drills take longer (the better the drill the less time) and have the ability to extract more (the better the drill the more able to be extracted) similar to damage vs. RoF on weapons.


pseudocode in case my explanation sucked in case Ship C. Also remember this is a super simple rough rough rough not even first draft kind of idea. I expect more from Josh, but never underestimate the power of simple solutions.
Edit: This was errounously placed in LTP suggestion forum. It has been moved here.

nickgreyden wrote:Ship A buys a scanner that is Tactical 50, Astrogation 20. - This scanner is not very good at it's job. The ship increases the range of system sensor by only 20%. The tactical information it will display on the AI skill of another ship would be (actual numerical AI skill * (RNG -0.50 to 0.50)) not giving a very good guess.

This would play nice with the stealth/visibility/power settings concept.

If you want to get some use out of your "bad" sensors, you would have to crank the power way up, meaning that you don't have that power available for other things and that you become a lot more visible due to your emissions.

Sensor systems more specialised in killing things would have a higher base percentage for the detection of them and could achieve the same much more... quietly.

JoshParnell wrote:Yep, it's true, exaggerated as it may be, I mined and sold my first 30 units of "unknown ore" today! It sure wasn't pretty. The mechanic right now is just a simple test, based solely on collision. Hit an ore-laden asteroid with something - anything (a pulse, a beam, even your ship's hull..) - and it will emit a piece of ore.

I assume that right now it's simple object collision.
Are you planning on a way to "dig" into the asteroid? To chip away at it until you get to the good stuff?

Even if not, you could still have an abstract version of "real mining".

Let's say there is one big mama asteroid or BMA.
Inside of the BMA there is a small sciurum asteroid - but you don't know that, yet.

If you take your biggest gun and fire at the BMA, you get a very low yield of silicates and other trash - but the BMA starts shrinking towards it's center.
Eventually it shrinks far enough that the sciurum asteroid starts poking out the side.
If you don't pay attention, you quickly trash the smaller asteroid with your "digging" laser.

At that point you switch to the mining laser, which doesn't dig as fast but has a much higher yield on the same deposit.


Overall it would still be a simple system.
Full object collision as the only "event".
No re-calculating any collision meshes - you scale the whole thing so asteroids shrink as they are being mined out.

The player could positively (or negatively =) affect the mining by switching and targeting the correct lasers at all times.
The alternative is to fire up the mining laser, point it towards the asteroid, and go make a cup of coffee.


Spin-off 1:
If you want to make it more interesting than that - that's easy.
There are different mining lasers that are calibrated for different materials / ores.
Every mining laser is not as random or as clumsy as a blaster but there are still noticeable differences in the yield when using the "right" one.
A "real" miner might be using 4 different lasers...
Basically that's a gimmick for players who like mining and pride themselves on filling their cargo holds much faster than some military wannabe miner... and not wasting any of the good stuff.


Spin-off 2:
Mining lasers are more efficient because they penetrate.
Where a regular blaster detonates on the surface and only "excavates" this material,
a mining laser
1. impacts on the surface, excavating a little material,
2. impacts 30 cm under the surface, excavating a little material from there,
3. impacts 60 cm under the surface, excavating a little material from there.

Every time you use a mining laser for drilling you are automatically doing some test drilling for deeper deposits.
Also, once you have spotted a valuable vein, you can mine it with your mining laser even after it shrinks back below the surface of the containing asteroid.
That makes it safer to switch to a big gun and clear some more trash.

Very interesting, I will have to play with the idea of scaling the asteroids to convey depletion. It's certainly technically easy, I just wonder how it will look...I'll try it sometime! But I love the idea of having embedded physical deposits inside the rock that need to be uncovered first before they can be mined. Love how physical that is, as opposed to just seeing some abstract representation of the underlying ore on your scanner and just "believing" that it's there when it gets extracted.

On the other side of the spectrum, I really wish we could do real asteroid destruction (actually see the hole you're drilling), but I do not think this will be feasible with the current resource system. It may be possible if I manage to thread and significantly speed up the generating system. Obviously this would be the coolest thing ever..."real" mining

I like the idea of specialized drills reaching deeper than the surface. Like you said, it's also a good opportunity to prospect by just tapping around on the surface. Then again, if you've got a drill, you also, presumably, have a scanner that can locate the deposits.

Finally, the original post's idea concerning scanners sound just like rolling several scanners into one. Not really a special case of anything, just a combination of what would already be there. I'm not at all opposed to it. It could be a good trade-off that you have to make if you're in a small ship. Maybe you only have one hardpoint that can fit a scanner, so you have to choose how much enemy detection capacity you want vs. how much ability to prospect. Bump up to the next class of ship and you'd have the ability to get a specialized scanner for both and fit them at the same time, no need to choose.

Good stuff

JoshParnell wrote:On the other side of the spectrum, I really wish we could do real asteroid destruction (actually see the hole you're drilling), but I do not think this will be feasible with the current resource system. It may be possible if I manage to thread and significantly speed up the generating system. Obviously this would be the coolest thing ever..."real" mining :)

That could still use the concept I described except that instead of the entire asteroid shrinking, you'd see the "real" hole you dug.
The question is if that's worth the effort.


These concepts are full of shades of grey so...
what if the BMA from above consisted of well... modules?
By shooting at a specific area of the asteroid, you are damaging a module that makes up a small part of the BMA.
That distinct piece is eventually destroyed and you get a hole or dent.

Certainly less memory intensive than saving the condition of each Minecraft-style block on an asteroid.
And with distinct modules having their own collision meshes, there is no dynamic reshaping going on. The whole module is taken out when it's destroyed.

Asteroids would be generated more like a ship. That these asteroid modules overlap would be normal and hardly be a visual problem. If a half sphere of sciurum is sticking out and you "mine it out", you would only see the half sphere vanishing and be looking at the next lower layer.
Who cares if it actually was a full sphere? It's an asteroid! There is no need to carefully line up modules to create a good-looking ship.


Spin-off 1:
With the module design, not every asteroid would need to be a solid rock.
Random chance would almost certainly generate asteroids with holes or entire cave systems, giving the spelunking miner (with a small ship) an opportunity to get at the good stuff faster.

I like the idea of specialized drills reaching deeper than the surface. Like you said, it's also a good opportunity to prospect by just tapping around on the surface. Then again, if you've got a drill, you also, presumably, have a scanner that can locate the deposits.

The player gets what we want him to get. =P
Besides, a scanner does not necessary print out a shopping list of ore deposits. It may just give you the distribution of light / medium / heavy elements.

Finally, the original post's idea concerning scanners sound just like rolling several scanners into one. Not really a special case of anything, just a combination of what would already be there. I'm not at all opposed to it. It could be a good trade-off that you have to make if you're in a small ship. Maybe you only have one hardpoint that can fit a scanner, so you have to choose how much enemy detection capacity you want vs. how much ability to prospect. Bump up to the next class of ship and you'd have the ability to get a specialized scanner for both and fit them at the same time, no need to choose.

Pretty much what I had in mind. The thought being the more diverse you get with your scanners the less good they do each job. A single scanner might have an 80 in tactical, but for the same cost an equivalent scanner might give you 70 tactical 10 astrometric... or the payout could be further reduced to 50 and 10. The higher the cost, the more "overall" points to spend on a single ability or shared abilities. If you have more than 1 hard port for a scanner, the math could result in either diminishing returns or simply have an additive effect. Either way, you can amp up your scanners ability if certain top-end ships, especially cargo ships or heavy combat ships, specialized in multiple scanner ports.

JoshParnell wrote: On the other side of the spectrum, I really wish we could do real asteroid destruction (actually see the hole you're drilling), but I do not think this will be feasible with the current resource system. It may be possible if I manage to thread and significantly speed up the generating system. Obviously this would be the coolest thing ever..."real" mining

Isn't this just a matter of subtracting a volume from another volume? I understood that these operations would be fairly easy with scalar fields. I would love the same system for hull damage or damaging internal ship systems. Imagine a beam laser shooting through an enemy ship, passing the shields and 2x the hull. Or even slice a ship in two?
Conceptually there wouldn't be much difference between handling an asteroid with veins of materials or a ship with rooms. The difficulty with ships seems to be that the builder needs to control the lay-out. (Hello player built asteroid base!)

Katorone wrote:

JoshParnell wrote: On the other side of the spectrum, I really wish we could do real asteroid destruction (actually see the hole you're drilling), but I do not think this will be feasible with the current resource system. It may be possible if I manage to thread and significantly speed up the generating system. Obviously this would be the coolest thing ever..."real" mining

Isn't this just a matter of subtracting a volume from another volume? I understood that these operations would be fairly easy with scalar fields. I would love the same system for hull damage or damaging internal ship systems. Imagine a beam laser shooting through an enemy ship, passing the shields and 2x the hull. Or even slice a ship in two?
Conceptually there wouldn't be much difference between handling an asteroid with veins of materials or a ship with rooms. The difficulty with ships seems to be that the builder needs to control the lay-out. (Hello player built asteroid base!)

Yes, you're right, it is very easy mathematically. The problem is that the engine would be trying to recompute the model in real-time, and I don't know if it's up for that. It's a lot of intense computation to evaluate the new mesh, and if you wanted to actually drill an asteroid or slice a ship in real-time, we're talking about many recomputations per second. Just don't know if that's feasible atm

Katorone wrote: Isn't this just a matter of subtracting a volume from another volume? I understood that these operations would be fairly easy with scalar fields. I would love the same system for hull damage or damaging internal ship systems. Imagine a beam laser shooting through an enemy ship, passing the shields and 2x the hull. Or even slice a ship in two?
Conceptually there wouldn't be much difference between handling an asteroid with veins of materials or a ship with rooms. The difficulty with ships seems to be that the builder needs to control the lay-out. (Hello player built asteroid base!)

It gets a little complicated to do it quickly in real time because while objects in LT are scalar fields which can have boolean operations done on them, the actual model you see is a triangle mesh generated once from the scalar field, so you have to regenerate it any time it changes if you want to show changes. At that point it becomes a decision, do we rebuild the whole mesh? Do we clip some triangles and patch the new geometry in? If we do, how do we do that reliably without artifacts? How do we do it all in one frame? Is it doable in one frame at all? If it's not, do we need to raycast when the player triggers firing a shot, determine where the mining beam will hit, and split generation up into the couple frames lead that gives us over doing it all when the beam hits?
That's just general, there's a lot more to consider depending on the engine. Lots of things to think about and work through.


Asteroid material shrinking uniformly worked in Homeworld because it was basically scraping the surface down all over with a tractor beam, then processing everything inside the Resource Collector. So it's also down to how you explain the tech. That being said, I'm in support of actually chipping away or boring into asteroids in an obvious and semi-realiastic way, rather than having them just scale down. It really depends on what level of realism is being shot for though.

Edit: Josh answered while I was writing this

More of a logistics possibility...

It depends how 'real time' you would want to show the change. For example, does it take at least X amount of time before any change is shown? If so, then you can recompute the mesh during that X time frame, and if the player decides not to mine until the shape changes, we can discard the new mesh. If the player keeps mining it, then show some sort of dust cloud explosion and replace the mesh, aligning properly so when the dust clears it looks like we dug something out.

I have always favored look-ahead types of operations rather than on-access. For example, when you are start a new game, the game should be working in the background to generate the systems that are all connected to your current one so that when you take a jump-gate / wormhole, you don't actually have load times, and you're just treated to fancy graphics. It also means that if you happened to take the wrong jump gate, going back through the one you came doesn't introduce a second load time as well.

We can also use some basic heuristics so we're not incorrectly assuming. If it takes X amount of time to mine a chunk that would require a mesh update, don't even assume the player is mining until time of X / Y has been reached. This way, we don't accidentally start creating hundreds of meshes upon a single shot being fired (maybe 1/4th of the damage done needed?).

While I know that more than likely this won't happen, I'm just tossing my thoughts out there in case it spawns any other ideas.

JoshParnell wrote: Yes, you're right, it is very easy mathematically. The problem is that the engine would be trying to recompute the model in real-time, and I don't know if it's up for that. It's a lot of intense computation to evaluate the new mesh, and if you wanted to actually drill an asteroid or slice a ship in real-time, we're talking about many recomputations per second. Just don't know if that's feasible atm

Wasn't this problems solved by a very simple game in the begining of computer games that happens to be about you favorite subject, Shooting asteroids?
When you hit an asteroid enough it breaks into to two parts that have less mass combined then the starting asteroid, and the process repeats a few steps until the parts are so small that they disappear when you hit/mine them.

Basically what I am suggesting, breaking off parts / chunks in a cloud of dust and removing much more mass from the asteroid then the actual chuck is. The process of removing mass is masked by the dust/action, and it's also divided into bigger events/steps for the re-computation to handle.

I am curious as to the difficulty of implementing physics on the asteroids so that, rather than being stable objects completely immune to your weapon-fire, trying to excavate them quickly with blasters would actually send smaller ones tumbling through space. This would add a certain level of difficulty to mining the asteroids rapidly, but could be offset by the actual mining lasers/drills having very little impact on the asteroids, preventing them from being flung about.

I'm not sure how much this would actually add to the gameplay, since it would really just make it more difficult to mine, but would make it more "realistic".

Whatever you decide, I really hope the actual asteroid deformation can be implemented. The only thing I would worry about with that is that very small parts of the asteroid could get left behind and produce hard to see "space speed-bumps" that your ship could randomly smash into.

Edit: Just thought of something: rather than mining just with lasers/blasters/random ranged mining tools, could a rock crusher + tractor-beam type system be implemented to rapidly consume small asteroids (or gnaw away at big ones) at the expense of not being able to be selective about what parts you are mining? I've always wanted a mining ship that could just sort of "eat" the asteroids.