Merge pull request #1661 from lawsonry/faq-copyedit

Proofread and copyedit the FAQ page to make it more user-friendly

about/faq.rst

@@ -6,27 +6,26 @@ Frequently asked questions
 What can I do with Godot? How much does it cost? What are the license terms?
 ----------------------------------------------------------------------------
 
-Godot is Free/Libre Open Source Software available under the `OSI-approved <https://opensource.org/licenses/MIT>`_ MIT license.
-
-This means it is free as in "free speech" as well as in "free beer".
+Godot is `Free and Open-Source Software <https://en.wikipedia.org/wiki/Free_and_open-source_software>`_ available under the `OSI-approved <https://opensource.org/licenses/MIT>`_ MIT license. This means it is free as in "free speech" as well as in "free beer."
 
 In short:
 
-* There are no usage restrictions on Godot
-* This means you can use it for any game or application, commercially or non-commercially, in any industry
-* You can modify, (re)distribute and remix Godot to your heart's content
-
-For more, see `here <https://tldrlegal.com/license/mit-license>`_ or ask your lawyer of choice.
+* You are free to download and use Godot for any purpose, personal, 
+non-profit, commercial, or otherwise;
+* You are free to modify, distribute, redistribute, and remix Godot 
+to your heart's content, for any reason, both non-commercially and commercially.
 
-All the contents of the documentation are under the permissive Creative Commons Attribution 3.0
-(`CC-BY 3.0 <https://creativecommons.org/licenses/by/3.0/>`_) license, with
-attribution to "Juan Linietsky, Ariel Manzur and the Godot Engine community".
+All the contents of this accompanying documentation are published under 
+the permissive Creative Commons Attribution 3.0 (`CC-BY 3.0 <https://creativecommons.org/licenses/by/3.0/>`_) license, with attribution 
+to "Juan Linietsky, Ariel Manzur and the Godot Engine community."
 
-Logos and icons are generally under the same Creative Commons license. Note that some third-party libraries
-included with Godot's source code may have different licenses.
+Logos and icons are generally under the same Creative Commons license. Note 
+that some third-party libraries included with Godot's source code may have 
+different licenses.
 
-For full details, look at the `COPYRIGHT.txt <https://github.com/godotengine/godot/blob/master/COPYRIGHT.txt>`_
-as well as the `LICENSE.txt <https://github.com/godotengine/godot/blob/master/LICENSE.txt>`_ and `LOGO_LICENSE.txt <https://github.com/godotengine/godot/blob/master/LOGO_LICENSE.md>`_ files in the Godot repository.
+For full details, look at the `COPYRIGHT.txt <https://github.com/godotengine/godot/blob/master/COPYRIGHT.txt>`_ as well 
+as the `LICENSE.txt <https://github.com/godotengine/godot/blob/master/LICENSE.txt>`_ and `LOGO_LICENSE.txt <https://github.com/godotengine/godot/blob/master/LOGO_LICENSE.md>`_ files 
+in the Godot repository.
 
 Also see `the license page on the Godot website <https://godotengine.org/license>`_.
 
@@ -48,74 +47,91 @@ Which platforms are supported by Godot?
 * iOS
 * Web
 
-Both 32 and 64 bit binaries are supported where it makes sense, with 64 being the default.
-
-Some users also report building and using Godot successfully on ARM-based systems with Linux, like the Raspberry Pi.
-There is also some unofficial thirdparty work being done on building for some consoles.
-None of this is included in the default build scripts or export templates, however.
+Both 32- and 64-bit binaries are supported where it makes sense, with 64
+being the default.
 
-For more on this, see the sections on :ref:`exporting <toc-learn-workflow-export>` and :ref:`compiling Godot yourself <toc-devel-compiling>`.
-
-Which languages are supported in Godot?
----------------------------------------
+Some users also report building and using Godot successfully on ARM-based 
+systems with Linux, like the Raspberry Pi.
 
-The officially supported languages for Godot are GDScript, Visual Scripting, C# and C++.
-See the subcategories for each language in the :ref:`scripting <toc-learn-scripting>` section.
+Additionally, there is some unofficial third-party work being done on building 
+for some consoles. However, none of this is included in the default build 
+scripts or export templates at this time.
 
