Category Archives: production line

When I initially designed the Production Line ‘car design’ system it sounded like it made so much sense. Cars were a list of ‘features’ such as ‘electric windows’ etc, and whenever a car came to be sold, we would see if we had sold a car with that list of features before or not, and if not, we popped up a dialog box asking the player what to call this design and how much to charge with it, along with information on the market value (fair price) for that combination of features. This seemed perfectly reasonable.

The problem is that a) there are about 999,999,999 permutations of features and b)actual cars arent really sold that way anyway.

If you buy a car, you decide to buy (for example) a Vauxhall Astra, and then you decide which options you want, effectively from a price-list of add-ons. Usually car companies bundle a set of features together as certain ‘models’ such as ‘deluxe’ or ‘GT’ or whatever, but essentially there is a base body design and a price list of features to go on top. In order to reduce the amount of pointless GUI and busywork in Production Line I decided to switch to a similar model for patch 1.13.

Now we have a new button in the GUI, which launches the ‘design browser’ in the game which shows you all of the actual properly different body types of cars you currently produce. (for now its hacked showing designs from an earlier version, so they all have the same body type, but for new games you will only have one here for now). That window lets you select which car design you want to view or edit.

That then brings up this new window, which will also pop-up when you produce a car for the first time, or when you ship a car with a feature that was not previously available in this design. (That should happen only when you have researched a new upgrade and then shipped an upgraded car).

This is where the GUI gets a bit confusing. Essentially any design is just a shopping list of features with the base feature being ‘basic car’. For each feature you can see the market value of that feature (the consensus in the market place for the fair value for one of those), the price you are currently charging, and the markup over the market value in both percentage and dollar terms (with buttons to adjust this).

You can price cars at a premium to earn higher profits, or a discount to shift them quicker. This is where the confusion will come..

This does not represent a hard profit or loss for that car.

because there are so many fixed costs, its very very hard to work out how much each feature really costs you to add, so you have to separately keep an eye on what that feature is costing you. The premium/discounts here are only a guide as to how competitive you are with your rivals, who may be more or less efficient than you. My big dilemma here is how confusing is this? and is there a better way to explain/present it? Obviously there will eventually be a tutorial.

I also think that probably what I need here is some option to copy a single premium/discount to all features, so you are not adjusting each one manually. I’m not sure of the best way to present that from a GUI POV. In terms of ‘why would you ever not want to do that?’ consider this: You rush ahead in the early stages of the game to research cruise control before anybody else. As a result, you have the ONLY cars with cruise control. You can therefore charge a whacking great premium for that feature, way above the premium you would charge for other car features.

Does that make sense? Is this an improvement on the old model? Feedback most welcome. This is hopefully going into the 1.13 patch coming this week. maybe even Wednesday! (more likely Thursday).

BTW don’t forget the price goes to $12 from Sunday. If you know you are going to get it anyway, order it below :D

I missed two weekends of doing these due to GDC but worry ye not, I am back working on the game with a vengeance:

I currently have a minor routing issue with the new sped-up code, but I’m getting closer to squashing it. The next big change to the game will be design pricing, and after than its likely to be some new components, machines and slots. New cars hopefully next month.

 

I recently got sent a HUGE factory in a savegame for Production Line. It has over 600 production slots and 24 resource importers, and its MASSIVE. Here are some screenshots:

Despite its awesomeness it was MASSIVELY slow. Not only did loading it take forever, but whenever you changed any of the resource conveyors the game would hang for about 20 seconds. hardly ideal, especially given that I have an 8core i7 PC. So I set to work trying to optimize the code. I did some fairly small optimisations first, which boosted processing by 12% but I needed more fundamental re-design.¬† After chatting to a fellow indie coder, I agreed that my currents system of always calculating the optimum route to everywhere, for everyone, when something changed, was clearly not viable. I switched over to a new system of ‘lazy’ computation. Basically when I change a route somewhere, it now sets a flag on every production slot saying ‘you should recalculate your nearest slot soon’. That flag gets checked every frame, and sometime in the next 120 frames 92 seconds) each slot will calculate the route from its location to all the importers, and store the nearest two. It needs this so slots seem to import from a sensible location, as opposed to an importer that is miles away.

