Jump to content

MalReynolds

Alpha Tester
  • Content Count

    45
  • Joined

  • Last visited

About MalReynolds

  • Rank
    Advanced Member

Profile Information

  • backer_title
    Iron Founder
  • Alpha
    Yes

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. This post is about the experience of crafting using industry in the early game. I am fully aware that as you build resources these concerns decrease, but .. this still leaves us with a less than ideal early game experience - which is the issue I want to address. So, early game, you're building things in your nanocrafter and you're starting your industry... You build the parts for the Assembly Line S (skipping the XS as it's useless initially), then you build the parts and Assembly Line M, then you build the parts and a Smelter, Refiner, Electronics, Metalwork, 3D Printer, and containers galore. The progression here is fine, the issue is that because you have to use the nanocrafter to produce the parts required (typically into a linked container as input to the assemblies), and because you have to manually alter the recipe each time, you're essentially tied to your base, for long periods of time, doing "nothing". Sure, you could be building the base .. but.. typically you've used all your starting honeycomb and don't want to make more, yet, as it would slow down your industry creation. Sure, you could run off and mine.. but then your nanocrafter queue will put the current output in the wrong place (because you leave the linked container range) and then it will stall (as all the inputs are in the linked container, now out of range). So.. instead, you sit with your thumb up your .. doing "nothing". This is a "not much fun" gameplay loop which I would like to see improved. I think the solution is to add queues to industry units. What I mean by this is that we ought to be able to queue a "make X of Y" request, just as we can in the nanocrafter. I am not suggesting we queue "make infinite" or "maintain X, and Y, and Z" or anything like that. So, industry units can either be processing a queue of make X of Y OR doing one of those other things, not both. So, lets start by listing and attempting to refute the common objections to this: 1) this would make large factories redundant If you can build everything with 1 electronics, why have more? Because one electronics can only do 1 thing at a time. So, if you want to produce something with 5 ingredients, you would have to wait for one electronics to produce all the input, one ingredient at a time, and your "factory" (of 2 units) would be super slow and inefficient. Given this, you still need large factories, especially once you reach the scale where you want to "maintain" a range of input ingredients to keep your factory production constant and efficient. Queues have to be queued manually, so they're not appropriate for a fully automated factory. In short, queues won't change how large factories operate, so they will still exist just as they do today. 2) this would reduce the "value" / "cost" of items in the game, and "ruin" the market. If things are too easy to build, who would buy items from the market. Yes, this will make it easier for new players to build the smallest, cheapest, T1 elements in the game. But, doing so will still take them quite some time (see point #1 above) even if they have a few industry units, so they might prefer to buy these items some of the time. For higher tier items, with more ingredients and longer build times for those ingredients and the item itself.. those players are going to have an ever better reason to buy the items instead of making them. Another way to look at this; even late game players might prefer to simply buy, in bulk, lower tier items. If crafting these is easier for new players, then they may even be selling on the market. This is actually a net positive for the market, even if the price per unit is lower, there will be more items being bought and sold. In short, queues may have an effect on the low end of the market (positive and negative), but very little effect on T2 and above. 3) Any other objections? If you have any, please let me know, keeping in mind the points made in response to objections #1 and #2 above (as I can think of some potential objections which these points refute). This is not just my complaint I am not the only person who has issue with this gameplay loop. I recently watched this video where they express the same concerns about crafting speed and having to sit round doing "nothing".
  2. Yeah. In fact, as a programmer myself it seems likely that TUs and Industry are coded in fundamentally the exact same way. Take X units of A, produce Y units of B, in time T. In the case of a TU, A and B are the same resource, and X and Y are 1. So, rather than create more code to do something different, simply lowering the cost is the pragmatic solution.
  3. I think we need a better interface for managing links. As it stands it can be very tricky to pick out the links for a specific industry, or to a specific container. Perhaps a button like 'u' which highlights them would help. But, also, a screen where we can see all the industry and containers (a rectangle for each), click one (to focus it), and see all the links (and available sockets) in and out with the ability to delete and change these links (by clicking an X, or dragging the other industry/container rectangles onto the focused one, or similar. The goal here is to get a better overview, so we can more easily manage the links to resolve issues like running out of sockets on a container with resources you need.
  4. They're made in an Assembly Line L and require more resources than the industry units which actually produce something. They only allow one item type to be moved at a time. They can pull from multiple containers/hubs, and place into one. My biggest issue with industry is running out of sockets on containers. For example, the container with my basic connectors has no more output sockets and I want to connect another electronics to it. So.. I could create another container, and electronics, and then connect to that. Or, I could use a transfer unit to spread the output from the first (which is keeping up with demand just fine) to two containers. The former solution is a lot cheaper than the latter.. but it irks me because it's less efficient in terms of space and optimised production. If transfer units were cheaper, it would be ok. If transfer units could handle multiple resources, it would be ok. But, as it stands, it's just plain annoying. I realise that if reached the point where I needed 2 electronics producing basic connectors full time it would cease to be a problem, .. for basic connectors. But the same issue will simply happen again for something further down the chain. For me, the fun here is building a well oiled machine and to do that I need a bit more flexibility with things like this.
  5. Yes. I would like to be able to swap a core for another, increasing the build area. Even if this was only limited to increasing size (at first, or ever) it would still be a great help, especially to new players.
  6. To be honest.. I'm finding it hard to convince my friends to give DU a go. The issue seems to be the minimum 3 month subscription.. sure, it's not a lot, but it's also roughly the same price as any other indie game which you get permanently. Now, I think DU is worth it, but they need to try it before they can be sure. I had them convinced to give it a go, under this scheme, for the price of a month's sub. So.. how about a once only one month sub, a "try before you buy" option?
×
×
  • Create New...