I’ve done some musing on this, and outlined my conclusions here:
positech.co.uk/cliffsblog/2017/0 … tion-line/
Feel; free to suggest improvements 
I also agree that not everyone will want to care about needing different production lines, but I almost wonder if later on it could be done so that people that do want it, can have it.
So have two modes, one that’s “simplistic” and one that’s “extreme”/“hardcore”. The simplistic is the version you linked to (with having the few seconds to change the tool widgets) and the extreme being every different car type needs a different line. I think then everyone (but probably the people having to code the different ways) will be happy.
I also like this idea, that’s the kind of system I had in mind. This way players who play on the smaller sized maps don’t get penalised by not having the room to store all the components for the different car types, and people can still have separate lines if they want to. What I would suggest is changing it from a drop down list to something that would let the player set ratios for the different car types (ie: make 3 sedans for every 2 SUVs) so they don’t have to keep micromanaging their production lines to make more than one car type.
Oh good idea on the car ratios. I guess when I code the GUI I may as well do it like that
Well i do prefer different production lines for different type of cars.
I also did a suggestion some time ago about the export part of the game, now you can upgrade in 2 stage.
Administration
- Here i would add the option to create 1 to 6 packs.
- I also would give the ability to decide how many cars need to be produced on every pack.
example: If you produce 100cars/day
Pack 1: 35
Pack 2: 30
Pack 3: 20
Pack 4: 10
Pack 5: 5
this will mean the car goes from a basic price to a more full option price, also the option to grant less profit on a specific pack to get it sold.
Just a little fast creation to show what i mean, this will give you more simulation feeling. If you decide wrong you get a lot of stock that will not be sold.
Computerized Sales:
- In this stage i would love to see cars build on demand of the costumer besides the options packs to get more luxury options.
I have a different point of view on this. For robots welding, it would be trivial to store different settings for different body-types. A sedan rolls into the station and the robots detect this and use sedan settings. Likewise for SUV, or compact, etc. They’re just numbers in a database for the welders, after all.
So that leaves different components, which I agree would get WAY out of control. So this is out.
So ask yourself, why must there be a difference? Anyone can custom order a new car to their exact specifications. The factory, when building the car, knows what options go in, what color to make it, etc. No retooling needed.
The one area I can see being the biggest change would be the paint booths. It would take more paint to cover a SUV versus a sedan. Using 4 instead of 3 paint, for example. Then 2 for a compact.
So, for those wanting a difference, or penalty for other lines so-mingling, I say make larger models take some % longer at each station. A 3m station for sedan, might be 3m30s for an SUV, for example.
interesting point on the time taken to carry out tasks, and variable component requirements. In fact its only as I type this that I realize that when we add a compact 2 door car, obviously it will need less doors and windows, and I have no system in place to do that yet
Anyway… SUV coming soon, and I have already written half the code allowing the player to specify the mix of models each production line would make. I’ll do more thinking about retooling penalties once we have multiple models in and working!
Hey Cliff, if you don’t want to have a mess of branching code I would suggest you could implement car models with templates:
<model=sedan>
<frontaxles>2</frontaxles>
<rearaxles>2</rearaxles>
<driveshaft>1</driveshaft>
<undercarriage>1</undercarriage>
<fueltank>1</fueltank>
<rollcage>1</rollcage>
<hood>1</hood>
<trunk>1</trunk>
<frontbumper>2</frontbumper>
<rearbumpber>2</rearbumper>
<bottomtrim>2</bottomtrim>
<frontarch>2</frontarch>
<reararch>2</reararch>
<vent>1</vent>
<roof>1</roof>
<doorpanels>4</doorpanels>
<windows>4</windows>
<wingmirrors>2</wingmirrors>
<paintundercoat>3</paintundercoat>
<paintfinish>3</paintfinish>
<powertrain>1<powertrain>
<radiator>1</radiator>
<exhaust>1</exhaust>
<brakes>4</brakes>
<wheels>4</wheels>
<tires>4</tires>
<steeringcolumn>1</steeringcolumn>
<steeringwheel>1</steeringwheel>
<lights>4</lights>
<horn>1</horn>
<seats>4</seats>
<windscreen>1</windscreen>
<dashboard>1</dashboard>
<electronics>1</electronics>
</model>
And so on… or at least something similar like that. (Of course it needs to be structured better and probably more information too, so above is just a simple example)
Basically a template for each model with the required amount of resources. That way you could control which (like for example difference between classic combustion engine, electric engine and hybrids or hydrogen and other related components) and how many resources (like 2 doors instead of 4) are required.
Each issued car instance of a specific model would get a personal copy of the component list as specified in the template it is based upon which it carries with it through its entire lifecycle until it is sold and which has to be worked off one by one while it moves from slot to slot. A similar list must already exist in a very basic manner for each car instance anyways otherwise the game engine wouldn’t be able to keep track of which components have been already installed… so it would only expand upon that by giving each car instance the entire list right from the beginning instead of growing over time. Yeah, I know it increases the memory/savegame footprint to a certain extend due to the early extra information per car instance but I think it is a worthwhile tradeoff (especially if you are experimenting with 64 bit which has only one major advantage anyways… allowing more than 4 GB RAM).
At each slot the car instance would be checked which and how many resources to install and adjust the time needed dynamically based upon which and how much work there is to do.
And once a slot is finished with installing a component then internally the number of required components is decreased to either:
- 0 … “component has been installed succesfully” or
- -1 … “component has been installed faulty” (that’s where Quality Check kicks in to detect it as it isn’t shown to the player ingame)
If the required component list/template is structured more clever (like categorizing components by slot) I think it could be done with some for/while loops (which emulates a switch of undefined length) so you don’t need a lot of specific branch code for each model/configuration… that way it would only have to be written once and it would scale more easily and flexible with later expansions (more different models or additional components/change in components) or even modding.
I think that the list could also be used to do the routing of each car instance based upon the components it has in its personal required component list… where after finishing all the work in one slot it looks which slot is next in the list and then look for a matching slot down the conveyor path. That way cars that don’t need a specific slot don’t even go there… like for example a car with electric engine doesn’t have the exhaust component in the list so after fitting the electric powertrain it instead goes directly to a Fit Brakes slot. That would open up interesting possibilities how to design the factory with bypass routes, crossing paths or even backpass routes (to do the same stage a second time like for example drying the paint or if the car failed the quality check to send it back to the slot with the component it failed to get it fixed/replaced) etc.
Another interesting part about the suggestion of using templates is that the player could be presented a GUI version where they can adjust/manipulate various things of a model template… like for example the type of engine and other things… and the selection gets saved to the template and newly created car instances based upon the template would then follow the new configuration, while the cars based upon the old settings would be slowly superseded.
Variable Car Features which may or may not be installed on a car could be integrated to this template system, but don’t necessarily have to be integrated and could instead remain in a seperate variable component list (= don’t have to be installed to make a car work) analogous to the fixed component list (= have to be installed to make a car work).
Yup, I definitely plan in the medium term to implement a similar feature. Right now the priority was to get the physical art assets working ok within the game, which was hard for this second model, but will be easier in future. here is a screenshot:
I will come back to the whole ‘car design template stuff’ probably once the game is in early access on Steam and GoG which takes a lot of one-off admin work I have to get done first 
You stinker!