This article covers questions regarding development of OpenTTD, e.g. source code, setting up compilers, etc..
Contributing to the project
What can I do to contribute to the project?
This depends on your talents.
- Without coding
- Translating to other languages
- Extend this Wiki, or better: Update out-dated stuff.
- Graphics, sound and music: If you draw stuff, but you can't code; check out the forums for some project to contribute to. Note: If you do not cover all skills required for some project, it's smarter to join an existing project, than trying to find someone else to join your new project.
- Add-on coding:
- Main-game coding (C/C++):
- See below.
- Tool-chains for Add-ons (mostly python):
How to get in contact with people
Checkout the Community page for links to the various forums and platforms for each subject.
How does open-source work? What to expect from people?
As general advice, if you are new to open-source: Consider the different interests of people in the project. Don't expect people to have rational goals, or to share interests with you. Even if you seem to work on the same thing, some people are mainly interested in the result (what to do?), while others are mainly interested in the path towards some result (how to do something?).
This applies to both "inoffical add-ons" as for the "official branch": This is a volunteer project; everyone is here for fun, not for obligations. Some people develop stuff with the expectation that official maintainers are obliged to look at their stuff and include it into the main branch; but the truth is that people will only look at stuff when they are interested in it.
In every volunteer project you will find posts like "this patch has been around for 10+ years, I want it so badly, why is it still not in the main branch?". But don't let that spoil your fun :)
Contributing to the main game
Want to contribute? Great!
- We have a guide: Contributing to OpenTTD
What are the goals of the offical branch?
The main goals of the offical branch are:
- Replicate the original gameplay.
- Improve the user interface.
- Allow extending the gameplay with add-ons.
In contrast, extending or altering the gameplay of the base game is not encouraged.
The rationale behind these goals is that people have different opinions about what OpenTTD is and what it should be. When it comes to gameplay, there are at least these groups of people:
- Model railway (mostly singleplayer): Build "realistic" landscapes, roleplay a world, or even replicate historical scenarios.
- Economical challenge (mostly singleplayer): Run a business with economical challenges.
- Transport challenge (singleplayer or cooperative multiplayer): Build efficient track layouts with high cargo throughput and tons of vehicles.
- Competitive speed run (competitive multiplayer): Maximize some goal in some limited amount of time.
When it comes to gameplay features there are at least these groups of interests:
- Control freak: Micromanagement like conditional orders, refitting and loading, ...
- Casual: Automatisation like cargodist, path based signalling, ...
To please everyone, the official branch tries to stay close to the original gameplay; after all, that is what everyone brought here. The preferred method to alter and extent the gameplay is via add-ons like NewGRF and GameScripts.
For the longest time, the official branch was also open to features which could be enabled/disabled, but the corner-cases that came with some configurations have rendered some parts of the code very complicated. Today, new features have to work with all the already existing features, which is not only challenging in corner cases, but also requires spending considerable more work than just "making it work in the game mode that I play".
The preferred method to allow gameplay extensions is to extent the add-on interface. This moves conflict-solving away from the codebase to the player picking from the add-on options. It is more accepted for add-ons not working together than the base game not working with certain setting combinations.
In general the game should allow anything that doesn't violate basic rules, but it should warn players if they take potentially dangerous or "stupid" actions. For example, players are not prevented from starting vehicles without orders, but will receive a warning about vehicles having too few orders. This lack of limitation has led to players challenging themselves to create networks where all vehicles have no orders, increasing gameplay possibilities.
I do not agree with the goals of the offical branch, what can I do instead?
There exist many "patches" for the main game which add "gameplay features", which are often combined into patch packs. If your interest is in altering the main game in C/C++, you will likely find your home here.
The predominant version control system in this area is git. You may want to check out tt-forums development section for other people in this area. At the time of writing, "JGR's patch pack" is a good source for finding maintained patches to orientate at.
I've fixed a bug / added a feature. How can I submit it to the codebase?
I want to become an official OpenTTD developer! How?
- This is a matter of trust. OpenTTD has many complicated and arcane mechanics with lots of corner cases. You can join the official team by proving that you fix more than you break.
- The best way to get started is by fixing small things, either from the GitHub issues, or things you find yourself. Submit Pull Requests for these. We do try to review all pull requests, especially from new contributors, but sometimes it takes a while before someone gets to it.
- Nearly all official communication is via GitHub, or in irc channels, joining irc regularly is the most effective route to becoming a long-term contributor.
What is source code?
- Source code is the uncompiled version of the program, or in this case OpenTTD, which enables the developers to make changes to the game.
- If you are unfamiliar with source code, then we suggest starting off with a C++ tutorial.
How can I obtain the source code?
You can also obtain the source via tar balls, but avoid this, if you can make use of a VCS:
Now I have got the source code how can I compile it?
To test the compiler setup, try compiling the game from source code without applying any patch (see below), and run the resulting executable. If all goes well, you can be fairly sure the setup is good. If it fails, you know for sure the patch is not the source of the problems.
I had a problem compiling! What should I do?
- This is not a compiling FAQ. Try to ask your compiler vendor for help.
How do I create a patch?
- See the guide in Contributing to OpenTTD