本帖日更

起床了

简明版：
请先复习英语阅读方法。
·善用翻译软件，但不要过分相信：Mindustry以英语为基本载体，一些简单的英语单词就是小学水平，翻译软件足以搞定。但同时要小心，如果这个词不是单一义项的，或者你压根查不到，或是你感觉义项驴唇不对马嘴，那只能说明这个翻译软件搞不定。如果是多义词或是较为少见的词，百度没收入还好，要是计算机用语或干脆是anuke造的，自求多福罢；
·了解一些计算机用语：定义是用来简练语言表达的，所以当别人使用术语交流时，请记住他不是在炫技，而是更快速精准地表达意思。对于初学者而言，知道java中的包、类、对象、字段、继承、类型，知道json的键值对、键名、键值，知道java字段名和json键名的关系，就足够了。
·清楚目录结构中每个的作用：目录结构是用来让人更清晰地寻找到需要的文件，如果仅仅是全平铺在core/src/mindustry，程序完全可以跑，甚至会加速和精简，但却会使维护变成地狱，所以明白目录的作用是至关重要的。
·Mindustry依赖于Arc！：写java的尤其要注意，Core这个对象是Arc的，绘图方法大多数也是Arc的，面向安卓开发还需要注意一些java方法要用Arc的，永远不要忘记这个！
这只是理论的简明版，下面还会介绍每一个目录和文件的作用。

顶可惜社畜只会vba

说好日更

下载源代码的方法
1. 使用Github下载
Github是一个源代码托管平台，通俗来说就是放源代码的，Mindustry的代码正是托管于Github，所以我们可以直接从Github下载源代码。
首先，我们打开网址https://github.com/Anuken/Mindustry ，这就是Mindustry项目的网址，接下来，直接点击大大的“Code”，然后点击“Download Zip”即可。
如果你是手机端，或是压根打不开Github，则可以使用直链下载：https://github.com/Anuken/Mindustry/archive/master.zip，正常来说你还是打不开，这时我们则需要加速，打开ghproxy.com，将上文直链复制进去，应该就可以下载了，注：不考虑速度。
2. 使用Git下载
如果你是个日用CLI的怪物或者想要一份可以编译的版本，需要使用此方法。注意：编译改端必须有桌面端系统，Windows请自行寻找Windows的Git。
直接运行 git clone https://github.com/Anuken/Mindustry.git
如果clone失败，可以把github.com换成hub.gitfast.xyz或hub.gitfast.tk

然后呢

20万的文件何年马月才能全部看完

有无人知道mod的sprites的游戏内加载路径

楼主更新太慢了，我替楼主更新一个开发指南吧。源文件为主目录的CONTRIBUTING.md

