Godot.wiki readability fixes

godot.wiki-readability.patch

diff --git a/GDScript.md b/GDScript.md
index eed5107..07a6d77 100644
--- a/GDScript.md
+++ b/GDScript.md
@@ -1,6 +1,6 @@
 #  Introduction 
 
-GDScript is a high level, dynamically typed programming language used to create content. It uses a syntax that is very similar to the Python language (blocks are indent-based) and its goal is to be very optimal and tightly integrated with the engine, allowing great flexibility for content creation and integration.
+GDScript is a high level, dynamically typed programming language used to create content. It uses a syntax that is very similar to the Python language (blocks are indent-based) and its goal is to be very efficient and tightly integrated with the engine, allowing great flexibility in content creation and integration.
 
 #  History 
 
@@ -84,7 +84,7 @@ func _init():
 
 ##  Identifiers 
 
-Any string that restricts itself to alphabetic characters (’a’ to ’z’ and ’A’ to ’Z’), digits (’0’ to ’9’) and ’_’ qualifies as an identifier. Additionally, identifiers must not begin with a digit. Identifiers are case-sensitive (’foo’ is different to ’FOO’).
+Any string that restricts itself to alphabetic characters (’a’ to ’z’ and ’A’ to ’Z’), digits (’0’ to ’9’) and ’_’ qualifies as an identifier. Additionally, identifiers must not begin with a digit. Identifiers are case-sensitive (’foo’ is different from ’FOO’).
 
 ##  Keywords 
 
