a long time since I blogged the last time, huh? Well, as I always pointed out, I’ll always stay in touch with ‘coop – and so I accidentally ran into a coopetition challenge at Sunday 4th!

As many of you may know, there is a cool mod out there named “Head to Head” for some reason: it features a map-generation logic which duplicates a landscape in order to offer a fair head2head competition gameplay! The mod is created and maintained by Yexo. Further information is to be found at the TT-Forums, the binary itself may be obtained at openttd.org.

Well, the game itself turned out to be a disaster to our #openttdcoop members! As Ammler went bankrupt at the very beginning of the session, planetmaker decided to keep the gameplay on a very slow pace and I made several wrong decisions in the first game year, thus giving Yexo a good opportunity to outperform all of us! Eventually, we did not even find a plausibly reason to disqualify him so we had to admit his total victory over planet ‘coop – see the screenshot at the bottom for further details

Finally, I want to thank Yexo (although he degraded us ingame) for this great mod and I have to add that I will definitely be around for a new coopetition session in the next days or weeks!

The trick itself was neat, but caused a downfall in delivered cargo and income profit. Also the decision to make a new drop zone and finance the factory itself was very costly. Green on the other hand should have started with two way tracks from the beginning, because it took them quite some time to upgrade the single tracks they had layed out.

Narc our referee and in control of the pause command made sure we stopped exactly after 8 years. So on Jan 1st 1971 the game ended, that made green the clear winners.

Game results:

More about coopetition: Coopetition Wiki entry

great news, another big step forward in OpenTTD development: the new framework for computer players has been merged from the NoAI branch into trunk. So, from now on, there’s no need anymore to complain about those stupid AI which OpenTTD had up until now – everyone may programme his or her own AI with as much intelligence as desired. Like many people did as documented in the NoAI subforums. Check out the threads there for different AIs.

Company chart from our first coop game against a few AIs
I got curious when the number and frequency of commits started to increase significantly that afternoon, starting with r15000:

[11:48] <cia -1> OpenTTD: truebrain * r15000 /branches/noai/src/ (ai/ai.hpp saveload/ai_sl.cpp): [NoAI] -Fix (r14984): forgot to rename @file too

[14:51] <cia -1> OpenTTD: truebrain * r15001 /branches/noai/src/ai/ai_core.cpp: [NoAI] -Fix: make NoAI network safe again

hmm… making it network safe again? Let’s see…
a number of other commits followed, also and especially in th NoAI branch. Then then finally what seemed to become more and more inevitable:

[18:12] <cia -1> OpenTTD: truebrain * r15027 /trunk/ (311 files in 30 dirs): (log message trimmed)
[18:12] <cia -1> OpenTTD: -Merge: tomatos and bananas left to be, here is NoAI for all to see.
[18:12] <cia -1> OpenTTD: NoAI is an API (a framework) to build your own AIs in. See:
[18:12] <cia -1> OpenTTD: http://wiki.openttd.org/wiki/index.php/AI:Main_Page
[18:12] <cia -1> OpenTTD: With many thanks to:
[18:12] <cia -1> OpenTTD: – glx and Rubidium for their syncing, feedback and hard work
[18:12] <cia -1> OpenTTD: – Yexo for his feedback, patches, and AIs which tested the system very deep
[18:12] <cia -1> OpenTTD: – Morloth for his feedback and patches
[18:12] <cia -1> OpenTTD: – TJIP for hosting a challenge which kept NoAI on track
[18:12] <cia -1> OpenTTD: – All AI authors for testing our AI API, and all other people who helped in one way or another
[18:12] <cia -1> OpenTTD: -Remove: all old AIs and their cheats/hacks

I can only support this: many thanks to all who made this big step in the history of OpenTTD possible. Great job, guys!

So now let’s look forward to maybe an occasional coopetition game of us coopers against the best of AIs – it will definitely require a slightly different approach than in our usual games w/o any competition as we tried out some time ago in a match against AdmiralAI.

PS: Maybe there’re some further nice fruit in the basket in the not so distant future:

[13:09] <TrueBrain> and ‘extra’ package, which contains AIs, grfs, …
[13:10] <TrueBrain> of course the ‘game’ package should contain the tram grf, and at least a few AIs (which should be in SVN too)

A Bus Terminal

We decided to create a similar setup to the one we used yesterday. Instead of the monorail inter-city connection we used busses and a highway this time. Before you build a bigger bus station (lets say a station having more than two bus stops) you should be aware of the following (rough) facts:

1. A bus station can consist of 16 bus stops only, not more.
2. Drive-through road stops are not supporting the queueing features (finding the next empty stop). Busses will act strange if you use them: i.e. queueing up, ignoring other (free) drive-through stops and causing terribly jams.
3. If you are using LV4, the best bus is `Leyland Olympian` and beyond 2020 the `Dolphin Intercity Bus` (vehicle details).
4. Busses slowdown at curves.

Bus Stations

