The idea of a drawing or draw-on-map feature was floated in 2009, generated a flurry of interest, and went dormant due to lack of focus. Let's see if we can provide some of that missing focus and detail.



Needs and use cases:


Whether solo or multiplayer, we need to plan out what we hope to do. Currently, there are about 3 ways to do this:


New players need to have the game explained in detail. Even if we think we don't care, it's in our best interest to provide docs. Wordy explanation is only intelligible if you already understand the game; a bare shot rarely tells enough; so current docs are mostly generated by shot-and-edit.

This is workable but now flexibility becomes a liability. It's difficult to maintain consistency across multiple drawings. Because various editors provide various tools, which various players use in various ways, all the doc shots come out looking different.


OpenTTD crams an enormous amount of detail into a few pixels. A single tile may contain a road, a streetcar track, parts of two road vehicles, a streetcar, a ro-ro truck stop, and part of a town sign, not to mention streetlights, catenaries, trees, and a plume of black smoke coming from one of the vehicles. These are not all mere trimmings; they convey important info about the game.

Besides visible, concrete attributes, the tile has invisible, abstract attributes. It may be part of a certain route between cities, say; a tile owned by town, company, or competitor. Oh, and don't forget that when you view that tile with buildings opaque, the entire scene may be obscured by the tops of two or three office towers.

Most readers of this page will not fully appreciate this level of complexity. But then, only a certain type of person plays OpenTTD for long: extremely intelligent, skilled, abstract thinkers. We may have difficulty being humble enough to admit that we are ever confused about anything.

We do get confused, though; and while we are always able to figure out the situation eventually, the confusing situation may remain. The next time we encounter it, we might have to figure it out again. This issue is common in software engineering and has a commonplace solution: comments. While some hackers disdain all comments, others understand that well-commented code is very good and some comments better than none at all.

Playing a game of OpenTTD is essentially a computer programming task; the savegame represents the program. Currently, there is exactly one commenting tool available: the free sign, plain text in one style. It's not even clear where it's pointing.

City beautiful

Many NewGRF sets exist mainly for beautification; they add no new function to a game. This is not wrong; rather, it shows that there is considerable desire for attractions of one sort or another. Usually, a NewGRF set is the right way to add new graphics that combine with function, such as a new vehicle or industry type.

But a player may just want to make a small and specific alteration to the appearance of some tile or area in one game. These edge cases are relatively rare but, this being a game of many interactions, there are many edges, many opportunities for a special case to crop up.


OpenTTD development is a spare-time activity. Grand overhauls are less likely to be taken up. Fuzzy ideas have little merit compared to detailed proposals. Drawing needs to be a specific feature and as simple and small as possible while meeting needs.

OpenTTD gameplay is already quite complex; the new player can expect some hours of study before puzzlement starts to recede. A new feature must require little additional study for the player to become competent in its use; the reward should be immediate and significant.

Drawing must not put an additional large burden on processor time, memory, or disk space. Drawing interface must not demand excessive screen area.

Savegames with drawing layers should not be incompatible with those without. This is perhaps a minor consideration.



The keyword must be minimal. Nonessential subfeatures cannot be thrown in. Each subfeature must be justified against a mainstream use case.

Drawing Toolbar

This is the main user interface to the drawing feature, equivalent to the Railway Construction toolbar.

Button Name Description

img Edit Standard editing functions to and from clipboard
Cut copies selection to clipboard and clears it from the drawing
Copy (default) copies selection to clipboard
Paste copies clipboard to drawing, to selection if any
Clear clears selection from drawing