Open cut mining (mining + changing landscape)

[ssilk]

Two things brought me to this idea:
1. The lakes are sometimes disturbing and there is a need to fill them...
2. Need for mining deeper (sometimes, when material goes out)

The machine to do the open cut needs lots of ressources; two kinds exists:
1. Open cut miner
2. Open cut deployer

The miner works exactly like the mining drill (maybe it shows where it digs/fills up currently), except it is much, much faster (maybe fills one belt completely?), covers a much bigger area (aka 15x15), needs only one piece of land as the base, he can't touch and needs lots of power.

As long as it is positioned on a mineable area, it tries to empty the field, like mines. In normal mode, it stops when all is mined.

Switching to mode 2 (autoswitched when placed on an empty area), it digs into the earth and finds by decreasing probability any supply (iron, coal, copper...) and by increasing probability dirt.

Dirt is ... just dirt. Can't be used nowhere but in lakes, to fill them up. Therefore you need the open cut deployer. Any item the deployer gets will be used to fill up lakes. (So you can get also rid of too many trees etc.)

When the miner reaches a limit of X items digged on a piece of land, a piece of lake will be created instead. The other way round is with the deployer: When deploying X number of items, a piece of lake will become land. In both situations, the miner/deployer jump to the next reachable field and continue work.

Optional: Both, miner and deployer have sitches, how deep/high they go. So that the digger/deployer doesn't change the landscape. So a digger has 3 modes: "mineable only", "dig ground", "dig ground to lake" - and the deployer has 2 modes: "fill lake", "fill lake to land"

I think it would be fun to handle the amount of material, that comes out. Perhaps, dirt cannot be destroyed, so the way to put all dirt into a chest and destroy the chest is "not so good".

[DexterNemrod]