Planetmaker and I experimented a lot with several different layouts of bus stations. Unluckily we did not find an optimal and highly efficient station layout. This is caused by the facts that drive-through road stops cause the bus drivers to go crazy (driving infinite loops, stopping at stations and whatnot) and the standard bus stations are not heaving such a high throughput (joining and leaving takes too long). The layout shown above is probably the most effective so far (until devs develop better features). If a station is crowded all stops will be used, the busses hopefully don’t queue up and if something went wrong the backup loop can correct the mistake. For the better structure, the station follows the principles of RoRo-stations. You can test terminus style too, but don’t employe any drunken bus drivers. Thanks.

Highways

Its questionable whether highways must consist of two one-way roads or not. Since all the busses will have the same speed, it is highly unlikely that they will ever overtake. Though we used them for a better structure. In the beginning of the game I doubt thats its necessary. Building 200 tiles of road costs approximately 100.000$. The double amount could cause a time of struggling in the beginning. In my opinion it is much more important to build straight road. Avoiding too many curves is much better, because busses slow down heavily.

Intersections / Junctions

Again we experimented a lot. And came to the conclusion that it is not necessary to build difficult and complex junctions. Road vehicles are more flexible than trains, the no-clip mode is turned on and in most cases they pass an intersection really smoothly. Thinking competitive (maximizing the profit) it is better to build a simple junction, because:

• Its definitely cheaper
• Its definitely built faster
• Its as effective as complex junction

A Simple Crossing you should prefer.

The only case when more complex junctions are better is when eyecandy comes into play.

If you’ve read this article you are ready for the competition against NoAI.

We had some troubles with a first start on a small (256×256 tiles), crowded map. The AI died after very short time (where both we and the AI were approx. performing equally well). Unfortunately an AI cannot be re-vived after it crashes. Then we decided to go with a passenger only game on a slightly larger map: 512 tiles squared and no industry, only NewGRF in use was LongVehicles which allows decent busses. Starting year was 2000.

After some initial discussion about the map we decided to go for a ICE / S-bahn concept and picked two areas which we wanted to start with. In order to match somewhat the building speed of the AI we assigned the different areas (terminal1, terminal2, s-bahn1, s-bahn2, intercity connection) to different people and then we unpaused the server to start.

And it didn’t look well in the beginning for us coopers. We managed to build the two ICE terminals with one train and barely some basic feeders to them. Money was scarce and the AI was already making good money. Slowly though the feeders grew and the train(s) started to generate considerable revenue. Once the trains ran fully loaded between the ICE terminals, our revenue sky rocketed and after three years we had about twice the income of that of the 2nd best. Soon then we developed a 3rd and 4th metropolitan area with each its own ICE terminal and feeder system, providing good service and thus also taking passengers from the AI competitors.

Company value of the companies. Coop as usual in orange, AdmiralAI in pink

Company revenues

After the 5th year we decided to stop the game as the winner was clear and our motivation to started to drop – probably also due to the hour of the day

It has to be noted though, that the AIs only worked with busses while we generated our income from long distance, high velocity (305 km/h monorail) trains. Therefore our transported distance was on average further while the speed certainly wasn’t slower.
Another thing worth noticing is the user interface to giving orders. If it comes to a time efficient system the mouse only interface started to really slow us down, especially in the 2nd half of the game where we were generating more money than we could spend jointly together. So, if someone has some good ideas and also an idea how to implement it: please! Very much welcome so.

Saves from the games are available here, the final save is this.

Company performances

Our income table after five years of playing

Despite the fact that we won this game – difficulty will be harder on a smaller map as we saw in the first, crashed test game. Also, of course, we profited a lot from good co-ordination, using teamspeak a lot and some advance planning before the game started. One player alone couldn’t have achieved what we did – this was coopetition at its best . And it’s a lot of fun to play against competent opponent AIs who just build sensibly and don’t destroy the landscape. Let’s hope for a future where the AIs might even get stronger and both, the AI (developers) and we, might learn from eachother!

See more screenshots here (by dihedral).

Please feel free to join, open your company or join an existing one (don’t use individual company pw here. Server has maybe pw ‘coop’ or no pw) and extensively test this feature. Besides being a really nice feature for the usual multiplayer games, giving them a completely new dimension, this patch is, if tested successfully, also a nice, big step forward to maybe a next incarnation of the next wwottdgd (World wide OTTD gaming day) with much more than just 10 clients connected – a real co-opetition event .

So far available: r13031IS.diff, linux binary (32bit), OS-X (intel) binary and Win binary

The patch setting “When dragging, place signals every: X tiles” should always be set to “2″ when playing on #openttdcoop, and most players will also use this setting if playing alone. If dragging signals, you will always have one piece of track with a signal on it followed by one without one and so on.

Now, if trains are jamming up somewhere in the network, for example behind a full station, those trains should block as little space as possible, so that they won’t for example block the mainline.

As you can see in the first screenshot, with signals every 2 tiles, the trains with tilelength 5 (left) fit almost perfectly in between the signals. However, the TL4-trains (right) always have a gap of more than one tile between them and need as much space as the TL5-trains. To fix that, you would have to place additional signals in the gaps, which might look ugly (especiall for straight track, see below) and is a lot of work, as you would have to do it manually.