@@ -467,7 +467,8 @@ export var number = 5  # also available to the property editor
 One of the fundamental benefits of exporting member variables is to have them visible in the property editor. This way artists and game designers can modify values that later influence how the program runs. For this, a special export syntax is provided for more detail in the exported variables:
 
 ```python
-# if the exported value assigns a constant or constant expression, the type will be inferred and used in the editor
+# if the exported value assigns a constant or constant expression, the type will be 
+# inferred and used in the editor
 
 export var number = 5
 
diff --git a/Home.md b/Home.md
index 134b681..0091af3 100644
--- a/Home.md
+++ b/Home.md
@@ -56,7 +56,7 @@ Welcome to the Godot Engine documentation center. The aim of these pages is to p
 *  [Alphabetical Class List](class_list) List of classes in alphabetical order.
 *  ~~[Categorized Class List](class_category) List of classes organized by category.~~
 *  ~~[Inheritance Class Tree](class_inheritance) List of classes organized by inheritance.~~
-*  [Relevant Classes](relevant_classes) List of the most relevant classes to learn first.
+*  ~~[Relevant Classes](relevant_classes) List of the most relevant classes to learn first.~~
 
 #### Languages
 
diff --git a/advanced.md b/advanced.md
index 0ff7f69..aaa89fd 100644
--- a/advanced.md
+++ b/advanced.md
@@ -34,7 +34,7 @@
 
 ## Misc
 
-*  [Command Line](command_line) Using the command line, for fans of doing everything in Unix/Windows shell.      
-*  [External Editor](external_editor) Configuring an external editor for opening scripts.
+*  [Command Line](command_line) Using the command line, for fans of doing everything in Unix/Windows shell.
+*  ~~[External Editor](external_editor) Configuring an external editor for opening scripts.~~
 *  [Changing Editor Fonts](editor_font) Changing the editor font (including support for CJK)
 *  [iOS Services](ios_services) Using iOS services (GameCenter, StoreKit)
diff --git a/devel_roadmap.md b/devel_roadmap.md
index efd369b..e748cbf 100644
--- a/devel_roadmap.md
+++ b/devel_roadmap.md
@@ -19,6 +19,7 @@ These are just tentative to have a rough idea of the development plan. Ideas and
 * 2D deforms and skeletons
 * FBX Import (blender did it..)
 * Live scene editing (should be rather easy)
+* Navmesh support
 
 ### Milestone 3 (~November 2014)
 
diff --git a/export.md b/export.md
index 157aae2..8c1421e 100644
--- a/export.md
+++ b/export.md
@@ -10,9 +10,9 @@ When more developers (and even non-programmers) started using it, and when our c
 
 Distributing a game project on PC with Godot is rather easy. Just drop the godot.exe (or godot) binary together in the same place as the engine.cfg file, zip it and you are done. This can be taken advantage to make custom installers.
 
-It sounds simple, but there are probably a few reasons why the developer may not want to do this. The first one is that it may not be desirable to distribute loads of files. Some developers may not like curious users peeking at how the game was made, others may just find it inelegant, etc. 
+It sounds simple, but there are probably a few reasons why the developer may not want to do this. The first one is that it may not be desirable to distribute loads of files. Some developers may not like curious users peeking at how the game was made, and others may just find it inelegant, etc. 
 
-Another reason is that, for distribution, the developer might use a specially compiled binary, which is smaller in size, more optimized and does not include tools inside (like the editor, debugger, etc).
+Another reason is that, for distribution, the developer might prefer a specially compiled binary, which is smaller in size, more optimized and does not include tools inside (like the editor, debugger, etc).
 
 Finally, Godot has a simple but efficient system for creating DLCs as extra package files.
 
@@ -20,13 +20,13 @@ Finally, Godot has a simple but efficient system for creating DLCs as extra pack
 
 The same scenario in mobile is a little worse. To distribute a project in those devices, a binary for each of those platforms is built, then added to a native project together with the game data. 
 
-This can be troublesome because it means that the developer must be familiarized with the SDK of each platform before even being able to export. In other words, while learning each SDK is always encouraged, it can be frustrating to be forced to do it at an undesired time.
+This can be troublesome because it means that the developer must be familiarized with the SDK of each platform before even being able to export. While learning each SDK is always encouraged, it can be frustrating to be forced to do it at an undesired time.
 
-There is also another problem with this approach, which is the fact that different devices prefer some data in different formats to run. The main example of this is texture compression. All PC hardware uses S3TC (BC) compression and that has been standardized for more than a decade, but mobile devices use different formats for texture compression, such as PVRCT (iOS) or ETC (Android)
+There is also another problem with this approach. Different devices prefer some data in different formats to run. The main example of this is texture compression. All PC hardware uses S3TC (BC) compression and that has been standardized for more than a decade, but mobile devices use different formats for texture compression, such as PVRCT (iOS) or ETC (Android)
 
 ### Export Dialog
 
-After many attempts at different export workflows, the current one has worked the best.At the time of this writing, not all platforms are supported yet, but that will change soon.
+After many attempts at different export workflows, the current one has worked the best. At the time of this writing, not all platforms are supported yet, but that will change soon.
 
 To open the export dialog, just click the "Export" Button:
 
@@ -36,7 +36,7 @@ The dialog will open, showing all the supported export platforms:
 
 <p align="center"><img src="images/export_dialog.png"></p>
 
-The default options are often enough to export, so tweaking them is not necessary until it's needed. However, many platforms require additional tools (SDKs) to be installed to be able to export. Additionally, Godot needs exports templates installed to create packages. The export dialog will complain when something is missing and will not allow the user to export for that platform until he or she resolves it:
+The default options are often enough to export, so tweaking them is not necessary until it's needed. However, many platforms require additional tools (SDKs) to be installed to be able to export. Additionally, Godot needs export templates installed to create packages. The export dialog will complain when something is missing and will not allow the user to export for that platform until he or she resolves it:
 
 <p align="center"><img src="images/export_error.png"></p>
 
diff --git a/export_android.md b/export_android.md
index 78f302d..ab8312e 100644
--- a/export_android.md
+++ b/export_android.md
@@ -1,6 +1,6 @@
 ## Exporting for Android
 
-Exporting for android has much less requirements than compiling Godot for it. As follows are the steps to setup the SDK and the engine.
+Exporting for android has much less requirements than compiling Godot for it. Below are the steps to setup the SDK and the engine.
 
 #### Download the Android SDK
 
diff --git a/export_images.md b/export_images.md
index bf6833f..51ef9f3 100644
--- a/export_images.md
+++ b/export_images.md
@@ -1,6 +1,6 @@
 ### Exporting Image Files
 
-It is often desired to do an operation to all or a group of images upon export. Godot provides some tools for this. Examples of such operations are:
+It is often desirable to do an operation to all or a group of images upon export. Godot provides some tools for this. Examples of such operations are:
 
 * Converting all images from a lossless format to a lossy one (ie: png -> web) for greater compression.
 * Shrinking all images to half the size, to create a low resolution build for smaller screens.
@@ -16,14 +16,14 @@ In this dialog the image extensions for conversion can be selected, and operatio
 
 * Convert Image Format: Probably the most useful operation is to convert to Lossy (WebP) to save disk space. For lossy, a Quality bar can set the quality/vs size ratio.
 * Shrink: This allows to shrink all images by a given amount. It's useful to export a game to half or less resolution for special devices.
-* Compress Formats: Allows to select which image exensions to convert.
+* Compress Formats: Allows to select which image extensions to convert.
 
 On export, Godot will perform the desired operation. The first export might be really slow, but subsequent exports will be fast, as the converted images will be cached.
 
 ### Image Group Export Options
 
 This section is similar to the previous one, except it can operate on a selected group of images. When a image is in a group, the settings from the global export options are overridden by the ones from the group.
-An image can only be in one group at the same time. So if the image is in another group different to the current one being edited, it will not be selectable.
+An image can only be in one group at a time. So if the image is in a group other than the current one being edited, it will not be selectable.
 
 <p align="center"><img src="images/imagegroup.png"></img></p>
 
@@ -31,4 +31,4 @@ An image can only be in one group at the same time. So if the image is in anothe
 
 As a plus, an atlas can be created from a group. When this mode is active, a button to preview the resulting atlas becomes available. Make sure that atlases don't become too big, as some hardware will not support textures bigger than 2048x2048 pixels. If this happens, just create another atlas.
 
-The atlas can be useful to speed up drawing of some scenes, as state changes are minimized when drawing from it (through unlike other engines, Godot is designed so state changes do not affect it as much). Textures added to an atlas get cropped (empty spaces around the image are removed), so this is another reason to use them (save space). If unsure, though, just leave that option disabled.
+The atlas can be useful to speed up drawing of some scenes, as state changes are minimized when drawing from it (though unlike other engines, Godot is designed so state changes do not affect it as much). Textures added to an atlas get cropped (empty spaces around the image are removed), so this is another reason to use them (save space). If unsure, though, just leave that option disabled.
diff --git a/image_files.md b/image_files.md
index a42fad9..ed2cc91 100644
--- a/image_files.md
+++ b/image_files.md
@@ -2,12 +2,12 @@
 
 If you have read the previous tutorials on [Resources](tutorial_resources) and [FileSystem](tutorial_fs), at this point you know that regular image files (.png, .jpg, etc) are treated as regular resources in Godot.
 
-Unlike texture resources (.tex files), image files contain no extra information on tiling (texture repeat), mipamps or filtering. Editing this information and saving the texture back will have not any effect, since such formats can't contain that information.
+Unlike texture resources (.tex files), image files contain no extra information on tiling (texture repeat), mipmaps or filtering. Editing this information and saving the texture back will not have any effect, since such formats can't contain that information.
 
 ### Image Loader
 
 Loading of images is done by the image loader. The behavior of the loader for all image files can be changed
-in the Project Settings dialog (Scene -> Project Settings). There is a section with values that correspond to the every image file when loaded:
+in the Project Settings dialog (Scene -> Project Settings). There is a section with values that correspond to every image file when loaded:
 
 <p align="center"><img src="images/imgloader.png"/></p>
 
@@ -15,7 +15,7 @@ in the Project Settings dialog (Scene -> Project Settings). There is a section w
 
 #### Filter:
 
-Filter is used when the image is stretched more than it's original size, so a texel in the image is bigger than a pixel on the screen. Turning off the fiter produces a retro-like look:
+Filter is used when the image is stretched more than it's original size, so a texel in the image is bigger than a pixel on the screen. Turning off the filter produces a retro-like look:
 
 <p align="center"><img src="images/imagefilter.png"/></p>
 
@@ -25,7 +25,7 @@ Repeat is mainly used for 3D textures, so it's off by default (textures are impo
 
 #### Mipmaps:
 
-When the mipmaps option is enabled, Godot will generate mip-maps. Mipmaps are versions of the image shrunk by half in both axis, recursively, until the image is 1 pixel of size. When the 3D hardware needs to shrink the image, it finds the largest mipmap it can scale from, and scales from there. This improves performance and image quality.
+When the mipmaps option is enabled, Godot will generate mip-maps. Mip-maps are versions of the image shrunk by half in both axis, recursively, until the image is 1 pixel of size. When the 3D hardware needs to shrink the image, it finds the largest mip-map it can scale from, and scales from there. This improves performance and image quality.
 
 <p align="center"><img src="images/mipmaps.png"/></p>
 
@@ -49,7 +49,7 @@ Since fixing this in so many images can be a little annoying, both Texture Impor
 
 ## Texture Import
 
-Sometimes, it might be desired to change the above settings per image. Unfortunately, the image loader settings are global. Texture flags also can't be saved in a regular .png or .jpg file. 
+Sometimes, it might be desirable to change the above settings per image. Unfortunately, the image loader settings are global. Texture flags also can't be saved in a regular .png or .jpg file. 
 
 For such cases, the image can be imported as a texture (.tex), where the individual flags can be changed. Godot also keeps track of the original file and will re-import if it changes.
 
diff --git a/import_fonts.md b/import_fonts.md
index d2935b1..d264ddb 100644
--- a/import_fonts.md
+++ b/import_fonts.md
@@ -17,11 +17,11 @@ The drawback of this process is that fonts must be pre-imported in the specific
 
 ### Importing a Font
 
-Fonts are imported via the Font import dialog. The dialog will ask for a font, a size, some options and a target resource fie to save.
+Fonts are imported via the Font import dialog. The dialog will ask for a font, a size, some options and a target resource file to save.
 
 <p align="center"><img src="images/fontimport.png"></p>
 
-The dialog is fully dynamic, which means that any change will be reflected in the font preview window. The user ccan tweak almost every parameter and get instant feedback on how the font will look.
+The dialog is fully dynamic, which means that any change will be reflected in the font preview window. The user can tweak almost every parameter and get instant feedback on how the font will look.
 
 Since the resulting font is a bitmap, a few more options were added to make the imported font look even nicer. These options were added to please graphic designers, who love putting gradients, outlines and shadows in fonts, as well as changing all the inter-spaces available :). The options which will be explained as follows.
 
@@ -36,7 +36,7 @@ It is possible to add more space for:
 
 #### Shadows & Outline
 
-Fonts can be added a shadow. For this, the font is drawn again below on a different color and the blurred with a gaussian kernel of different sizes. The resulting shadow can be adjusted with an exponential function to make it softer or more like an outline. A second shadow is also provided to create some added effects, like a bump or outline+shadow.
+Fonts can be given a shadow. For this, the font is drawn again below in a different color and then blurred with a gaussian kernel of different sizes. The resulting shadow can be adjusted with an exponential function to make it softer or more like an outline. A second shadow is also provided to create some added effects, like a bump or outline+shadow.
 
 <p align="center"><img src="images/shadowoutline.png"></p>
 
@@ -50,9 +50,9 @@ Gradients are also another of the visual effects that graphic designers often us
 
 Colors, shadows and gradients are beautiful, but it's time we get to serious business. Developing games for Asian markets is a common practice in today's globalized world and app stores. 
 
-Here's when things get tricky with using bitmap fonts. Asian alphabets (Chinese, Japanese and Korean) contains dozens of thousands of characters. Generating bitmap fonts with every single of them is pretty expensive, as the resulting textures are huge. If the font size is small enough, it can be done without much trouble, but when the fonts become bigger, we run out of video ram pretty quickly!
+Here's when things get tricky with using bitmap fonts. Asian alphabets (Chinese, Japanese and Korean) contains dozens of thousands of characters. Generating bitmap fonts with every single one of them is pretty expensive, as the resulting textures are huge. If the font size is small enough, it can be done without much trouble, but when the fonts become bigger, we run out of video ram pretty quickly!
 
-To solve this, Godot allows the user to specify a text file (in UTF-8 format) where it expects to find all the characters that will be used in the project. This seems difficult to provide at first, and more to keep up to date, but it becomes rather easy when one realizes that the .csv with the translations can be used as such source file (see the [Importing Translations](import_translations) section). As Godot re-imports assets when their dependencies change, both the translation and font files will be updated and re-imported automatically if the translation csv changes. 
+To solve this, Godot allows the user to specify a text file (in UTF-8 format) where it expects to find all the characters that will be used in the project. This seems difficult to provide at first, and more to keep up to date, but it becomes rather easy when one realizes that the .csv with the translations can be used as such a source file (see the [Importing Translations](import_translations) section). As Godot re-imports assets when their dependencies change, both the translation and font files will be updated and re-imported automatically if the translation csv changes. 
 
 Another cool trick for using a text file as limit of which characters can be imported is when using really large fonts. For example, the user might want to use a super large font, but only to show numbers. For this, he or she writes a numbers.txt file that contains "1234567890", and Godot will only limit itself to import data, thus saving a lot of video memory.
 
diff --git a/import_process.md b/import_process.md
index 20afcec..6996d24 100644
--- a/import_process.md
+++ b/import_process.md
@@ -2,11 +2,11 @@
 
 ### What is it for?
 
-When Godot was created, it was probably after several failed and not so failed engine attempts (well, each attempt failed a little less.. and so on). One of the most difficult areas of creating game engines is managing the import process. That means, getting the assets that artists make into the game, in a way that functions optimally. 
+One of the most difficult areas of creating game engines is managing the import process. That means, getting the assets that artists make into the game, in a way that functions optimally. 
 
-Artists use certain tools and formats, and programmers would rather have their data into a different format. This is because artists put their focus on creating assets with the best quality possible, while programmers have to make sure they actually run at decent speed (or run at all), use a certain amount of memory, and don't take ages loading from disk.
+Artists use certain tools and formats, and programmers would rather have their data in a different format. This is because artists put their focus on creating assets with the best quality possible, while programmers have to make sure they actually run at decent speed (or run at all), use a certain amount of memory, and don't take ages loading from disk.
 
-One would think that just writing a converter/importer would be enough, but this is not all there is to it. The same way programmers iterate several times over their code, artists keep making changes to their assets. This generates some bottleneck, because *someone* has to keep re-importing that artwork right? And importing assets is often something that has to be agreed by both parties, as the programmer needs to decide how the artwork is imported and the artists needs to see how it looks.
+One would think that just writing a converter/importer would be enough, but this is not all there is to it. The same way programmers iterate several times over their code, artists keep making changes to their assets. This generates a bottleneck, because *someone* has to keep re-importing that artwork right? And importing assets is often something that has to be agreed by both parties, as the programmer needs to decide how the artwork is imported and the artists needs to see how it looks.
 
 The goal to establishing an import process is that both can agree on how the rules under which the assets are going to be imported the first time, and the system will apply those rules automatically each time the asset is re-imported. 
 
@@ -16,12 +16,12 @@ Godot does not do the re-import process automatically, though. It gives the team
 
 The aim of the import system is that it works well enough for most common cases and projects. What is there has been tested and seems to cover most needs. 
 
-However, as mentioned before, this is on of the most difficult areas of writing a game engine. It may happen often (specially on large projects, ports, or projects with unusual requirement) that what is provided is not enough. It's easy to say that the engine is open source and that the programmer should make their own if they don't like what is there, but that would be making a huge disservice to the users and not the right attitude. Because of that, we made sure to provide as many tools and helpers as possible to support a custom import process, for example:
+However, as mentioned before, this is one of the most difficult areas of writing a game engine. It may happen often (especially on large projects, ports, or projects with unusual requirements) that what is provided is not enough. It's easy to say that the engine is open source and that the programmer should make their own if they don't like what is there, but that would be a huge disservice to the users and not the right attitude. Because of that, we provided as many tools and helpers as possible to support a custom import process, for example:
 
 *  Access to the internals of almost all data structures is provided to the scripting and C++ API, as well as saving and loading in all supported file formats.
 *  Some importers (like the 3D asset importer) support scripts to modify the data being imported.
 *  Support for creating custom import plugins is also provided, even for replacing the existing ones.
-*  If all else fails, Godot supports for adding custom resource loaders, to load data in alternative formats, without intermediate conversion.
+*  If all else fails, Godot supports adding custom resource loaders, to load data in alternative formats, without intermediate conversion.
 
 Both the import system and the custom tools provided will improve over time as more use cases are revealed to us.
 
@@ -35,7 +35,7 @@ First of all, it would be really good for this location to **not** be inside the
 
 Now that it is clear that this location must be outside the project folder, the rule that Godot uses to reference external assets can be explained. When an asset is imported, the engine stores a relative path from the project path to the asset (In windows, this works as long as they are on the same drive, otherwise an absolute path is stored). This ensures that the same asset can be re-imported in another computer.
 
-The usual approach to this, when using a VCS such as Subversion, Perforce or GIT, is to create the project in a subfolder, so both it and the source assets can be commited to a same repository. For example:
+The usual approach to this, when using a VCS such as Subversion, Perforce or GIT, is to create the project in a subfolder, so both it and the source assets can be committed to a same repository. For example:
 
 ```
 
@@ -54,11 +54,11 @@ In the above example, artists, musican, translators, etc. can work in the source
 
 #### Import Dialogs
 
-Godot provides for importing several types of assets, all of them can be accessed from the import dialog:
+Godot provides for importing several types of assets, all of them can be accessed from the import menu:
 
 <p align="center"><img src="images/import.png"></p>
 
-Each of the dialog shares a similar function, a source file (or several of them) must be provided, as well as a target destination inside the project folders. Once imported, Godot saves this information as metadata in the imported asset itself.
+Each of the dialogs shares a similar function, a source file (or several of them) must be provided, as well as a target destination inside the project folders. Once imported, Godot saves this information as metadata in the imported asset itself.
 
 <p align="center"><img src="images/importdialogs.png"></p>
 
diff --git a/import_samples.md b/import_samples.md
index c802324..d8bd025 100644
--- a/import_samples.md
+++ b/import_samples.md
@@ -2,7 +2,7 @@
 
 #### Why Importing?
 
-Importing Audio Samples into the game engine is a process that should be easier than it really is. Most readers are probably thinking "Why not just copying the .wav files to a folder inside the project and be over with it?".
+Importing Audio Samples into the game engine is a process that should be easier than it really is. Most readers are probably thinking "Why not just copy the .wav files to a folder inside the project and be done with it?".
 
 It's not usually that simple. Most game engines use uncompressed audio (in memory at least) for sound effects. The reason for this is because it's really cheap to play back and resample. Compressed streamed audio (such as .ogg files) takes a large amount of processor to decode so no more than one or two are streamed simultaneously. However, with sound effects, one expects a dozen of them to be playing at the same time in several situations.
 
