Crates On New Vehicle Expressways Yield Outrageous Riches But Exhaust Less Toxic Smog
Background
Recently I was working on adding a couple basic roadtypes to Wasteland, when I got the idea to make something a little different. The way gameplay works in Wasteland, it is often necessary to create short road vehicle routes to properly disperse cargo to nearby towns or industries, but making a 20-tile road with a string of trucks can look and feel a bit ridiculous. I thought, "Why can't there just be some kind of conveyor belt or something to make that short delivery?". I'm sure the idea of having Factorio-style conveyor belts in OpenTTD has floated around for quite a while, but as far as I know has never actually been done. Having cargo "magically" slide along a non-moving belt just looks silly, and I think the lack of ability to make true animated belts has been a big reason for the idea being disregarded.
However, after thinking on it for a bit I got the idea to (ab)use palette animations to fake this movement, and started experimenting. To my surprise, there are in fact at least 3 different palette cycles in the TTD palette which propagate at a decent enough speed to make this feasible. With the recent inclusion of Roadtypes into OpenTTD, there now also exists a way to force one-way directional travel by means of having each "lane" as a belt moving in one direction. This would have previously only been possible with railtypes, but since rails don't have directionality, having directional movement would have required two railtypes and unintuitive building methods to force "trains" to go the "correct" direction.
This implementation of conveyor belts uses three new Roadtypes using different palette animations to create the illusion of three different speeds of belts at 20mph, 40mph, and 80mph (this is, conveniently, how fast each chosen palette cycle propagates across a distance of one tile). To keep the jarring nature of the palette cycles suppressed, these roadtypes utilize 32bpp capabilities to suppress the brightness of each cycle, making them a little easier on the eyes. It may be possible to reduce the color even more to achieve something slightly more realistic, but I kind of like the colors to break up the otherwise drab gray belts. On that note, I only textured the middle one because it looked the worst initially. It turned out to be more work than I wanted to put into it for now though, so the other two I've left plain, but they could be improved later if there's interest.
Since making all three belts, I've also started to reconsider including the middle speed belt at all, mostly because it is the ugliest one to watch due to the palette cycle, but also because of it's dubious gameplay usefulness. But, I spent a lot of time making that one work visually so I've left it in for now! I also wanted to do 4x zoom and left-hand drive versions of all the belts, but decided to wait until I get feedback on the general concept, as those will be a lot more work and I'd rather not get burnt out doing something that turns out to be pointless!
Limitations and Reason for "Crates"
To go along with these new roadtypes are a set of new vehicles, or "crates". Now, anyone familiar with Factorio knows that the cargo itself travels along the belts, it does not require the use of containers. Initially I wanted to do something similar (i.e. Coal would be represented by a lump of coal, Livestock would be a cow, etc), however this comes with some issues. First, and most obvious, is that there are tons of cargos in OpenTTD. By my count, assuming the wiki is up-to-date and not including deprecated or "special" cargos, there are about 108 unique cargo labels defined by various industry sets. That is a lot of "vehicles" to draw, and making them all look unique especially at 1x scale would be difficult, especially since not all industries use those labels with the exact same cargo in mind.
However, an even bigger issue with this idea is how vehicle movement works. Unfortunately, the vehicles in OpenTTD change their shape and size as they go around corners, which masks the fact that they are not travelling in smooth lines. When making a vehicle of a single sprite and trying to make it smoothly and sensibly navigate a roadway, it instead jerks forward and backward in every corner, almost like it is doing a three-point turn.
This effect looks horrible, and completely breaks the illusion of a piece of cargo travelling effortlessly on a belt. The only solution I could come up with was to use crates instead of showing the cargo directly, this way the crates could turn when going around corners which helps to mask this jerky vehicle movement. This problem also foils the idea of using barrels for liquid cargos since, being round, they will effectively look the same in all directions, which brings up the same issue (and no, I don't count barrels lying on their side as a valid solution :P).
The result is that all cargos can instead be represented by crates, which besides being easier to draw initially, still allows for representing the cargo they carry, either through logos on the sides or in the case of liquid crates, by making them see-through in some way to show the color of liquid they carry. Yes, static units of cargo seamlessly moving around on a network of belts looks much cooler, but unfortunately game mechanics forces a compromise here, and rotating crates was my best solution (and why there's no barrels!)
I'm sure some people will disagree with that decision and insist the vehicle movement isn't a big enough issue to warrant removing the individual cargos as vehicles, but I felt it best at least for now. And it can always be added later as a new vehicle set if someone really wanted it.
Vehicles and Costs
To go along with the three types of belt available, there are also three variations of both the regular and liquid crates. Currently these are only drawn in 1x zoom so the non-liquid crates do not visually show what cargo they carry (this is impossible at 1x scale), but it is planned to eventually include 4x zoom sprites which will be capable of displaying an icon of the type of cargo they carry. As a complement to this cargo display capability, a new feature I thought I'd experiment with is making empty vehicles appear "ghosted", or slightly translucent, to distinguish them from crates which are fully loaded. Currently this ghosting effect is applied to any crate with less than half load, allowing you to quickly see at a glance which vehicles are travelling loaded and which are not, which helps in spotting potential issues in your network. This feature is experimental and may or may not change depending on how people react to it.
Keeping with the experimental nature of this set, as a departure from the standard model of costs, and in an effort of "realism", the vehicles themselves actually cost nothing to operate, although are very expensive to buy. Instead all of the operating cost is carried by the very high maintenance cost of the belts themselves. Being that these belts are mostly intended for short distance routes, the cost of initially building them is also exceptionally high. Due to the nature of maintenance costs growing proportionally higher with more infrastructure, and the steep initial cost of purchase, the hope is that this will promote smaller, denser networks of belts to maximize their effectiveness, rather than spamming them everywhere and travelling across the map. Some additional future balancing and tweaking of costs may be necessary to help achieve this, but no matter what, once you inevitably have near-infinite money, nothing will stop people from doing that anyway.
Known Issues
Now, this cost issue brings up some important points already mentioned in the release post, the first is maintenance cost. It is a setting. That can be turned off. I don't think I need to spell out for you how that can obviously be abused! This is an issue, but it is ultimately up to the player to decide how they want to use this set. It is intended to be used with maintenance costs turned on; but if you choose to ignore that and instead use these as what is effectively a cheat device, then that is your choice. Ideally I would be able to detect this setting to change the way costs work to prevent this exploit, but sadly that option does not exist. So play fair!
Second, this brings up an interesting issue with multiplayer. Since all of the cost is carried by the infrastructure, which has to be built by someone, which is coded as a roadtype, and roads can be used by any player....you get the point. It is easy to abuse this, so again, player attention (especially in multiplayer!) is necessary to avoid paying for a network that allows anyone else on the map to have free profits. This does open an interesting possibility with builder AIs or even some type of co-op play, but I'll leave that for you to figure out!
Well, I think that pretty much covers it, if you still have any questions or concerns drop me a line on tt-forums!