Use "low-level" and "high-level" instead of "low level" and "high level"

Co-Authored-By: John Veness <2512915+JohnVeness@users.noreply.github.com>

contributing/development/best_practices_for_engine_contributors.rst

@@ -179,7 +179,7 @@ they'll need to do* in the future?
 .. image:: img/best_practices6.png
 
 The answer to this question is that, to ensure users still can do what they want
-to do, we need to give them access to a *low level API* that they can use to
+to do, we need to give them access to a *low-level API* that they can use to
 achieve what they want, even if it's more work for them because it means
 reimplementing some logic that already exists.
 

contributing/workflow/bug_triage_guidelines.rst

@@ -114,7 +114,7 @@ describe an issue or pull request.
 -  *3D*: relates to 3D-specific issues. Should be coupled with one of the labels below, and should not be coupled with *2D*.
 -  *Animation*: relates to the Animation system, editors and importers.
 -  *Assetlib*: relates to issues with the asset library.
--  *Audio*: relates to the audio features (low and high level).
+-  *Audio*: relates to the audio features (low- and high-level).
 -  *Buildsystem*: relates to building issues, either linked to the SCons
    buildsystem or to compiler peculiarities.
 -  *Codestyle*: relates to the programming style used within the codebase.

tutorials/2d/2d_transforms.rst

@@ -8,7 +8,7 @@ Introduction
 
 This is an overview of the 2D transforms going on for nodes from the
 moment they draw their content locally to the time they are drawn onto
-the screen. This overview discusses very low level details of the engine.
+the screen. This overview discusses very low-level details of the engine.
 
 The goal of this tutorial is to teach a way for feeding input events to the
 Input with a position in the correct coordinate system.

tutorials/2d/custom_drawing_in_2d.rst

@@ -613,7 +613,7 @@ Drawing text
 ^^^^^^^^^^^^
 
 While using the :ref:`Label <class_Label>` Node is the most common way to add
-text to your application, the low level `_draw` function includes functionality
+text to your application, the low-level `_draw` function includes functionality
 to add text to your custom Node drawing. We will use it to add the name "GODOT"
 under the robot head.
 
@@ -844,7 +844,7 @@ It will look somewhat like this when run:
 
 Please note that ``_mouth_width`` is a user defined property like any other
 and it or any other used as a drawing argument can be animated using more
-standard and high level methods such as a :ref:`Tween<class_Tween>` or an
+standard and high-level methods such as a :ref:`Tween<class_Tween>` or an
 :ref:`AnimationPlayer<class_AnimationPlayer>` Node. The only difference is
 that a ``queue_redraw()`` call is needed to apply those changes so they get
 shown on screen.

tutorials/export/exporting_for_web.rst

@@ -235,10 +235,10 @@ player to click, tap or press a key/button to enable audio, for instance when di
 Networking
 ~~~~~~~~~~
 
-.. UPDATE: Not implemented. When low level networking is implemented, remove
+.. UPDATE: Not implemented. When low-level networking is implemented, remove
 .. this paragraph.
 
-Low level networking is not implemented due to lacking support in browsers.
+Low-level networking is not implemented due to lacking support in browsers.
 
 Currently, only :ref:`HTTP client <doc_http_client_class>`,
 :ref:`HTTP requests <doc_http_request_class>`,

tutorials/networking/high_level_multiplayer.rst

@@ -97,7 +97,7 @@ for full IPv6 support.
 Initializing the network
 ------------------------
 
-High level networking in Godot is managed by the :ref:`SceneTree <class_SceneTree>`.
+High-level networking in Godot is managed by the :ref:`SceneTree <class_SceneTree>`.
 
 Each node has a ``multiplayer`` property, which is a reference to the ``MultiplayerAPI`` instance configured for it
 by the scene tree. Initially, every node is configured with the same default ``MultiplayerAPI`` object.

tutorials/networking/websocket.rst

