Inside the "Production Line Controller you can Setup a Production Job:
on the Software Designe Side Production Line Controller will create instance of a Car Class
class Car{
// <-- required Parts ,...
};
during production every Slot will look into the Car Object and add only Parts laid down by Designe if the Slot have the needet Updates.
conveyor junction can route individual cars by needet Parts from Slot to Slot.
Example: If you Car Designe need a air-condition car will take the Conveyor route to the air-condition Slot otherwise
the can bypass and move to the next Station.
"Sorry for my broken Englisch and the bad graphics im Designer not a artist or translators "
thanks for the nice graphics. It seems to me that your suggestion meets mine very well.
So maybe you want to take a look into this post: viewtopic.php?f=54&t=17970
At least it would allow to handle all the design variants much better than currently. Currently if you want more variants you have to create seperate lines and can’t share certain production slots without risking to create a magnitude of undesired other design variants you don’t want.
Currently in the worst case if you allow each upgrade to be installed optionally… you may end up with 2^34 design variants… and only a few really make sense.
I have a suggestion to the idea above… the Production Line Controller Slot should have to be attached to the Car Import/Export wall tiles… So the production line can’t start in the middle of nowhere but rather have to start at a wall.
So the production line always starts at a Car Import/Export wall tile and ends with a Car Import/Export Wall tile.
That could then be used to simulate even car repairs, where the broken cars are imported through the Car Import/Export Wall tile.
Another thing is the Production amount… I hope you mean that the amount is used for weighted scheduling… something like so:
MyCar 1: 80 Cars
MyCar 2: 50 Cars
MyCar 3: 30 Cars
YouCar1: 10 Cars
Internally that would be transformed into a weighted table:
MyCar 1: 100 * 80 / (80+50+30+10) = ~47.1%
MyCar 2: 100 * 50 / (80+50+30+10) = ~29.4%
MyCar 3: 100 * 30 / (80+50+30+10) = ~17.6%
YouCar1: 100 * 10 / (80+50+30+10) = ~5.9%
So MyCar 1 has a 47.1% chance to be scheduled, MyCar 2 has a 29.4% chance to be scheduled and so on… you get the idea.
No matter how it is exactly done, it should cycle through the list relying on the weight because otherwise you get a lot of cars from a particular design and you have to wait for all eternity to get cars from another design.
Wow this is great. One question though: Ist it also possible if i don’t want to have bypasses? Will the car enter an unnecessary station? Will it be equipped there against the design rules?
But I think what OP suggests is that when a car instance leaves a slot it will look down the path for a slot that has the necessary upgrades equipped as specified by the design the car instance is based upon. If it finds a slot that is suitable It will move there, gets the upgrades as specified by design and moves on to the next and so forth.
So it will never go to a station that doesn’t have the necessary upgrades for the design.
But what is up for discussion is if a car instance that doesn’t require any upgrades from a particular slot would still be able to go there or not. Because if it is able to go there, it wouldn’t get any upgrades installed… but it would hog the slot even when another car that actually requires the upgrades would actually need the slot more urgently.
That might actually create a backlog where car instances from various designs start to compete with one another for the same slots and eventually cause a traffic jam… and the player might not know why that is happening.
It would require the pathfinder to be smart enough to avoid that issue… like always trying to send a car instance that doesn’t require any upgrades to a slot that doesn’t have any upgrades installed first and only if no such slot can be found then use a slot that has upgrades.
That would prioritize slots with upgrades for car instances that actually need upgrades.
The only other way to avoid the “competing for slots” issue would be if every slot instance has the same upgrades installed (which is probably how most people play the game anyways currently)… then the pathfinder could pick any of them. So then there would be no competition… every slot can do the same anyways.
An additional thing would be how the slot timings work. It would be different from now… because each car approaching a slot might require different upgrades… so each car instance will ultimatively cause different timings at a particular slot. There wouldn’t be a fixed guarantee anymore that each car takes for example 5 seconds to finnish. Some might require 4 seconds, some might require 5, some might require 6 seconds and so on, depending on the amount of upgrades the design requires.
That in turn might also create backlog problems if not taken care of by the player by expecting the worst case scenario of a car requiring every upgrade that is available.
I think that’s the idea needs a lot more discussion.
Would be nice to know what Cliff thinks about the general idea of having such a Design-Based Production Line in the first place. If he thinks that it is against his vision then it is futile to speculate about possible issues with the proposed system anyways.
Sure, and there will be lot of changes to be implemented if he decides to change his concept at this point.
I was thinking about what it would mean to make a car configuration by a dialog. This would require to think about how to know which options are related to which production step, which are addable with no matter of other upgrades and which one may alternates each other, which slots will utilize the upgrades, how to handle the required parts, …
To get a feeling how much tasks need to be created (and how much components could be added) when putting each upgrade I took the production slots with their existing parts and all upgrades related to the car as of version 1.07 into an Excel sheet:
For explanaition: the value in the column ‘origin/related’ means the source of the line of information.
‘b’ means it’s based on the model type. So when selecting the model type in the car configuration this tasks and the available production slots should be added to the Task List of a model and all components should get attached to the Bill of Material.
‘o’ means thats this is an option which would be accessable as soon as research is complete and is not related to any other option. When selecting such an option at the car configuration dialog this would result in adding the necessary task in the correct sequence of the Task List and its component (if something is required for this like servos) adding to the Bill of Material.
‘d’ and ‘s’ means that both are options but will alternate each other. The line marked with ‘d’ is the default value and available at start. The ‘s’-Line means some research has to be done before you can (see and) select this option at the car configuration. When selecting such an ‘s’-option it should result in removing the previous options task and production slots from the Task List and components from the Bill of Material and adding the selected options task/production slot to the Task List and related components to the Bill of Material.
Most of this happens in background. Because such model related issues should be static the is neither a need for a ‘change’-dialog nor the chance to get a stuck car production because a production order has passed the slot for an upgrade-task when the just researched option has been added to the model.
For the player (as well as for the worker in real life) this means either to make a new car model step by step from the beginning (model type) or copy and modify an existing car model so the source car model stays untouched.
The hard work for the developer/designer is to prepare the basic data in a way that it will be expandable to future updates (like new model types) and reliable for the configuration and production process.
For the production process it will be necessary to know which model it is and which tasks have been done / which progress has the actual task. This could be presented very transportent to the player:
All that would make it necessary to do some changes to the slots as well: Which tasks are provided by default and upgrade.
This will of course result in improved route calculation. It’s necessary to check which of the build stations fit the required bunch of tasks. Calculating the next possible slot regarding the production line sequence is already present but I think it needs to be improved to manage tasks required by the car model and tasks offered by the production slots.
At this point I will stop. Before doing more brain storming and presentation I’ld like to know if such a concept change is a NOGO in the development of production line and how other people would like to see / expect in in-game.
As far as I am aware, there are only 2 optional slots currently in the game, Air Cond and Quality Check. I would say they should always go to the next slot, if it is not in the design, it should treat the slot as a normal conveyer and go through. The point of the design first idea is that you don’t need to make crazy extra slot orders to accommodate.
yeah, this was my first idea to but meanwhile I would prefer to make both available on startup but with a easy basic task, e.g. ‘Basic Ventilation’ at the AirCon slot and ‘Check Production Papers’ at the QA.
I also tried to figure out, how the data related to production tasks etc. could be precised. So I made an overview of any possible task the was present in 1.07 or needs to be added to make the add of an option processable:
I’m afraid all of this is very technical and needs more explanation but at all it would allow anything - including sub assembling.
So for the one who are interested please find the Excel file as rar in the attachements.
Some things are radio boxes, meaning you can only chose one…
Others are Check boxes, meaning you can have multiple or none.
Some may only work if a preset is selected. Like for example Climate Control can only be ticked if Air Con is ticked (hence why some options are tabbed in to make clear that they are conditional sub options that depend on a another option being present.)
Of course the selections/options could be placed into a scroll list or split up into tabs… so that the menu isn’t so big…
The design would then get saved as template. And in at the Production Line start it could be added to the schedule, something like so:
Though the management and scheduling of various designs is another story.
The car istance would only go to the slots that have the required upgrades installed as required by the template the car instance is based upon.
I would also say that a car should be able to path through an unrequired slot to the next slot if it provides a shortcut… with other words skipping a slot by drive-through.
you’re my hero of the day.
Yep, thanks.
So in the meaning of locked until researched the options could be either just grey or not visible. But same as with other details it’s more GUI design and cosmetics …
At this point I’m not really sure becouse of some wanted features like subassembling. The benefit of a Task List is to know which step has to be next - and in case of the table with the tasks to know which slots may process it. So either having a basic task at a slot or a separate conveyor to bypass it.
But at last it’s a question of making working code …
Kind regards
Edit:
And regarding the Designs: never edit or delete a design, this will result in casualties. e.g. with the vehicles in production. Better ‘Create modified Design’ to take an existing design and add some (newly researched) upgrades. Deleting a design meens deleting all the statistics. This could cause inconsistence at finance or sales statistics. Better just mark a design as ‘obsolete’ to junk all unsold cars and vehicles in production but keep all the statistics.
At the point how to put a design into production I’m with DarkThunder: new slot as first slot of the production line. We named it in a different way but meant the same. This would allow different handling on different lines for giga factories
The consumer market would provide something like a “Demand” for certain features/price ranges.
What that means is that each feature has a unique value attached to it that specifies how much desired it is on the market.
Like for example high-end equipment like Voice Recognition or Lane Departure Warning Systems are often costly extras and not everyone wants or needs them. Each Feature would have such a “desirability” index (like low end, mid end, high end) which may change over time due to newer features superseding older ones etc or saturating the market or because of competition driving the price lower, raising the standards etc.
That means… that if you create a car design… the car design has an overall desirability… that can be used to calculate the estimated production demand of a certain car.
Which also creates the incentive to create different models targeted at different price classes… where features are grouped together that are most likely to appeal to a certain audience.
That in turn could be used to simulate an actual market itself where cars get ordered by customers…
The other thing related to that is… what if Optional features are really Optional features, meaning the customer who orders a car actually says “I want model XY, BUT with a sub-selection of the available feature options for that Model”.
So if you have a Design Template Model XY which has for example following adjustments:
Spare Wheel (Can be installed if the Customer wishes to have it)
Driver Airbag (They are always installed)
Passenger Airbag (They are always installed)
Heater (They are always installed)
Air Conditioning (They are always installed)
In-Car Music (Can be installed if the Customer wishes to have it)
Sat-Nav (Can be installed if the Customer wishes to have it)
Quality Assurance (Can be made if the Customer wishes to have it)
Then the customer might say “Hell no, I don’t need the Spare Wheel and neither that Sat-Nav, but I want the optional In-Car Music and Quality Assurance”. So a customized order gets placed on the production line based on Model XY but only with those features:
Model XY Customized
Electric Windows
Automatic Wipers
Driver Airbag
Passenger Airbag
Heater
Air Conditioning
In-Car Music
Quality Assurance
Another customer 2 might only want the bare model…
Model XY Customized
Electric Windows
Automatic Wipers
Driver Airbag
Passenger Airbag
Heater
Air Conditioning
Another Customer 3 might want everything…
Model XY Customized
Electric Windows
Automatic Wipers
Spare Wheel
Driver Airbag
Passenger Airbag
Heater
Air Conditioning
In-Car Music
Sat-Nav
Quality Assurance
Which in turn would be much more like it is in real life where nobody (except if they are desperate and need a car right now) buys a car from stock anymore but they are all rather customized orders within a certain limited feature window… where some features are standard to that model and other features are really optional.
So most customers would actually order customized variants from your Models (given there are options)… and only a fraction of people would buy cars out of the stock at discount… which then handles your overproduction because your production line wouldn’t stop producing even if there are no customized orders.
The next thing to it would be that a small fraction of the orders might be canceled (which happens) and then you end up with a spare customized model in your stock.
Another thing is… if you pick too many options then you end up having problems to specialize your production line due to the different crafting latencies introduced (I know from experience from my 512 variant map)… since you have to calculate with the worst case throughput. So that is another incentive to have different models with different selections of options so that you can optimize your production line to suit each model better.
It wouldn’t be problematic at all because currently the game saves an instance of all already installed components for each invidiual car that is somewhere on the map to keep track of what is already installed and what isn’t otherwise after loading a savegame all the information about progress made on each car instance would be lost. So since that is already in place I would build upon that system…
That means if the production line start creates a new car instance of a design template then it would copy over the required/optional component list based upon the design template to that car instance with every required component being set to “FALSE” (meaning the components are required but not yet installed) and as the car instance travels down the production line each slot checks which components are required for that car as specified in that cars’ required component list and then installs these required components one after another and then sets the corresponding values to “TRUE” once done and then proceeds to the next slot.
That means that you could safely delete or modify a design template because it would only affect new cars that get placed in the beginning of the production line, while already existing cars would finish off until they are all exported because at no point they would ever look at the template again since all the necessary information like model name and required components, RGB Color, Pricing etc has been copied over at the creation of the car instance.
Sounds reasonable… the Production Line Controller slots could manage which Designs to schedule…
… and I still think that Production Line Controller Slot should be required to be placed at an Car port tile at the wall… which would also allow you to schedule to import cars that are in for repairs… which was something Cliff mentioned would be happening eventually.
But also because it looks unrealistic if the conveyor belt starts in the middle of nowhere… somewhere the belt must come back in after going out through the export because you need those moving platforms again so you can place a new car on it.
thanks for your awesome answer.
Until now I did not think about the sales and marketing concept.
But you’re right, another possibility of this idea to do a change of the sales concept from ‘sell from stock’ to ‘make to order’
My basic idea was keeping the sales as it is so you will have a limited number of vaiants. This would reduce the data that is needed for every car to the model and the progress of each task.
But at all you’re right, car selling as ordered means lot size = 1 (with the fortune to the manufacturer that some customers, a lot of dealers and car rentals order the same configuration …) would require to find the necessary tasks for each production order and configured buy the simulated customer. So it’s part of each order and the design itself could be edited or deleted.
At this point I’m not sure what Cliff’s intention was when he started the design of Production Line. The line design, upgrading, enlargen etc. is its 9.49€ worth. If he would include sales and marketing as a ‘Make to Order’ concept would allow and reflect the real life he should take some more money ;o)
But when switching to ‘Make to Order’ how will the code ensure that the ordered configuration can be made? This question was my No-Go to think about this concept. It would be frustrating, if you would receive orders you can’t fit atm.
And: How to balance the sales and the production site?
Regarding rejected cars my idea was just to place a conveyor belt from Quality Check to the Production Line Controller so it can take it’s tour through the production line to fix the claimed tasks. But I’m not related to/experienced with car manufacturing so it’s just an idea without facts.
That’s a good point and, if I understand you in the correct meaning, this would make a new wall tile necessary and all existing maps obsolete.
Related the Car Design Creator my idea of the gui was a general overview on top and every single group as a tab. To make it userfriendly with a ‘next’ button on each tab (except the last) and a ‘previous’ button (except on the first tab ;o)) as well. So going through the config step by step will unlock the tabs so it will easily to go back several tasks without the chance to do a misconfiguration while skipping other tabs.
[EDIT]
Putting every group in a single tab would allow to set a price for an option. It was a suggestion of someone else but I can’t find.
At all optional upgrades mean you will not have a fixed price but a minimum (no upgrades except they are ‘in’ without any choice) and a maximum (all offered options added). at all this means: setting a sales price in reference to it cost for the basic car (as atm) and each upgrade selected as ‘in’ or optional.
[/EDIT]
Btw.: We’re more at details as I wanted to go before I know if such a concept change would not be a dead end.
Yeah that’s basically what it is… a change from “sell from stock” to “make from order”, ontop of selling from stock.
Because when there is no order currently then the production line would be idle. Since we don’t want that… we still craft cars based on the available designs as a “leap of faith” in hope that when an order comes it will look into the stock first and see if there is a suitible car already in the stock that can be sold, and only if there is no car in the stock then put a new custom car at the beginning of the production line.
So the “sell from stock” would still be there as some sort of speculative execution/leap-ahead, which can be based upon the recent sales. So it would most likely produce more variations of the car variation that sold the most in expectation that it will still sale well in the near future.
It would ensure that your Production Line is always running 24/7 even if there are no specific orders.
Yeah, the code background rather stays the same as it is now I think or only unnoticably bigger at least when it comes to how a car gets its components added and wanders through the factory… because the game already has to keep track of installed components… so it wouldn’t become that much more… It would just get the information that it would get anyways much sooner… as soon as when the car is placed on the map for the first time. Because currently shortly before exporting a car it will have a list with a tons of components installed no matter what due to having to keep track in case of saving the game.
Well I think if Cliff targets to charge 25-30 or more Dollars/Euros eventually then it better would have some interesting sales and marketing feature because what most recent Indie games suffer a lot from is the lack of endgame or gameplay features that keep the players on the edge.
Such a sale system could provide a funny long-term replayability.
I mean firstly we are talking here about taking on the orders automatically… so the player doesn’t have to accept each individual order one by one, because that would be frustrating.
Secondly a “customer” can only order a configuration that is within a model’s feature window. That is the basic premise.
So if your model doesn’t have for example Cruise Control, neither as Fixed Model Feature nor as Optional Model Feature… then the customer will go “elsewhere” (other car companies)… And we don’t really simulate that (Or only if AI companies ever get a thing, then they might satisfy certain amounts of the demand if they have model that suits their taste, more on that later). We could simulate something like a persuasion though… if you give a discount on a car then you might motivate someone to buy it even if it doesn’t have all the desired features.
Which brings me to the point on how one could simulate the desire for certain car features depending on price classes:
Step - Market Research
First what we need is something like a marketing window with market research.
That market research window would display for different price classes (Like for example Low End, Mid End, Upper Class, High End, whatever) how many customers (in percent for example, or per 1000 customers) in each sector would like or absolutely need to see Feature XY on a car to make them want it.
Each price sector obviously has a default desire for each feature. (It’s only a matter of balancing.)
That then gives you some hint on if it is worthwhile adding a specific option to a model for specific price class or not.
Step - Calculation of Demand Fractions (Explanation)
The calculation of Demand Fractions for various combinations is then based exactly on the desirability percentages. So if 30% of the Mid End sector want to see Air Conditioning… and you add that to a mid end sector car as an feature/option then you will see a 30% increased order demand thanks to that particular car variant (and hence sell more cars at a more expensive price (Base + Air Condition Price).
Over time as more features become available to the market (like new inventions) then the nasty part starts… fraction of fraction of fraction of fraction calculation. I have done some work on that for a grand strategy 4x space game which I’m occasionally working on where I wanted to simulate different demographics combinations for various ideologies which kinda works in the same way.
So what could happen there is that for each price class (Lower, Middle, Upper, etc) the features with the most significant percentages, like for example the top most relevant 4 or 5 optional features with the highest demand you do a 2^3, 2^4 or 2^5 combination table that calculates the fractions of fractions for them.
100% values aren’t considered in that calculation… 100% demand for a feature would mean people see that as standard (= Base Model) and if you don’t have it you are outdated so you absolutely need to have that feature on the car or the customers give you the middle-finger-salute and buy elsewhere.
I also say the most significant percentages because the smallest ones would just never happen or would be so goddamn uncommon that it is not worth wasting performance and time on them if a combination turns out to be 1 time in 1 million produced cars. So there is a reasonable cap to how many combinations are worthwile pursuing… and I think that cap is somewhere around 2^8-2^10… everything else just gets cut off and that’s it. (I know about that from experience while working on the demographics thingy I mentioned above… and also because of my mega map in Production Line)
Step - Calculation of Demand Fractions (Example)
But let’s do it for a small 3 feature example (In an actual implementation it would be 8-10 features like I said, I’m only doing it for 3 to spare myself the work)… lets say we are talking about low end sector car models… we gather the top 3 desired features in the low end car sector:
30% Electric Windows
25% Air Condition
20% Automatic Wipers
First we scale them to 100% like so:
40% Electric Windows
33% Air Condition
27% Automatic Wipers
Then next we calculate the fractions using the said combination table (2^3 in this case):
Base Model = 1 * 1 * 1 = 1
Electric Windows = 0.40 * 1 * 1 = 0.40
Air Condition = 1 * 0.33 * 1 = 0.33
Automatic Wipers = 1 * 1 * 0.27 = 0.27
Electric Window & Air Condition = 0.40 * 0.33 * 1 = 0.13
Electric Windows & Automatic Wipers = 0.40 * 1 * 0.27 = 0.11
Electric Window & Air Condition & Automatic Wipers = 0.40 * 0.33 * 0.27 = 0.04
(At this point I want to mention that one could also make all combinations equally sellable, but somehow that’s boring and I think that the more features are enabled then the more unlikely it is for a customer to buy it… because of how mostly no-one is willing to pay for all the extras… so my suggested algorithm puts the bulk on the base model and only a small fraction of customers want the maxed out model)
Scaling the table to 100% again:
Base Model = 42.29%
Electric Windows = 16.92%
Air Condition = 14.10%
Automatic Wipers =11.28%
Electric Window & Air Condition = 5.64%
Electric Windows & Automatic Wipers = 4.51%
Air Condition & Automatic Wipers = 3.76%
Electric Window & Air Condition & Automatic Wipers = 1.50%
Total Market = 1000 customers for example (up for balancing)
Base Model = 42.29% * 1000 = 423 Cars
Electric Windows = 16.92% * 1000 = 169 Cars
Air Condition = 14.10% * 1000 = 141 Cars
Automatic Wipers =11.28% * 1000 = 113 Cars
Electric Window & Air Condition = 5.64% * 1000 = 56 Cars
Electric Windows & Automatic Wipers = 4.51% * 1000 = 45 Cars
Electric Window & Air Condition & Automatic Wipers = 1.50% * 1000 = 15 Cars
The numbers look a little bit gross imbalanced, especially for such trivial features, but it’s a basic demonstration of how the algorithm could work so it’s fine for the purpose I guess.
The actual placement of orders on the production line could then be done by weighted picking from that combination table above and issuing that combination as an order… and once placed on the production line, decreasing the table entry for that combination by 1 Car… and after x-hours the demand for all the car combinations is reset.
If you reached zero for a combination before the demand is reset it means you have satisfied that demand fraction and no more cars get produced for that fraction. That is unless you reached zero for all combinations for that model… then it will start with speculative production of cars for that model for the stock by looking which cars of said model where ordered the most… as said, that is done to keep the production line 24/7 active.
The same would happen for all other models and their top optional features too… and as you see they work in an interlocked fashion so you get fractions of fractions of fractions, and the more you “adapt to the overall desire” of a price class the more orders (and variants) for a car model you will get and the more expensive cars you will sell.
Step - New Unlocked Features devaluing Existing Features
The fun part about that would be that once a new feature hits the scene and becomes very popular on the market it automatically decreases desire for variants that don’t have that feature (= devaluing existing combinations)… so you will start to see less orders for cars that don’t have the new feature… and the only way to get back that part of business is to integrate the new feature to your design as well.
Step - Competing Models & AI
It works perfectly for more models too. Since each car that gets placed at the start of the production line references a particular combination they do influence the demand, by decreasing the demand by 1 for that particular combination. So that means if multiple models that have subsets of combination that are identical to one another they would actively compete with one another since both would start to drain from the same demand fraction.
Interesting would be AI companies on the matter… their design models and variants would draw from that global pool as well, not only your own car models. So every car order for a combination they accept and produce is one that isn’t available anymore to you… creating true competition. Of course the actual price of the cars would have to be factored in as well so that you can beat an AI company with discounts and so the customers are more likely to put their order on you instead of the AI. So eventually you’d have to multiply the Car Combination with the actual price and see who is the cheapest before the customer decides to go for company XY’s model.
Step - Increasing/Decreasing the desirability by Events/etc
Of course the basic desirability for each feature for each price segment would change over time… some features that may not have been standard for a price segment at the beginning might become standard later on. That could depend on events or market saturuation as well as other things. The algorithm above is quite flexible to adjust to all of that periodically.
Step - Developer/Code Side
At first it looks like an extreme mindboggling method in the code background but actually it is superfast and quite easy to calculate and only calculated once every while when the demand gets reset or something happens to the market (like events that change the desirabilty etc). Otherwise it’s just draining/decreasing values in a table. At least that’s on the development side.
Step - Player Side
The player would never know how exactly the demand is calculated… they would only see on the market research “aha a car model with this and that feature might be a good idea because the demand for that feature is high and my model doesn’t have it yet” and maybe “Oh I’m selling less of that model… maybe I should upgrade the model with something new?”.
And only people who really dig deep into the game would start micromanaging it around the algorithm. That’s something that will always happen in any game anyways.
At least I think that is how it could work… but I might have another thought about it over the week.
Yeah cars that fail during the QA are sent back to the appropriate stage with a backpass route and are repaired before shipping… but I also think Cliff mentioned taking on repairs from the outside world, like repairing cars you already sold… Probably by giving each car model a chance to fail… and then you get that fraction of failing cars back to your factory to repair… on your behalf of course if it falls under warranty.
Nope, the existing Car Export wall tile would gain the double purpose of being able to import or export cars. There is no real restriction that an Car Export tile can’t also be used to import something. Same for Resource Conveyors. A Resource Import Tile could also be used for exporting resources… no restriction on that.
Therefore existing Maps wouldn’t become obsolete because of that.
Also thought about that with the tabs… using next/previous to go forth and back… to reduce the menu cluttering. But that is mere aesthetics and usability stuff I think… xD
I think it would be good if the tabs were categorized the same way the slots are:
Chassis
Body
Paint
Engine
Accessories
Electronics
Or so… that would make it rather future proof as well and easy to add more options in each tab as they become availble.
Setting a price would be neat… but I think the total premium/discount basically does the same on a global level?
Because the price calculation for a car would still be the same as it is currently, even with my suggestion from above.
True… but the thing got me triggered… and when I’m into something I’m pretty hardcore, above and beyond. xD
Have had some points at which I’ld like to ‘reply with quote’ but at all you answered all of my questions excet one:
If I (the player) can make a configuration that allows to trigger an option by ordering process and I need to produce even without such a order to keep the lines running, how will the know which final configuration has to be taken? Or does it mean that any upgrade selected as ‘option’ will be set to ‘no’ for the specific production order?
Did I misread/skipped reading an idea?
My thinking was: The benefit of setting a price to every single option would make it transparent to the player so no visible ‘calculation’ of the price is necessary and: If a upgrade gets a new version (e.g. basic ‘Cruise Control’ to enhanced ‘Adaptive Cruise Control’ the first one will not make any cars with this option obselete but should decrease the price customers will pay for.
But when keeping in mind that this (Production Line) is still a game and not a job it may be usefull to set a global price for every upgrade so it will be easy to change for all configurations at once.
//
So at all maybe just set a premium/discount related to the material cost of the basic car and each upgrade (like it is atm) will be fine too.
"