In the first screenshot, you have seen what happens with diagonal track, now the second picture shows you that the effect is the same with straight track.

You can compare any odd and even tilelength, there will always be a greater gap at the even tilelength. This leads me to the conclusion that it might be better to use odd tilelengths rather than even ones, if nothing speaks against it.

There isn’t a big difference in carried cargo if using tilelength 15 or 13 instead of 14, but you will have a better usage of track space. To convince people to use tl 5 or 3 instead of 4 might be more difficult, as this makes quite a difference, however, i would still strongly suggest to always use odd tilelengths – maybe even in all #openttdcoop games? Tell me what you think!

I also created a wiki-article about it – have a look if you want!

Things that I consider most important for a cargo game is amount of units delviered on one side and running stock used to do it on the other. Profit in first place can be accounted for network performance and efficiency of routes, but it also affected by such factors as idle and stopping trains, efficiency of junctions, lane balancing, appropriate train length, sufficient width of mainlines. Essentially, what I am trying to say is that a good network “has just enough properly sized and shaped trains to carry as much cargo as needed”. And hence the criteria to define a good network would be something like: yearly_profit * delivered_cargo / number_of_wagons. I specificaly do not want to use train count and length due to the fact that these are part of network design and if network can cope with whatever is the amount while goals are being reached it doesnt really matter. At same time, if the number of trains is too high – profit will be hurting, since there will be jams and stops or idle trains that only waste money. If trains are too long – they will be loading for longer at stations and will require larger/more complex network, if they are too short – need more of them, and again more complex networking in a different way. Setting volume criteria such as delivered cargo yearly as the goal – eleminates it from rating calculation. So it can be as simple as profit / cars.

Passeger based games, in my opinion, have different goals and criterias. Effeciency of company can be defined by reach of pax network and amount of delivered happy customers. By “reach” I imply ratio between transfered and possible passengers (and mail in case if that is rulled in). Say a city can produce X amount of passengers per month, a good network would be one that moves as close to X as possible and makes as much money as it can in that process. This gets more complex with increased size or number of towns, especialy with obstacles such as unfriendly landscape, authorities or set rules. Delivered – is same as for cargo game – units yearly, while happy – promply movied to destionation and as result well paying. Hence, the efficiency rating can look like: sum(transfered_passenger_per_city/possible_passenger_per_city) * yearly_profit * delivered_cargo / number_of_wagons. And in case if delivered cargo used as an game end criteria: sum of passenger ratios * profit / cars

A special note on counting cars – for railroad these are cargo wagons as well as engines capable of carrying something, For road vehicles it is a simple head count aside of articulated ones – where each wagon should be counted (only affects some trams at this time). Despite the fact that road vehicles seem less profitable than trains, if counted per car/wagon and used appropriately they both can be efficient and contribute to score close to equaliy, especialy for pax games.

All this only makes sense if apples are compared to apples: same map, same train set, regulated network features (track sharing and number of drops). I did some studying of games I have at hand, especialy these that I have different version of (I like continuing to optimize public games sometimes, which did not exhaust all posibilities to improve in my opinon). And there are other factors to be considere if scores are to be compared across diferent landscapes, shapes, network and rail types. For example. such important characteristics as average vehicles speed fgor trains is factored into profit already, where as maximum speed can be used to debunk game results based on faster vehicles so scores can be comprated across different types and sets.

The exact rules for competative gaming are yet to come, hence scoring also remains without strict definition, this is a start of conversation on what coopetition might look like eventualy.

Phazorx and I were discussing this, and I wanted to open it up to other suggestions.

Our ideas:

The game would be a medium sized map with two identical continents. Each team would have a different continent, and they would try to build rival networks of the same type (freight v freight, pax v pax, combo v combo). For this to work, we need to make a ‘score’ system. This is some formula that will take into account differences between each team’s network and then work out which one was the best. We thought that the formula should take into account:

Yearly profit in last game year.
Number of Vehicles.
Cargo delivered in last game year.
Flow and visual appeal of network.

If anyone has an idea of a formula we can use. Please post it.

Also, my main thought was that unlike previous coopetition games that were run for a period of two hours or so,

this would be a much longer game. Running till about the year 2150-2200 in game. Also, its my idea that every
‘usual suspect’ and member be assigned a team before the start of the game, even if they dont play, it gives some
indication of who should be on what team when they join the game. It should be an even mix between skilled and new players, as well as taking into account who is online at what times usually. Its no good if the teams are equal if
you can only get one online at any one time.

Finally, there should be a rule about no deliberate interfering with the other team’s network. I know that removes a bit of the fun, but I’d like this game to be about network design, so players spend their time building their own
network instead of trying to ruin the other team’s.

For this to work, there will need to be some set ‘Judges’ who can keep an eye on players. It would probaly be best if they joined the game as spectators, then all players could agree that the Judge wasn’t helping one team build or something like that.
I think that if we can get people interested in this, it can be one awesome game of OTTD.

What does everyone think?

There are already some patches for our purposes around. Additionally, there is this wiki-page dedicated for ideas to be implemented within this branch. Feel free to join our IRC-Channel and report your ideas!