Category: production line

Something that I have always wanted to have in Production Line (and which is popular with the players as an option) is the idea of equipment breakdown and reliability. If you have played the game already you will know that having a sudden ‘stop’ in the line is incredibly disruptive to output, and thus profits, so introducing the risk of breakdown would make for an interesting game mechanic. With this in mind, I’m starting to think about implementation.

So to start with, what are my design goals for this new feature in the game? I see them as these:

• Add a new random event to shake up late gameplay.
• Add a new research tree option or options to improve reliability
• Add a new consideration regarding factory design and layout.

Right now, there is a slight problem in that, until world events get coded, the late game is one where you can simply leave your factory to run endlessly at a profit. In some ways, this doesn’t matter, as factorio has proven, the real goal is building fun and efficient layouts, not just achieving a set goal. However, it would be nice to have something that interrupts this otherwise fairly predictable process, so having a key production slot break down would be an interesting way to do this.

New research options are always fun, but I’m not sure which way to go regarding the reliability and repair stuff. On the one hand, I could offer slot-level upgrades which allow the player to (at a cost) buy more expensive robots and parts to reduce the chance of that slot breaking down. On the other hand I could introduce a global factory wide system of researchable upgrades which boosted the reliability of the entire factory? The second option is perhaps a little unbalanced because in the real world, such research would lead to systems whose cost scaled up with the factory size. I already have some upgrades that are ‘one-shot-regardless-of-factory’ like conveyor speeds, and in retrospect, these seem perhaps a little too generous. I should probably avoid expanding that.

 

 

So that would leave me with perhaps the idea of a series of ‘reliability’ upgrades for every slot in the game. Maybe ‘Enhanced maintenance’ ‘Error monitoring system’ etc, which when purchased at a slot would progressively reduce the chance of a breakdown. This might make for interesting decisions because for example if a single paint-dryer in a line breaks down, thats no big deal, so you could avoid paying for that upgrade, but if there is a single point of failure thats critical to the whole line… maybe it would be worth it.

This all leads into my final goal and would make it more sensible to plan for multiple lines, or at least partial lines, as a hedge against single line failure. I sometimes design my factories with parallel lines with cross points, which would allow production to route around broken down slots just like the internet routes around failures.

So given that I want there to be breakdowns, and researchable techs that reduce (but never 100% eliminate) them, how should the actual mechanics of a breakdown take place? The simplest and cleanest implementation that occurs to me at the moment is to give each slot a chance of a breakdown per minute of game-time.  If we assume each slot has a 99.5% uptime, then we are talking about a breakdown of ten minutes every 33 hours.  Very large factories could have maybe 200 slots, which would mean one of them was always broken and in need of repair. That sounds reasonable? (alternatively I could tie breakdown chance to time spent actually running…which makes more sense).

This allows for two different upgrade paths in terms of dealing with reliability. We can have research that decreases the chance of a breakdown, and research that decreases the duration of a breakdown. It would be interesting to have the chance upgrades be a per-slot thing (I’m thinking better engineered robots, better designed processes at the slot…) and the duration upgrades being global (maybe a better trained maintenance team to attend to the breakdowns?).

 

 

In terms of GUI, I’m thinking a new slot status notice (like we currently have for ‘no export room’ or ‘not connected to resources’ ) saying “breakdown!” and possibly a timer next to it (more realistically a circular progress count down thing?) showing how long it will be out of action until the breakdown is fixed. So with that in mind, here is my first-pass thoughts about how to implement breakdowns and reliability into the game, as a todo list for me:

• Add a base chance for any slot to breakdown and make this trigger a breakdown of some random duration range (say 7-15 minutes?)
• Add a new global variable for ‘breakdown repair efficiency’ which can be changed by global research items.
• Add new researchable technologies to reduce the duration of breakdowns.
• Add new upgrades for each slot that reduce the likelihood of a breakdown.
• Add new researchable technologies that enable the purchasing of those upgrades.
• Implement a nice GUI to show breakdowns when zoomed in and when zoomed out.

There are of course a bunch of other options, such as adding a repair-cost that gets auto-deducted when a slot is being repaired (but what if that sends you bankrupt? surely needs to be optional…requiring more GUI…), or requiring new repair-shops to be placed down to ‘unlock’ certain upgrades (but then can you delete them after the upgrades are in effect?). The system as described relies on the player accepting that a ‘hidden’ global variable (breakdown duration and chance) really is changing, unless I add yet more GUI options to show this to the player.

As I type this I realize there could also be the possibility (maybe as a secondary feature to code), of slots ‘silently breaking’, in that every car they work on produces a defect…This would be a bit evil, but also pretty cool, as you would have to introduce regular QA to track down the cause :D)

