When you want to answer I would be glad not to concentrate on details. I think much more important are things like "is it really possible?". Stuff like rotation of blueprints. The details are tasks of the developers, but I mean we (the users of the forum) should define the use-cases...
... Ok. I mean, that blueprints would give the game really some more depth. I found for example this thread:
https://forums.factorio.com/forum/vie ... nts#p10177
And it point to this:
https://forums.factorio.com/forum/vie ... 9045#p9045
and in the second part of this post is a video and I would say I want to do something like that - because it is cool. Or think to Star Wars, the mech-fabrics. It would be really, really cool, because this is also a feature, which brings the game very forward, because it speeds up the gameplay. And I want to mention the factory-thread ( https://forums.factorio.com/forum/vie ... f=5&t=1016 ) because on a bigger scale that reflects my thought in this post.
"How it works in detail?" is of course the next question. The best description I found is from here:
https://forums.factorio.com/forum/vie ... int#p10163
(Well, relevant is only the first paragraph, but I quoted more, because I found the other ideas worth mentioning.)Holy-Fire wrote:You don't need building robots for that. What I have in mind is that you can place a blueprint anywhere on the map, and it will appear as "ghosted" structures - they're not really there but you can see a mostly transparent version of the structure. When you go near the ghosted structure, if you're within building range and have the building in inventory, it will automatically be placed for real. So you just place the layout and then run through the construction site.
The same mechanic can be used for placing buildings in general, not just with blueprints. It's annoying when you try to place something, find out you're too distant and then have to place it again. I'm suggesting that when buildings are placed out of range, they will be ghosted, and placed when you get in range if you have them in stock. There should of course be visual and audio indication that the building was not placed for real.
Alternatively, you could do it so that placing ghosted buildings deducts from your inventory to begin with.
I mean, that it is simple, intuitive. You can place every entity as a "planned entity" and it will show up "blue ghosted", as long, as it could be built there and red, if there are trees or natives have settled there meanwhile... (maybe it shows yellow, when it can be built, but you don't have enough resources. Btw. crafting is some point I will came back later.)
On a larger scale, a blueprint is the plan how to place some entities. Placing a blueprint means then, that the "plan" is drawed into the map and the entities, which should be placed are now shown as described above. So I would distinct it:
- "planning" or "planned entities" is the process to set one entity anywhere on the map and it marks for the player, where he wants to place an entity (and the setup of it!) anywhere into future.
- "blueprinting" is the process to automatically place planned entities.
I would add, that logistic bots can also built. Instead of yourself. Much slower of course. And of course this needs to be researched, after you have the bots. You just need to plan/place blueprint and mark the entities in a way, that the robots know, that they need to built it. (Technically it is simple: Every entity, which should be placed is put into the queue and when it is placed it is removed from queue, it works not much different than a requester chest.)
I would also add (maybe researched), that the robots can "bulldoze". That means they can level the land (remove lakes? big question...), cut the trees, which stand in the way. They should remove existent structures/buildings. That would make sense, because I don't like to remove some big structures I had built (long lines of belts which have no use anymore and so on); takes too long and is a show-stopper in the game. A side effect would be to bulldoze only, without building anything. But this are also things, which can be implemented much later.
I mean this can really work and is easy to understand. It enables for example to plan big things and built it on demand, some times later. And enables to bypass waiting time, when you construct or when you plan it, it is put into a special crafting queue or so. I think I would use the planning very early in the game, because I don't like to craft and built at the same time, because it always interrupts me in my thoughts. So I would recommend to introduce planning very early, or from beginning. Blueprints can follow much later.
Now to the blueprints
Definition
The blueprint is a fixed plan of how to set entities in a fixed area. Using a blueprint means automatically place planned entities. See above.
Fixed plan means: When you have it (created, loaded)... the blueprint itself cannot be changed. The blueprint is fixed, like an plan on paper. You need to plan it (place it on the map, see above), then planned stuff can be changed of course (remove entities, turn them, replace...).
Fixed area means: They cannot be endlessly big. I mean, it can be just a map from another game (without borders), but how do you place it then? I think the blueprint needs borders. If the borders are just rectangular or can be any form is an implementation-detail. But the borders must be clear, and it should not be much bigger than a zoomed out view, due to pure practical reasons. Of course we can think about placing it on overview-map, but how should that work in detail?
So, what is a blueprint? And how can it be used?
Of course the first thought about it is like the blueprint-mod: A rectangle piece of map.
Basic use-cases are then: selecting the area, store the area as blueprint. Save the blueprint to disk, load blueprint, use blueprint to plan. That's the four basic functions. (Of course we can think about modifying a blueprint, when saved, but I come to it back later)
Besides these basic functions, instead of loading a blueprint, blueprints can be researched. (Eventually we need a new way to research blueprints?) But this is very much dependent on the balancing of the game, I think it doesn't make sense to discuss this in detail, but basically I mean, that I can select either a blueprint, which is game-content (they cannot be modified!) or own blueprints. For the game-content-blueprints I think to many (hundret?) of blueprints, which are sorted into self-describing folders. Now to really load the blueprint you need to "pay" something, call it research or something like that. It is quite cheap and fast, if you have enough resources. Maybe we can use the market for that?
But back to the blueprint itself.
A rectangle piece of "transparent" map has some disadvantages.
- mirrorable: I mean this is not a real problem. I found no exception to mirror every map. But I can be false.
Edit: This is a problem, when you use the splitters or inserters in some way, where the orientation plays a role. Best example is using two inserters as output. One inserter has the priority and that depends on orientation. In this case the map is not mirrorable. - rotateable: it is not possible to rotate every entity in Factorio. Best example is the gun turret. It is 2x1 tiles and when rotating it it keeps 2x1. In that case the map cannot be rotated, because other content may be overlapped or just doesn't make sense.
- argumentable: Of course it is possible to store the programming of an entity (which type of item should be produced in an assembly, how is the smart inserter programmed?) but what, if you won't store that in the blueprint and instead want the player to decide? Or more complicated: if you want to have "arguments" for a map, for example which type of item a storage should store? A production street should produce curved or straight tracks? That is not so easy, if you just have a piece of map, because you need to tell in any way, how the parameters should be checked.
- sub-blueprintable: I don't see much problems here. It is just a description which sub-blueprint is placed on which position under which circumstances.
This is an idea from arguments + rotating: A sub-blueprint is a blueprint in a blueprint. Why should that be useful? The rotation can be seen as argument. Now we can say: For this rotation use this sub-blueprint, for that the other. - connectable: lets say I want to place a powerpole and around them a set of laser guns with walls. I can create that once, store it and load it as blueprint and then place the others. But - what a shit - when the stuff is built together the powerpoles aren't connected. Because when you place a blueprint as plan on the map, it cannot know, that the blueprints should have a connection over this powerpole (and only this and not all others, because that would look ugly).
- automateable: lets say we have reached the end game and now we can generate self-reproducing factories. This means, that the bots have the ability to place plans from blueprints. The question is then: when should they stop? When should they use another blueprint? We are coming here to a very cool part, which means, that blueprints include also some kind of programming.
Rotation/Mirroring
-------------------------
As said for mirroring I don't see a problem. Edit: See above, there are cases, which work very different, when mirrored.
But I mean, especially the rotating hurts much more. We can go around that either by forbiding rotating blueprint. In my eyes no option, because I can think cases, where you cannot come out with mirroring only, because the direction of inserter/splitter takes sometimes a big role.
The next option is by (very) intelligent algorithms, which know, how the blueprint can be rotated or mirrored to have the same function or
by storing two blueprints (one for vertical, one for horizontal rotation, the 180 degree rotation is no problem and can be simply computed; don't mix this up with mirroring!) - that includes also, that it cannot be rotated, if the other direction is missing. Edit: Maybe we need to mix up different methods... see also sub-blueprints!
The algorithmic way can work for many situations, but there needs to be a verification-process, if it is possible.
Arguments
---------------------
I mean this is simple. Can work like stupid search and replace system: If this parameter is in the map, then show this requester to the user and replace that variables with the input-value.
Sub-Blueprints
-----------------------
This enables to create fractal structures. Might be very useful, because currently such stuff isn't possible, because it is just too much work.
Connectable
---------------------
More complex. I mean the prerequisite to this is, that it is possible to drag powerlines or belts, tracks, pipes (walls? every entity which connects to other areas of the map), instead of placing them. And this needs more or less intelligent pathfinding algorithms, which differ for every kind of structure a bit. Building power poles is completely different to building tracks and belts.
Marking entities in the blueprint which should connect to previous planned entities is easy, but I think the details are complex.
Automatable
---------------------
I'm thinking to some kind of programming language. I make some examples.
* An automated mine-builder: You set up an "intelligent requester chest" this "blueprint" and place it anywhere near a resource. Then you configure the area of the resource and the destination, where the belt from the mines should end. The intelligent requester chest requests a bot, a mine, poles, belts etc. and the bot places the mine at the best place, connects it to some power-source. Then the bot connects output to the belt and targets to the destination. Then the process restarts by connecting the next belt, where the mine should be placed possibly near to an existing belt. And so on. When a mine is empty, the mine is removed and the belt, when there is no more mine behind it.
* Self-reproducing factory: It needs copper and ore as given input-belts. From here it loads many small sub-blueprints and creates some assembly lines, which produce basic stuff like belts, assemblies etc. The last step in program is to find the next place for the blueprint, elongate the copper and iron belts to that point and create the next blueprint at this place.
I mean that kind of flexibility is very high end. I won't think too much about it.
Real user-stories
As the last points I want to describe some use-cases for simple things, which can give immediately a new type of gameplay.
- blueprints for "defense points". Call them "castles" or "line of defense". Many different types of "castles" are thinkable, including points, which have included radar, or balanced in a way, that they have their own power, by balanced solar-panels.
The user story here is: When I want to built that, it may happen, that I need to research some stuff, because it is not researched yet. I want to have that a little bit automated.
I mean as follows: Above I explained the list of planned things, ordered by the time I placed them. Now I can filter the entities, which are currently not researched. Then click to "research" and the research point is preselected. - Blue-potion production. Sometimes you have a perfect place and can built all in one. Sometimes not. Then you want to have different production-lines. Sometimes you have much resources and you can make it big, sometimes it's better to make it small.
I think it makes sense to have many different layouts for one type of production. - Train factories. This would be a dream: A factory, which produces tracks, trains and wagons. And it has a railway station, where it puts on trains in the wanted configuration (number of wagons, locomotives) and ready filled with tracks, ammunitions etc., if wanted.
Therefore I think we need a special type of inserter, which is able to place vehicles (entities) on ground/tracks and we need also a new "thing", which is able to enter any entity in reach and do some programming (in this case press "G" to couple the wagons/locos). - Autocrafting. You planned some cool stuff, long time ago. Now you came back, much later, and want to built it. You won't know how much you need to do that. For that case it would be quite useful to select the area of the planned stuff and it shows exactly which items are needed, like if you craft it yourself. Then you can just put that into your own crafting queue or fetch the stuff you need. And because that may take some time it would be a good idea to enable this function also on the overview-map.
- I made a super-cool train-station. Now I want to share it. Not possible, because the format of maps isn't very readable.
But the format of an blueprint should be human-read- and writeable. There are many other reasons for that, which I don't want to count here all, because the posting is long enough. But the second user-story from here is, that I want to be sure, that I made a valid map, which has the above described attributes (mirrorable, rotateable etc.) or not. - I planned and planned, much stuff. Now I want to built some part of it. I need to find the parts and eventually I need to tell my bots to built it. Without grouping it is not possible. So the user-story here is, to add groups into the planned items. Grouping can be easy if you add something like "signs". You place a sign anywhere on map and all items, which are near this sign become the same group. Could be of course much more complex later, but I mean in this way it is just practical.