# Contributing
# 指南
This is for code contributions. For translations, see [TRANSLATING](TRANSLATING.md).
开发指南，翻译请阅读(TRANSLATING.md)
## Basic Guidelines
## 基础指南
### Use an IDE.
### 开发环境
Specifically, IntelliJ IDEA. Download the (free) Community Edition of it [here](https://www.jetbrains.com/idea/download/). Some people use other tools, like VS Code, but I would personally not recommend them for Java development.
使用IntelliJ IDEA开发。在这里下载免费的社区版(https://www.jetbrains.com/idea/download/)
有些人可能更喜欢使用其他的开发工具，比如VS什么的，但我个人不推荐使用它们进行Java开发。
### Always test your changes.
### 坚持测试你的代码
Do not submit something without at least running the game to see if it compiles.
If you are submitting a new block, make sure it has a name and description, and that it works correctly in-game. If you are changing existing block mechanics, test them out first.
在成功编译一次之前，不要提交你的代码。
如果你想提交一个新物品，请确保它有名字和描述，并且能够在游戏中正确运行。如果你要改变现有物品的机制，首先测试它们。
### Do not make large changes before discussing them first.
### 讨论前不要进行大的更改
If you are interested in adding a large mechanic/feature or changing large amounts of code, first contact me (Anuken) via [Discord](https://discord.gg/mindustry) - either via PM or by posting in the `#pulls` channel.
For most changes, this should not be necessary. I just want to know if you're doing something big so I can offer advice and/or make sure you're not wasting your time on it.
如果你非常想添加一个庞大的新游戏机制/地貌或者想更改大部分代码，请在[Discord]与我(Anuken)联系
这是连接(https://discord.gg/mindustry) - 要么通过PM要么在"#pulls"频道发布
对于大部分更改，这是没有必要的。我只是想知道你是否打算干一件大事，以便给你提供建议，或者至少可以避免你浪费自己的时间(去做一件不可能/无意义的事)。
### Do not make formatting PRs.
### 不要做格式PR(GitHub术语 Pull Request 请求合并分支)
Yes, there are occurrences of trailing spaces, extra newlines, empty indents, and other tiny errors. No, I don't want to merge, view, or get notified by your 1-line PR fixing it. If you're implementing a PR with modification of *actual code*, feel free to fix formatting in the general vicinity of your changes, but please don't waste everyone's time with pointless changes.
没错，这里有很多尾随空格、额外的换行符、空缩进或者别的微小错误。但我不想被你的一行PR通知修复、查看，然后合并它。如果你是通过修改“实际代码”来实现PR，你可以自由地在你所做的更改附近修复格式，但请不要在无意义的更改上浪费所有人的时间。
## Style Guidelines
## 风格指南
### Follow the formatting guidelines.
### 遵循以下格式
This means:
- No spaces around parentheses: `if(condition){`, `SomeType s = (SomeType)object`
- Same-line braces.
- 4 spaces indentation
- `camelCase`, **even for constants or enums**. Why? Because `SCREAMING_CASE` is ugly, annoying to type and does not achieve anything useful. Constants are *less* dangerous than variables, not more. Any reasonable IDE should highlight them for you anyway.
- No underscores for anything. (Yes, I know `Bindings` violates this principle, but that's for legacy reasons and really should be cleaned up some day)
- Do not use braceless `if/else` statements. `if(x) statement else statement2` should **never** be done. In very specific situations, having braceless if-statements on one line is allowed: `if(cond) return;` would be valid.
- Prefer single-line javadoc `/** @Return for example */` instead of multiline javadoc whenever possible
- Short method/variable names (multipleLongWords should be avoided if it's possible to do so reasonably, especially for variables)
- Use wildcard imports - `import some.package.*` - for everything. This makes incorrect class usage more obvious (*e.g. arc.util.Timer vs java.util.Timer*) and leads to cleaner-looking code.
Import [this style file](.github/Mindustry-CodeStyle-IJ.xml) into IntelliJ to get correct formatting when developing Mindustry.
包括：
- 括号周围不要有空格
正确示范: 'if(condition){`, `SomeType s = (SomeType)object'
错误示范: 'if(condition) {`, `SomeType s = (SomeType) object'
经过观察，运算符前后是可以有空格的。
- 括号在同一行上(应该不包括{}，此外的括号全部都在同一行上)
- 四空格缩进(而不是tab，这样可以有效避免在不同环境导致的缩进问题)
- 驼峰命名法，**即使是常量或枚举(也应该用驼峰命名法)[类名的首字母应当大写]** 为什么？因为下划线风格命名奇怪且繁琐，也没有任何益处。
定数比变数带来的危险要小，任何开发环境都应该为你高亮它们。
- 不要使用下划线。(是的，我知道' Bindings '违反了这个原则，但这是由于遗留原因，确实应该在将来的某一天清除)
- 不要使用不带括号的'if/else'语句。任何类似于'if(x) statement else statement2'的代码都是被严格**禁止**的。在非常特定的情况下，
允许在一行中使用不带括号的if语句，如: 'if(cond) return;'
- 任何时候，优先使用单行的javadoc注释，示例: '/** @return for example */'
而不是多行的javadoc注释，示例:
'/**
* Loads all game content.
* Call load() before doing anything with content.
*/'
- 方法/变量的名称应当精简(如果可以的话，尽量避免使用复合名称，尤其是变量)
- 使用通配符导入，示例: 'import some.package.*' 任何时候，这样做能使类的错误用法更加明显，代码更加简洁。
在开发minindustry时，将[此样式文件](.github/ minindustry - codestyle - ij .xml)导入IntelliJ以获得正确的格式。