Upgrades & Modules

[BenSeidel]

Hi,
From what I gather I am supposed to start this with:
"So, I have been playing factorio for about 10 hours now...."
and I have come up with a few ideas that I feel would increase both the realism in some cases and reduce need to "skip" some content. Basically I am putting forward one coherent upgrade and progression system, that feel more inline with assemblers and transport belts. This really comes down to the way item upgrades and research are applied to the game. I think that an active user-upgrade process would feel more "factorio" than the current "research is complete" (say it in a starcraft voice) style. I mean, we should be automating everything! not being given an already automated system. Also as much as possible I think that all items should have an upgrade path without "dead-ends" that causes people (me) to restrict the way I play, especially in the first hour or so.

So this really comes down to two basic ideas, removal of dead ends and the upgrade/module system.

I'm going to go out on a limb here and say that removing dead-ends should be a priority, as it offers nothing enjoyable for the player and only decreases their enjoyment. So, what is a "dead-end"? A dead end is an item that is superseded in every way by a better item, but is not required in the construction of said better item. For example, I constantly skip over using iron chests because every one that I build will just have to be shoved into a chest somewhere because I am now only using steel chests. I also "struggle" through the armors because crafting each tier is a waste of both time and resources (the module armor does not fit a reactor and roboport, so I run round naked till I can build the power armor, or worse the Mk2). The armor thing is really only true in some of the maps I have played where either space or resources is a limiting factor, but cutting out some of the tech-tree because I don't want to have to have a trash area in the map feels off somehow. Wooden chests & wooden power poles aren't much of a drama because you can just burn them... along with any other wood based product, meaning that all wooden items are "value added" while you are using them, but I can't see a "wooden inserter" working well.

Simple solutions:
1) make each item in the path to the highest tier. Iron chests -> Steel chests, Armor X -> Armor X+1
2) Allow items to be recycled. (don't do this one)
3) Make all lower-tier items burnable! (don't do this one either)


Manual upgrades & Making inserters fit into a unified upgrade model
Upgrades available through research should have to be "manually" constructed and applied, like the assemblers, belts and modules. I cannot fathom a way that my labs are able to instantaneously upgrade my robots mid-flight! Maybe better software to reduce energy consumption, but not "ohh look, my cargo space has doubled".

Simple solutions:
1) Require items that are to be upgraded be run through an assembler (robots cargo size for example)
Maybe a not-so-simle solution:
1) Require upgrades to be applied using modules

There are two main categories that could go through a re-work to enable modules, allowing for greater flexibility and compositional complexity in the design of a players base: Robots & Inserters

The upgrade path for inserters could be:
Simple inserter -> filtered inserter.
That's right, just the two!
The different types of inserters - Stack, Long, Burner, Fast could come from modules!
for example, place a boiler into an inserter, it becomes a burner inserter, place an "arm extender" into an inserter its a long inserter, place a "stack" attachment and it becomes a stack inserter, place a speed module and it becomes a fast inserter.
This may allow for the addition of a research upgrade that allows for two modules - burner long arm inserters anyone? (not too sure about the long arm inserter, I can see some issues with that - eg, What happens when there are two long modules? and how does the graphics get altered?)

An additional benefit to having a modular system is that the upgrades to the inserter stack size bonus could then allow for upgrades to the "multi grabber" (stack size) module - instead of just popping the bonus into existence. There have been a few cases where upgrading my bonus has broken my factory because I was limiting the production with the speed the inserters could put them into the assembler. I believe all upgrades should be a conscious decision (and one that costs), including to make your inserters faster/more efficient. Its already the case for all the other modules, the current inserter speeds, assemblers, etc.

Roboports could have modules that robots can take on their way out:
As assigning a module to a robot would be tiresome and cumbersome, I would suggest that a roboport have one, two or three (up-gradable through construction?) areas to place modules in that the robots can grab when they leave. For example, place some MK2 batteries in there and each robot would take one upon leaving the roboport, increasing its maximum energy, thereby allowing it to operate longer before needing to be charged. Ever had a long stretch that needed to be covered by robots? Place some personal solar panels in there and the robots can charge themselves during daylight, meaning less roboports overall. Place speed modules and they move faster, efficiency modules and they use less energy! The combinations can be endless.