@@ -10,14 +10,14 @@ Because of this, sound effects are loaded uncompressed into memory, and here is
 
 As is usual with graphics, the situation where programmers don't really know about audio and audio engineers don't know about programming is also common in the industry. This leads to a scenario where a project ends up wasting resources unnecessarily. 
 
-To be more precise, sfx artists tend to work with audio formats that give them a lot of room for tweaking the audio with a low noise floor minimum aliasing, such as 96khz, 24 bits. In many cases, they work in stereo too.
+To be more precise, sfx artists tend to work with audio formats that give them a lot of room for tweaking the audio with a low noise floor and minimum aliasing, such as 96khz, 24 bits. In many cases, they work in stereo too.
 Added to that, many times they add effects with an infinite or really long fadeout, such as reverb, which take a long time to fade out. Finally, many DAWs also add silence at the beginning when normalizing to wav.
 
 This results in extremely large files to integrate more often than desired, with sound effects taking dozens of megabytes.
 
 #### How Much does Quality Matter?
 
-First of all, it is important to know that Godot has an internal reverb generator. Sound effects can go to four different setups (small, medium and large room as well as hall), with different send amounts. This saves sfx artists the need to add reverb to the sound effects, reducing their size greatly and ensuring correct trimming. Say no to SFX wit baked reverb!
+First of all, it is important to know that Godot has an internal reverb generator. Sound effects can go to four different setups (small, medium and large room as well as hall), with different send amounts. This saves sfx artists the need to add reverb to the sound effects, reducing their size greatly and ensuring correct trimming. Say no to SFX with baked reverb!
 
 <p align="center"><img src="images/reverb.png"></p>
 
@@ -34,6 +34,7 @@ As seen, for being no audible difference, the 16 bits, 44khz takes *6 times less
 
 One last issue that happens often is that the waveform files received have silences at the beginning and at the end. These are inserted by DAWs when saving to a waveform, increase their size unnecessarily and add latency to the moment they are played back. Trimming them solves this, but it takes effort for the sfx artist, as they have to do it in a separate application. In the worst case, they may not even know the silences are being added.
 <p align="center"><img src="images/trim.png"></p>
+
 #### Importing Audio Samples
 
 Godot has a simple screen for importing audio samples to the engine. SFX artists only have to save the .wav files to a folder outside the project, and the import dialog will fix the files for inclusion, as well as doing it automatically every time they are modified and re-imported.
diff --git a/import_textures.md b/import_textures.md
index 61f3437..8017d2f 100644
--- a/import_textures.md
+++ b/import_textures.md
@@ -1,13 +1,13 @@
 # Importing Textures
 
-### Do NOT to import them in most cases.
+### Do NOT import them in most cases.
 
 In most cases you **don't** want images imported when dealing with 2D and GUI. Just copy them to the filesystem. Read the tutorial on [dealing with image files](image_files) before continuing! 
 For 3D, textures are always imported by the 3D scene importer. The flags and options are the same as here, so reading the rest of the document might help too.
 
 ### OK you _might_ want to import them.
 
-So, if you have read the previous tutorial on the texture exporter, the texture importer gives you more finer grained control on how textures are imported. If you want to change flags such as repeat, filter, mip-maps, fix edges, etc _**PER texture**_, importing them is the best way to accomplish this (since you can't save such flags in a standard image file). 
+So, if you have read the previous tutorial on the texture exporter, the texture importer gives you finer grained control on how textures are imported. If you want to change flags such as repeat, filter, mip-maps, fix edges, etc _**PER texture**_, importing them is the best way to accomplish this (since you can't save such flags in a standard image file). 
 
 ### Lack of MipMaps
 
@@ -49,7 +49,7 @@ Video texture compression formats are several and non standard. Apple uses PVRTC
 
 Still, when using this option, Godot converts and compresses to the relevant format depending on the target platform (as long as the user pre-imported the texture and specified video ram compression!).
 
-This kind of compression is often not desirable for many types 2D games and UIs because it has visible visual artifacts. This is specially noticeable on games that use the trendy vectory social game artwork. 
+This kind of compression is often not desirable for many types of 2D games and UIs because it has visible visual artifacts. This is specially noticeable on games that use the trendy vectory social game artwork. 
 However, again, the fact that it saves space and improves performance may make up for it.
 
 The 3D scene importer always imports textures with this option turned on.
diff --git a/import_translation.md b/import_translation.md
index db28398..b42a854 100644
--- a/import_translation.md
+++ b/import_translation.md
@@ -8,9 +8,9 @@ In regular desktop or mobile applications, internationalized text is usually loc
 
 There are two approaches to generate multi language games and applications. Both are based on a key:value system. The first is to use one of the languages as key (usually english), the second is to use a specific identifier. The first approach is probably easier for development if a game is released first in english, later in other languages, but a complete nightmare if working with many languages at the same time.
 
-In general, games use the second approach and a unique ID is used for each string. This allows to revise the text while it's being translated to others. the unique ID can be a number, a string, or a string with a number (it's just a unique string anyway). 
+In general, games use the second approach and a unique ID is used for each string. This allows you to revise the text while it's being translated to other languages. The unique ID can be a number, a string, or a string with a number (it's just a unique string anyway). 
 
-Translators also, most of the time prefer to work with spreadsheets (either as a Microsoft Excel file or a shared Google Spreadsheet).
+Translators also usually prefer to work with spreadsheets (either as a Microsoft Excel file or a shared Google Spreadsheet).
 
 #### Translation Format
 
@@ -35,11 +35,11 @@ The "lang" tags must represent a language, it must be one of the [valid locales]
 
 The import dialog takes a .csv file in the previously described format and generates several compressed translation resource files inside the project.
 
-Selecting a .csv file autodetects the languages from the first row. and determines which column represents which language. It is possible to change that manually, by selecting the language for each column.
+Selecting a .csv file auto-detects the languages from the first row and determines which column represents which language. It is possible to change that manually, by selecting the language for each column.
 
 <p align="center"><img src="images/trans.png"></p>
 
-The import dialog also can add the translation to the list of translations to load when the game runs, specified in engine.cfg (or the project properties). Godot allows to load and remove translations at runtime, too.
+The import dialog can also add the translation to the list of translations to load when the game runs, specified in engine.cfg (or the project properties). Godot allows you to load and remove translations at runtime, too.
 
  --- //[Juan Linietsky](reduzio@gmail.com) 2013/11/10 21:42//
  
diff --git a/one_click_deploy.md b/one_click_deploy.md
index 090b82f..76d5a7a 100644
--- a/one_click_deploy.md
+++ b/one_click_deploy.md
@@ -3,7 +3,7 @@
 ### Sounds Good, What is it?
 
 This feature will pop up automatically once a platform is properly configured and a supported device is connected to the computer. 
