Thoughts about blueprints

Post all other topics which do not belong to any other category.
Post Reply
User avatar
ssilk
Global Moderator
Global Moderator
Posts: 10531
Joined: Tue Apr 16, 2013 10:35 pm
Contact:

Thoughts about blueprints

Post by ssilk » Fri Oct 25, 2013 2:04 pm

This is a very long posting, so I hope you take the time to read it with the needed attention. :)
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
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.
(Well, relevant is only the first paragraph, but I quoted more, because I found the other ideas worth mentioning.)

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.
Planning should be endless, I mean, you can plan as much as you want. But there should be an overview what has been planned, where it is on the map (something like a link into the overview-map and/or the direction/distance) and in which order. The first planned entities should be first in the list of course. On a higher level it is eventually possible to group them, like "belongs to blueprint A" or user signs like "area 51". Many possibilities but now not really needed.

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.
Possible solutions

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.
Ok. finished. That comes out, when I have time. :)
Last edited by ssilk on Fri Oct 25, 2013 2:34 pm, edited 1 time in total.
Cool suggestion: Eatable MOUSE-pointers.
Have you used the Advanced Search today?
Need help, question? FAQ - Wiki - Forum help
I still like small signatures...

ficolas
Smart Inserter
Smart Inserter
Posts: 1068
Joined: Sun Feb 24, 2013 10:24 am
Contact:

Re: Thoughts about blueprints

Post by ficolas » Fri Oct 25, 2013 2:13 pm

Wooo longest post record! :)

I havent readed it yet but I will... :)

slpwnd
Factorio Staff
Factorio Staff
Posts: 1837
Joined: Sun Feb 03, 2013 2:51 pm
Contact:

Re: Thoughts about blueprints

Post by slpwnd » Sat Oct 26, 2013 9:16 am

Scary long, but interesting:) I will need to let it sync a bit.

Though there is one point which I would like to state briefly already. I am a bit afraid that the blueprints will take away the "pride" feeling when looking at a big factory and thinking "wow I built all this myself".

Yes it sounds really cool to be able to click a button and bunch of robots goes on and builds a train station for you. And yes there are a lot of tasks that get boring when you do them on a larger scale (mining sites, production lines, solar / accumulator fields, train stations, etc.). But we need to strike the good balance between removing the boring bit and keeping the pride thing.

User avatar
Dysoch
Filter Inserter
Filter Inserter
Posts: 442
Joined: Fri Oct 18, 2013 2:27 pm
Contact:

Re: Thoughts about blueprints

Post by Dysoch » Sat Oct 26, 2013 10:45 am

slpwnd wrote:Scary long, but interesting:) I will need to let it sync a bit.

Though there is one point which I would like to state briefly already. I am a bit afraid that the blueprints will take away the "pride" feeling when looking at a big factory and thinking "wow I built all this myself".

Yes it sounds really cool to be able to click a button and bunch of robots goes on and builds a train station for you. And yes there are a lot of tasks that get boring when you do them on a larger scale (mining sites, production lines, solar / accumulator fields, train stations, etc.). But we need to strike the good balance between removing the boring bit and keeping the pride thing.
I agree, but not about the pride. Even when robots build it, you can still say: wow, i designed that! They are not smart, so they wont design themselfs, so you still have to plan yourself about the design
Image

User avatar
ssilk
Global Moderator
Global Moderator
Posts: 10531
Joined: Tue Apr 16, 2013 10:35 pm
Contact:

Re: Thoughts about blueprints

Post by ssilk » Sat Oct 26, 2013 11:21 am

Yes, well, that was my thought too. I think it is important, to take care about that. That's the reason why

- it will cost something to load a blueprint from disk
- there are game-content blueprints and own blueprints.

I will explain a bit: the costs are not big. Like 10-100 red and green potions or so, must be balanced. And maybe the market is much better for that, because it is an immediate task. But affordable.

And everyone will think "is it really needed to buy it?" Or can I built it once and THEN make a blueprint of it (which costs of course nothing!). This is the way, how the blueprint mod works, and I think this works quite well. Nobody likes to repeat things, even if it is the best idea ever. And affordable (time) repetitions will work, believe me, I make much music and repetition is good, if automated: sometimes it is a absolutely great feeling, to combine/composite existing structures to new, and in a way, which never was imagined by the author.

And the second is, that you have a basic set of always repeating tasks like building a field of solar panels/accus. Everyone needs that. That is eventually in a basic set of blueprints, which costs nothing. If that isn't enough, you can make your own blueprints. With the time every player will generate a set of own blueprint, he will be proud of. You can say "see, all is done by myself". And it is never-ending task, because everything can be optimized.

Together with the human-readability of the blueprints there will be posts like "see, if have made a ultra fast train station" with attached blueprint and the next will answer "cool. I have improved your blueprint by 0.4 secs". Much easier to handle, than save-games.

And now I think it it would be a good idea
- to see, how many and which blueprints are used in a game. See the parts, which are built out of a blueprint.
- to have control, which blueprints are available at which stage. Make it mod able.


Edit: one point I forgot! The blueprints aren't available from beginning. Only the planing. Blueprints must be researched. I mean that can happen parallel to logistic bots and needs also blue potions.
Cool suggestion: Eatable MOUSE-pointers.
Have you used the Advanced Search today?
Need help, question? FAQ - Wiki - Forum help
I still like small signatures...

User avatar
ssilk
Global Moderator
Global Moderator
Posts: 10531
Joined: Tue Apr 16, 2013 10:35 pm
Contact:

Re: Thoughts about blueprints

Post by ssilk » Mon Oct 28, 2013 7:42 am

Some small additions:
- the built bots should be a different entity than the logistic bots. Reason is, that otherwise, they bring the whole logistic system in trouble, when I build a bigger structure. Another reason is, that the bots are eventually smarter. Perhaps like so (much too concrete):
Logistic bots -> built bots
and later
Logistic bots -> repair bots -> bulldozer bots? Sounds logic to me. (off topic: I mean from the repair bots up they should have something like a laser to have a small defense! the laser could then be used to bulldozer things)

- from the development part I would order the tasks like so:
1 planning (not place able on non built able places) and building planned stuff myself
2 in-game blueprints.
3 queuing planned things for crafting, list of planned stuff sortable filter able.
4 mentioned bots
And then we'll see, what of this thread is up to date. Because I think it is very big step to save BP to disk in human readable format and also verify changes in it. :)
Cool suggestion: Eatable MOUSE-pointers.
Have you used the Advanced Search today?
Need help, question? FAQ - Wiki - Forum help
I still like small signatures...

Post Reply

Return to “General discussion”

Who is online

Users browsing this forum: No registered users