The so-called "coop style" with "clean building" etc. is the most typical thing that comes to mind when you think about a Public Server Game, there is one special piece which always stands out, if done correctly. Chaos games. Games with nothing defined, hardest games to manage to get success in, but also the style of playing which everybody started with in the very beginning.
In this article I will not try to describe concepts which show how something works, nor will I try to documentate some high-wtf logic mechanisms or anything like that.
This article is meant to help you manage chaos games - but not just those, the experience gained will greatly improve your understanding of the game in general.
Introduction: What is CHAOS?
CHAOS is one of the gametypes we recognize. Typically it means a very open network plan, usually without pre-defined network system and with very open rules, allowing players to do a lot of things creatively. Even if you do not call it that way, chaos is the most typical style which you use when you play a normal game like on our Welcome Server, alone, or anywhere where you start with limited amount of cash and cannot afford to build a gigantic network right away - you have to build more progressively, start with something small, and expand that over time.
With this dangerous name "chaos" comes a huge problem though ... when people join a Public Server Game which has "CHAOS" written in gametype description, they usually go downright batshet bananas, throw everything (including common sense) out of the window, and create a game which usually does not end very well, OR an active group of people re-builds the messy parts - which is even more work than starting a new game would be so those people usually only suffer through that only once.
All of the issues basically have the same source. Interpretation of rules and conventions - each player imagines something different behind various things, and if you make too many rules and restrictions, you end up back at a normal coop game again, because the network looks just the same at LL_RR state as a normal game would since there remains no room for difference. The hardest part is for the members/experienced players - those have to watch the map ultra carefully, and guide players so that the game does not derail in some brutal fashion very quickly.
Earlier (around psg #200s), Chaos even ended up being banned because it would just result in way too bad results every time we tried it - or it had cost the active players so much effort to get such a game into stabilized state, that the most productive part of players simply agreed that Chaos is not an option.
At the same time, there have always been and will be many people who find Chaos interesting. And for good reasons - from my point of view, Chaos was always something I really wanted to get done right. I simply imagined my single player games and wanted to do that in coop size, with coop power. I joined the public server and built a lot there, but I always missed the "start with a minimalistic network -> expand until there are tracks EVERYWHERE" kind of game.
Over the time of my playing alone in my own companies, I have created a set of clear conventions and systematic rules which - when being followed - let me create a game which is nice and organic but at the same time gets huge and impressive. If you are one of the people who miss games likes that, this article is exactly for you.
Starting the network
Apart from looking around, judging situation, preparing your tea, putting your chair into comfortable position, and other things, the start of the game is Extremely important to how the network will progress during the game.
In the general scope of gameplay, it does not really matter if you decide to go for a normal game, or something specific as refit, something additional like for example goods being loaded to 100% at multiple points, or even go for some utter logic wtf like a SRNW. The following hints apply everywhere and if you do use those, you already have a lot more chance to get very far in the game without having to rebuild things much.
Note that it does not matter at all if you follow the ML/SL hierarchy coop does. I will refer to it because the ML/BBH always means a place of high traffic - and things which need a lot of space to build - but if you just build randomly without such a specified hierarchy, it is just fine.
1. LEAVE SPACE
When does a game end? Typically because you cannot fix issues anymore - and that only happens because you do not have enough space anymore.
From that comes a relatively simple convention - leave space between everything. When I tell people this, they usually just agree and say they will, but let's just put a few examples to demonstrate the point a bit better.
[LR shit and LR T-hub] vs [spaced out hub]
It is very easy to just build your main line as a LR in the start. But how do you want to expand that? Always outside is usually the answer, some people even just build a new LL_RR next to it and then re-route the traffic. That is not what we want to do.
We want to create something which works for our expanding later.
While the spaced out hub and everything far apart might look less sophisticated in the beginning, later on you will be happy you did it.
In other words, do something along those lines or prepare to poo hedgehogs and porcupines. Think about it.
[SLH near BBH] vs [SLHs distributed]
I see it way too often that people choose their hub locations too close to each other, which later becomes a gigantic problem and one of the hubs usually gets moved elsewhere simply because of insufficient space.
It is a good idea to distribute the hubs at least somewhat evenly, so each one has enough room to work with later on.
2. No overkill
Especially at the beginning when you do not have terribly much experience with what works and what does not, it is extremely dangerous when people just build something big and complicated - it usually breaks due to some elementary issue and they are sad that it did not work out while they put so much time into it.
It is very helpful if you always build everything small - I even build single bridges in most places, and eventually expand those. The great reason behind is that once things break, you can see where is the source of it, fix it, and continue. With huge constructions you usually do not really have the space/flexibility anymore.
Also, since you can see things break more often, you learn more. Simple fail-learn process.
Last but definitely not least, by building things small, you save space over time by expanding only the necessary parts. Example: When building a LLLL station from scratch, it is likely you will build too many platforms which takes space. Building small and adding things when necessary lets you see how much do you Really need.
[small station] vs [LL station to start with]
[clean building] vs [mess]
EXPANDING
Once you have the basic network set up and you get into first throughput problems, there is no way to go around things other than simply to get more rails. Unless you have some considerable flaws on your tracks, which I will not assume.
Expanding is one of the most interesting things to do in OpenTTD simply because it is the only way to good results, and because it allows so much creativity due to the many options. Also, you need to somewhat know what you want to reach, otherwise your constructions just get messy very quickly.
So this part of the article is going to demonstrate what we want to achieve, and how to do it.
3. Starting expansion
The idea I follow always is to let trains join the track if it is already built - therefore I start at the end of it, and go against the flow of the trains.
Because I know that the track is fully functional, I can connect anything to it without having to worry much.
3a. Expanding joins/merges
Mergers are always the hardest part but you got to do it at some point anyway ;) It depends what kind of merger you are building, in case of our first expansion everything ends up as L_R in the output since we did not expand that yet, so there mergers are simple. With more tracks you can follow any of the ideas in the junctionary, or make your own merger ideas.
I usually just let everything join every line, and am done with it. There can be a few exceptional lines which get a short priority because they do not get any choice.
3b. Expanding splits
Splits are a lot simpler to expand, BUT you really need to make SURE that you give each line all split options, so that your trains do not get lost anywhere. Otherwise porcupines.
FURTHER IMPROVING OF THE FLOW
While the things above are all cute and important, there is other optional stuff that can help you a lot when done.
A. No bridges on ML
A rather obscure rule that I follow very often is to try to avoid disturbing the ML flow much by not making bridges on it.
Bridges generally mean they need to be at least 2 per line. Normally this is not an issue at all but once anything slows down, they can become the weak spot which prevents the line from re-gaining speed.
ABR 14: Playing "Normal" [CHAOS]
On the first sight you could say "but I always have to bridge _something_!", especially in BBHs where is "ML" is everything.
Let's break it down and see more of the reason why double bridges can be such a problem. The so-called evil mode harms the flow after any jam or slowdown. The evil mode however requires trains to split/bridge and join to the same line again.
If you put the bridges as a part of a choice/merger, you technically have no double bridges - each bridge is a single bridge to a different direction.
This is a bit of an advanced thing to do, but it will greatly improve the performance of your networks if you do this - everything unjams quickly so stuff is a lot more fluent in total.
B. Short priorities
Very often people build long priorities, call the prioritized thing Main line, and expect that everything will be great because their ML can never slow down.
While the main line probably will not slow down ever, it will have less throughput, you side lines will probably start jamming because trains could not join the ML, and your trains will be very likely to get stuck when waiting on joins for a very long time with hedgehogs.
It is very important to understand the job of the priority. While it technically is just a mechanism which really does prioritize one line over another locally, in the bigger picture it achieves that trains choose from multiple tracks the emptier ones.
Point A. No bridges on ML is greatly helpful now, because we can let the ML slow down (due to shorter priorities) occasionally when SL trains are joining - because it will fix itself very quickly.
In total you get nice continuous flow everywhere instead of having one untouchable flow with everything around it jamming.
This is just a small thing, one could even say rather cosmetic (if you do not mind the trains waiting forever etc), but I like to do this a lot, especially since with the point A. it has no big downsides other than some space requirements and keeping some system in mind.
C. Autoplace friendliness
In many games which progress through the years and include autoreplacing your engines/wagons to better ones as they get introduced, the actual process of autoreplace often causes jams. It is a good idea to consider autoreplace friendliness even in games where you start with your "final" engine because what if you want to change all of your 1000 trains later on? I already wrote an article about this, so I will just link to it.
Also note that e.g. refit networks are extremely good with autoreplace because once trains have "go to (nearest) depot" in their orders, they automatically service/autoreplace there, and nowhere else - also preventing a lot of mess. Other than that, since trains visit depots often, they also autoreplace very quick.
Conclusion
In general, chaos is a great bunch of fun if it works for you. That is easily done when playing alone, but when playing with a group of people it gets a lot harder. To get solid results it helps a lot to do the things I described above, but also other factors can greatly increase the chances that stuff is going to be good. One of them is choice of trains - choosing some fitting trains which have lower curve length but good throughput capacity is a great idea, with chaos the SLUGs are extremely potent due to their superb acceleration and needing only very short curves.
I hope you found my experience useful and feel invited to do some mayhem on our servers. :)
Thank you for reading
V453000