-Note that C# and Visual Scripting support is comparatively young and GDScript still has
-some advantages as outlined below.
+For more on this, see the sections on :ref:`exporting <toc-learn-workflow-export>` 
+and :ref:`compiling Godot yourself <toc-devel-compiling>`.
 
-Support for new languages can be added by third parties using the GDNative / NativeScript / PluginScript facilities.
-(See question about plugins below.)
+Which programming languages are supported in Godot?
+---------------------------------------
 
+The officially supported languages for Godot are GDScript, Visual Scripting, 
+C#, and C++. See the subcategories for each language in the 
+:ref:`scripting <toc-learn-scripting>` section.
+
+If you are just starting out with either Godot or game development in general, 
+GDScript is the recommended language to learn and use since it is native to Godot. 
+While scripting languages tend to be less performant than lower-level languages in 
+the long run, for prototyping, developing Minimum Viable Products (MVPs), and 
+focusing on Time-To-Market (TTM), GDScript will provide a fast, friendly, and capable 
+way of developing your games.
+
+Note that C# support is still relatively new, and as such, you may encounter some 
+issues along the way. Our friendly and hard-working development community is always 
+ready to tackle new problems as they arise, but since this is an open-source project, 
+we recommend that you first do some due diligence yourself. Searching through 
+discussions on `open issues <https://github.com/godotengine/godot/issues>`_ is a 
+great way to start your troubleshooting. 
+
+As for new languages, support is possible via third parties using the GDNative / 
+NativeScript / PluginScript facilities. (See question about plugins below.) 
 Work is currently underway, for example, on unofficial bindings for Godot
 to `Python <https://github.com/touilleMan/godot-python>`_ and `Nim <https://github.com/pragmagic/godot-nim>`_.
 
-GDScript? Why use a custom scripting language instead of my language of choice?
+What is GDScript and why should I use it?
 -------------------------------------------------------------------------------
 
-The short answer is that we think the additional complexity both on your side
-(when first learning Godot and GDScript) as well as our side (maintenance)
-is worth the more integrated and seamless experience over
-attracting additional users with more familiar programming languages that result
-in a worse experience. We understand if you would rather use another language
-in Godot (see list of supported options above),
-but we strongly encourage you to try it and see the benefits for yourself.
-
-GDScript is designed to integrate from the ground to the way Godot
-works, more than any other language, and is simple and easy to
-learn. Takes at most a day or two to get comfortable and it's easy
-to see the benefits once you do. Please make the effort to learn
-GDScript, you will not regret it.
-
-Godot C++ API is also efficient and easy to use (the entire Godot
-editor is made with this API), and an excellent tool to optimize parts
-of a project, but trying to use it instead of GDScript for an entire
-game is, in most cases, a waste of time.
-
-Yes, for more than a decade we tried in the past integrating several
-VMs (and even shipped games using them), such as Python, Squirrel and
-Lua (in fact we authored tolua++ in the past, one of the most popular
-C++ binders). None of them worked as well as GDScript does now.
-
-More information about getting comfortable with GDScript or dynamically
-typed languages can be found in the :ref:`doc_gdscript_more_efficiently`
-tutorial.
-
-For the more technically versed, proceed to the next item.
-
-I don't believe you. What are the technical reasons for the item above?
+GDScript is Godot's integrated scripting language. It was built from the ground 
+up to maximize Godot's potential in the least amount of code, affording both novice 
+and expert developers alike to capitalize on Godot's strengths as fast as possible. 
+If you've ever written anything in a language like Python before then you'll feel 
+right at home. For examples, history, and a complete overview of the power GDScript 
+offers you, check out the `GDScript scripting guide <gdscript_basics>`_.
+
+There are several reasons to use GDScript--especially when you are prototyping, in 
+alpha/beta stages of your project, or are not creating the next AAA title--but the 
+most salient reason is the overall **reduction of complexity.** 
+
+The original intent of creating a tightly integrated, custom scripting language for 
+Godot was two-fold: first, it reduces the amount of time necessary to get up and running 
+with Godot, giving developers a rapid way of exposing themselves to the engine with a 
+focus on productivity; second, it reduces the overall burden of maintenance, attenuates 
+the dimensionality of issues, and allows the developers of the engine to focus on squashing 
+bugs and improving features related to the engine core--rather than spending a lot of time 
+trying to get a small set of incremental features working across a large set of languages. 
+
+Since Godot is an open-source project, it was imperative from the start to prioritize a 
+more integrated and seamless experience over attracting additional users by supporting
+more familiar programming languages--especially when supporting those more familiar 
+languages would result in a worse experience. We understand if you would rather use 
+another language in Godot (see list of supported options above). That being said, if 
+you haven't given GDScript a try, try it for **three days**. Just like Godot, 
+once you see how powerful it is and rapid your development becomes, we think GDScript 
+will grow on you. 
+
+More information about getting comfortable with GDScript or dynamically typed 
+languages can be found in the :ref:`doc_gdscript_more_efficiently` tutorial.
+
+What were the motivations behind creating GDScript?
 -----------------------------------------------------------------------
 
-The main reasons are:
+The main reasons for creating a custom scripting language for Godot were:
 
-1. No good thread support in most script VMs, and Godot uses threads
+1. Poor thread support in most script VMs, and Godot uses threads
    (Lua, Python, Squirrel, JS, AS, etc.).
-2. No good class extending support in most script VMs, and adapting to
+2. Poor class-extending support in most script VMs, and adapting to
    the way Godot works is highly inefficient (Lua, Python, JS).
-3. Horrible interface for binding to C++, results in large amount of
-   code, bugs, bottlenecks and general inefficiency (Lua, Python,
-   Squirrel, JS, etc.)
+3. Many existing languages have horrible interfaces for binding to C++, resulting in large amount of
+   code, bugs, bottlenecks, and general inefficiency (Lua, Python,
+   Squirrel, JS, etc.) We wanted to focus on a great engine, not a great amount of integrations.
 4. No native vector types (vector3, matrix4, etc.), resulting in highly
    reduced performance when using custom types (Lua, Python, Squirrel,
    JS, AS, etc.).
@@ -125,77 +141,56 @@ The main reasons are:
    completion, live editing, etc. (all of them). This is well
    supported by GDScript.
 
-GDScript was designed to solve the issues above, and performs well
-in all the above scenarios. Please learn GDScript and enjoy a
-smooth integration of scripting with the game engine (yes, it's a
-rare but enjoyable situation when things just work). It's worth
-it, give it a try!
-
-I want to extend Godot. What are my options for creating plugins?
------------------------------------------------------------------
-
-For creating Godot Editor plugins look at :ref:`EditorPlugins <doc_making_plugins>` and tool scripts.
-
-Additional languages could be added via PluginScript or the more low-level NativeScript.
+GDScript was designed to curtail the issues above and more. 
 
-If you want to add a certain native library, your best bet is GDNative and custom C++ modules.
+What type of 3D model formats does Godot support?
+------------------------------------
 
-Also see the official blog posts on these topics:
+Godot supports Collada via the `OpenCollada <https://github.com/KhronosGroup/OpenCOLLADA/wiki/OpenCOLLADA-Tools>`_ exporter (Maya, 3DSMax).
 
-* `A look at the GDNative architecture <https://godotengine.org/article/look-gdnative-architecture>`_
-* `GDNative is here! <https://godotengine.org/article/dlscript-here>`_
+If you are using Blender, take a look at our own `Better Collada Exporter <https://godotengine.org/download>`_.
 
-You can also take a look at the GDScript implementation,
-the Godot modules as well as the `unofficial Python support <https://github.com/touilleMan/godot-python>`_ for Godot.
-
-Why is FBX not supported for import?
-------------------------------------
+As of Godot 3.0, glTF is supported.
 
 FBX SDK has a `restrictive license <https://www.blender.org/bf/Autodesk_FBX_License.rtf>`_,
 that is incompatible with the `open license <https://opensource.org/licenses/MIT>`_