This method should be easy to implement, as the robots would need an extra variable to store their current modules, the robot release procedure would need to assign a module to a leaving robot, decrementing its current storage count, and the robot docking process would then increment the count. The only issue I can see is that maybe the robot simulation process would need to be updated to take into account varying power usages and movement speeds (as they would no longer be global). Storage in the roboport for the modules could be tricky as there might not be enough room to accept both the robot and the module (if the roboport is full of other types of modules). Some solution would need to be figured out for that, say an inventory system that is capped to 250 items as opposed to stacks?

A second method (that has just come to me) is to allow the roboports themselves to transmit the upgrade in the area they are covering. Each roboport could transmit the effect of one module to say 10 robots. This method has the difficulty of "what ratio is best", "How do you transmit it to all robots in some major path", "What occurs when two roboports overlap?", so possibly the 1st method would be better.

While I am not sure that these implementations are aligned with the developers goals, I think that it does offer a consistent style for upgrading and customising your factory, especially if we ever get an "upgrade planner" that will allow us to replace specific buildings or modules with their counter-parts (including downgrading) then this style will really shine. There are some other things that will also need to be implemented, such as allowing robots to dock with requester chests (but not launch) when the chest is requesting them or their modules as chasing down those speed module 1s to replace them would be a nightmare!


I chose to place these two ideas in a single thread because I believe they are closely related and help illustrate my idea that there should be some underlying design principles to the upgrade system in Factorio that all upgrades and customisations should follow. So that everyone is aware, I have played about 10 hours of factorio, if you only count time spent in v0.13. I have two maps, both 150+ hours, and both designed around some central idea, one being an osmosis system where all items are on one belt and the biters are set to maximum and a trains map where I move every part between sections of my factory using trains (the green circuit section is larger than my entire osmosis map).

Thanks!

[ssilk]

Long read. First I will make a

TL;DR:

Avoid dead ends of upgrade
Examples:
1) make each item in the path to the highest tier. Iron chests -> Steel chests, Armor X -> Armor X+1
2) Allow items to be recycled. (don't do this one)
3) Make all lower-tier items burnable! (don't do this one either)

Unified upgrade model (by using modules)
Example for inserters could be:
Simple inserter -> filtered inserter.
The different types of inserters - Stack, Long, Burner, Fast could come from modules!
For example, place a boiler into an inserter, it becomes a burner inserter, place an "arm extender" into an inserter its a long inserter, place a "stack" attachment and it becomes a stack inserter, place a speed module and it becomes a fast inserter.

....


To the first (Avoid dead-ends): I like that idea, but it is difficult, cause I there is just no rule. This is hard work and if a dev does a wrong decision here he can simply ruin the game. For example: The wooden chest is just such a dead-end. And it would make sense to have a wooden chest as the base of a iron chest. BUT you need to automate wood production for that. Nice. But does THAT makes the game more worth playing? I doubt it.

In general I would sort this idea into the ideas of viewtopic.php?f=80&t=21278 Recycling/Disassembling of Waste / Scrap / Trash (what I did now ), because the whole subject could also be seen from that end: What to do with all the iron chests, if you cannot use them as steel chest? It's both the same kind of problem.

I think this recycling problem could also be seen from this side and it would be a good idea to first make recipes as "dead-end-less" as possible and for the remaining items (which then would be much less than yet) we could find a clever solution.


The second (upgrade model) is much more problematic (and no, I think this and the above don't belong together, but I see the logic in doing it in this article ). The idea to use modules to upgrade inserters is not new, they did come a several times now (sorry, no link-collection till now). Indeed there is also another idea: Factory-streets. Robots put things into a FRAME and in the end we have a (more or less unique) product... think to a car production.

And we recently had the discussion about the abilities of the inserters and one of my arguments to use modules for inserters was, that that is not practicable:
- You need somehow to choose, which modules should be packed into the inserters AFTER placing. That is with the hundreds of inserters needed in one game not useful.
- you will have a display problem: What capabilities an inserter has must be displayed somehow.
- you have the agony of choice. Think to the combinations of possible modules.
- (And not a good argument) It's a programmers and modders horror, cause each combination of module could mean something different.

So the total game-play value of this is in the end questionable.