#openttdcoop

There is a channel on blip.tv based on Starcraft 2 by a person called Day9. It is someone who not only knows a damn lot about SC2 gameplay but he is an extremely clever person who thinks about things in an interesting way. And he is entertaining to listen to, at least for me.

What I want to share with you in this post is a link for his 400th daily episode. This time his daily is not completely related to SC2 but it is more of a general talk about how people think not only when playing SC2 or playing games in general. Of course it is not entirely relevant to OpenTTD in all aspects like for example making a surprise attack strategy, but many other points are very valid to consider even here.

Here is the link for the videos and below in the article I will try to show how do I think those points fit even to our environment.
Day9 daily 400

I really enjoy watching is videos despite I do not play Starcraft 2 just because he is such an entertaining person to listen to.

Assumption 1: Skill = secrets

Typically people play with Lev4 when they start with the game. Some people even follow that for years. Now when such a person learns about cyclotron he automatically considers his network amazing. But the cyclotron still does not make him able to put 1000 trains on 512×512 map. There are many little secrets in OpenTTD that you can discover. But if you for example look at psg219 which reached 2777 trains on a ridiculously watery map, one would assume “oh what secret magic has been done!”. The answer is nothing. That game is completely simple. Mergers are usually very messy or random, it is just made to somehow work without anything incredibly complicated. All that was done was just looking what part of map needs more traffic, what part has too much, trying to expand it of course, but also trying to make it as easy to expand as possible by increasing traffic in other parts than our problematic part. (Which is also the mind process that the current psg (224) is wrapped around.)

Assumption 2: Broad knowledge

I don’t think this point is very relevant to OpenTTD gameplay but generally if you like something, stick with it and improve it. If you have your style and it works, play with it and improve it further because then you might come up something new. 🙂

Assumption 3: If it ain’t broke, dont fix it!

I would interpretate this one as something like learning from other savegames. Within a game when you see a merger is horribly wrong, but somehow works, you do not need to fix it indeed. But it happens way too often that people say “Ok, this worked in the last game so I use it again”. And then of course it breaks in the new game. There are many aspects that trains influence and one thing does not have to work somewhere else. So I would just bend it to If it ain’t broke, that doesnt mean it “works”.

Assupmtion 4: The system is flawed

This is quite hard to demonstrate but I think it is quite related to OpenTTD regarding new features. Often you hear “omg, we totally need signals on bridges”. The thing is, why? We are able to make a working network. We are able to make bridges full speed by doubling them. Majority of people does not find this out on their own, they will just continue building single bridges until someone tells them otherwise. Or there is the other option – they will consider the system flawed and use the patch. I see that as rather eliminating the solution instead of trying to make up a solution – which is the whole key of OpenTTD gameplay the why OpenTTD is so entertaining for such an enormously long period of time. What happens if we get capacity problems on the main line? Will we upgrade it, or will we load a train set with higher wagon capacity and more powerful engines?

Assumption 5: Believe patterns

There are always things we learn from. There is a wiki, there are other players, but there are also ourselves. I would compare this point to a thing which occurs quite often. People often come and say “Hey I read that terminus stations are bad, so you build this wrongly.” However the person probably lacks knowing the reasons why. Or when someone learns to build a balanced station but has no clue why he actually did that. Or building a SRNW “just cause”. Of course “just have fun” is always good, but it does not bring the progress and development of our gameplay.
I would conclude that as: Learning is great whereever it comes from. But always think about the process why, how, under what circumstances and what exactly is going on.
Another nice idea is the pre-signal bypass station which has major flaws in the logic (the logic itself is forcing it’s issues) which did work somehow under some circumstances when it was made. But nobody considered that all the logic is actually not needed and the 2way signals are just enough. The only thing that was needed was to try to solve the problem again and provide a better solution to an already “best” solution.
Always try to build it and understand why is something done what way. The ideal case is when all your knowledge is checked, tested, and well understood by yourself, not just absorbed from the wiki or anywhere else.

Assumption 6: Language is knowledge

Typical: I learned to build a balancer. I know how to balance tracks. My tracks are balanced. What does that actually mean? The word balancing means something like equal load on both tracks in this case. Do I really reach that? Do I actually want that? Is that what the balancer does/is supposed to do? Unless your balancer is a flipflop it of course does not. You do not care if your track A has more load than track B. The point of that balancer you have is to let trains use both tracks effectively. There are many ways how to call a merger/balancer/chooser/mixer/cat/whatever. The point is how it works, what it does and what is the purpose. Names can be very misleading sometimes.

Assumption 7: If I give a good answer, I must be answering the right question.

Answer: Roro is faster than terminus. Period.
What is the question here? Typically you will hear “the platforms are used more efficiently”. Is that the right question though? Do we really care how often train arrives to a platform?
The better question would be “Does roro slow the ML/incoming line less than terminus?” You all know the answer, neither of them has to slow the ML but also can slow the ML – completely regardless of the platform efficiency but mainly dependant on how the station is actually built.
Answer: PBS is better in front of platforms and PBS makes terminus with X viable.
How do we actually ask this? What about “Is the throughput of a PBS block faster than block signals?” Of course not, we do not care whether it is better, we ask whether anything has actually improved in the end. So better questions would be “Does the X actually need a better throughput?” or “Do the platforms actually operate quickly enough to make the X require a PBS?”
These questions should explain this: When there are slow trains with short unloading times, you probably can improve the throughput of an X by putting PBS there. However with fast trains and long unloading times, the difference between block and path signals will be unsignificant.

Conclusion

There are certainly many more points that are interesting even in our environment but I will leave those for you to discover and think about. In my opinion it is a great video to watch and that it can be really helpful not only for StarCraft 2 people but also for us. It might be focused on competitive gaming, but that does not matter. In the whole mind process, we are just trying to improve what we do, just like competitive gamers want. Only their goal is to beat someone, our goal is to beat ourselves. I hope you enjoyed watching it and eventually even liked reading my article related to it.

Thanks for reading as always 🙂