-provided by Godot.
-
-That said, Godot's Collada support is good, please use the
-`OpenCollada <https://github.com/KhronosGroup/OpenCOLLADA/wiki/OpenCOLLADA-Tools>`_
-exporter for maximum compatibility if you are using Maya or 3DS Max.
-If you are using Blender, take a look at our own
-`Better Collada Exporter <https://godotengine.org/download>`_.
-
-Also, glTF support was added in Godot 3.0.
-
-FBX support could still be provided by third parties as a plugin. (See Plugins question above.)
+provided by Godot. That being said, FBX support could still be provided by third parties 
+as a plugin. (See Plugins question above.)
 
 Will [Insert closed SDK such as PhysX, GameWorks, etc.] be supported in Godot?
 ------------------------------------------------------------------------------
 
-No, the aim of Godot is to create a complete open source engine
-licensed under MIT, so you have complete control over every single
-piece of it. Open versions of functionality or features from such SDKs
-may be eventually added though.
+The aim of Godot is to create a free and open-source MIT-licensed engine that 
+is modular and extendable. There are no plans for the core engine development 
+community to support any third-party, closed-source/proprietary SDKs, as integrating 
+with these would go against Godot's ethos. 
 
-That said, because it is open source, and modular, nothing prevents you
-or anyone else interested into adding those libraries as a module and
-ship your game using them, as either open or closed source. Everything
-is allowed.
+That said, because Godot is open-source and modular, nothing prevents you or 
+anyone else interested in adding those libraries as a module and shipping your 
+game with them--as either open- or closed-source.
 
-To see how support for your SDK of choice could still be provided, look at the Plugins question above.
+To see how support for your SDK of choice could still be provided, look at the 
+Plugins question above.
+
+If you know of a third-party SDK that is not supported by Godot but that offers 
+free and open-source integration, consider starting the integration work yourself.
+Godot is not owned by one person; it belongs to the community, and it grows along 
+with ambitious community contributors like you. 
 
 How should assets be created to handle multiple resolutions and aspect ratios?
 ------------------------------------------------------------------------------
 
-This question pops up often and it's probably thanks to the
-misunderstanding created by Apple when they originally doubled the
-resolution of their devices. It made people think that having the same
-assets in different resolutions was a good idea, so many continued
-towards that path. That originally worked to a point and only for
-Apple devices, but then several Android and Apple devices with
-different resolutions and aspect ratios were created, with a very
-wide range of sizes and DPIs.
+This question pops up often and it's probably thanks to the misunderstanding 
+created by Apple when they originally doubled the resolution of their devices.
+It made people think that having the same assets in different resolutions was a 
+good idea, so many continued towards that path. That originally worked to a 
+point and only for Apple devices, but then several Android and Apple devices 
+with different resolutions and aspect ratios were created, with a very wide 
+range of sizes and DPIs.
 
-The most common and proper way to achieve this is to, instead, use a
-single base resolution for the game and only handle different screen
-aspects. This is mostly needed for 2D, as in 3D it's just a matter of
-Camera XFov or YFov.
+The most common and proper way to achieve this is to, instead, use a single 
+base resolution for the game and only handle different screen aspect ratios.
+This is mostly needed for 2D, as in 3D it's just a matter of Camera XFov or YFov.
 
 1. Choose a single base resolution for your game. Even if there are
    devices that go up to 2K and devices that go down to 400p, regular
@@ -225,64 +220,68 @@ devices with tiny screens (fewer than 300 pixels in width), you can use
 the export option to shrink images, and set that build to be used for
 certain screen sizes in the App Store or Google Play.
 
-I have a great idea that will make Godot better. What do you think?
+How can I extend Godot? 
+-----------------------------------------------------------------
+
+For extending Godot, like creating Godot Editor plugins or adding support 
+for additional languages, take a look at :ref:`EditorPlugins <doc_making_plugins>` 
+and tool scripts.
+
+Also see the official blog posts on these topics:
+
+* `A look at the GDNative architecture <https://godotengine.org/article/look-gdnative-architecture>`_
+* `GDNative is here! <https://godotengine.org/article/dlscript-here>`_
+
+You can also take a look at the GDScript implementation, the Godot modules, 
+as well as the `unofficial Python support <https://github.com/touilleMan/godot-python>`_ for Godot.
+This would be a good starting point to see how another third-party library 
+integrates with Godot. 
+
+I would like to contribute! How can I get started?
 -------------------------------------------------------------------
 
