Thursday 27 December 2012

Module M: Optimizing Anshar- Production


This post is taken out of line from a larger series but I wanted to get it out early. It's an exploration of different principles when planning your production. Take it as a guideline to a specific approach, not a set in stone rule set. It's called Module M because it fits into a bigger picture.

Assume you want to build an Anshar Jump Freighter. This is no simple task to optimize, so let's just look at the "main" part: Actually building the thing. To make a good profit you need a set of researched blueprints as well as and Anshar BPC. Getting to this point will be covered elsewhere, let's just look at the BPs we need:

Anshar BPC
Obelisk BPO

Capital Propulsion Engine BPO
Capital Armor Plates BPO
Capital Cargo Bay BPO
Capital Construction Parts BPO
Capital Jump Drive BPO

Capital Crystalline Carbide Armor BPO
Capital Fusion Reactor BPO
Capital Ion Thruster BPO
Capital Magnetometric Sensor Cluster BPO
Capital Oscillator Capacitor Unit BPO
Capital Photon Microprocessor BPO
Capital Pulse Shield Emitter BPO

R.A.M. Starship Tech BPO

Disclaimer: Run your own numbers, they depend on your skills, the BPO research levels and other details.

That's a lot of BPOs and a lot of items to be manufactured. If I do them one by one, it'd take 100 days to build one. Luckily we can use more than one slot so those 100 days can be cut down by using these. Still that would not be efficient because we have downtimes of the BPOs and they'd sit idle. We could use multiple BPOs to offset this, but that will require more investment. It's an option, but maybe there is another way: Building manufacturing Packets, that consider when which items are required and which depend on each other. Look at this:

Packet 1: 23d, 8h, 7m
R.A.M. Starship Tech: 17h, 50m
Capital Pulse Shield Emitter: 3d, 1h, 30m
Capital Magnetometric Sensor Cluster: 3d, 0h, 32m
Capital Photon Microprocessor: 4d, 19h, 13m
Capital Oscillator Capacitor Unit: 4d, 19h, 13m
Capital Crystalline Carbide Armor: 6d, 21h, 39m

Packet 2: 12d, 10h, 52m
Capital Jump Drive: 2d, 20h, 58m
Capital Propulsion Engine: 1d, 19h, 6m
Capital Armor Plates: 1d, 16h, 14m
Capital Construction Parts: 6d, 2h, 34m

Packet 3: 10d, 2h, 30m
Capital Pulse Shield Emitter: 3d, 1h, 30m
Capital Fusion Reactor: 7d, 1h, 0m

Packet 4: 12d, 16h, 40m
Capital Ion Thruster: 2d, 21h, 0m
Capital Cargo Bay: 9d, 19h, 40m

Packet 5: 10d, 16h, 0m
Obelisk: 10d, 16h, 0m

Packet 6: 24d, 21h, 20m
Anshar BPC: 24d, 21h, 20m

Some notes: Packet 6 is the biggest and will be our production "frame", meaning all manufacturing will be synched to this timespan. Packet 5 can only be built after 2 and 4 complete. Packet 6 only after 1, 3 and 5 are complete. Looking at the build times you will see that 1 and 6 are roughly the same, as well as 2+3 and 4+5 combined. With this information we can set up a 2 Slot production line like this:

Slot 1: Build Packets 1 to 3
Slot 2: Build Packets 4 to 6

That wouldn't be really smart because we'd have idle time between the Packets waiting for others. But if we shift things a bit, this will change:

Slot 1: Build Pakets 1 to 3
Slot 2: Wait until Packet 1 finishes, then build 4 to 6.

Why wait until Packet 1 finishes you might ask: That's because we don't just want to build one Anshar, we want to build them continuously. If we repeat the manufacturing, the following will happen:

Slot 1: 1,2,3, 1,2,3 1,2,3, ...

Slot 2: X,4,5,6,4,5,6,4,5,6, ...

As you can see, Packets 1 and 6 will sync up being built at the same time, meaning while we build the Anshar itself we already are building the parts for the next one. It almost synchs up because 2+3 and 4+5 take roughly as long as Packet 1 and 6. Let's just put make sure it really syncs, introducing a bit of idle time, but lining it up a bit for convenience. This way, after wasting one slot for almost 25 days, we get an Anshar roughly every 49.5 days:



It's also what we would expect from using two slots, so where is the advantage? We will come to that soon. Right now our BPOs still have a lot of downtime, so let's fix this:


Simply by repeating this process we can now produce one Anshar every 25 days with one set of BPOs, reducing our BPO downtime to the idle time lost when synching up to the Packet lengths. Hint: You can reduce the initial wait time by splitting the first Packet 1 into two and using the slots initially to further cut down initial idle time.





Now, could we have done this another way? Sure. But this way has quite some advantages:

- You are aware of what Resources you require to start a Package at any point in time.
- You can easily identify your Packages and for which run it is in your  spreadsheets.
- The idle times give you a bit of room to queue up your Manufacturing slots because of your time zone requirements.
- It minimizes Investment costs in BPOs and their Research, since you need only one set.
- It scales both ways: Add another set of BPOs in the same manner and double your production on one character or shelf off parts of the Packets to other characters, the time frames then become "deadlines" for players.
- Minimized "at the keyboard" time because you can queue your production only needing minimal time to set up manufacturing.
- The time frame is synced to the production runs of an Anshar BPC, and also syncs with time frames from the Invention and Hauling Modules not published yet.

Depending on the complexity of your production chains it is worth the time to calculate a similar chain for capitals or other more complex production chains.

No comments:

Post a Comment

Posts older than 14 days are subject to moderation before being published. I do so sporadically. If you have a question regarding older posts, also evemail dotoo foo.

Blogger comments supports basic html. You can make a link 'clicky' by <a href="http://yoursite/yourpage">yoursite/yourpage</a>

While I currently accept anonymous users, please include a pseudonym. I get confused answering anonymous.

If the word verification is preventing you from adding a comment, please evemail DoToo Foo for alternative methods