![]() Basic class functions, (de|con)structors Most game classes are found here and loosely follows this convention: The source uses automatic documentation (Doxygen) - use it!Īll game source code is located under (openttd)/src.Many typedefs, macros, and other preprocessor-fu.Custom substitutes for common STL elements: map, list, vector, set, etc.Generic programming heavy - know your templates.Some concurrency: Understand mutex locks and critical sections.Some system-dependent code for (Windows, Linux, and MacOS).Several 3rd party libraries and frameworks (Cocoa, Allegro, SDL, etc).Inheritance hierarchy (OOP) favored over components (ECS).No cutting-edge C++ features (C++11 and later).But since it's not broken.Īfter sifting through the source code with several more greps, I had a good idea of what to expect: OpenTTD at first glance I'll be watching to see if evolving C++ standards lead them to reconsider this approach. This is one of the more interesting parts of this codebase. The reason is that the OpenTTD developers rolled their own type-safe implementations and didn't bother with STL. You may be shocked to see only 164 references to the STL in a project of this size. ![]() Just for fun, let's take a look at the STL components we may run across: An anecdotal test is to see if 'printf' is favored over 'cout' in the source. The original developers likely favored C and are probably just using the most useful features of C++ (i.e. Notice that many of the include directives use the C standard header names. This is a good sign that we're dealing with basic C++ features. The results show that all headers are prior to C++11. Another quick method is to scrape the code for the system includes. Knowing the presentation simplifies digging through the code, especially when using regular expressions.Ĭ++ has been constantly evolving for over 30 years, so we should try to understand which era of C++ and its features that we're dealing with. But before digging any further, I highly recommend reading the developer's style guide to understand how the soft rules for code presentation. A handful of other files comprise the system-dependent code (INI=Windows, Bash/awk = Linux/Unix, ObjC++ = MacOS). (cloc is a utility for counting lines of code) Let's start with some easy questions: How much code is there? What language(s)? Which variant of those languages? What style rules are enforced? Goal: Review the code to determine prerequisite knowledge Let's take a cursory look at what we're dealing with After that, we can execute the binary as shown in the screen shot at the top of this page. We have to pull those assets from the website, then extract them in bin/baseset. The OpenTTD source code is not distributed with graphics or sound assets. Note: All shell commands issued from $(openttd)/src Otherwise, the following command sequence was enough to get the source code up and running: Since Fedora is closest, I made sure that I had those dependencies covered. I was pleasantly surprised that the code was able to build with no effort, despite my CentOS system not being on the list of supported distros. For reference, here is the official repo that I pulled this version from. Much of the code base has stabilized and I expect that most of what we learn from 1.8 will remain true going forward. All code analysis will apply to only this version. I've fetched the recent public release (v1.8) and created a personal GitHub repo. ![]() I hope to make this as useful as possible in two weeks of decoding effort against a project that dozens of professionals built over the last 15 years. I'm looking at the code base with fresh eyes in order to relate my learning approach with beginners who struggle to dig in to similarly large projects. These guys are the heroes behind this project so please give credit where it's due. Above all, this exercise should be transferable to other projects.įull Disclosure: I am not an OpenTTD contributor, nor am I a community member. Instead, I will pick and choose the key ideas that an aspiring contributor may want to dig in to. It's not practical to take apart over 200,000 lines, especially for an actively developed project. ![]() This project deviates from my usual practice of documenting every line of code.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |