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

Needs and use cases:

Planning

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

• Draw on paper: Pros: Proven technology, highly extensible, almost infinite flexibility; requires no development. Cons: Requires printer to get from game to plan; requires scanner to get from plan to screen; no ability to display as overlay when building ingame. Not easily shared with other players.

• Screenshot editing: Take a screenshot and edit it in your choice of raster graphics editors, such as Photoshop or GIMP. Pros: Fairly easy to get from game to plan, easy to share with other players; great flexibility; requires no development. Cons: No ability to display as map overlay. Somewhat clumsy; requires skill, external dependencies.

• Keep it upstairs: Keep it all in your mind; share with other players by talking with words. Pros: Free; weeds out the weenies. Cons: You may forget; others may not understand.

Documentation

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.

Commentary

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.

Considerations

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.

Design

Subfeatures

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.