This was good, and sped things up a LOT. Now instead of hanging, the game would stutter for about 10 seconds. better but nowhere near good enough. I then realised I was doing something seriously dumb. I was going through all those routes I calculated, and picking the nearest, THEN doing it again, to pick the second nearest. doh! This sped things up, but in retrospect, it was trivial, it just alerted me (alongside my profiler) to the fact that when I tried to get (for example0 15,000 routes, I actually calculated 30,000. How come?

It turns out that the code that multithreaded all of the ‘calc the routes’ code, was not storing any of the results, so the code that came after it which then went through the (not saved) routes to pick the nearest ones was having to recalculate them anyway. I was essentially doing everything twice.l Worse…this second bit of code was single threaded, meaning all my multithreaded time was wasted and all the work happened in a single thread. What a dork.

A nice simple change to the code to make sure those multithreaded route calcs are actually stored *doh* means that not only did the processing time half, it now gets split over potentially 8 cores instead of 1, so on my PC its now running 16x faster. Combine that with the earlier speed-ups and its likely 18x faster, and because of the frame-spanning over 120 frames, it *feels* fluid as hell, even on insane maps.

Here is the concurrency visualiser showing the loading of the insanely big map.

And here it is zoomed in showing the multithreaded bits.

Those gaps are because each slot makes a single-threaded call to evaluate all of the import bays (each colored block is the code to get a route from one import bay to one production slot), and that call (in the main thread), then spreads it over the worker threads. Ideally I’d find time to eliminate that single thread blocking. Also I have some gaps in there because the end of each threads Calc() has to use a critical section lock to deposit its new routes safely in the main thread. Ideally I’d bunch them up inside a thread structure and dump them at the end.

Anyway, enough tech bollocks, the upshot is that massive factories will now be uber-fast :D.

There are no comments yet

Wow its been a BUSY week, like crazy busy. I released build 1.07 for Production Line, and started on 1.08. The price went up to $11 today, and I also started laying out a list of coming soon stuff in the forums here. There has been a steady (and accelerating) growth in daily pre-orders for the game. 4,000 sales seems ages ago now, and I’m struggling to keep up with all the feedback. Anyway…here is the new blog video.

I shouldn’t really be surprised, but the pace with which people have got around to building REALLY BIG factories is kinda amazing. This meant I needed to do some optimisation for those cases, often totally revising my idea of how big I should make certain fixed size buffers. (640k is enough for everybody!). I know some programmers might say ‘but dude…variable sized data structures. Yup, know all about them, but they can be SLOW. Try comparing the performance of a list or vector and an array one day… its HUGE. What I tend to do is have fixed arrays of oft-used objects, and allocate extra arrays if I start to run out, meaning rare one-off frame skips, but silky smooth performance most of the time.

My day is just now a blur of checking email;, then twitter, then facebook messages, then reddit posts, then forum posts, then forum messages, and then going through my bug list and my features todo list until its time to sleep or blow off steam in Battlefield One. However…just in case you thought that made me sound lazy, don’t forget we are also publishing another game (Shadowhand) which is coming soon. Here is Jakes latest video about the game:

Before long it will be GDC, and before that I’ve agreed to speak at TWO(!!!) events, which means…holy crap. I should stop typing and get on with it.. I will leave you with the exciting changelist for Production Line build 1.07:

[version alpha  1.07]
1) Major performance optimization for large factories.
2) Much faster vehicle rendering when zoomed out.
3) Fixed bug where very high car output resulted in no market price for a car being low enough.
4) Fixed the 'No room to TrashLowPriorityResource from stockpile' bug.
5) Fixed the 'Route Pending!' bug.
6) Possible fix for corrupt efficiency graph.
7) Fixed bug where manufacturing slots showed as not connected to a stockpile until the first resources arrived.
8) Added game-clock to top right menu.
9) Quitting the new car design dialog now gives a unique default name and price to the design.
10) Fixed bug where the warning notices on cars would persist until they encountered an empty conveyor belt.
11) Fixed bug where right clicking on research screen could delete items in the factory.
12) When a car is unable to move to the next (connected) slot, the message now tells the player which requirement is not met.
13) Background sound FX in R&D screen reduced in volume.
14) Fixed bug where some conveyor belt placements resulted in multiple placement sounds on top of each other.
15) Fixes to the layout of some R&D and slot menu items.
16) The warning and error notices in the factory now shrink to icons when zoomed right out.
17) As a temporary quick balance measure, only 4 valves are needed for engines now!
18) Fixed bug where supply stockpiles would not always fill correctly.

 

There are no comments yet