Just as I was writing the FFF, I saw the rising reddit post
. I was also initially mesmerized by it's simplicity. But the more I thought about it, the more questions went unanswered. Apart from the fact that's it's a nice tree view, the mockup explains nothing about the details.
Then I also was reading the comments and realized that everyone was basically filling in the missing details with their own version that worked well for their workflow. Some wanted blueprints as items, some didn't, some wanted books inside books, some completely ignored this fact.
Code: Select all
- New book vs new folder: since the tree can go down any number of levels, you need to be able to have books in books or differentiate between books and folders.
- A1. Allow books in books: this makes shift+scroll up/down strange. What gets selected? Next blueprint in the root? next blueprint including sub-books? does the book gets selected and that book's active selection gets used?. Add checkbox options for blueprint traversal? None of these are very user friendly by any stretch.
- A2. Differentiate between folders and books: leads to quite a bit a of confusion. You can choose to create a folder or a book. They work pretty much identically except you can't drag a folder to your quickbar. Will quickly start asking for more buttons like "convert folder to book"(and reverse).
- A3. Books no longer exist: not really an option
- Blueprints stay as items or not?
- B1. Blueprints stay as items: Plenty of questions regarding item transferring, duplication.
- B2. Blueprints are not items: Sharing in multiplayer? Need to bring back the shared blueprints library.
For the second question the answer for me is B2. But the first question was the main reason why we never went for a tree structure, none of the the options worked well with books.
Even though we went through so many iterations, we will look into the tree structure more, maybe as a significant change, maybe as a different way of organizing the existing "proposition zero". Or maybe disregarding the idea because of all the small problems and gotchas. Hopefully people won't go crazy about writing about blueprints for the 3rd week in a row, calling in "Proposition R"
Regarding blueprint sharing, it's where I become the evil developer. Most of us never thought the automatic sharing was really such a great feature, and if a feature is not great, plus it clogs the GUI, then it should not be in the game. By making players share items, organise them in chests, protect them, it leads to way more emergent situations that can be fun in multiplayer. "where is the steam engine blueprint? it's in a chest next to the boilers, use that to build more".
But it's quite probable that in multiplayer games there will be a separate "game" library that all players can add and remove blueprints from, so that can cooperatively build that game's blueprint collection.
Regarding locking the blueprint library: it will be locked on on installation and as soon as you research construction bots the feature is unlocked forever across all save games. It can also be unlocked using a simple command.
Not the perfect solution, but I constantly see new players trying to explore the GUI and eventually clicking the strange and confusing blueprints library. Then trying to figure out what the hell are blueprints and why they don't do anything. All this while they didn't even build their first furnace, they don't even know that this is a game about automation and not a game about chopping down trees(hello every other survival game).
Copy paste will still be there. I really doubt a fresh player will want to store a library of blueprints when he didn't even discover construction bots yet.
But nonetheless I don't have any strong feelings about this limitation.