Stopping the advantage gained by hiring workers individually

[Clayell]

The problem: A slight advantage can be gained in terms of both efficiency of the building (research center or lc) and time to finish the product (science or rocket) by hiring workers one by one instead of in batches. This leads to the slightly optimal hiring strategy being to spend tens of minutes hiring workers one by one, (as in, hiring a worker once you get 300 funds, and then warping until you have 300 funds again) which is, as I have encountered, very annoying to do.

I will lay down two ground rules for this problem, the solution needs to both be un-complicated to the player, and it cannot change existing gameplay by much.

test_account's Solution:
I've likely spent well over an hour cumulatively discussing and thinking about this problem with mainly test account, and in my opinion I do not find his solution satisfactory. Test account's solution is to only allow workers to be hired in batches of 10, and rounding the existing engineer caps for lc's/hangars to the nearest multiple of 10. This would change the existing gameplay by a lot, especially for early lc's/hangars, and this is why I do not find it satisfactory. Along with that, it still does not solve the problem if very large amounts of workers are needed (such as in the late-game with thousands of workers), as the optimal strategy would still hiring batches of 10 one by one, which would take quite a while.

lpg's Solution:
While making this issue, lpg half-jokingly gave a suggestion that I hadn't heard of before. Basically, their solution is to only allow batches of people to be hired at the start of the month. (they also said week, but per month is probably more realistic) Some further suggestions by others have also raised the idea of being able to hire workers whenever, but they would only start working (and thus start getting a salary) at the beginning of each month. These solutions would probably solve the annoying problem of having to hire workers one by one (or in batches one by one as in test_account's solution) although it would very clearly change the gameplay very drastically. I don't think they expected this solution to be taken seriously, but I think it is a potential (albeit confusing for new players) solution if it were communicated well enough.

My Solution:
My solution is to create an optional "Auto-Hire" system that would allow players to get the exact same results as hiring workers one by one without any of the actual time and effort to do it. Essentially, when the "Auto-Hire" button is turned on, it will give the player a text box for how many engineers/scientists they want to hire. (only one or the other, as hiring both at the same time would likely be not very useful) After this is filled in, the player will have their available funds locked at their current amount until the desired amount of workers is met. (although they would obviously be able to turn off the auto-hire if they realize they need money for something else) The system would then take the positive balance that would otherwise be going towards the player's available funds and putting it towards a counter. Once this counter got to 300 funds, it would hire the worker. As soon as the desired amount of workers is met, the system would disengage and allow the player to acquire funds again.

Obviously, this would be fairly difficult and time-consuming to code in, and it would probably have to come with a certain amount of lag while timewarping. Perhaps the maximum timewarping limit while "auto-hire" is on could be limited to prevent any errors from occurring. Even if the system was incredibly laggy, it would still be miles better than the current problem of having to hire one by one. Along with that, I cannot see any way in which this system could change the gameplay loop in any way, and the complication required to use it would certainly be acceptable with some explanation.

EDIT 2/24/2024: BETTER SOLUTION

We could just allow the player to pay off the hiring (training) cost over time. That way it would be just like nearly every other payment, which let you pay for the cost over time. If we assume that the cost is for training, then this makes even more sense, as training an employee takes time and doesn't happen instantly.

This does change the gameplay loop a little, but not by much, and it would be much easier to code than the auto-hire system mentioned earlier

[Clayell]

I'll also note that some are suggesting (and I have also previously suggested) that the hiring costs could be removed, fixing this problem before it could even show up, however I now realize that the cheese of hiring and firing many workers would be able to significantly change gameplay. (and, from a realism standpoint, hiring costs can represent training costs)

[Elouda]

An auto-hire system to a 'target number' of employees seems a logical solution, and one that came to mind to me also as I played recently.

A modification lpg's idea - instead of only being able to hire at the start of the month, what if you could hire anytime, but people only 'started working' at the start of each month. So you could hire throughout May, but all the new hires would only start to contribute (or go into the actual pool from a 'pending hires' pool) on June 1st.

[ghost]

That would help if new hires also start receiving salary on June 1st.
But it will make the game very unclear because it won't be immediately visible how the new hires affect research dates.

[Clayell]

While the idea of only allowing new workers to start at the beginning of every month would mostly solve this problem (except perhaps for very long builds that take a year or so) getting it implemented in a way that would make sense to a player, let alone a new player, would probably be just as or even more difficult than an auto-hire system. It would also just be very strange as it isn't realistic in the slightest for most companies, and it would certainly effect the balance of the game in some ways. I will edit that idea to include these revisions though.

[Clayell]

Oh, perhaps we could just allow the player to pay off the hiring (training) cost over time? That way it would be just like nearly every other payment, which let you pay for the cost over time. If we assume that the cost is for training, then this makes even more sense, as training an employee takes time and doesn't happen instantly.

[siimav]

Thoughts about this prototype?

unknown_2024.04.19-02.08.mp4

[Clayell]

Thoughts about this prototype?

Oh wow, that's pretty much exactly what I was hoping for! Seems to be much faster than my janky macro system as well, lol.
Please do let me know if or when that is implemented.

[siimav]

The beta version is available in #2352