I for my part always saw our current mining as open cut mining (sans the deploying of the emaining material somewhere else (but instead using it to fill the cavity again, after all iron/copper/coal has been removed) ...
the problem I see with your suggestion is exactly the thing mentioned above ... removing the dirt and deploying it somewhere else (instead using it to fill the mined out space again) considerably alters the landscape (creating deep furrows/craters).
For those people who don´t have any liginte mining in their country and cannot imagine it, here a pic:

These things eat whole villages (not just a saying ... hundreds of people usually get relocated if a lignite field is located under a village, so that the miner has access to the site [leaving no trace that there ever was a village when the mining is done])

Therefore IMHO it isn´t wise to implement such a thing, before we don´t have a way to also implement the landscape altering done at the mining site ... for example if we had different altitude levels (so that, for example, every mined out 1 xyz-tile (with z being the height level) generates 1 unit of dirt (that can be used as a filler or to increase the height level of a single tile somewhere else) as well as a certain number of raw materials)

[metzyn]

I think a very cool modification to the existing mining drills would be to have a new drill that mines 2 or 3 times faster, but with a waste percentage. 20% or higher of the resources mined come out as waste instead of usable material. Therefore, you get the faster speeds but at a cost. Just a thought.

[ssilk]

Cool...

I didn't think that complicated. I thought for "what is needed to have fun with levels?" and the agile approach is just that:

A piece of map is either land or lake (=sea).
When sea, the level is e. g. 0 and you can only fill it up, until e. g. 10000 reached, then it becomes land.
When land the level is e.g. 19999 and you can only dig from it, until 9999 reached, then it becomes sea.
So, if it is land or sea is just another ressource (like iron, or coal) called "level" and some special rules that are activated when reaching the above mentioned limits. Only the "level"-ressource can be digged by the open cut miner and becomes either dirt or any kind of other ressource with some probability.

The hole model can be replaced in the future, when you can render height of terrain or have a more specific model about how the leveling should work. But I bet in the end, there is not so much difference to what you might target to.

[ssilk]

And as a reply to the picture DexterNemrod posted: How cool would it be to create such big crater-landscapes. Dig down land line by line? Never heard of a game, that you enables to modify the map in this way...

[MF-]

I don't think I want to navigate around various holes in the ground or risk breaking my legs...
It would also be unfair for the creepers..

[SilverWarior]

A piece of map is either land or lake (=sea).
When sea, the level is e. g. 0 and you can only fill it up, until e. g. 10000 reached, then it becomes land.
When land the level is e.g. 19999 and you can only dig from it, until 9999 reached, then it becomes sea.
So, if it is land or sea is just another ressource (like iron, or coal) called "level" and some special rules that are activated when reaching the above mentioned limits. Only the "level"-ressource can be digged by the open cut miner and becomes either dirt or any kind of other ressource with some probability.

The hole model can be replaced in the future, when you can render height of terrain or have a more specific model about how the leveling should work. But I bet in the end, there is not so much difference to what you might target to.

While you suggestion might seem easy implementable it is far from that. Why?
1. You would need to store aditional information for each cell of your map and this would require athleast 16 bits of information for each map cell. So if you have 400x400 map this would mean 400*400*16 = 2560000 bits of data. So for 400x400 sized map you would require aditional 312.5 KB of data. Since Factorio actually supports infinite maps the memory requirements would increase drasticaly.
2. As soon as you start making holes, you would probably want to modify patfinding so that units won't walk through theese holes. Changing the way how pathfinding algorithms work isn't easy and can lead to many new bugs.
3. You would definitly want to have visual reference of how much the each pice of land is minedl which makes map rendering more demanding (low end computers might suffer large performance loss).

[ssilk]

Hm.

Nice view into the internals.

To 1: You need to allocate it only for those areas, where the miner is in. The memory is then: number of places where miners are/has been * area a miner can cover. Limit the total number of buildable miners AND add, that after some time (some hours), such an area recovers (= is removed), so that you can repeat bulding a miner on it. Both together enables you to make the limits in a way, that it won't use much memory.
To 2: No idea, I don't know what algorithm is taken. I realized, that the current algorithm is complicated, cause I often saw, that the miners try to run to a place, where I have been about 30 seconds before.
To 3: Level of land/sea is - when building a open cut miner on it just a ressource of the land/sea. So you see it, by clicking on it.

To MFs- anwser: Maybe the places, where miners can be built are limited, so that the creepers can avoid it? For example for every mineable area as much points as needed to mine it with open cut miners. Same for lakes... avoids building random lakes.

Just my two cents for this... don't take my suggestions as critics, the game just inspires me and my fantasy walks around...

[MF-]

Technical note: if you allocated that space only for areas that have miners, the rendering code would have to check "is this allocated" for each thing rendered.
I am not sure it would work well.

[ficolas]

poor creepers, they have a nice planet, with nature and fauna (maybe just nature...) and an alien (the player is an alien for em) arrives, kills them, and destroy theplanet

[SilverWarior]

To 1: You need to allocate it only for those areas, where the miner is in. The memory is then: number of places where miners are/has been * area a miner can cover. Limit the total number of buildable miners AND add, that after some time (some hours), such an area recovers (= is removed), so that you can repeat bulding a miner on it. Both together enables you to make the limits in a way, that it won't use much memory.

As MF- already sat that would require aditional checking to see if such information is available for certain map cell. Becouse of the large number of tiles on the map theese checkings could take quite some time especially if you want to use that information even for something more than just rendering (pathfinding, ability to place other structures on such tiles, etc.).

Now to be honest there is another way to achieve this in an eficient manner but it would probably require rewriting whole map structure of Factorio and probably pathfinding allgorithm with it.
@Developers
Main idea on this would be that each map cell is a class object which then uses aggregation relation with another class which can store some aditional information for certain cells where it is needed.
Since C++ class handling is much similar to Objective Pascal class handling you could do wonders with class aggregation and not only for map handling, but in many other areas of the game itself.
If you wan't more information on this just say so and I'll try to explain it.

To 2: No idea, I don't know what algorithm is taken. I realized, that the current algorithm is complicated, cause I often saw, that the miners try to run to a place, where I have been about 30 seconds before.

Factorio uses a bit modified A* pathfinding algorithm.
But the reason why the miners ran to the place where you were before is becouse they calculate path they need to take when decide to move (go to the position where you were when they decided to move towards you) or if for some reasony they encounter obstacle on their path.
Crepers do tend to recheck your position and adjust path towards you every now and then but I'm not exactly sure at which intervals.

Just my two cents for this... don't take my suggestions as critics, the game just inspires me and my fantasy walks around...

Don't worry I'm definitly not taking your suggestions as critics but as game developer myself I only tend to provide explanation of how hard implementing of such feature can be.

[ssilk]

I'm also a software developer (currently working on pro7-games-plattform) and know how complicated/much work that can become until one simple feature is working under all circumstances. But on the other side: If everything would be easy, then we didn't have a job.

PS: My postings do always have the background to give you as developers ideas of things you didn't have thought of. My intension is to get the best possible game.

[ssilk]

See also https://forums.factorio.com/forum/vie ... f=6&t=1980

The extract of this thread: problematic implementation, there are new "layers" of landscape needed, which has several side effects in a pure 2D game. From the current view can be closed as "won't implement".