-Since things can go wrong at many levels (platform may not be configured correctly, SDK may incorrectly installed, device may be improperly configured, kitty ate the USB cable, etc.), it's good to let the user know that it exists.
+Since things can go wrong at many levels (platform may not be configured correctly, SDK may be incorrectly installed, device may be improperly configured, kitty ate the USB cable, etc.), it's good to let the user know that it exists.
 
 Some platforms (at the time of this writing, only Android and Blackberry 10) can detect when a USB device is connected to the computer, and offer the user to automatically export, install and run the project (in debug mode) on the device. This feature is called, in industry buzz-words, "One Click Deploy" (though, it's technically two clicks...).
 
diff --git a/tutorial_2d.md b/tutorial_2d.md
index d5b2d8d..96f3457 100644
--- a/tutorial_2d.md
+++ b/tutorial_2d.md
@@ -1,7 +1,8 @@
 # Simple 2D Game (Pong!)
 
 ### Pong
-In this simple tutorial, a basic game of Pong will be created. There are plenty of more complex examples in the demos included with the engine, but this should get introduced to basic functionality for 2D Games.
+
+In this simple tutorial, a basic game of Pong will be created. There are plenty of more complex examples in the demos included with the engine, but this should introduce you to the basic functionality for 2D Games.
 
 ### Assets
 
@@ -9,7 +10,7 @@ Some assets are included for this tutorial, the [pong pads, the ball and the div
 
 ### Scene Setup
 
-For the sake of the old times, the game will be in 640x400 pixels resolution. This can be configured in the Project Settings (see previous tutorials). The default background color should be set to black:
+For old times sake, the game will be in 640x400 pixels resolution. This can be configured in the Project Settings (see previous tutorials). The default background color should be set to black:
 
 
 <p align="center"><img src="images/clearcolor.png"></p>
@@ -18,26 +19,26 @@ Create a [Node2D](class_node2d) node for the project root. Node2D is the base ty
 
 <p align="center"><img src="images/pong_layout.png"></p>
 
-The scene tree should, then look similar to this:
+The scene tree should then look similar to this:
 <p align="center"><img src="images/pong_nodes.png"></p>
 
 Save the scene as "pong.scn" and set it as the main scene in the project properties. 
 
 ### Input Actions Setup
 
-There are so many input methods for video games... Keyboard, Joypad, Mouse, Touchscreen (Multitouch). Yet this is pong. The only input that matters is for the pads going up and down.
+There are so many input methods for video games... Keyboard, Joypad, Mouse, Touchscreen (Multitouch). Yet this is pong. The only input that matters is whatever makes the pads go up and down.
 
 Handling all possible input methods can be very frustrating and take a lot of code. The fact that most games allow controller customization makes this worse. For this, Godot created the "Input Actions". An action is defined, then input methods that trigger it are added.
 
 Open the project properties dialog again, but this time move to the "Input Map" tab. 
-On it, add 4 actions: "left_move_up","left_move_down","right_move_up","right_move_down". Assign the keys that you desire. A/Z for left and Up/Down as keys should work in most cases.
+On it, add 4 actions: "left_move_up","left_move_down","right_move_up","right_move_down". Assign the keys that you desire. A/Z for left and Up/Down for right should work in most cases.
 
 <p align="center"><img src="images/inputmap.png"></p>
 
 
 ### Script
 
-Create a script for the root node of the scene and open it (should have been explained in the previous tutorial!). The script will inherit Node2D:
+Create a script for the root node of the scene and open it as explained in the previous tutorial. The script will inherit Node2D:
 
 ```python
 extends Node2D
@@ -47,7 +48,7 @@ func _ready():
 
 ```
 
-In the constructor, two things will be done. The first is to enable processing, and the second to store some useful values. Such values are the dimensions of the screen and the pad:
+In the _ready() callback, two things will be done. The first is to enable processing, and the second to store some useful values. Such values are the dimensions of the screen and the pad:
 
 ```python
 
@@ -68,25 +69,24 @@ Then, some variables used for in-game will be added:
 
 ```python
 
-#speed of the ball (in pixels/second0
-
+# speed of the ball (in pixels/second)
 var ball_speed = 80
-#direction of the ball (normal vector)
 
+# direction of the ball (normal vector)
 var direction = Vector2(-1,0)
-#constant for pad speed (also in pixels/second)
 
+# constant for pad speed (also in pixels/second)
 const PAD_SPEED = 150
 
 ```
 
-Finally, the process function:
+Finally, the _process() callback:
 
 ```python
 func _process(delta):
 ```
 
-Get some useful values for computation. The first is the ball position (from the node), the second is the rectangles (Rect2) of the pads. Sprites by defaut center the textures, so a small adjustment of size/2 must be added.
+Get some useful values for computation. The first is the ball position (from the node), the second is the rectangles (Rect2) of the pads. Sprites by default center the textures, so a small adjustment of size/2 must be added.
 
 ```python
 
@@ -95,17 +95,17 @@ Get some useful values for computation. The first is the ball position (from the
 	var right_rect = Rect2( get_node("right").get_pos() - pad_size/2, pad_size )
 ```
 
-Since the ball pos was obtained, integrating it should be simple:
+Since the ball_pos was obtained, integrating it should be simple:
 
 ```python
-	ball_pos+=direction*ball_speed*delta
+	ball_pos += direction*ball_speed*delta
 ```
 
 Then, now that the ball has a new position, it should be tested against everything. First, the floor and the roof:
 
 ```python
 
-	if ( (ball_pos.y<0 and direction.y <0) or (ball_pos.y>screen_size.y and direction.y>0)):
+	if ( (ball_pos.y < 0 and direction.y < 0) or (ball_pos.y > screen_size.y and direction.y > 0)):
 		direction.y = -direction.y
 ```
 
@@ -120,13 +120,13 @@ If one of the pads was touched, change direction and increase speed a little.
 
 ```
 
-If the ball went out of the screen, it's game over. Game restarts:
+If the ball went out of the screen, it's game over and the game restarts:
 
 ```python
-	if (ball_pos.x<0 or ball_pos.x>screen_size.x):
-		ball_pos=screen_size*0.5 #ball goes to screen center
-		ball_speed=80
-		direction=Vector2(-1,0)
+	if (ball_pos.x < 0 or ball_pos.x > screen_size.x):
+		ball_pos = screen_size*0.5 # ball goes to screen center
+		ball_speed = 80
+		direction = Vector2(-1,0)
 ```
 
 Once everything was done with the ball, the node is updated with the new position:
@@ -139,30 +139,30 @@ Only updating the pads according to player input. the Input class is really usef
 
 ```python
 
-	#move left pad	
+	# move left pad	
 	var left_pos = get_node("left").get_pos()
 	
 	if (left_pos.y > 0 and Input.is_action_pressed("left_move_up")):
-		left_pos.y+=-PAD_SPEED*delta
+		left_pos.y += -PAD_SPEED*delta
 	if (left_pos.y < screen_size.y and Input.is_action_pressed("left_move_down")):
-		left_pos.y+=PAD_SPEED*delta
+		left_pos.y += PAD_SPEED*delta
 		
 	get_node("left").set_pos(left_pos)
 		
-	#move right pad	
+	# move right pad	
 	var right_pos = get_node("right").get_pos()
 	
 	if (right_pos.y > 0 and Input.is_action_pressed("right_move_up")):
-		right_pos.y+=-PAD_SPEED*delta
+		right_pos.y += -PAD_SPEED*delta
 	if (right_pos.y < screen_size.y and Input.is_action_pressed("right_move_down")):
-		right_pos.y+=PAD_SPEED*delta
+		right_pos.y += PAD_SPEED*delta
 		
 	get_node("right").set_pos(right_pos)
 	
 ```	 
 
 
-And that's it! a simple Pong was written with a few lines of code.
+And that's it! A simple Pong was written with a few lines of code.
 
 
 
diff --git a/tutorial_animation.md b/tutorial_animation.md
index 5036b64..6ad8700 100644
--- a/tutorial_animation.md
+++ b/tutorial_animation.md
@@ -2,14 +2,14 @@
 
 ### Introduction
 
-This tutorial will explain how everything is animated in Godot. Godot animation system is extremely powerful and flexible. 
+This tutorial will explain how everything is animated in Godot. Godot's animation system is extremely powerful and flexible. 
 
-To begin, let's just use the scene from the previous tutorial (splash screen). The goal will be to add a simple animation to it. Here's a copy just in case: <p align="center"><img src="robisplash.zip|}}
+To begin, let's just use the scene from the previous tutorial (splash screen). The goal will be to add a simple animation to it. [Here](media/robisplash.zip) is a copy just in case.
 
 
 ### Creating the Animation
 
-First of all, add an [AnimationPlayer](class_animationplayer) node to the scene, make it a child of bg (the root node):
+First, add an [AnimationPlayer](class_animationplayer) node to the scene, make it a child of bg (the root node):
 
 <p align="center"><img src="images/animplayer.png"></p>
 
@@ -27,18 +27,18 @@ After the animation has been created, then it's time to edit it, by pressing the
 
 ### Editing the Animation
 
-Now this is when the magic happens! Several things happen when the "edit" button is pressed, the first one is that the animation editor appears above the animation panel. 
+Now this is when the magic happens! Several things happen when the "edit" button is pressed. First, the animation editor appears above the animation panel. 
 
 <p align="center"><img src="images/animeditor.png"></p>
 
-But the second, and most important, is that the property editor enters into "animation editing" mode. In this mode, a key icon appears next to every property of the property editor. This means that, in Godot, *any property of any object* can be animated:
+Second, and most important, the property editor enters into "animation editing" mode. In this mode, a key icon appears next to every property of the property editor. This means that, in Godot, *any property of any object* can be animated:
 
 <p align="center"><img src="images/propertykeys.png"></p>
 
 
 ### Making the Logo Appear
 
-Next, the logo will appear from the top of the screen. After selecting the animation player, the editor panel will stay visible until manually hidden (or the animation node is erased). Taking advantage of this, select the "logo" node and go to the "pos" property, move it up, to position: 114,-400.
+Next, we want to make the logo appear from the top of the screen. After selecting the animation player, the editor panel will stay visible until manually hidden (or the animation node is erased). Taking advantage of this, select the "logo" node and go to the "pos" property, move it up, to position: 114,-400.
 Once in this position, press the key button next to the property:
 
 <p align="center"><img src="images/keypress.png"></p>
@@ -51,11 +51,11 @@ And the keyframe will be added in the animation player editor:
 
 <p align="center"><img src="images/keyadded.png"></p>
 
-Second, move the editor cursor to the end, by clicking here:
+Next, move the editor cursor to the end, by clicking here:
 
 <p align="center"><img src="images/move_cursor.png"></p>
 
-Change the logo position to 114,0 and a keyframe again. With two keyframes, the animation happens.
+Change the logo position to 114,0 and add a keyframe again. With two keyframes, the animation is ready.
 
 <p align="center"><img src="images/animation.png"></p>
 
@@ -63,7 +63,4 @@ Pressing Play on the animation panel will make the logo descend. To test it by r
 
 <p align="center"><img src="images/autoplay.png"></p>
 
-And finally, when running the scene, the animation should look like this:
-
-<p align="center"><img src="images/out.gif"></p>
 
diff --git a/tutorial_fs.md b/tutorial_fs.md
index 8ef7f1a..f605caf 100644
--- a/tutorial_fs.md
+++ b/tutorial_fs.md
@@ -2,19 +2,19 @@
 
 ### Introduction
 
-Filesystem usage is yet another hot topic in engine development. This means, where are assets stored, how are they accessed, how do multiple programmers edit the same repository, etc.
+Filesystem usage is yet another hot topic in engine development. This means where assets are stored, how they are accessed, how multiple programmers edit the same repository, etc.
 
-Initial versions of the engine (and previous iterations before it was named Godot) used a database. Assets were stored there and assigned an ID. Other approaches were tested, too, with local databases, files with metadata, etc. To say truth, and after a long time, simplicity proved to be best and Godot stores all assets as files in the flesystem. 
+Initial versions of the engine (and previous iterations before it was named Godot) used a database. Assets were stored there and assigned an ID. Other approaches were tested, too, with local databases, files with metadata, etc. In the end simplicity proved to be best and Godot stores all assets as files in the filesystem. 
 
 ### Implementation
 
-Godot stores resources to disk. Anything, from a script, to a scene or a PNG image is a resource to the engine. If a resource contains properties that referece other resources on disk, the path to that resource is included. If it has sub-resources that are built-in, the resource is saved in a single file together with all the bundled sub-resources. For example, a font resource is often saved with the character textures bundled inside.
+Godot stores resources to disk. Anything, from a script, to a scene or a PNG image is a resource to the engine. If a resource contains properties that reference other resources on disk, the path to that resource is included. If it has sub-resources that are built-in, the resource is saved in a single file together with all the bundled sub-resources. For example, a font resource is often saved with the character textures bundled inside.
 
 Metadata files were also dropped and the whole engine design tries to avoid them. The reason for this is simple, existing asset managers and VCSs are just much better than anything we can implement, so Godot tries the best to play along with SVN, Git, Mercurial, Perforce, etc. 
 
 ### engine.cfg
 
-The mere existence of this file marks that there is a Godot project in that directory and all sub-directories.
+The mere existence of the engine.cfg file in a directory indicates that there is a Godot project in that directory and all sub-directories.
 This file contains the project configuration in plain text, win.ini style, though it will work to mark the existence of a project even if the file is empty. 
 
 Example of a filesystem:
@@ -36,7 +36,7 @@ Godot only supports "/" as a directory delimiter. This is done for portability r
 
 ### Resource Path
 
-For accessing resources, using the host OS filesystem layout can be cumbersome and non portable. To solve this problem, the specal path `"res://"` was created.
+For accessing resources, using the host OS filesystem layout can be cumbersome and non portable. To solve this problem, the special path `"res://"` was created.
 
 The path `"res://"` will always point at the project root (where engine.cfg is located, so in fact `"res://engine.cfg"` is always valid).
 
@@ -44,7 +44,7 @@ This filesystem is read-write only when running the project locally from the edi
 
 ### User Path
 
-Writing to disk is still needed often, from doing a savegame to downloading content packs. For this, the engine ensures that there is a special path `"user://"` that is always writable.
+Writing to disk is still needed often, from doing a save game to downloading content packs. For this, the engine ensures that there is a special path `"user://"` that is always writable.
 
 ### Host Filesystem
 
@@ -52,8 +52,7 @@ Of course, opening the host filesystem always works, as this is always useful wh
 
 ### Drawbacks
 
-
-Not everything is rosy. Using resources and files and the plain filesystem has two main drawbacks. The first is that moving assets around (renaming them or moving them from a directory to another inside the project) once they are referenced is not that easy. If this is done, then dependencies will need to be re-satisfied upon load. 
+Not everything is rosy. Using resources and files and the plain filesystem has two main drawbacks. The first is that moving assets around (renaming them or moving them from one directory to another inside the project) once they are referenced is not that easy. If this is done, then dependencies will need to be re-satisfied upon load. 
 
 The second is that under Windows or OSX, file access is case insensitive. If a developer works in this operating system and saves a file like "myfile.PNG", then references it as "myfile.png", it will work there, but not on any other platform, such as Linux, Android, etc. It may also not work on exported binaries, which use a compressed package for files. 
 
diff --git a/tutorial_gui.md b/tutorial_gui.md
index b5f3026..7a14a1d 100644
--- a/tutorial_gui.md
+++ b/tutorial_gui.md
@@ -2,14 +2,14 @@
 
 ### Introduction
 
-If there is something that most programmers hate with passion, that is programming graphical user interfaces (GUIs). It's boring, tedious and unchallenging. Several aspects make matters worse such as:
+If there is something that most programmers hate with passion, it's programming graphical user interfaces (GUIs). It's boring, tedious and unchallenging. Several aspects make matters worse such as:
 
-*  Pixel alignment of UI elements is difficult (so it looks just like the designer intends).
+*  Pixel alignment of UI elements is difficult (so it is hard to make it look exactly like the designer intends).
 *  UIs are changed constantly due to design and usability issues that appear during testing.
-*  Handling proper screen re-sizing for different display resolutions.
-*  Animating several screen components, to make it look less static.
+*  Handling proper screen re-sizing for different display resolutions can be challenging.
+*  It can be hard to animate several screen components to make the GUI look less static.
 
-GUI programming is one of the leading causes of programmer burnout. During the development of Godot (and previous engine iterations), several techniques and philosophies for UI development were put in practice, such as immediate mode, containers, anchors, scripting, etc. This was always done with the main goal of reducing the stress programmers had to face while putting together user interfaces.
+GUI programming is one of the leading causes of programmer burnout. During the development of Godot (and previous engine iterations), several techniques and philosophies for UI development were put into practice, such as immediate mode, containers, anchors, scripting, etc. This was always done with the main goal of reducing the stress programmers had to face while putting together user interfaces.
 
 In the end, the resulting UI subsystem in Godot is an efficient solution to this problem, and works by mixing together a few different approaches. While the learning curve is a little steeper than in other toolkits, developers can put together complex user interfaces in very little time, by sharing the same set of tools with designers and animators.
 
@@ -23,16 +23,16 @@ When controls are put in a scene tree as a child of another control, it's coordi
 
 Controls receive input events by means of the [_input_event](class_control#_input_event)() callback. Only one control, the one in focus, will receive keyboard/joypad events (see [set_focus_mode](class_control#set_focus_mode)() and [grab_focus](class_control#grab_focus)().
 
-Mouse Motion events are received by the control directly below the mouse pointer. When a control receives a mouse button pressed event, all subsequent motion events are received by the pressed control until that button is released, even if the pointer moves outside the control boundary.
+Mouse motion events are received by the control directly below the mouse pointer. When a control receives a mouse button pressed event, all subsequent motion events are received by the pressed control until that button is released, even if the pointer moves outside the control boundary.
 
-Like any class that inherits from [CanvasItem](class_canvasitem) (Control does), a [_draw](class_canvasitem#draw)() callback will be received at the begining and every time the control needs to be redrawn (programmer needs to call [update](class_canvasitem#update)() to enqueue the CanvasItem for redraw). If the control is not visible (yet aother CanvasItem property), the control does not receive any input.
+Like any class that inherits from [CanvasItem](class_canvasitem) (Control does), a [_draw](class_canvasitem#draw)() callback will be received at the beginning and every time the control needs to be redrawn (programmer needs to call [update](class_canvasitem#update)() to enqueue the CanvasItem for redraw). If the control is not visible (yet another CanvasItem property), the control does not receive any input.
 
-In general though, the programmer does not need to deal with drawing and input events directly when building UIs, (that is more useful when creating custom controls). Instead, controls emit different kinds of signals with contextural information for when action occurs. For example, a [Button](class_button) emits a "pressed" signal when pressed, a [Slider](class_slider) will emit a "value_changed" when dragged, etc.
+In general though, the programmer does not need to deal with drawing and input events directly when building UIs. Those things are more useful when creating custom controls. Instead, controls emit different kinds of signals with contextual information when actions occurs. For example, a [Button](class_button) emits a "pressed" signal when pressed, a [Slider](class_slider) will emit a "value_changed" signal when dragged, etc.
 
 ### Custom Control Mini Tutorial
 
-Before going into more depth, creating a custom control will be a good way to get the picture on how controls works, as they are not as complex as it might seem.
-Additionally, even though Godot comes with dozens of controls for different purposes, it happens often that it's just easier to attain a specific functionality by creating a new one.
+Before going into more depth, creating a custom control will be a good way to get the picture of how controls work. They are not as complex as they might seem.
+Additionally, even though Godot comes with dozens of controls for different purposes, often it's just easier to attain a specific functionality by creating a custom control.
 
 To begin, create a single-node scene. The node is of type "Control" and has a certain area of the screen in the 2D editor, like this:
 
@@ -44,46 +44,46 @@ Add a script to that node, with the following code:
 
 extends Control
 
-var tapped=false
+var tapped = false
 
 func _draw():
 
-	var r = Rect2( Vector2(), get_size() )
+	var r = Rect2(Vector2(), get_size())
 	if (tapped):
-		draw_rect(r, Color(1,0,0) )
+		draw_rect(r, Color(1,0,0))
 	else:
-		draw_rect(r, Color(0,0,1) )
+		draw_rect(r, Color(0,0,1))
 
 func _input_event(ev):
 
-	if (ev.type==InputEvent.MOUSE_BUTTON and ev.pressed):
-		tapped=true
+	if (ev.type == InputEvent.MOUSE_BUTTON and ev.pressed):
+		tapped = true
 		update()
 
 ```
 
-Then run the scene. When the rectangle is clicked/taped, it will go from blue to red. That synnergy between the events and drawing is pretty much how most controls work internally. 
+Then run the scene. When the rectangle is clicked/tapped, it will go from blue to red. That interaction between the events and drawing is pretty much how most controls work internally.
 
 <p align="center"><img src="images/ctrl_normal.png"></p>
 <p align="center"><img src="images/ctrl_tapped.png"></p>
 
 ### UI Complexity
 
-As mentioned before, Godot includes dozens of controls ready for using in a user interface. Such controls are divided in two categories. The first is a small set of controls that work well for creating most game user interfaces. The second (and most controls are of this type) are meant for complex user interfaces and uniform skinning trough styles. A description is presented as follows to help understand which one should be used in which case.
+As mentioned before, Godot includes dozens of controls ready for using in a user interface. Such controls are divided into two categories. The first is a small set of controls that work well for creating most game user interfaces. The second (and most controls are of this type) are meant for complex user interfaces and uniform skinning through styles. A description is presented below to help you understand which one should be used in which case.
 
 #### Simplified UI Controls
 
-This set of controls is enough for most games, where complex interactions or ways to present information are not necessary. The can be skinned easily with regular textures.
+This set of controls is enough for most games, where complex interactions or ways to present information are not necessary. They can be skinned easily with regular textures.
 
 *  [Label](class_label) : Node used for showing text.
 *  [TextureFrame](class_textureframe) : Displays a single texture, which can be scaled or kept fixed.
-*  [TextureButton](class_texturebutton) : Displays a simple texture buttons, states such as pressed, hover, disabled, etc can be set.
+*  [TextureButton](class_texturebutton) : Displays a simple textured button. States such as pressed, hover, disabled, etc can be set.
 *  [TextureProgress](class_textureprogress) : Displays a single textured progress bar.
 
 
-Additionally, re-positioning of controls is most efficiently done with anchors in this case (see the [Size and Anchors](tutorial_gui_repositioning) tutorial for more info).
+Additionally, re-positioning of controls is most efficiently done with anchors when using these controls (see the [Size and Anchors](tutorial_gui_repositioning) tutorial for more info).
 
-In any case, it will happen often that even for simple games, more complex UI behaviors will be required. An example of this is a scrolling list of elements (for a high score table, for example), which needs a [ScrollContainer](class_scrollcontainer) and a [VBoxContainer](class_vboxcontainer). These kind of more advanced controls can be mixed with the regular ones seamlessly (they are all controls anyway).
+In any case, even for simple games, more complex UI behaviors will often be required. An example of this is a scrolling list of elements (for a high score table, for example), which needs a [ScrollContainer](class_scrollcontainer) and a [VBoxContainer](class_vboxcontainer). These kind of more advanced controls can be mixed with the regular ones seamlessly.
 
 #### Complex UI Controls
 
diff --git a/tutorial_gui_repositioning.md b/tutorial_gui_repositioning.md
index fb0c60f..6cc5ecc 100644
--- a/tutorial_gui_repositioning.md
+++ b/tutorial_gui_repositioning.md
@@ -1,11 +1,10 @@
-
 ### Size and Anchors
 
-If a game was to be always run in the same device and at the same resolution, positioning controls would be a simple matter of setting the position and size of each one of them. Unfortunately, it is rarely the case. 
+If a game was to be always run in the same device and at the same resolution, positioning controls would be a simple matter of setting the position and size of each one of them. Unfortunately, that is rarely the case. 
 
 Only TVs nowadays have a standard resolution and aspect ratio. Everything else, from computer monitors to tablets, portable consoles and mobile phones have different resolutions and aspect ratios.
 
-There are several ways to handle this, but for now let's just imagine that the screen resolution has chanced and the controls need to be re-positioned. Some will need to follow the bottom of the screen, others the top of the screen, or maybe the right or left margins.
+There are several ways to handle this, but for now let's just imagine that the screen resolution has changed and the controls need to be re-positioned. Some will need to follow the bottom of the screen, others the top of the screen, or maybe the right or left margins.
 
 <p align="center"><img src="images/anchors.png"></p>
 
diff --git a/tutorial_instancing.md b/tutorial_instancing.md
index 59cd455..156785b 100644
--- a/tutorial_instancing.md
+++ b/tutorial_instancing.md
@@ -2,13 +2,13 @@
 
 ###Rationale
 
-Having a scene and throwing nodes to it might work for small projects, but as a project grows, more and more nodes are used and it can quickly become unmanageable. To solve this, Godot allows a project to be separated in several scenes. This, however, does not work the same way as in other game engines. In fact, it's quite different, So please do not skip this tutorial!
+Having a scene and throwing nodes into it might work for small projects, but as a project grows, more and more nodes are used and the scene can quickly become unmanageable. To solve this, Godot allows a project to be separated into several scenes. This, however, does not work the same way as in other game engines. In fact, it's quite different. So please do not skip this tutorial!
 
 To recap: A scene is a collection of nodes organized as a tree, where they can have only one single node as the tree root. 
 
 <p align="center"><img src="images/tree.png"/></p>
 
-In Godot, a scene can be created and saved it to disk. As many scenes can be created and saved as desired.
+In Godot, a scene can be created and saved to disk. As many scenes can be created and saved as desired.
 
 <p align="center"><img src="images/instancingpre.png"/></p>
 
@@ -74,6 +74,6 @@ The next it will happen is that a green "revert" button appears. When this butto
 
 ###Conclusion
 
-Instancing seems handy, but there is more to it than it meets the eye! The next part of the instancing tutorial should cover the rest..
+Instancing seems handy, but there is more to it than meets the eye! The next part of the instancing tutorial should cover the rest...
 
 
diff --git a/tutorial_instancing_2.md b/tutorial_instancing_2.md
index b036a81..c0a572c 100644
--- a/tutorial_instancing_2.md
+++ b/tutorial_instancing_2.md
@@ -10,9 +10,9 @@ Instancing has many handy uses. At a glance, with instancing you have:
 
 ###Design Language
 
-But the real strong point of instancing scenes is that it works as an excellent design language. This is pretty much what makes Godot special and different to any other engine out there. All the engine was designed from the ground around this concept.
+But the real strong point of instancing scenes is that it works as an excellent design language. This is pretty much what makes Godot special and different from any other engine out there.  The entire engine was designed around this concept.
 
-When making games with Godot, the recommended approach is to leave aside other design patterns such as MVC or Entity-Relationship diagrams and start thinking games in a more natural way. Start by imagining the visible elements in a game, the ones that can be named not by just a programmer but by anyone.
+When making games with Godot, the recommended approach is to leave aside other design patterns such as MVC or Entity-Relationship diagrams and start thinking about games in a more natural way. Start by imagining the visible elements in a game, the ones that can be named not by just a programmer but by anyone.
 
 For example, here's how a simple shooter game can be imagined:
 
@@ -20,22 +20,22 @@ For example, here's how a simple shooter game can be imagined:
 
 It's pretty easy to come up with a diagram like this for almost any kind of game. Just write down the elements that come to mind, and then the arrows that represent ownership.
 
-Once this diagram exists, making a game is about creating a scene for each of those nodes, and use instancing (either by code -more of that later- or from the editor) to represent ownership. 
+Once this diagram exists, making a game is about creating a scene for each of those nodes, and using instancing (either by code -more on that later- or from the editor) to represent ownership. 
 
-Most of the time programming games (or software in general) is spent designing an architecture and fitting game components to that architecture. Designing based on scenes replaces that and makes development much faster and more straightforward, allowing to concentrate on the game itself. Scene/Instancing based design is extremely efficient at saving a large part of that work, since most of the components designed map directly to a scene. This way, none or little architectural code is needed.
+Most of the time programming games (or software in general) is spent designing an architecture and fitting game components to that architecture. Designing based on scenes replaces that and makes development much faster and more straightforward, allowing you to concentrate on the game itself. Scene/Instancing based design is extremely efficient at saving a large part of that work, since most of the components map directly to a scene. This way little or no architectural code is needed.
 
 The following is a more complex example, an open-world type of game with lots of assets and parts that interact: 
 
 <p align="center"><img src="images/openworld_instancing.png"/></p>
 
-Make some rooms with furniture, then connect them. Make a house later, and use those rooms are the interior.
-The house can be part of a citadel, which has many houses. Finally the citadel can be put on the world map terrain. Add also guards and other NPCs to the citadel by previously creating their scenes. 
+Make some rooms with furniture, then connect them. Make a house later, and use those rooms as the interior.
+The house can be part of a citadel, which has many houses. Finally the citadel can be put on the world map terrain. Add also guards and other NPCs to the citadel by instancing scenes previously created which represent them. 
 
-With Godot, games can grow as quickly as desired, as only more scenes have to be made and instanced. The editor UI is also designed to be operated by non programmers too, so an usual team development process involves 3D or 2D artists, level designers, game designers, animators, etc all working with the editor interface.
+With Godot, games can grow as quickly as desired, as only more scenes have to be made and instanced. The editor UI is also designed to be operated by non programmers, so a typical team development process involves 3D or 2D artists, level designers, game designers, animators, etc all working with the editor interface.
 
 ###Information Overload!
 
-Do not worry to much, the important part of this tutorial is to create awareness on how scenes and instancing are used in real life. The best way to understand all this is to make some games. 
+Do not worry too much, the important part of this tutorial is to create awareness of how scenes and instancing are used in real life. The best way to understand all this is to make some games. 
 
-Everything will become very obvious when put to practice, so, please do not scratch your head and go on to the next tutorial!
+Everything will become very obvious when put into practice, so, please do not scratch your head and go on to the next tutorial!
 
diff --git a/tutorial_resources.md b/tutorial_resources.md
index 2daa326..f1253e5 100644
--- a/tutorial_resources.md
+++ b/tutorial_resources.md
@@ -2,18 +2,18 @@
 
 ### Nodes AND Resources
 
-So far, [Node](class_node) have been the most important datatype in Godot, as most of the behaviors and features of the engine are implemented through them. There is, though, another datatype that is equally as important. That is [Resource](class_resource)..
+So far, [Nodes](class_node) have been the most important datatype in Godot, as most of the behaviors and features of the engine are implemented through them. There is, though, another datatype that is equally as important. That is [Resources](class_resource)..
 
 Where *Nodes* focus on behaviors, such as drawing a sprite, drawing a 3D model, physics, GUI controls, etc, 
 *Resources* are mere *data containers*. This means that they don't do any action nor process any information. Resources just contain data.
 
 Examples of resources are [Texture](class_texture), [Script](class_script), [Mesh](class_mesh), [Animation](class_animation), [Sample](class_sample), [AudioStream](class_audiostream), [Font](class_font), [Translation](class_translation), etc.
 
-When Godot saves o loads (from disk) a scene (.scn or .xml), an image (png, jpg), a scrit (.gd) or pretty much anything, that file is considered a resource.
+When Godot saves or loads (from disk) a scene (.scn or .xml), an image (png, jpg), a script (.gd) or pretty much anything, that file is considered a resource.
 
 When a resource is loaded from disk, **it is always loaded once**. That means, if there is a copy of that resource already loaded in memory, trying to load the resource again will just return the same copy again and again. This corresponds with the fact that resources are just data containers, so there is no need to have them duplicated.
 
-Typically, every object in Godot (Node, Resource, or anything else) can export properties, properties can be of many types (like a string, integer, Vector2, etc) and one of those types can be a resource. This means that both nodes and resources can contain resources as properties. To make it a litle more visual:
+Typically, every object in Godot (Node, Resource, or anything else) can export properties, properties can be of many types (like a string, integer, Vector2, etc) and one of those types can be a resource. This means that both nodes and resources can contain resources as properties. To make it a little more visual:
 
 <p align="center"><img src="images/nodes_resources.png"></p>
 
@@ -28,7 +28,7 @@ Pressing the the ">" button the right side of the preview, allows to view and ed
 
 <p align="center"><img src="images/resourcerobi.png"></p>
 
-When the resource comes from a file, it is considered an *external* resource. If the path property is erased (or never had a path o begin with), it is then considered a built-in resource. 
+When the resource comes from a file, it is considered an *external* resource. If the path property is erased (or never had a path to begin with), it is considered a built-in resource. 
 
 For example, if the path `"res://robi.png"` is erased from the "path" property in the above example, and then the scene is saved, the resource will be saved inside the .scn scene file, no longer referencing the external "robi.png". However, even if saved as built-in, and even though the scene can be instanced multiple times, the resource will still always be loaded once. That means, different Robi robot scenes instanced at the same time will still share the same image.
 
@@ -57,9 +57,9 @@ func _ready():
 
 ### Loading Scenes
 
-Scenes are also resources, but there is a catch. Scenes saved to disk are resources of type [PackedScene](class_packedscene), this means that the scene is packed inside a resource.
+Scenes are also resources, but there is a catch. Scenes saved to disk are resources of type [PackedScene](class_packedscene). This means that the scene is packed inside a resource.
 
-To obtain an instance of the scene, the method  [instance](class_packedscene#instance)() must be used. 
+To obtain an instance of the scene, the method [instance](class_packedscene#instance)() must be used. 
 ```python
 func _on_shoot():
 
@@ -67,7 +67,7 @@ func _on_shoot():
         add_child(bullet)                  
 ```
 
-This method creates the nodes in hierarchy, configures them (sets all the properties) and returns the root node of the scene, which can be added to any other node.
+This method creates the nodes in the scene's hierarchy, configures them (sets all the properties) and returns the root node of the scene, which can be added to any other node.
 The approach has several advantages. As the [instance](class_packedscene#instance)() function is pretty fast, adding extra content to the scene can be done efficiently. New enemies, bullets, effects, etc can be added or removed quickly, without having to load them again from disk each time. It is important to remember that, as always, images, meshes, etc are all shared between the scene instances.
 
 ### Freeing Resources
@@ -76,7 +76,7 @@ Resource extends from [Reference](class_reference). As such, when a resource is
 
 ### Scripting
 
-Like any object in Godot, not just nodes, Resources can be scripted too. However, there isn't generally much of a win, as resources are just data containers.
+Like any object in Godot, not just nodes, resources can be scripted too. However, there isn't generally much reason to, as resources are just data containers.
 
 
 
diff --git a/tutorial_scene.md b/tutorial_scene.md
index 3ec7531..69f6e23 100644
--- a/tutorial_scene.md
+++ b/tutorial_scene.md
@@ -6,29 +6,29 @@
 
 Imagine for a second that you are not a game developer anymore. Instead, You are a chef! Change your hipster outfit for a toque and a double breasted jacket. Now, instead of making games, you create new and delicious recipes for your guests. 
 
-So, how does a chef create a recipe? Recipes are divided in two sections, the first is the ingredients and the second is the instructions to prepare it. This way, anyone can follow the recipe and savor your magnificent creation.
+So, how does a chef create a recipe? Recipes are divided into two sections, the first is the ingredients and the second is the instructions to prepare it. This way, anyone can follow the recipe and savor your magnificent creation.
 
 Making games in Godot feels pretty much the same way. Using the engine feels like being in a kitchen. In this kitchen, *nodes* are like a refrigerator full of fresh ingredients to cook with.
 
-There are many types of nodes, some show images, others play sound, other nodes display 3D models, etc. There's dozens of them.
+There are many types of nodes. Some show images, others play sound, other nodes display 3D models, etc. There are dozens of them.
 
 ### Nodes
 
 But let's go to the basics. A node is a basic element for creating a game, it has the following characteristics:
 
-*  Has a name.
-*  Has editable properties.
-*  Can receive a callback to process every frame.
-*  Can be extended (to have more functions).
-*  Can be added other nodes as children.
+*  It has a name.
+*  It has editable properties.
+*  It can receive a callback to process every frame.
+*  It can be extended (to have more functions).
+*  It can be have other nodes as children.
 
 
 <p align="center"><img src="images/tree.png"></p>
 The last one is very important. Nodes can have other nodes as children. When arranged in this way, the nodes become a *tree*. 
 
-In Godot, the ability to arrange nodes in this way creates a powerful tool for organizing the projects. Since different nodes have different functions, combining them allows to create more complex functions.
+In Godot, the ability to arrange nodes in this way creates a powerful tool for organizing the projects. Since different nodes have different functions, combining them allows you to create more complex functions.
 
-This is probably not clear yet and it makes little sense, but everything will click a few sections ahead. The most important fact to remember for now is that nodes exist and can be arranged this way.
+This is probably not clear yet, but everything will click in a few sections. The most important fact to remember for now is that nodes exist and can be arranged this way.
 
 ### Scenes
 
@@ -46,9 +46,9 @@ Basically, the Godot editor is a *scene editor*. It has plenty of tools for edit
 
 ### Creating New Project
 
-Theory is boring, so let's change subject and go practical. Following a long tradition in tutorials, the first project will be a hello world. For this, the editor will be used.
+Theory is boring, so let's get practical. Following a long tradition in tutorials, the first project will just display "Hello world!". For this, the editor will be used.
 
-When godot executable is run outside a project, the Project Manager appears. This helps developers manage their projects.
+When the godot executable is run outside a project, the Project Manager appears. This helps developers manage their projects.
 
 <p align="center"><img src="images/newproject.png"></p>
 
@@ -63,7 +63,7 @@ Once the "New Project" is created, the next step is opening it. This will open t
 <p align="center"><img src="images/editor.png"></p>
 
 
-As mentioned before, making games in Godot feels like being in a kitchen, so let's open the refrigerator and add some fresh nodes to the project. We'll begin with a Hello World! To do this, the "New Node" button must be pressed:
+As mentioned before, making games in Godot feels like being in a kitchen, so let's open the refrigerator and add some fresh nodes to the project. We'll begin with a label that displays "Hello World!" To do this, the "New Node" button must be pressed:
 
 <p align="center"><img src="images/newnode.png"></p>
 
@@ -81,9 +81,9 @@ And finally, create the Label! A lot happens when Create is pressed:
 <p align="center"><img src="images/addedlabel.png"></p>
 
 First of all, the scene is changed to the 2D editor (because Label is a 2D Node type), and the Label appears, selected, at the top left corner of the viewport.
-The node appears in the scene tree editor (box in the top right corner), and the label properties apear in the Inspector (box in the bottom right corner).
+The node appears in the scene tree editor (box in the top right corner), and the label properties appear in the Inspector (box in the bottom right corner).
 
-The next step, will be to change the "Text" Property of the label, let change it to "Hello, World!":
+The next step, will be to change the "Text" Property of the label. Let's change it to "Hello, World!":
 
 <p align="center"><img src="images/hw.png"></p>
 
@@ -99,7 +99,7 @@ Scenes need to be saved to be run, so save the scene to something like hello.scn
 
 <p align="center"><img src="images/savescene.png"></p>
  
-And here's when something funny happens. The file dialog is a special file dialog, and only allows to save inside the project. `The project root is "res://" which means "resource path. This means that files can only be saved inside the project. For the future, when doing file operations in Godot, remember that "res://" is the resource path, and no matter the platform or install location, it is the way to locate where resource files are from inside the game.`
+And here's when something funny happens. The file dialog is a special file dialog, and only allows you to save inside the project. `The project root is "res://" which means "resource path". This means that files can only be saved inside the project. For the future, when doing file operations in Godot, remember that "res://" is the resource path, and no matter the platform or install location, it is the way to locate where resource files are from inside the game.`
 
 After saving the scene and pressing run scene again, the "Hello, World!" demo should finally execute:
 
@@ -121,10 +121,9 @@ Once the window opens, the task will be to select a main scene. This can be done
 
 With this change, pressing the regular Play button (or F5) will run the project, no matter which scene is being edited.
 
-Going back to the project settings dialog. This dialog provides a lot of options that can be added to engine.cfg and show their default values. If the default value is ok, then there isn't any need to change it.
-When a value is changed, a tick is marked to the left of the name. This means that the property will be saved to the engine.cfg file and remembered. 
+Going back to the project settings dialog. This dialog provides a lot of options that can be added to engine.cfg and show their default values. If the default value is ok, then there isn't any need to change it. When a value is changed, a tick is marked to the left of the name. This means that the property will be saved to the engine.cfg file and remembered. 
 
-As a side note, for future reference and a little out of context (this is the first tutorial after all!), it is also possible to add custom configuration options and read them in run-time using the [Globals](class_globals) singleton. 
+As a side note, it is also possible to add custom configuration options and read them in at run-time using the [Globals](class_globals) singleton. 
 
 ### To Be Continued...
 
diff --git a/tutorial_scene_main_loop.md b/tutorial_scene_main_loop.md
index 2a84333..dda2175 100644
--- a/tutorial_scene_main_loop.md
+++ b/tutorial_scene_main_loop.md
@@ -3,7 +3,7 @@
 ### Introduction
 
 This is where things start getting abstract, but don't panic, as there's not really more depth than this.
-In previous tutorials, everything revolves around the concept of Nodes, scenes are made of them, and they become active once they enter the active scene.
+In previous tutorials, everything revolves around the concept of Nodes. Scenes are made of them, and they become active once they enter the active scene.
 
 This deserves going a little more into depth. In fact, the scene system is not even a core component of Godot, as it is possible to skip it and make a script (or C++ code) that talks directly to the [Servers](tutorial_servers). But making a game that way would be a lot of work and is reserved for other uses.
 
@@ -12,7 +12,7 @@ This deserves going a little more into depth. In fact, the scene system is not e
 The way Godot works internally is as follows. There is the the [OS](class_os) class, which is the only instance that runs at the beginning. Afterwards, all drivers, servers, scripting languages, scene system, etc are loaded. 
 When initialization is complete, [OS](class_os) needs to be supplied a [MainLoop](class_mainloop) to run. Up to this point, all this is internals working (you can check main/main.cpp file in the source code if you are ever interested to see how this works internally). 
 
-The user program, or game, starts in the MainLoop. This class has a few methods, for initialization, idle (frame-syncronized callback), fixed (physics-synchronized callback), and input. Again, this is really low level and when making games in Godot, writing your own MainLoop does not even make sense. 
+The user program, or game, starts in the MainLoop. This class has a few methods, for initialization, idle (frame-synchronized callback), fixed (physics-synchronized callback), and input. Again, this is really low level and when making games in Godot, writing your own MainLoop does not even make sense. 
 
 ### SceneMainLoop
 
@@ -24,7 +24,7 @@ This is automatically instanced and set when running a scene, no need to do any
 
 It's important to know that this class exists because it has a few important uses:
 
-*  It contains the root [Viewport](class_viewport), when a scene is first opened, it's added as a child of it to become part of the active scene (more on that next)
+*  It contains the root [Viewport](class_viewport). When a scene is first opened, the root Viewport is added as a child of the scene to become part of the active scene (more on that next)
 *  It contains information about the groups, and has means to call all nodes in a group, or get a list of them.
 *  It contains some global state functionality, such as setting pause mode, or quitting the process.
 
@@ -32,7 +32,7 @@ When a node is part of the active scene, the [SceneMainLoop](class_scenemainloop
 
 ### Root Viewport
 
-The root [Viewport](class_viewport) is always a top of the scene. From a node, it can be obtained in two different ways:
+The root [Viewport](class_viewport) is always at the top of the node hierarchy. From a node, it can be obtained in two different ways:
 
 ```python
     get_scene().get_root() # access via scenemainloop
@@ -46,7 +46,7 @@ While other viewports can be created in the scene (for split-screen effects and
 ### Active Scene
 
 When a node is connected, directly or indirectly, to the root viewport, it becomes part of the active scene. 
-This means that, as explained in previous tutorials, will get the _enter_scene() and _ready() callbacks (as well as _exit_scene()).
+This means that, as explained in previous tutorials, it will get the _enter_scene() and _ready() callbacks (as well as _exit_scene()).
 
 <p align="center"><img src="images/activescene.png"></p>
 
@@ -64,7 +64,7 @@ Most node operations in Godot, such as drawing 2D, processing or getting notific
  2.  The root node of that scene (only one root, remember?) is added as either a child of the “root” Viewport (from SceneMainLoop), or to any child or grand-child of it.
  3.  Every node of the newly added scene, will receive the “enter_scene” notification ( _enter_scene() callback in GDScript) in top-to-bottom order.
  4.  An extra notification, “ready” ( _ready() callback in GDScript) is provided for convenience, when a node and all it’s children are inside the active scene.
- 5.  When a scene (or part of it) is removed, they receive the “exit scene” rotification ( _exit_scene() callback in GDScript) in bottom-to-top order
+ 5.  When a scene (or part of it) is removed, they receive the “exit scene” notification ( _exit_scene() callback in GDScript) in bottom-to-top order.
 
 
 
diff --git a/tutorial_scripting.md b/tutorial_scripting.md
index 7930d82..3989539 100644
--- a/tutorial_scripting.md
+++ b/tutorial_scripting.md
@@ -6,17 +6,17 @@ Much has been said about tools that allow users to create video games without pr
 
 Many products have been shipped promising a no-programming environment, but the result is often incomplete, too complex or inefficient compared to traditional code. As a result, programming is here to stay for a long time. In fact, the general direction in game engines has been to add tools that try to reduce the amount of code that needs to be written for specific tasks, to speed up development. 
 
-In that sense, Godot has taken some useful design decisions towards that goal. The first and most important is the scene system. The aim of it is not obvious at first, but works well later on. That is, to relieve programmers from the responsibility of architecting code. 
+In that sense, Godot has taken some useful design decisions towards that goal. The first and most important is the scene system. The aim of it is not obvious at first, but but it becomes clear later on that it relieves programmers from the responsibility of architecting code. 
 
 When designing games using the scene system, the whole project is fragmented in *complementary* scenes (not individual ones). Scenes complement each other, instead of being separate. There will be plenty of examples  about this later on, but it's very important to remember it.
 
-For those with a good amount of programming expertise, this means a different design pattern to MVC. Godot promises efficiency at the expense of dropping the MVC habits, which are replaced by the *scenes as a complement* pattern.
+For those with a good amount of programming expertise, this means a different design pattern from MVC. Godot promises efficiency in return for dropping the MVC habits. The MVC pattern is replaced by the *scenes as a complement* pattern.
 
 Godot also uses the [extend](http://c2.com/cgi/wiki?EmbedVsExtend) pattern for scripting, meaning that scripts extends from all the available engine classes.
 
 ### GDScript
 
-[GDScript](gdscript) (click link for reference) is a dynamically typed scripting language to fit inside Godot. It was designed with the following goals:
+[GDScript](gdscript) (click link for reference) is a dynamically typed scripting language that fits inside Godot. It was designed with the following goals:
 
 *  First and most importantly, making it simple, familiar and as easy to learn as possible.
 *  Making the code readable and error safe. The syntax is mostly borrowed from Python.
@@ -29,7 +29,7 @@ In any case, if more performance is required, critical sections can be rewritten
 
 ### Scripting a Scene
 
-Before continuing, please make sure to read the [GDScript](gdscript) reference. It's a simple language and the reference is short, should not take more than a few minutes to glance.
+Before continuing, please make sure to read the [GDScript](gdscript) reference. It's a simple language and the reference is short. It should not take more than a few minutes to glance.
 
 #### Scene Setup
 
@@ -67,15 +67,15 @@ Once this is done, the script will be created and added to the node. You can see
 <p align="center"><img src="images/scriptadded.png"></p>
 
 
-To edit the script, pushing the icon above should do it (although, the UI will take you directly to the Script editor screen). So, here's the template script:
+To edit the script, pushing the icon above should do it (although the UI will take you directly to the Script editor screen). So, here's the template script:
 
 <p align="center"><img src="images/script_template.png"></p>
 
-There is not much in there. The "_ready()" function is called when the node (and all it's children) entered the active scene. (Remember, It's not a constructor, the constructor is "_init()" ). 
+There is not much in there. The "_ready()" function is called when the node (and all it's children) entered the active scene. Remember, it's not a constructor; the constructor is "_init()". 
 
 #### Handling a Signal
 
-Signals are used mostly in GUI nodes, (although other nodes have them too). Signals are "emitted" when some specific kind of action happens, and can be connected to any function of any script instance. In this step, the "pressed" signal from the button will be connected to a custom function.
+Signals are used mostly in GUI nodes, although other nodes have them too. Signals are "emitted" when some specific kind of action happens, and can be connected to any function of any script instance. In this step, the "pressed" signal from the button will be connected to a custom function.
 
 There is a GUI for connecting signals, just select the node and press the "Signals" button:
 
@@ -86,9 +86,9 @@ Which will show the list of signals a Button can emit.
 <p align="center"><img src="images/button_connections.png"></p>
 
 But this example will not use it. We don't want to make things *too* easy. So please close that screen!
-In any case, at this point it is clear that that we are interested in the "pressed" signal, so instead of doing it with the visual interface, the connection will be done using code. 
+In any case, at this point it is clear that that we are interested in the "pressed" signal, so instead of using the visual interface, the connection will be made using code. 
 
-For this, there is a function that is probably the one that Godot programmers will use the most, this is [get_node](class_node#get_node)(). This function uses paths to fetch nodes in the current tree or anywhere in the scene, relative to the node holding the script.
+For this, there is a function that is probably the one that Godot programmers will use the most. This is [get_node](class_node#get_node)(). This function uses paths to fetch nodes in the current tree or anywhere in the scene, relative to the node holding the script.
 
 To fetch the button, the following must be used:
 
@@ -98,7 +98,7 @@ get_node("Button")
 
 ```
 
-So, next, a callback will be added for when a button is pressed, that will change the label's text:
+So, next, a callback will be added for when a button is pressed. The callback will change the label's text:
 
 ```python
 
diff --git a/tutorial_scripting_2.md b/tutorial_scripting_2.md
index be3498e..8ec8d26 100644
--- a/tutorial_scripting_2.md
+++ b/tutorial_scripting_2.md
@@ -2,9 +2,9 @@
 
 ### Processing
 
-Several actions in Godot are triggered by callbacks or virtual functions, so there is no need to check for writing code that runs all time time. Additionally, a lot can be done with animation players.
+Several actions in Godot are triggered by callbacks or virtual functions, so there is no need to write code that runs all the time. Additionally, a lot can be done with animation players.
 
-However,it is still a very common case to have a script process on every frame. There are two types of processing, idle processing and fixed processing.
+However, it is still a very common case to have a script process on every frame. There are two types of processing, idle processing and fixed processing.
 
 Idle processing is activated with the [Node.set_process](class_node#set_process)() function. Once active, the [Node._process](class_node#set_process)() callback will be called every frame. Example:
 
@@ -36,11 +36,11 @@ func _process(delta):
 
 ```
 
-Which will show a counter increasing each second.
+Which will show the constantly increasing time in seconds (and fractions of a second) since the scene started.
 
 ### Groups
 
-Nodes can be added to groups (as many as desired per node). This is a simple yet useful feature for organizing large scenes. There are two ways to do this, the first is from the UI, from tne Groups button:
+Nodes can be added to groups (as many as desired per node). This is a simple yet useful feature for organizing large scenes. There are two ways to do this, the first is from the UI, from the Groups button:
 
 <p align="center"><img src="images/groups.png"></p>
 
@@ -77,7 +77,7 @@ More will be added about [SceneMainLoop](class_scenemainloop) later.
 
 ### Notifications
 
-Godot has a system of notifications. This is usually not needed to be used from scripting, as it's too low level and virtual functions are provided for most of them. It's just good to know they exists. Simply add a [Object._notification](class_object#_notification)() function in your script:
+Godot has a system of notifications. This usually doesn't need to be used from scripting, as it's too low level and virtual functions are provided for most of them. It's just good to know they exists. Simply add a [Object._notification](class_object#_notification)() function in your script:
 
 ```python
 
@@ -99,37 +99,48 @@ As mentioned before, it's better to use these functions. Nodes provide many usef
 ```python
 
 func _enter_scene():
-   pass # When the node enters the active scene, this function is called. Children nodes have not entered the active scene yet. In general, it's better to use _ready() for most cases.
+   # When the node enters the active scene, this function is called. Children nodes have
+   # not entered the active scene yet. In general, it's better to use _ready() for most cases.
+   pass
 
 func _ready():
-   pass # This function is called after _enter_scene, but it ensures that all children nodes have also entered the active scene, and they are all functional.
-   
+   # This function is called after _enter_scene, but it ensures that all children nodes 
+   # have also entered the active scene, and they are all functional.
+   pass
+
 func _exit_scene():
-   pass # When the node exists the active scene, this function is called. Children nodes have all exited the active scene at this point.
+   # When the node exists the active scene, this function is called. Children nodes have all
+   # exited the active scene at this point.
+   pass
    
 func _process(delta):
-   pass # When set_process() is enabled, this is called every frame
+   # When set_process() is enabled, this is called every frame.
+   pass
 
 func _fixed_process(delta):
-   pass # When set_fixed_process() is enabled, this is called every physics frame
+   # When set_fixed_process() is enabled, this is called every physics frame.
+   pass
    
 func _paused():
-   pass #Called when game is paused, after this call, the node will not receive any more process callbacks
+   # Called when game is paused. While the game is paused, the node will not receive any 
+   # more process callbacks.
+   pass
    
 func _unpaused():
-   pass #Called when game is unpaused   
+   # Called when game is unpaused.
+   pass
    
 ```
 
 ### Creating Nodes
 
-To create a node from code, just call the .new() method, (like for any other class based datatype). Example:
+To create a node from code, call the .new() method, just like for any other class based datatype. Example:
 
 ```python
 var s
 func _ready():
    s = Sprite.new() # create a new sprite!
-   add_child(s) #add it as a child of this node
+   add_child(s) # add it as a child of this node
 ```
 
 To delete a node, be it inside or outside the scene, free() must be used:
@@ -141,9 +152,7 @@ func _someaction():
 
 When a node is freed, it also frees all it's children nodes. Because of this, manually deleting nodes is much simpler than it appears. Just free the base node and everything else in the sub-tree goes away with it.
 
-However, it might happen very often that we might want to delete a node that is currently "blocked" this means, the node is emitting a signal or calling a function. This will result in crashing the game. Running Godot in the debugger often will catch this case and warn you about it.
-
-The safest way to delete a node is by using [queue_free](class_node#queue_free)() instead. This erases the node during idle, safely.
+However, if you try to delete a node that is currently "blocked" (because it is emitting a signal or calling a function) you will crash the game. Running Godot in the debugger often will catch this case and warn you about it, but the safest way to delete a node is by using [queue_free](class_node#queue_free)() instead. This erases the node during idle time, safely.
 
 ```python
 func _someaction():
@@ -171,7 +180,7 @@ var node = scene.instance()
 add_child(node)
 ```
 
-The advantage of this two-step process is that a packed scene may be kept loaded and ready to use, so it can be used to create as many instances as desired. This is specially useful, for example, to instance several enemies, bullets, etc. quickly in the active scene.
+The advantage of this two-step process is that a packed scene may be kept loaded and ready to use, so it can be used to create as many instances as desired. This is especially useful, for example, to instance several enemies, bullets, etc. quickly in the active scene.
 
 
     
diff --git a/tutorial_singletons.md b/tutorial_singletons.md
index bea0ce7..9413a6d 100644
--- a/tutorial_singletons.md
+++ b/tutorial_singletons.md
@@ -2,7 +2,7 @@
 
 ### Introduction
 
-Scene Singletons are very useful things, as they represent a very common use case, but it's not clear at the begining where their value is.
+Scene Singletons are very useful things, as they represent a very common use case, but it's not clear at the beginning where their value is.
 
 The scene system is very useful, but by itself it has a few drawbacks:
 
@@ -15,7 +15,7 @@ So, after using Godot for a while, it becomes clear that it is necessary to have
 *  Are always loaded, no matter which scene is opened from the editor.
 *  Can keep global variables, such as player information, items, money, etc.
 *  Can handle switching of scenes and transitions.
-*  Just have something that acts like a singleton, since GDScript does not support global variables by design.
+*  Just acts like a singleton, since GDScript does not support global variables by design.
 
 For this, the option for auto-loading nodes and scripts exists.
 
@@ -27,7 +27,7 @@ Each autoload needs a name, this name will be the node name, and the node will b
 
 <p align="center"><img src="images/singleton.png"></p>
 
-This means, that a for a singleton named "playervariables", any node can access it by requesting:
+This means, that for a singleton named "playervariables", any node can access it by requesting:
 
 ```python
 
@@ -40,11 +40,11 @@ var player_vars = get_node("/root/playervariables")
 This short tutorial will explain how to make a scene switcher by using autoload.
 First download the template from here: [autoload.zip](media/autoload.zip), then open it.
 
-Two scenes are present, scene_a.scn and scene_b.scn on an otherwise empty project. Each are identical and contain a button connected to a callback for going to the opposite scene. When the project runs, it starts n scene_a.scn. However, this does nothing and pressing the button does not work.
+Two scenes are present, scene_a.scn and scene_b.scn on an otherwise empty project. Each are identical and contain a button connected to a callback for going to the opposite scene. When the project runs, it starts in scene_a.scn. However, this does nothing and pressing the button does not work.
 
 ### global.gd
 
-First of all, create a global.gd script. The easier way to create a resource from scratch is from the resources tab:
+First of all, create a global.gd script. The easiest way to create a resource from scratch is from the resources tab:
 
 <p align="center"><img src="images/newscript.png"></p>
 
@@ -58,7 +58,7 @@ The script should be opened in the script editor. Next step will be adding it to
 <p align="center"><img src="images/addglobal.png"></p>
 
 Now, when any scene is run, the script will be always loaded.
-So, going back to it, In the _ready() function, the current scene will be fetched. Both the current scene and global.gd are children of root, but the autoloaded nodes are always first. This means that the last child of root is always the loaded scene.
+So, going back to global.gd, when the the _ready() function is called, the current scene will have already been fetched. Both the current scene and global.gd are children of root, but the autoloaded nodes are always first. This means that the last child of root is always the loaded scene.
 
 Also, make sure that global.gd extends from Node, otherwise it won't be loaded.
 
@@ -106,7 +106,7 @@ func _on_goto_scene_pressed():
 
 ```
 
-Finally, by running the project it's possible to switch bewtween both scenes y pressing the button!
+Finally, by running the project it's possible to switch between both scenes by pressing the button!
 
 
 
diff --git a/tutorial_splash.md b/tutorial_splash.md
index a44b61c..b6ed504 100644
--- a/tutorial_splash.md
+++ b/tutorial_splash.md
@@ -4,9 +4,7 @@
 
 This will be a simple tutorial to cement the basic idea of how the GUI subsystem works. The goal will be to create a really simple, static, splash screen. 
 
-Following is a file with the assets that will be used:
-
-<p align="center"><img src="robisplash_assets.zip|}}
+[Here](media/robisplash_assets.zip) is a file with the assets that will be used.
 
 
 ### Setting Up
@@ -16,18 +14,18 @@ Create a scene with screen resolution 800x450, and set it up like this:
 <p align="center"><img src="images/robisplashscene.png"></p>
 <p align="center"><img src="images/robisplashpreview.png"></p>
 
-The nodes 'background" and "logo" are of [TextureFrame](class_textureframe) type. These have a special property for setting the texture to be displayed, just load the corresponding file.
+The nodes "background" and "logo" are of [TextureFrame](class_textureframe) type. These have a special property for setting the texture to be displayed, just load the corresponding file.
 
 <p align="center"><img src="images/texframe.png"></p>
 
-The node "start" is a [TextureButton](class_texturebutton), it takes several images for different states, but only the normal and pressed will be supplied in this example:
+The node "start" is a [TextureButton](class_texturebutton), it takes several images for different states, but only the normal and pressed images will be supplied in this example:
 
 <p align="center"><img src="images/texbutton.png"></p>
 
-Finally, the node "copyright" is a [Label](class_label). Labels can be set a custom font by editing the following property:
+Finally, the node "copyright" is a [Label](class_label). Labels can use a custom font by editing the following property:
 
 <p align="center"><img src="images/label.png"></p>
 
-As a side note, the font was imported from a TTF, there is a [specific tutorial](import_fonts) for importing fonts.
+As a side note, the font was imported from a TTF. There is a [specific tutorial](import_fonts) for importing fonts.