My biggest fear, (as should always be the case with Early-Access) is that I could screw up and make the game *worse*. I don’t want to make the game unbearable at the start (where a single slot breakdown may be more critical), but then I don’t want to make the game too easy in the late game either. I could just *cheat* and not let slots break down at the start of the game, and actually more realistically, I could just give each slot the first 48 hours or so to be totally free of breakdowns (makes sense as they are new…). Ideally breakdowns become a serious concern, but not annoying, which is an incredibly thin line to walk.

I am as usual always interested in peoples thoughts on this as a new mechanic for the game.

 

There are a lot of games on steam.  Those games are also cheap, PLUS steam has a refund policy. As a result, gamers don’t have to be patient. To be blunt…if gamers get confused or frustrated playing my game(s), they can refund them, or forget about them, and play something else. This is so different from when I was a kid, games were EXPENSIVE, there were far fewer of them, and you had to sit there and try things until stuff made sense. If you were really lucky, there might be a manual. These days, even if there is a series of explanatory videos, an illustrated manual, pop-up tooltips and an in-game tutorial, most players will ignore ALL of that, and just try to wing it. If things don’t make sense… your game is toast, your review score drops, your refund rate goes up, your sales go down, and you find yourself practising ‘do you want fries with that’ in the mirror ready for your next career move.

Obviously this is suboptimal.

I make innovative and fun games that have historically been a bit confusing to play and a bit buggy. This is the year where I try to address my game production shortcomings. Early Access is a godsend to me, as is collecting metrics on gameplay usage (anonymously). I can tell when people do not use a feature, and collect a lot of opinions from people on what sucks, and what needs work. I’ve made real progress in the last few weeks on reducing the bug count in Production Line, and I know I have a fair bit of work to do when it comes to the GUI and the ease with which players understand the game mechanics. In short, I need to give some more thought to a lot of my first-pass GUI choices.

A few screenshots illustrate a ton of minor things I need to give some thought to. Take this example:

Theoretically thats a fairly obvious and simple piece of UI that shows you information on the imports to a production slot in the game. The player uses this tab to adjust where those imports come from, presuming they have researched the tech that allows such configuration to be made. Each line shows a different resource item that comes in, the percentage of the last 100 items to be used that were locally produced (within this factory) and 3 mutually exclusive buttons to set the import mode for that resource.

There are potentially loads of issues here. The game tracks the last 100 items used by this slot, but if 90 of them (in this case) were Door Panels and only 10 were Chips, then the sample size for chips is way lower, and the ‘local’ percentage is not as accurate or granular. Does this matter? Does the player know what ‘local’ means? should there be a tooltip for that part of the GUI (there is for the buttons, but the player may not hover-over those). This entire tab is also hidden (grayed out at the tab button level) if the player has not researched the tech. Should they still be able to see the local percentage in this case? or are we fine hiding that from the player until then?

Then we have those selectable buttons. Firstly, do they look like they are clickable? They change the cursor and highlight on mouse over, is that enough? And is it obvious they are exclusive to each other? they don’t ‘look’ like conventional radio buttons used in multiple-selection. Should I change the UI? Finally, whats with the text? it explains things but isn’t it a bit clunky? Should I have column headers with text and then just radio buttons with green check buttons to illustrate selection on each line? would that make more sense? Does all this text even fit in German?

Lets take another look at the same bit of UI in a different circumstance:

In this case, the entire efficiency tab, which normally contains a pie chart, is completely blank. Why? because nothing has actually happened in the last X seconds of game time, meaning that there is no data to display here. However, this is surely a GUI bug, we should be drawing a pie chart anyway and showing the last state the slot was in surely? Thats easily fixed… Meanwhile the entire slot is effectively paused, because the stockpile is FULL, and there is no room to export more product. Effectively, we are on hold due to a lack of component usage or storage elsewhere in the factory. The ONLY clue to this is the ‘Status: No export room’ text. This is woeful. The immediate state of the slot is not even that obvious to ME.

Possibly I should highlight that status in red, or have it flashing, or maybe both. Perhaps the grey progress bars should be red, or flashing?

While I’m at it, on the stockpile strip, those numbers show the currently in stock value PLUS the number of requested items currently en-route in brackets. Nowhere is this explained. Can I explain it easily in the space provided? I shouldn’t make those icons any smaller, but maybe instead of numbers I should just have 16 slots for icons and a different color or shape to show which ones are en-route? Would that make more sense? would it be visually cluttered?

There are no trivial answers to any of these questions, they all need some careful thought and experimentation. I may end up changing all of this, or none of it. Maybe some of my ideas would make things worse…its hard to tell without trying. the really painful thing is that the end user who buys the final game post-release wont see any of this. They will see a GUI layout of a window with some text and icons and think that it all sprang into existence fully formed. It really isn’t like that. To get the level of UI polish I want (and need) I’m going to have to iterate on this stuff a lot. This is tricky when you are the only programmer, and only designer. There is much to do…