News:

Simutrans Chat Room
Where cool people of Simutrans can meet up.

Suggested rule change (was Re: Bridgewater-Brunel game no. 5)

Started by Huitsi, November 03, 2022, 12:54:57 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Huitsi

Another new game, another company I failed to get profitable before inadvertently landscaping it into administration. Per the rules, I now have to wait 2 in-game years – about 2 IRL days – for my company to get liquidated before trying again. Considering that a new player is pretty much guaranteed to fail with their first company and even seasoned veterans seem to do that pretty frequently, this wait seems like a really harsh punishment. After discussing the matter with Freahk on the server, I suggest a change to the rules: a player should be allowed to start a new company when their old one has gone into administrations, provided that:
  • the new company does not takeover or interact with the old company, to prevent abuse, and
  • the player list does not get filled (which could include a limit on total companies per player).


jamespetts

Thank you for your feedback. This is quite complex, as to achieve this end without causing other problems is requires some really very complex rules which are likely to be hard to monitor. If anyone can suggest something workable, I should be grateful, but very careful thought about all the implications are necessary. The following are some of the main difficulties.

  • Player slots are a scarce resource. Even if there are, e.g., two or three slots spare now, a single player taking up multiple slots may cause problems if one or two new players decide to join. There is no easy threshold to decide when this is and is not acceptable.
  • A player might take advantage of a company in administration to assist a newly started company, as the routes of such a company continue to be operated as a going concern. This means that players could use routes run unprofitably to subsidise a new company. This advantage could be very indirect and difficult to disentangle and could easily create complex perverse incentives.
  • A player might take over a company in administration using a newly started company.
  • A player might successively create huge numbers of companies in succession to undertake expensive permanent work (e.g. landscaping) to benefit a successor company.

If we can think of an algorithm that is clear, precise, can be communicated clearly to players and can realistically be enforced that fully addresses these issues, does not cause any problems of its own, and solves the original problem, then I see no reason that this algorithm cannot form part of the rules. However, I cannot at present think of an algorithm that has all of these qualities.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Huitsi

Thank you for considering this. Here's some thoughts on the listed difficulties:
  • Based on my experience in the previous iteration, reserving 2 or 3 slots for new players should be plenty. Keep in mind that failed companies still get cleared in a couple of years/days. Of course, the correct solution would be to eliminate the player cap, but I imagine it would've already been done if it was easy.
  • I don't think this is a big issue, since these services would only exist for a year. Prohibiting direct connections between the new and old company should suffice.
  • This can be explicitly forbidden.
  • I would say this is the biggest difficulty. I also can't think of an explicit rule that would limit this but not natural gameplay – the lanscaping that ruined my company is currenly helping another player on the server. Asking players to act in good faith in and not abuse this is the best I could come up with, and I gather you'd rather not have such vague rules.

Would granting just one instant second chance be an acceptable compromise?

Sirius

I think the suggested ruleset is a quite good tradeoff between "anti-cheating" restrictions and gameplay.

Pushing very restrictive rules to players will rather make players search for gaps in the ruleset, especially when the ruleset is quite frustrating (just like waiting for 2 real-world days is)

Such rules given, pleople will usually do either of these:
- Accept the rules, being frustrated after one or a few tries and never trying again
- Search for gaps in the ruleset to abuse these, and there are many in the current ruleset.
- Ignore the rules entirely, who's gonna judge...

For example, given the current ruleset, it is totally legal to ask a friend who is not yet playing on BB to assist your own company.
He could totally legally use his starting money to get some landscaping done every few days.

Thus, imho a good ruleset should always consider game play aspects and put some trust on players.
Those who want to cheat will always find their way, even without breaking the rules.
Those who don't want to cheat will just be frustrated by such rules.

That's why the above suggested is imho a good rule to address the issue. It is simple enough, not frustrating and clearly gives an idea on what kind of interaction is allowed when a new company is created.

Let's get explicitly to the raised concerns:
2., 3., 4. This is effectively prevented by the first suggested rule:
Quote from: Huitsi on November 03, 2022, 12:54:57 PMthe new company does not takeover or interact with the old company

1. This is ensured by the second suggested rule
Quote from: Huitsi on November 03, 2022, 12:54:57 PMthe player list does not get filled (which could include a limit on total companies per player).
Although this rule needs to be a bit more precise: I'd suggest to permit starting ONE new company as soon as the old one is in administration, and there are at least 3 spare slots left.
From the previous two BB games, it seems unlikely enough for me that more than two new players join the game in less than two real-world days, to accept the small chance of a new player being blocked by a not-yet liquidated company.