@@ -20,7 +20,10 @@ Godot supports WebSocket in both native and HTML5 exports.
 Using WebSocket in Godot
 ------------------------
 
-WebSocket is implemented in Godot via :ref:`WebSocketPeer <class_WebSocketPeer>`. The WebSocket implementation is compatible with the High Level Multiplayer. See section on :ref:`high-level multiplayer <doc_high_level_multiplayer>` for more details.
+WebSocket is implemented in Godot via :ref:`WebSocketPeer <class_WebSocketPeer>`.
+The WebSocket implementation is compatible with the High-Level Multiplayer. See
+section on :ref:`high-level multiplayer <doc_high_level_multiplayer>` for more
+details.
 
 .. warning::
 
@@ -161,4 +164,7 @@ This will print (when a client connects) something similar to this:
 Advanced chat demo
 ^^^^^^^^^^^^^^^^^^
 
-A more advanced chat demo which optionally uses the multiplayer mid-level abstraction and a high level multiplayer demo are available in the `godot demo projects <https://github.com/godotengine/godot-demo-projects>`_ under `networking/websocket_chat` and `networking/websocket_multiplayer`.
+A more advanced chat demo which optionally uses the multiplayer mid-level
+abstraction and a high-level multiplayer demo are available in the
+`godot demo projects <https://github.com/godotengine/godot-demo-projects>`_
+under `networking/websocket_chat` and `networking/websocket_multiplayer`.

tutorials/performance/using_servers.rst

@@ -5,7 +5,7 @@
 Optimization using Servers
 ==========================
 
-Engines like Godot provide increased ease of use thanks to their high level constructs and features.
+Engines like Godot provide increased ease of use thanks to their high-level constructs and features.
 Most of them are accessed and used via the :ref:`Scene System<doc_scene_tree>`. Using nodes and
 resources simplifies project organization and asset management in complex games.
 
@@ -21,7 +21,7 @@ with signals, so no polling is required). Still, sometimes it can be. For exampl
 tens of thousands of instances for something that needs to be processed every frame can be a bottleneck.
 
 This type of situation makes programmers regret they are using a game engine and wish they could go
-back to a more handcrafted, low level implementation of game code.
+back to a more handcrafted, low-level implementation of game code.
 
 Still, Godot is designed to work around this problem.
 

tutorials/physics/ray-casting.rst

@@ -11,7 +11,7 @@ custom shaped object) and checking what it hits. This enables complex
 behaviors, AI, etc. to take place. This tutorial will explain how to
 do this in 2D and 3D.
 
-Godot stores all the low level game information in servers, while the
+Godot stores all the low-level game information in servers, while the
 scene is only a frontend. As such, ray casting is generally a
 lower-level task. For simple raycasts, nodes like
 :ref:`RayCast3D <class_RayCast3D>` and :ref:`RayCast2D <class_RayCast2D>`
@@ -24,7 +24,7 @@ so a way to do this by code must exist.
 Space
 -----
 
-In the physics world, Godot stores all the low level collision and
+In the physics world, Godot stores all the low-level collision and
 physics information in a *space*. The current 2d space (for 2D Physics)
 can be obtained by accessing
 :ref:`CanvasItem.get_world_2d().space <class_CanvasItem_method_get_world_2d>`.

tutorials/scripting/scene_tree.rst

@@ -32,11 +32,11 @@ level and when making games in Godot, writing your own MainLoop seldom makes sen
 SceneTree
 ---------
 
-One of the ways to explain how Godot works is that it's a high level
-game engine over a low level middleware.
+One of the ways to explain how Godot works is that it's a high-level
+game engine over a low-level middleware.
 
 The scene system is the game engine, while the :ref:`OS <class_OS>`
-and servers are the low level API.
+and servers are the low-level API.
 
 The scene system provides its own main loop to OS,
 :ref:`SceneTree <class_SceneTree>`.