-Your idea will most certainly be ignored. Examples of stuff that is
-ignored by the developers:
+Awesome! As an open-source project, Godot thrives off of the innovation and 
+ambition of developers like you. 
+
+The first place to get started is in the `issues <https://github.com/godotengine/godot/issues>`_.
+Find an issue that resonates with you, then proceed to the `How to Contribute <https://github.com/godotengine/godot/blob/master/CONTRIBUTING.md#contributing-pull-requests>`_ 
+guide to learn how to fork, modify, and submit a Pull Request (PR) with your changes.
 
--  Let's do this because it will make Godot better
--  Let's do this in Godot because another game engine does it
--  Let's remove this because I think it's not needed
--  Let's remove clutter and bloat and make Godot look nicer
--  Let's add an alternative workflow for people who prefer it
+I have a great idea for Godot. How can I share it?
+-------------------------------------------------------------------
 
-Godot developers are always willing to talk to you and listen to your feedback
-very openly, to an extent rarely seen in open source projects, but they
-will care mostly about real issues you have while using Godot, not ideas
-solely based on personal belief. Developers are interested in (for
-example):
+It might be tempting to want to bring ideas to Godot, like ones that 
+result in massive core changes, some sort of mimicry of what another
+game engine does, or alternative workflows that you'd like built into 
+the editor. These are great and we are thankful to have such motivated 
+people want to contribute, but Godot's focus is and always will be the 
+core functionality as outlined in the `Roadmap <https://github.com/godotengine/godot-roadmap/blob/master/ROADMAP.md>`_, 
+`squashing bugs and addressing issues <https://github.com/godotengine/godot/issues>`_, 
+and conversations between Godot community members. 
+
+Most developers in the Godot community will be more interested to learn 
+about things like:
 
 -  Your experience using the software and the problems you have (we
    care about this much more than ideas on how to improve it).
 -  The features you would like to see implemented because you need them
    for your project.
--  The concepts that were difficult to understand in order to learn the
-   software.
+-  The concepts that were difficult to understand while learning the software.
 -  The parts of your workflow you would like to see optimized.
--  Parts where you missed clear tutorials or where the documentation wasn't up to par.
-
-Once one of the above points is stated, we can work together on a
-solution and this is where your ideas and suggestions are most valuable
-and welcome, they need to be in context of a real issue.
-
-As such, please don't feel that your ideas for Godot are unwelcome.
-Instead, try to reformulate them as a problem first, so developers and
-the community have a base ground to discuss first.
-
-Examples of how NOT to state problems generally and vaguely are:
-
--  Certain feature is ugly
--  Certain workflow is slow
--  Certain feature needs optimization
--  Certain aspect of the UI looks cluttered
-
-Associating something with an adjective will not get you much attention
-and developers will most likely not understand you. Instead, try to
-reformulate your problem as a story such as:
+-  Parts where you missed clear tutorials or where the documentation wasn't clear.
 
--  I try to move objects around but always end up picking the wrong one
--  I tried to make a game like Battlefield but I'm not managing to
-   understand how to get lighting to look the same.
--  I always forget which script I was editing, and it takes me too many
-   steps to go back to it.
+Please don't feel like your ideas for Godot are unwelcome. Instead, 
+try to reformulate them as a problem first, so developers and the community 
+have a functional foundation to ground your ideas on.
 
-This will allow you to convey what you are thinking much better and set
-a common ground for discussion. Please try your best to state your
-problems as stories to the developers and the community, before
-discussing any idea. Be specific and concrete.
+A good way to approach sharing your ideas and problems with the community 
+is as a set of user stories. Explain what you are trying to do, what behavior 
+you expect to happen, and then what behavior actually happened. Framing problems 
+and ideas this way will help the whole community stay focused on improving 
+developer experiences as a whole. 
 
-Bonus points for bringing screenshots, concrete numbers, test cases or example projects (if applicable).
+Bonus points for bringing screenshots, concrete numbers, test cases, or example 
+projects (if applicable).
 
 How can I support Godot development or contribute?
 --------------------------------------------------